[gstreamer-bugs] [Bug 639848] [mpegtsmux] doesn't join an h264 and an audio ES

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=639848
  GStreamer | gst-plugins-bad | 0.10.20

--- Comment #6 from Fraxinas <andreas.frisch at multimedia-labs.de> 2011-01-20 15:06:11 UTC ---
i've discovered that when demuxing the m2ts and parsing the ac3-ES, there are
no more buffers produced by the parser after the first 2kb:

gst-launch -v filesrc location=test_h264_ac3.m2ts ! mpegtsdemux ! audio/x-ac3 !
ac3parse ! fakesink -v
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstMpegTSDemux:mpegtsdemux0: pat-info = ((GValueArray*)
0x4a5ba0)
/GstPipeline:pipeline0/GstMpegTSDemux:mpegtsdemux0: pmt-info =
((MpegTsPmtInfo*) 0x463060)
/GstPipeline:pipeline0/GstCapsFilter:capsfilter1: caps = audio/x-ac3
/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:src: caps = audio/x-ac3
/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:sink: caps =
audio/x-ac3
/GstPipeline:pipeline0/GstAc3Parse:ac3parse0.GstPad:sink: caps = audio/x-ac3
/GstPipeline:pipeline0/GstAc3Parse:ac3parse0.GstPad:sink: caps = audio/x-ac3
/GstPipeline:pipeline0/GstAc3Parse:ac3parse0.GstPad:src: caps = audio/x-ac3,
framed=(boolean)true, rate=(int)48000, channels=(int)2
/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = audio/x-ac3,
framed=(boolean)true, rate=(int)48000, channels=(int)2
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "preroll   *******
"
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "event   ******* E
(type: 102, GstEventNewsegment, update=(boolean)false, rate=(double)1,
applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME,
start=(gint64)104355555, stop=(gint64)-1, position=(gint64)104355555;)
0x4b5cc0"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
( 1024 bytes, timestamp: 0:00:00.104355555, duration: 0:00:00.032000000,
offset: 0, offset_end: -1, flags: 32) 0x4af468"
New clock: GstSystemClock
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
( 1024 bytes, timestamp: 0:00:00.136355555, duration: 0:00:00.032000000,
offset: 1024, offset_end: -1, flags: 0) 0x4af2c8"
Caught interrupt -- handling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 7740071000 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstAc3Parse:ac3parse0.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstAc3Parse:ac3parse0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstMpegTSDemux:mpegtsdemux0.GstPad:video_0040: caps =
NULL
/GstPipeline:pipeline0/GstMpegTSDemux:mpegtsdemux0.GstPad:audio_0041: caps =
NULL
Setting pipeline to NULL ...
Freeing pipeline ...

if i omit the ac3parse element, the buffers flow happily to the fakesink until
eos, also it works when leaving the parser plugged in but using the ts instead
of the m2ts source file

gst-launch -v filesrc location=test_h264_ac3.ts ! mpegtsdemux ! audio/x-ac3 !
filesink location=ac3.ts.es
and 
gst-launch -v filesrc location=test_h264_ac3.m2ts ! mpegtsdemux ! audio/x-ac3 !
filesink location=ac3.m2ts.es
produce two files that are byte-identical for the first, who would have
thought, exactly 2048 bytes
unfortunetaly this still doesn't help me find out whether the problem lies at
the muxing or demuxing side

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.