GNOME Bugzilla – Bug 784989
qtdemux: cannot play file downloaded from vimeo: no valid frames found
Last modified: 2018-09-09 02:17:58 UTC
I cannot play a file I downloaded from vimeo using gst-play-1.0 (or totem). I can play the file fine using VLC or ffplay from ffmpeg. I have the gstreamer1.0-libav package installed (it is built against ffmpeg on Debian). I am using gstreamer1.0-libav/gstreamer1.0-plugins-base-apps 1.12.1-1 on Debian stretch. $ youtube-dl --hls-prefer-native --prefer-ffmpeg --format best https://vimeo.com/9827433 $ gst-play-1.0 Zendegi-9827433.mp4 Press 'k' to see a list of keyboard shortcuts. Now playing /home/pabs/Zendegi-9827433.mp4 Redistribute latency... ERROR No valid frames decoded before end of stream for file:///home/pabs/Zendegi-9827433.mp4 ERROR debug information: gstaudiodecoder.c(2261): gst_audio_decoder_sink_eventfunc (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/avdec_aac:avdec_aac0: no valid frames found Reached end of play list. $ gst-discoverer-1.0 -v Zendegi-9827433.mp4 Analyzing file:///home/pabs/Zendegi-9827433.mp4 Done discovering file:///home/pabs/Zendegi-9827433.mp4 An error was encountered while discovering the file No valid frames decoded before end of stream $ gst-typefind-1.0 Zendegi-9827433.mp4 Zendegi-9827433.mp4 - video/quicktime, variant=(string)iso $ ffprobe Zendegi-9827433.mp4 ffprobe version 3.2.6-1+b3 Copyright (c) 2007-2017 the FFmpeg developers built with gcc 6.3.0 (Debian 6.3.0-19) 20170618 configuration: --prefix=/usr --extra-version=1+b3 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libebur128 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared libavutil 55. 34.101 / 55. 34.101 libavcodec 57. 64.101 / 57. 64.101 libavformat 57. 56.101 / 57. 56.101 libavdevice 57. 1.100 / 57. 1.100 libavfilter 6. 65.100 / 6. 65.100 libavresample 3. 1. 0 / 3. 1. 0 libswscale 4. 2.100 / 4. 2.100 libswresample 2. 3.100 / 2. 3.100 libpostproc 54. 1.100 / 54. 1.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Zendegi-9827433.mp4': Metadata: major_brand : iso5 minor_version : 512 compatible_brands: iso6mp41 encoder : Lavf57.75.100 Duration: 00:01:06.12, start: 0.000000, bitrate: 2152 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 1974 kb/s, 24 fps, 24 tbr, 24k tbn, 48 tbc (default) Metadata: handler_name : VideoHandler Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 157 kb/s (default) Metadata: handler_name : SoundHandler
Could you make such a file available to us please?
Unfortunately I don't own the copyright on this video and it doesn't appear to be freely licensed and isn't available outside vimeo so I can't distribute it to you. You should be able to download it using the youtube-dl command listed above, or possibly one of the other video downloaders. It looks like the video is downloaded via the DASH protocol. https://wiki.debian.org/MultimediaFetchingTools $ youtube-dl https://vimeo.com/9827433 [vimeo] 9827433: Downloading webpage [vimeo] 9827433: Extracting information [vimeo] 9827433: Downloading webpage [vimeo] 9827433: Downloading JSON metadata [vimeo] 9827433: Downloading akfire_interconnect_quic m3u8 information [vimeo] 9827433: Downloading fastly_skyfire m3u8 information [vimeo] 9827433: Downloading akfire_interconnect_quic MPD information [vimeo] 9827433: Downloading akfire_interconnect_quic MPD information [vimeo] 9827433: Downloading fastly_skyfire MPD information [vimeo] 9827433: Downloading fastly_skyfire MPD information [dashsegments] Total fragments: 12 [download] Destination: Zendegi-9827433.mp4 [download] 100% of 16.97MiB in 00:17
I can reproduce this here, and it works fine with ffplay. youtube-dl is transcoding an HLS stream to MP4 btw.
For audio, a single 26 byte buffer is output. For video nothing is output ever. So likely a qtdemux problem.
Plays fine with current master.
And also with 1.14
I still experience this issue with gstreamer1.0-plugins-base-apps 1.14.2-1 from Debian buster.
What is the output of $ GST_DEBUG=2 gst-play-1.0 Zendegi-9827433.mp4
$ GST_DEBUG=2 gst-play-1.0 Zendegi-9827433.mp4 Press 'k' to see a list of keyboard shortcuts. Now playing /home/pabs/Zendegi-9827433.mp4 0:00:00.160817739 31011 0x562b75c756d0 WARN basesrc gstbasesrc.c:3583:gst_base_src_start_complete:<source> pad not activated yet 0:00:00.161339432 31011 0x562b75c756d0 WARN basesrc gstbasesrc.c:3583:gst_base_src_start_complete:<source> pad not activated yet 0:00:00.211254064 31011 0x562b75e091e0 WARN qtdemux qtdemux_types.c:233:qtdemux_type_get: unknown QuickTime node type pasp Redistribute latency... 0:00:01.890851116 31011 0x562b75f74990 WARN audiodecoder gstaudiodecoder.c:1596:gst_audio_decoder_drain:<avdec_aac0> still 1 frames left after draining 0:00:01.890887951 31011 0x562b75f74990 WARN audiodecoder gstaudiodecoder.c:2263:gst_audio_decoder_sink_eventfunc:<avdec_aac0> error: No valid frames decoded before end of stream 0:00:01.890898646 31011 0x562b75f74990 WARN audiodecoder gstaudiodecoder.c:2263:gst_audio_decoder_sink_eventfunc:<avdec_aac0> error: no valid frames found ERROR No valid frames decoded before end of stream for file:///home/pabs/Zendegi-9827433.mp4 ERROR debug information: gstaudiodecoder.c(2263): gst_audio_decoder_sink_eventfunc (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/avdec_aac:avdec_aac0: no valid frames found 0:00:01.892080112 31011 0x562b75e10ed0 WARN videodecoder gstvideodecoder.c:1161:gst_video_decoder_sink_event_default:<avdec_h264-0> error: No valid frames decoded before end of stream 0:00:01.892104396 31011 0x562b75e10ed0 WARN videodecoder gstvideodecoder.c:1161:gst_video_decoder_sink_event_default:<avdec_h264-0> error: no valid frames found Reached end of play list.
Created attachment 373445 [details] debug output Added the same content as a file so that line wrapping is avoided.
Do you have aacparse installed ? If you do and it still fails, the only last culprit would be a gst-libav compiled with system-wide ffmpeg (and therefore not supported).
I'm not entirely sure but I think these indicate that I do: $ strings /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstaudioparsers.so | grep aacparse gstaacparse.c aacparse https://buildd.debian.org/status/fetch.php?pkg=gst-plugins-good1.0&arch=i386&ver=1.14.2-1&stamp=1532352484&raw=0 Debian tends to compile things against system libraries, especially ffmpeg, since it has a lot of security issues and updating embedded code copies for that is tedious when there are a lot of code copies. $ lddtree /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so | grep libav libgstlibav.so => /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so (interpreter => none) libavfilter.so.7 => /usr/lib/x86_64-linux-gnu/libavfilter.so.7 libavformat.so.58 => /usr/lib/x86_64-linux-gnu/libavformat.so.58 libavcodec.so.58 => /usr/lib/x86_64-linux-gnu/libavcodec.so.58 libavutil.so.56 => /usr/lib/x86_64-linux-gnu/libavutil.so.56
Ok, then you'll have to refer this issue to your distribution. We don't support versions of gst-libav built that way.
Are there any changes to the gstreamer fork of ffmpeg that might be responsible for this feature working with your version of ffmpeg but not with the standard version? PS: Debian is using gstreamer1.0-libav version 1.15.0.1+git20180723+db823502-1 (and ffmpeg 4.0.2), which version of it did you test with?
I've just tested against Fedora/RPMFusion shipped ffmpeg 4.0.2 and this movie works fine.
And we don't apply any patches to FFMPEG, we are current set on 4.0.2 release.
Could you attach the debug output requested above so I can compare the results with Debian's output? Which version of gstreamer and gstreamer1.0-libav did you test against?
The file as created by youtube-dl plays fine for me on Debian with these exact same versions (Debian maintainer of those packages here).
Could you attach the debug output requested above? Also an strace might be useful. I've just tried this with a new user and a new install but the results are the same. I wonder if I'm missing some optional package that would explain this.
A level-2 debug log is not very useful, but here it is. 0:00:00.017210761 17653 0x55931700cf00 WARN basesrc gstbasesrc.c:3583:gst_base_src_start_complete:<source> pad not activated yet 0:00:00.017421854 17653 0x55931700cf00 WARN basesrc gstbasesrc.c:3583:gst_base_src_start_complete:<source> pad not activated yet 0:00:00.025884833 17653 0x7f0bc81a5e30 WARN qtdemux qtdemux_types.c:233:qtdemux_type_get: unknown QuickTime node type pasp 0:00:00.025901983 17653 0x7f0bc81a5e30 WARN qtdemux qtdemux_types.c:233:qtdemux_type_get: unknown QuickTime node type sgpd 0:00:00.025905831 17653 0x7f0bc81a5e30 WARN qtdemux qtdemux_types.c:233:qtdemux_type_get: unknown QuickTime node type sbgp 0:00:00.025917508 17653 0x7f0bc81a5e30 WARN qtdemux qtdemux.c:3031:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 1 0:00:00.025970308 17653 0x7f0bc81a5e30 WARN qtdemux qtdemux.c:3031:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 2 0:00:00.026014481 17653 0x7f0bc81a5e30 WARN basesrc gstbasesrc.c:2445:gst_base_src_update_length:<source> processing at or past EOS Can you provide a log with GST_DEBUG=6 from the problem you're running into?
Created attachment 373470 [details] debug output at level 6 Attached the level 6 debug. Please note that it contains terminal colour code escapes so you will need to view it with `less -R` or strip them using ansi2txt from the Debian colorized-logs package.
Ok so this fails simply because avdec_aac can't decode any of the AAC frames, and that's working fine for me. What version of gstreamer1.0-libav do you have installed, and which of libavcodec58?
gstreamer1.0-libav 1.15.0.1+git20180723+db823502-1 and libavcodec58 7:4.0.2-1+b1
Same here. Maybe our versions of youtube-dl get us different files? $ md5sum Zendegi-9827433.mp4 f267346569716f8aeafbe0673236acae Zendegi-9827433.mp4
I have a different file, but if I re-download it with youtube-dl 2018.06.18-1.1 I get the same file: $ md5sum Zendegi-9827433.mp4 06118309ee9748bc1ab1bc38d8ef39db Zendegi-9827433.mp4 However, when I use youtube-dl 2018.06.18-1.1 without my set of arguments I get your file and playing that works: $ youtube-dl https://vimeo.com/9827433 [vimeo] 9827433: Downloading webpage [vimeo] 9827433: Extracting information [vimeo] 9827433: Downloading webpage [vimeo] 9827433: Downloading JSON metadata [vimeo] 9827433: Downloading akfire_interconnect_quic m3u8 information [vimeo] 9827433: Downloading fastly_skyfire m3u8 information [vimeo] 9827433: Downloading akfire_interconnect_quic MPD information [vimeo] 9827433: Downloading akfire_interconnect_quic MPD information [vimeo] 9827433: Downloading fastly_skyfire MPD information [vimeo] 9827433: Downloading fastly_skyfire MPD information [dashsegments] Total fragments: 12 [download] Destination: Zendegi-9827433.fdash-fastly_skyfire_sep-video-16680098.mp4 [download] 100% of 15.73MiB in 00:36 [dashsegments] Total fragments: 12 [download] Destination: Zendegi-9827433.fdash-fastly_skyfire_sep-audio-16680098.m4a [download] 100% of 1.24MiB in 00:07 [ffmpeg] Merging formats into "Zendegi-9827433.mp4" Deleting original file Zendegi-9827433.fdash-fastly_skyfire_sep-video-16680098.mp4 (pass -k to keep) Deleting original file Zendegi-9827433.fdash-fastly_skyfire_sep-audio-16680098.m4a (pass -k to keep) pabs@chianamo ~ $ gst-play-1.0 Zendegi-9827433.mp4 Press 'k' to see a list of keyboard shortcuts. Now playing /home/pabs/Zendegi-9827433.mp4 Redistribute latency... Redistribute latency... Redistribute latency... 0:00:01.1 / 0:01:06.0 pabs@chianamo ~ $ md5sum Zendegi-9827433.mp4* f267346569716f8aeafbe0673236acae Zendegi-9827433.mp4 If I pass the extra arguments I mentioned above to youtube-dl then I get a file that works in vlc/ffplay but not in gst-play: $ youtube-dl --hls-prefer-native --prefer-ffmpeg --format best https://vimeo.com/9827433 [vimeo] 9827433: Downloading webpage [vimeo] 9827433: Extracting information [vimeo] 9827433: Downloading webpage [vimeo] 9827433: Downloading JSON metadata [vimeo] 9827433: Downloading akfire_interconnect_quic m3u8 information [vimeo] 9827433: Downloading fastly_skyfire m3u8 information [vimeo] 9827433: Downloading akfire_interconnect_quic MPD information [vimeo] 9827433: Downloading akfire_interconnect_quic MPD information [vimeo] 9827433: Downloading fastly_skyfire MPD information [vimeo] 9827433: Downloading fastly_skyfire MPD information [dashsegments] Total fragments: 12 [download] Destination: Zendegi-9827433.mp4 [download] 100% of 16.97MiB in 00:32 $ md5sum Zendegi-9827433.mp4 06118309ee9748bc1ab1bc38d8ef39db Zendegi-9827433.mp4
That one can indeed be played with GIT master but not with the packages in Debian. Must be missing a patch or so.
Ok unrelated to gst-libav but definitely fixed in GIT master. Using GIT master of everything and using gst-libav from Debian works fine. In aacparse there are no changes apart from a memory leak fix. So someone would have to properly bisect this to find the change that fixed it.
I have bisected this and found the following commit in gst-plugins-good fixes the issue. Unfortunately it does not apply to the stable release in Debian. commit 025a430d0861bdbc3d8221bddeaa2adae85bfc3e (HEAD, refs/bisect/working) Author: Alicia Boya García <aboya@igalia.com> Date: Sat Jun 9 23:58:01 2018 +0200 qtdemux: rework segment event pushing, again This patch aims at fixing the recent regressions in the adaptive test suite. All segment pushing in push mode is now done with gst_qtdemux_check_send_pending_segment(), which is idempotent and handles both edit lists cases and cases where the upstream TIME segments have to be sent directly. Fragmented files that start with a non-zero tfdt are also taken into account, but their handling has been vastly simplified: now they are handled as implicit default seeks so there is no need to extend the GstSegment formulas as was being done before. qtdemux->segment.duration is no longer modified when upstream_format_is_time, respecting in this way the durations provided by dashdemux and fixing bugs in reverse playback tests where mangled durations appeared in the emitted segments. https://bugzilla.gnome.org/show_bug.cgi?id=752603
So now that the commit has been bisected, where do we go from here? Should the commit be backported to the stable branch? Should git master just become the new stable branch?