Opened 18 months ago
Last modified 12 months ago
#10014 new defect
ffmpeg does not report upload failures when PUTting content to a remote WebDAV server
Reported by: | anonymous_coward | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | git-master | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description (last modified by )
Summary of the bug:
ffmpeg does not report upload failures when PUTting content to a remote WebDAV server.
I'm trying to send HLS content to a remote server using ffmpeg. The server requires Digest authentication. Credentials are provided in the URL, which ffmpeg correctly extracts.
ffmpeg opens the connection and sends the request headers, including Expect: 100 Continue, but obviously cannot include the Authorization header at this point. The server responds 100 Continue (rather than eg a 401 Unauthorized), so ffmpeg assumes no auth is needed and continues to send the body.
Once the request is complete, the server makes a final response with 401 Unauthorized but it seems that, once the connection is opened and 100 is received, ffmpeg no longer cares for the rest of the response and never checks again (it's just flushed when the connection is closed) so it doesn't see that the request failed, and it doesn't retry with the provided digest parameters.
I am aware that the server should probably respond to the Expect with 401 Unauthorized, but it also seems to me that ffmpeg ought to consume the server's final response and see that the request ultimately failed for some reason and report that back, instead of just assuming everything was successful. Ideally ffmpeg would then retry with the relevant authorization.
How to reproduce:
ffmpeg -re -stream_loop -1 -i example.avi -c:v:2 libx264 -x264-params "nal-hrd=cbr:force-cfr=1" -b:v 1M -maxrate:v 1M -minrate:v 1M -bufsize:v 1M -preset ultrafast -g 30 -sc_threshold 0 -keyint_min 30 -c:a:0 aac -b:a:0 96k -ac 2 -f hls -hls_list_size 10 -hls_time 2 "https://username:password@example.com/stream.m3u8" ffmpeg version N-109029-g1800a0da09 Copyright (c) 2000-2022 the FFmpeg developers built with gcc 9 (Ubuntu 9.4.0-1ubuntu1~20.04) configuration: --enable-gpl --enable-static --enable-libsrt --enable-libx264 --enable-gnutls --extra-libs='-lpthread -lm' --ld=g++ libavutil 57. 42.100 / 57. 42.100 libavcodec 59. 52.100 / 59. 52.100 libavformat 59. 34.101 / 59. 34.101 libavdevice 59. 8.101 / 59. 8.101 libavfilter 8. 50.100 / 8. 50.100 libswscale 6. 8.112 / 6. 8.112 libswresample 4. 9.100 / 4. 9.100 libpostproc 56. 7.100 / 56. 7.100 [avi @ 0x7ffff574ebc0] non-interleaved AVI Input #0, avi, from 'example.avi': Metadata: software : MEncoder 1.5-7 Duration: 00:10:34.53, start: 0.000000, bitrate: 15032 kb/s Stream #0:0: Video: h264 (High) (h264 / 0x34363268), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 15018 kb/s, 60 fps, 60 tbr, 60 tbn Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) Press [q] to stop, [?] for help [libx264 @ 0x7ffff57709c0] using SAR=1/1 [libx264 @ 0x7ffff57709c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 [libx264 @ 0x7ffff57709c0] profile Constrained Baseline, level 4.2 [libx264 @ 0x7ffff57709c0] 264 - core 155 r2917 0a84d98 - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=30 keyint_min=16 scenecut=0 intra_refresh=0 rc_lookahead=0 rc=cbr mbtree=0 bitrate=1000 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=1000 vbv_bufsize=1000 nal_hrd=cbr filler=1 ip_ratio=1.40 aq=0 [hls muxer @ 0x7ffff57fa040] No HTTP method set, hls muxer defaulting to method PUT. Output #0, hls, to 'https://username:password@example.com/stream.m3u8': Metadata: software : MEncoder 1.5-7 encoder : Lavf59.34.101 Stream #0:0: Video: h264, yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 1000 kb/s, 60 fps, 90k tbn Metadata: encoder : Lavc59.52.100 libx264 Side data: cpb: bitrate max/min/avg: 1000000/0/1000000 buffer size: 1000000 vbv_delay: N/A [hls @ 0x7ffff5755f00] Opening 'https://username:password@example.com/stream0.ts' for writing [https @ 0x7ffab0004480] Opening 'https://username:password@example.com/stream.m3u8' for writing [https @ 0x7ffab0004480] Opening 'https://username:password@example.com/stream1.ts' for writing
Change History (4)
comment:1 by , 18 months ago
Description: | modified (diff) |
---|
comment:2 by , 18 months ago
Description: | modified (diff) |
---|---|
Summary: | ffmpeg does not report upload failures when PUTting content to remote a remote WebDAV server → ffmpeg does not report upload failures when PUTting content to a remote WebDAV server |
comment:3 by , 18 months ago
comment:4 by , 12 months ago
Hello, I am having a similar issue when trying to push hls segments via POST requests to a remote server with the http_persistent option. Since ffmpeg doesn't check the responses after the first one, it cannot catch http errors. Additionally, my server won't write the last few segments to disk because ffmpeg's process is already down and not listening to its responses anymore.
Did you ever find a workaround for this problem?
Thanks!
Further data point: if http_persistent option is set to 1 the receive buffer is not flushed, subsequent requests immediately consume the final response of the previous request (receiving the 401) rather than waiting for the 100 Continue as it should.
ffmpeg really needs to consume the final response at the end of each request.