[mythtvnz] DNLA/UPnP server

[Stephen Worthington]

On Wed, 9 Dec 2009 01:21:00 +1300, you wrote:

>On Tue, Dec 8, 2009 at 10:42 PM, Stephen Worthington <
>stephen_agent at jsw.gen.nz> wrote:
>
>> On Tue, 8 Dec 2009 22:22:30 +1300, you wrote:
>>
>> >On Tue, Dec 8, 2009 at 8:59 PM, Stephen Worthington <
>> >stephen_agent at jsw.gen.nz> wrote:
>> >
>> >> For
>> >> example, all MHEG5 data is currently dropped as MythTV does not
>> >> support it.
>> >
>> >
>> >Yes, it does. See http://www.mythtv.org/wiki/MHEG.
>> >
>> >
>> >>  It then multiplexes the streams it wants for that channel
>> >> together into a container format and writes that to disk.
>> >
>> >
>> >Are you sure? My understanding is that MythTV doesn't do anything to the
>> >stream at all except for pid filtering (and I believe even that can be
>> >handled by the card or the driver). I don't think there is any "MythTV
>> >format", it's just mpeg2 ts.
>>
>> Yes, MPEG2 TS.  Which is a container format.  MythTV does not write
>> raw streams, it has to remux them into a container format, otherwise
>> it would have to write each stream as a separate file.  It can not
>> just copy the container data from the on air signal, as it has changed
>> the data in the container so the enclosing container data is no longer
>> applicable.
>
>
>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):
>General
>ID                               : 15
>Complete name                    : M:\tv\3905_20091205223500.mpg
>Format                           : MPEG-TS
>File size                        : 1.70 GiB
>Duration                         : 56mn 55s
>Overall bit rate                 : 4 283 Kbps
>
>Video
>ID                               : 520 (0x208)
>
>Audio
>ID                               : 658 (0x292)
>
>DVBScan reports:
>0x0000 0x0788: pmt_pid 0x0112 SKY -- PRIME (running)
>PRIME                    (0x0788) 01: PCR == V   V 0x0208 A 0x0292 (eng)
>
>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 lyngsat.com as
>well: 520 and 658.
>
>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.
>
>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).
>
>The streams inside the MPEG2 TS containers are the same, but note the
>> different ID numbers used.  I have no idea what they mean yet.
>>
>
>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.
>
>Cheers,
>Steve

Now that I know more about transport streams, I think you are right.
In order to store the streams MythTV is receiving, all it needs to do
is to create new header packets referencing just the streams it wants
and then copy only the packets with the PIDs referenced in those new
headers.  Plus a few other packets that provide time/sync referencing.

I have not tried dvbscan to see what is actually coming in off the air
(the MythTV box is pretty busy recording things), but if MythTV is
taking the PIDs it sees without change from DVB-S, there is no reason
to think it would be doing anything different for DVB-T.  So for some
reason, MediaPortal must be changing all the PID numbers - strange.

I found a nice tool called dvbsnoop that allows me to see the packets
in transport stream files.  I have not had time to look in any great
depth yet, but the only difference I can see so far between the
MediaPortal files and MythTV ones (apart from the PID numbers) is the
order of the header packets - the PAT and PMT are swapped around.  Now
I need to find the time to break down the header packets (dvbsnoop
does not do that) and see what is different there.

The basic difference in the AVCHD format is only the 192 byte packets
with extra time reference information in the 4 extra bytes.  All the
rest of the AVCHD format for transport streams seems to be just
restrictions on what you can put in them, such as only AC3 or PCM
audio.  It is a pity that the AVCHD standard is not openly published.
I wonder if an application from an open source developer for a copy
would be accepted, or whether they would want lots of $$$.