<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
It turns out, the problem was the packets are merged, when they
shouldn't have been. I am not sure if this is a bug in 1.0.6, but
the pes filter code *should* drop the AC3 encoded audio stream info
(stream type 0x83, sub stream ID 0x76). I fixed this in
plugins-bad 0.10.23 by detecting the stream id (as is done in 1.0.6
properly) and skipping the packet.<br>
<br>
Also in 0.10 at least there was already a nifty way to combine all
of the related data for a pes into one buffer, by setting
"gather_pes = TRUE" which let me start looking at the problem a lot
better seeing complete audio chunks in one GstBuffer<br>
<br>
<div class="moz-cite-prefix">On 4/9/2013 8:04 PM, Brian Dodge wrote:<br>
</div>
<blockquote cite="mid:5164ACA4.9020405@gmail.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
In mpegtsdemux, Dolby trueHD extended buffers (pes extension,
codeAC) should be merged with the not-extended-bit-set buffers
into single buffer to push out. The PES parser properly detects
the extension field length, and I can pull out the proper stream
ID from the extension header, but I don't see how this info can be
sent back up, so that the callback knows that this extension
buffer should be merged with the next buffer (or previous buffer,
I don't know enough to know). <br>
<br>
</blockquote>
<br>
</body>
</html>