[FFmpeg-trac] #10014(avformat:new): ffmpeg does not report upload failures when PUTting content to remote a remote WebDAV server
FFmpeg
trac at avcodec.org
Tue Nov 8 17:10:57 EET 2022
#10014: ffmpeg does not report upload failures when PUTting content to remote a
remote WebDAV server
-------------------------------------+-------------------------------------
Reporter: | Owner: (none)
anonymous_coward |
Type: defect | Status: new
Priority: normal | Component: avformat
Version: git-master | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Description changed by anonymous_coward:
Old description:
> Summary of the bug:
> ffmpeg does not report upload failures when PUTting content to remote 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@sexample.com/stream1.ts' for writing
> }}}
New description:
Summary of the bug:
ffmpeg does not report upload failures when PUTting content to remote 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
}}}
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/10014#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list