<div class="gmail_quote">On Tue, Dec 8, 2009 at 10:42 PM, Stephen Worthington <span dir="ltr"><<a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div><div></div><div>On Tue, 8 Dec 2009 22:22:30 +1300, you wrote:<br>
<br>
>On Tue, Dec 8, 2009 at 8:59 PM, Stephen Worthington <<br>
><a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>> wrote:<br>
><br>
>> For<br>
>> example, all MHEG5 data is currently dropped as MythTV does not<br>
>> support it.<br>
><br>
><br>
>Yes, it does. See <a href="http://www.mythtv.org/wiki/MHEG" target="_blank">http://www.mythtv.org/wiki/MHEG</a>.<br>
><br>
><br>
>> It then multiplexes the streams it wants for that channel<br>
>> together into a container format and writes that to disk.<br>
><br>
><br>
>Are you sure? My understanding is that MythTV doesn't do anything to the<br>
>stream at all except for pid filtering (and I believe even that can be<br>
>handled by the card or the driver). I don't think there is any "MythTV<br>
>format", it's just mpeg2 ts.<br><br>
</div></div>Yes, MPEG2 TS. Which is a container format. MythTV does not write<br>
raw streams, it has to remux them into a container format, otherwise<br>
it would have to write each stream as a separate file. It can not<br>
just copy the container data from the on air signal, as it has changed<br>
the data in the container so the enclosing container data is no longer<br>
applicable. </blockquote><div><br>I don't think that is right.The data off the card is mpeg2 ts and that's packetised. The dvb card (or driver) filters those packets based on PID. MythTV just writes the remaining packets to the file. There's no remuxing required as the ts stream already has the streams multiplexed. There's no container data to change as there is no container data in ts above the stream level. If you check the PIDs in the MythTV recording against what the satellite reports (e.g. via dvbscan) you'll find they match. For example, my recording of Dead Zone from last Saturday (on Prime) shows (trimmed for brevity):</div>
<div><div>General</div><div>ID : 15</div><div>Complete name : M:\tv\3905_20091205223500.mpg</div><div>Format : MPEG-TS</div><div>File size : 1.70 GiB</div>
<div>Duration : 56mn 55s</div><div>Overall bit rate : 4 283 Kbps</div><div><br></div><div>Video</div><div>ID : 520 (0x208)</div><div><br></div><div>Audio</div>
<div>ID : 658 (0x292)</div><div><br></div><div>DVBScan reports:</div><div>0x0000 0x0788: pmt_pid 0x0112 SKY -- PRIME (running)</div><div><div>PRIME (0x0788) 01: PCR == V V 0x0208 A 0x0292 (eng)</div>
</div><div><div><br></div><div>The video PID (0x0208) and the audio PID (0x0292) in the recording match the pids as delivered by the satellite. You can see these on <a href="http://lyngsat.com">lyngsat.com</a> as well: 520 and 658.</div>
<div><br></div><div>FYI, 0x788 is the service id (which goes into the service id column of the channel table in the database). 0x0112 is the PID of the stream that holds the Program Map Table.</div><div><br></div><div>The way these IDs are figured out is that the decoder finds the Program Association Table in the stream with PID 0. The PAT gives the PID of the PMT (0x112 in this case). The PMT gives the elementary stream PIDs (0x208,0x292 in this case).</div>
<div><br></div></div></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">The streams inside the MPEG2 TS containers are the same, but note the<br>
different ID numbers used. I have no idea what they mean yet.<br></blockquote><div> </div><div>Perhaps MediaPortal is changing the PIDs for some reason. All they are is identifiers to allow the decoder is see which stream a packet belongs to. MythTV doesn't alter them though.</div>
<div><br></div><div>Cheers,</div><div>Steve</div></div>