After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 640589 - matroskademux: set streamheader on vorbis/theora srcpad caps for easier remuxing
matroskademux: set streamheader on vorbis/theora srcpad caps for easier remuxing
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.1.1
Assigned To: Tim-Philipp Müller
GStreamer Maintainers
: 681201 683895 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-01-25 21:56 UTC by Ralf
Modified: 2012-10-30 23:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
matroskademux: put streamheaders on vorbis/speex/flac/theora caps to make remuxing work (18.83 KB, patch)
2012-09-27 23:46 UTC, Tim-Philipp Müller
committed Details | Review

Description Ralf 2011-01-25 21:56:24 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
Comment 1 Devendra Tewari 2011-07-28 00:03:01 UTC
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.
Comment 2 Vincent Penquerc'h 2011-08-10 10:49:21 UTC
I'm not sure either whether matroskademux should, but adding 'vorbisparse' in the audio part of the pipeline should fix the issue.
Comment 3 Ralf 2011-08-10 17:15:57 UTC
(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.
Comment 4 Vincent Penquerc'h 2011-08-10 17:33:46 UTC
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.
Comment 5 Sebastian Dröge (slomo) 2011-08-11 07:12:05 UTC
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.
Comment 6 Tim-Philipp Müller 2012-08-09 09:08:08 UTC
*** Bug 681201 has been marked as a duplicate of this bug. ***
Comment 7 Tim-Philipp Müller 2012-09-23 19:07:36 UTC
*** Bug 683895 has been marked as a duplicate of this bug. ***
Comment 8 Tim-Philipp Müller 2012-09-27 08:56:22 UTC
I'll have a look at this.
Comment 9 Tim-Philipp Müller 2012-09-27 23:46:49 UTC
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.
Comment 10 Christian Fredrik Kalager Schaller 2012-10-01 12:18:30 UTC
Ok, testing remux of Matroska vorbis track to Ogg, and it now works with this patch.