[mythtvnz] DNLA/UPnP server

[Nick Rout]

On Wed, Dec 9, 2009 at 9:08 PM, Stephen Worthington
<stephen_agent at jsw.gen.nz> wrote:
> 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 $$$.

OpenShot video editor claims to support editing avchd, i am thinking
through the MLT framework. I would take a look at the MLT
documentation or contact the developers.

Or look on doom9.net :)