Opened 4 months ago

Last modified 4 months ago

#9444 new defect

No errors when a live stream is pushed to an invalid http endpoint

Reported by: damiano.falcioni Owned by:
Priority: normal Component: avformat
Version: 4.2.4 Keywords: http 404
Cc: damiano.falcioni Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
When a live stream is sent to an http endpoint that does not exist (http status 404) or, more in general, that return an http error code, FFMPEG does not terminate with an error but continue to push data.

How to reproduce:

% ffmpeg -report -f v4l2 -i /dev/video0 -f mjpeg https://innovation-laboratory.org/404

ffmpeg version 4.2.4-1ubuntu0.1
built with gcc 9 (Ubuntu 9.3.0-10ubuntu2)
 and also with 
ffmpeg version 4.4-full_build
built with gcc 10.2.0 (Rev6, Built by MSYS2 project)

The same behaviour occur for:

% ffmpeg -report -f v4l2 -i /dev/video0 -f mjpeg https://github.com/404

but for some reason this work as expected and terminate with an error:

% ffmpeg -report -f v4l2 -i /dev/video0 -f mjpeg https://www.google.com/404

The issue does not occur when the input is not live, like a mjpeg or any other supported file; this is why I tested using the stream from a connected webcam.
Same behaviour can be reproduced on Windows OS using the dshow input.

Attachments (3)

ffmpeg-error1.log (27.5 KB ) - added by damiano.falcioni 4 months ago.
ffmpeg-error2.log (27.6 KB ) - added by damiano.falcioni 4 months ago.
ffmpeg-ok.log (21.8 KB ) - added by damiano.falcioni 4 months ago.

Download all attachments as: .zip

Change History (6)

by damiano.falcioni, 4 months ago

Attachment: ffmpeg-error1.log added

by damiano.falcioni, 4 months ago

Attachment: ffmpeg-error2.log added

by damiano.falcioni, 4 months ago

Attachment: ffmpeg-ok.log added

comment:1 by damiano.falcioni, 4 months ago

Summary: No errors on live stream push to invalid http endpointNo errors when a live stream is pushed to an invalid http endpoint

comment:2 by Brad Isbell, 4 months ago

FFmpeg doesn't send the Expect: 100-continue message. Therefore, it is not possible for FFmpeg to know if there is a 404 or some other error status code, as the server isn't allowed to respond until the entire request body is sent. So, in the case of an indefinite length stream, such as your webcam, the HTTP request just continues running unless the server closes the underlying socket.

So, I think what you're asking for is an enhancement to add support for 100 Continue responses, and for Expect: 100-continue to be added by default to HTTP requests. (And, it'd be good to verify that this doesn't mess up Icecast connections.)

in reply to:  2 comment:3 by damiano.falcioni, 4 months ago

Replying to Brad Isbell:

FFmpeg doesn't send the Expect: 100-continue message. Therefore, it is not possible for FFmpeg to know if there is a 404 or some other error status code, as the server isn't allowed to respond until the entire request body is sent. So, in the case of an indefinite length stream, such as your webcam, the HTTP request just continues running unless the server closes the underlying socket.

So, I think what you're asking for is an enhancement to add support for 100 Continue responses, and for Expect: 100-continue to be added by default to HTTP requests. (And, it'd be good to verify that this doesn't mess up Icecast connections.)

Hi Brad, thanks for the suggestion.
I see that there is already the parameter -send_expect_100 so I tried:

% ffmpeg -loglevel trace -f v4l2 -i /dev/video0 -f mjpeg -send_expect_100 1 http://example.com/404

output:

...
[http @ 0x55ba4110be40] request: POST /404 HTTP/1.1
Transfer-Encoding: chunked
User-Agent: Lavf/58.29.100
Accept: */*
Expect: 100-continue
Connection: close
Host: example.com
Icy-MetaData: 1


[http @ 0x55ba4110be40] header='HTTP/1.1 100 Continue'
[http @ 0x55ba4110be40] http_code=100
[http @ 0x55ba4110be40] header=''
Successfully opened the file.

....

So I think FFMPEG handle it correctly, and the problem is on the web server that return HTTP/1.1 100 Continue also on 404 pages (I checked already this with Wireshark).
This looks a quite common problem because occur on sites like example.com, github.com, and also on my innovation-laboratory.org (based on apache 2.4.29), but not on google.com.
I will further investigate.

Note: See TracTickets for help on using tickets.