GNOME Bugzilla – Bug 640589
matroskademux: set streamheader on vorbis/theora srcpad caps for easier remuxing
Last modified: 2012-10-30 23:46:49 UTC
I tried to stream webm from ffmpeg to gstreamer, using this command: ffmpeg -f x11grab -s 1280x1024 -r 15 -i :0.0 -f alsa -i default -vcodec libvpx -b 420k -minrate 420k -maxrate 420k -bufsize 835k -s 640x512 -g 30 -acodec libvorbis -ab 64000 -ac 1 -f webm - | gst-launch-0.10 filesrc location=/dev/stdin ! matroskademux name=demux ! queue ! webmmux name=mux streamable=true ! gdppay ! tcpserversink, host=127.0.0.1 demux.audio_0 ! multiqueue ! mux.audio_0 the result is an invalid vorbis header error: FFmpeg version SVN-r26402, Copyright (c) 2000-2011 the FFmpeg developers built on Jan 21 2011 19:41:34 with gcc 4.4.4 configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --mandir=/usr/share/man --enable-static --enable-shared --cc=x86_64-pc-linux-gnu-gcc --enable-gpl --enable-version3 --enable-postproc --enable-avfilter --disable-stripping --disable-debug --disable-doc --disable-static --disable-optimizations --enable-runtime-cpudetect --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --disable-indev=v4l --disable-indev=v4l2 --disable-indev=oss --enable-x11grab --disable-outdev=oss --enable-pthreads --enable-libdirac --enable-librtmp --enable-libspeex --enable-libvpx --enable-libopenjpeg --disable-altivec --cpu=amdfam10 --enable-hardcoded-tables libavutil 50.36. 0 / 50.36. 0 libavcore 0.16. 1 / 0.16. 1 libavcodec 52.108. 0 / 52.108. 0 libavformat 52.93. 0 / 52.93. 0 libavdevice 52. 2. 3 / 52. 2. 3 libavfilter 1.74. 0 / 1.74. 0 libswscale 0.12. 0 / 0.12. 0 libpostproc 51. 2. 0 / 51. 2. 0 [x11grab @ 0x640d00] device: :0.0 -> display: :0.0 x: 0 y: 0 width: 1280 height: 1024 [x11grab @ 0x640d00] shared memory extension found Leitung wird auf PAUSIERT gesetzt ... Leitung läuft vor … [x11grab @ 0x640d00] Estimating duration from bitrate, this may be inaccurate Input #0, x11grab, from ':0.0': Duration: N/A, start: 1295884126.689013, bitrate: 629145 kb/s Stream #0.0: Video: rawvideo, bgra, 1280x1024, 629145 kb/s, 15 tbr, 1000k tbn, 15 tbc [alsa @ 0x6506a0] capture with some ALSA plugins, especially dsnoop, may hang. [alsa @ 0x6506a0] Estimating duration from bitrate, this may be inaccurate Input #1, alsa, from 'default': Duration: N/A, start: 1295884126.706427, bitrate: N/A Stream #1.0: Audio: pcm_s16le, 44100 Hz, 1 channels, s16, 705 kb/s [buffer @ 0x6734b0] w:1280 h:1024 pixfmt:bgra [scale @ 0x68f300] w:1280 h:1024 fmt:bgra -> w:640 h:512 fmt:yuv420p flags:0x4 [libvpx @ 0x64f8f0] v0.9.5 Output #0, webm, to 'pipe:': Metadata: encoder : Lavf52.93.0 Stream #0.0: Video: libvpx, yuv420p, 640x512, q=2-31, 420 kb/s, 1k tbn, 15 tbc Stream #0.1: Audio: libvorbis, 44100 Hz, 1 channels, s16, 64 kb/s Stream mapping: Stream #0.0 -> #0.0 Stream #1.0 -> #0.1 Press [q] to stop encoding FEHLER: Von Element /GstPipeline:pipeline0/GstWebMMux:mux: Der Datenstrom konnte nicht multiplext werden. Zusätzliche Fehlerdiagnoseinformation: matroska-mux.c(1547): gst_matroska_mux_audio_pad_setcaps (): /GstPipeline:pipeline0/GstWebMMux:mux: vorbis stream headers missing or malformed FEHLER: Leitung läuft nicht vor. Leitung wird auf NULL gesetzt ... Leitung wird geleert When removing the audio part and remuxing only the video, it works. Even simply saving the webm to a file ffmpeg -f x11grab -s 1280x1024 -r 15 -i :0.0 -f alsa -i default -vcodec libvpx -b 420k -minrate 420k -maxrate 420k -bufsize 835k -s 640x512 -g 30 -acodec libvorbis -ab 64000 -ac 1 -f webm - | gst-launch-0.10 filesrc location=/dev/stdin ! queue ! filesink location=/data/test3.webm results into a not valid webm file ./mkvalidator --details /data/test3.webmERR0C2: The timecode of the Cluster at 46225 is not incrementing WRN0C0: First Block for video track #1 in Cluster at 46225 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 76805 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 109721 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 179114 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 224566 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 257448 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 308976 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 356695 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 397164 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 420759 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 453680 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 514109 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 557515 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 590351 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 627573 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 682634 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 735132 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 775979 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 813478 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 869347 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 903871 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 921525 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 932792 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 972263 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1006105 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1023530 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1039998 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1079491 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1113718 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1131047 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1186514 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1221165 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1244054 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1257762 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1298679 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1336815 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1358267 is not a keyframe WRN0C0: First Block for video track #1 in Cluster at 1431190 is not a keyframe WRN800: The segment has Clusters but no Cues section (bad for seeking) . file created with Lavf52.93.0 / Lavf52.93.0 Everthing running on x86_64 Gentoo, gstreamer-0.10.32, gst-plugins-good-0.10.27
matroskamux looks for streamheader structure in the caps for some mime types, audio/x-vorbis being one, it will not proceed if not set. vorbisenc sets streamheader in the caps. matroskademux pushes stream headers as a buffer, once that buffer has been consumed elements added to a dynamic pipeline will not have access to the stream headers. Should matroskademux set the streamheader structure in the caps? I have no experience with gstreamer code base. I see the resolution of this issue as critical for streaming of webm and mkv to work properly with GStreamer. Curiously oggdemux sets streamheader in the caps, that could serve as a basis for a fix.
I'm not sure either whether matroskademux should, but adding 'vorbisparse' in the audio part of the pipeline should fix the issue.
(In reply to comment #2) > I'm not sure either whether matroskademux should, but adding 'vorbisparse' in > the audio part of the pipeline should fix the issue. Where exactly should it be added? I tried it in several variations, but none fixed the problem.
Have you tried changing: demux.audio_0 ! multiqueue ! mux.audio_0 to: demux.audio_0 ! vorbisparse ! multiqueue ! mux.audio_0 or: demux.audio_0 ! multiqueue ! vorbisparse ! mux.audio_0 ? One of the things vorbisparse does is adding headers on caps.
As matroska has the stream header for all the Xiph formats in the headers it can and should add them to the caps. It doesn't require much work and will make usage of the demuxer output easier. Your comment about vorbisparse is correct though, as a workaround this should work just fine.
*** Bug 681201 has been marked as a duplicate of this bug. ***
*** Bug 683895 has been marked as a duplicate of this bug. ***
I'll have a look at this.
Created attachment 225301 [details] [review] matroskademux: put streamheaders on vorbis/speex/flac/theora caps to make remuxing work Only tested with vorbis so far. Needs testing with speex, flac and theora as well.
Ok, testing remux of Matroska vorbis track to Ogg, and it now works with this patch.