[FFmpeg-trac] #8561(avformat:new): "URL read error: End of file" when http_persistent enabled

[FFmpeg]

#8561: "URL read error: End of file" when http_persistent enabled
-------------------------------------+------------------------------------
             Reporter:  vschweitzer  |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  http         |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+------------------------------------
Changes (by cehoyos):

 * component:  undetermined => avformat


Old description:

> When streaming via HLS to a HTTP server while http_persistent
> is enabled, some segments will fail to upload with the error
> {{{
> [http @ 0000023db7ff2140] URL read error: End of file
> [hls @ 0000023db85f0200] upload segment failed, will retry with a new
> http session.
> }}}
>
> The command line used to reproduce the output above is
> {{{
> ffmpeg -y -f lavfi -i color=c=black:s=1920x1080:r=25 -vcodec libx264 -f
> hls -http_persistent 1 http://127.0.0.1:45000/streams/index.m3u8
> }}}
> The error should occur after approximately 50 requests.
>
> This behavior was tested with both Apache and NGINX.
> NGINX was configured in the following way:
>
> In front of "server {...}":
> {{{
> map $request_method $my_proxy_method {
>   default $request_method;
>   POST PUT;
> }
> }}}
>
> In "server {...}":
> {{{
> location /streams/ {
>     proxy_pass http://127.0.0.1:45000/test/;
>     proxy_method $my_proxy_method;
>     proxy_ignore_client_abort on;
> }
>
> location /test/ {
>     root   html;
>     index  index.html index.htm;
>     dav_methods PUT DELETE MKCOL COPY MOVE;
>     dav_access all:rw;
>     create_full_put_path on;
>     client_max_body_size 10000m;
> }
> }}}
>
> As FFmpeg sometimes uses POST requests even if PUT is explicitly
> specified, POST requests are mapped to PUT. This requires a
> new request, which is why the server creates a new request
> to itself to a new directory when receiving a request to
> /streams/.
>
> On a possibly related note, the NGINX log reports a strange
> looking request at the time of the FFmpeg error:
> {{{
> 127.0.0.1 - - [09/Mar/2020:10:48:26 +0000] "PUT /streams/index54.ts
> HTTP/1.1" 201 0 "-" "Lavf/58.35.104"
> 127.0.0.1 - - [09/Mar/2020:10:48:26 +0000] "PUT /test/index54.ts
> HTTP/1.0" 201 0 "-" "Lavf/58.35.104"
> 127.0.0.1 - - [09/Mar/2020:10:48:26 +0000] "0" 400 157 "-" "-"
> }}}
>
> Although possibly related, this bug is not the same as
> [ticket:#8546 "http_persistent not honored when encryption is enabled"].

New description:

 When streaming via HLS to a HTTP server while http_persistent
 is enabled, some segments will fail to upload with the error
 {{{
 [http @ 0000023db7ff2140] URL read error: End of file
 [hls @ 0000023db85f0200] upload segment failed, will retry with a new http
 session.
 }}}

 The command line used to reproduce the output above is
 {{{
 ffmpeg -y -f lavfi -i color=c=black:s=1920x1080:r=25 -vcodec libx264 -f
 hls -http_persistent 1 http://127.0.0.1:45000/streams/index.m3u8
 }}}
 The error should occur after approximately 50 requests.

 This behavior was tested with both Apache and NGINX.
 NGINX was configured in the following way:

 In front of "server {...}":
 {{{
 map $request_method $my_proxy_method {
   default $request_method;
   POST PUT;
 }
 }}}

 In "server {...}":
 {{{
 location /streams/ {
     proxy_pass http://127.0.0.1:45000/test/;
     proxy_method $my_proxy_method;
     proxy_ignore_client_abort on;
 }

 location /test/ {
     root   html;
     index  index.html index.htm;
     dav_methods PUT DELETE MKCOL COPY MOVE;
     dav_access all:rw;
     create_full_put_path on;
     client_max_body_size 10000m;
 }
 }}}

 As FFmpeg sometimes uses POST requests even if PUT is explicitly
 specified, POST requests are mapped to PUT. This requires a
 new request, which is why the server creates a new request
 to itself to a new directory when receiving a request to
 /streams/.

 On a possibly related note, the NGINX log reports a strange
 looking request at the time of the FFmpeg error:
 {{{
 127.0.0.1 - - [09/Mar/2020:10:48:26 +0000] "PUT /streams/index54.ts
 HTTP/1.1" 201 0 "-" "Lavf/58.35.104"
 127.0.0.1 - - [09/Mar/2020:10:48:26 +0000] "PUT /test/index54.ts HTTP/1.0"
 201 0 "-" "Lavf/58.35.104"
 127.0.0.1 - - [09/Mar/2020:10:48:26 +0000] "0" 400 157 "-" "-"
 }}}

 Although possibly related, this bug is not the same as
 ticket #8546.

--

--
Ticket URL: <https://trac.ffmpeg.org/ticket/8561#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker