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

[damiano.falcioni]

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.

[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.)

[damiano.falcioni]

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.