[mythtvnz] DNLA/UPnP server

[Steve Hodge]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ourshack.com/pipermail/mythtvnz/attachments/20091209/5be19f4f/attachment.htm