[mythtv] Re: State of DVB ATSC

[Doug Larrick]

Taylor Jacob wrote:
> Quoting Doug Larrick <doug at ties.org>:
>
>>Well a lot of the code (especially Daniel's new code) was a nice
>>framework to parse and get useful information out of the TS stream.  Had
>>the DVB folks (not Myth, the driver authors) provided a library to do
>>these manipulations, I doubt much of it would have been written.
>
>
> What specificly are you refering to?  Any MPEG manipulations are not the drivers
> responsibility and should be put into the dtvrecorder class I would suspect..
> All I can think of is keyframe detection, but without specifics I can't really
> answer this one..

I'm thinking of the code to assemble TS packets into higher-level
packets, and to do the packet filtering and state tracking.  Not a
deficiency in Myth at all... I think much of the functionality in the
DVB *drivers* should/could have been a standard userspace library
instead.  I'm just rambling here; not suggesting any action.

>
>>* I would like to see a more automatic connection from the
>>auto-discovered  channels from the card and the Zap2it data.  Something
>>as simple as just looking at the channel major and minor will work well
>>for >90% of cases.  If I get some time I plan to look at this myself.  I
>>think this is important; right now, hdtvrecorder users can get Zap2it
>>set up, plug it into Myth, and it just works.  PSIP guide is all well
>>and good, but it's missing an awful lot of info (episode titles, repeat
>>status, original air date, etc.)
>
>
> This is a matter of fixing mythfilldatabase to do a fuzzy match on sources that
> are attached to DVB cards..  I may do this sometime in the next week if I need
> an easy victory.. I am starting to hit some walls for easy fixes right now.. :)
>

Yeah, not tough I agree.  The harder one is merging the guide data somehow.

>
>>* Not having >1 channel currently (see below) I have no idea how well
>>PSIP guide filling works with multiple channels.
>
>
> Well the crawl for EIT isn't working yet since I have some issues to fix for
> German and Finnish EIT before I want to complicate the logic even more, but
> when the code is done EIT should be kept up to date whenever the backend is not
> recording.. (Crawling for EIT I call it)..

OK.  Still I think it's probably a prerequisite for deprecating
hdtvrecorder.

>
>
>>* You need to finish hooking up the STT parser to get the GPS offset.
>>GPS *will* add another leap second eventually, and the PSIP times will
>>no longer line up properly.  Unfortunately this means delaying
>>processing any PSIP guide entries until it's set.  In my homegrown PSIP
>>parser I keep EIT/ETT entries in a queue until we've seen MGT, VCT, and
>>STT.  But you could just as easily discard them since they'll be around
>>again soon enough.
>
>
> This is already done.. The STT is a prerequisite of the EIT in the
> TableHandler[] class.. The TableHandler[] class has all of the prerequisutes
> for each table built in, so it makes siparser not look so complicated.. But for
> example PAT is mandatory before PMT.. VCT and STT before EIT, etc..

As of when?  Last couple weeks?  When I last looked at the code it was
present but actually setting the member variable was commented out for
some reason.

>
> A valid GPS offset was mandated when the PSIP mandate took place, and I am
> handling that now..
>
>
>>* A couple of my channels have PSIP guide data that's odd (one has
>>extremely extensive description text (ETT); one has a full week of data;
>>several are malformed -- mention ETTs but never send them, etc.), and
>>I'm curious how your parser will do with this stuff.
>
>
> Are your malformed ETTs still happening since we fixed the syntax_indicator
> error?

No, not on the one station I get on my dev box.  It's other Boston-area
stations that I have concerns about.

> Mentioning ETTs that never show up isn't surprising.. The making of pretty much
> 100% of the PSIP equipment Thales (in France of all places) equipment seems to
> be shoddy at best.. The PBS station here is missing tables all the time because
> the Thales Amber box at teh transmitter location drops packets like crazy and
> they aren't going to get it fixed.. The Amber box at my Dads station (WBTV in
> Charlotte, NC) completely died and they currently have NO PSIP at all (VCT,
> etc).. Good thing is Myth would still be OK with the DVB code since we cache
> the channel locations since all they are sending anymore is Mpeg-TS level
> tables (PAT/PMT)..

That would break current hdtvrecorder completely... no caching.  Then
there's the issue of whether the engineering staff is allowed time to
look at HDTV issues when it's so little (but growing) of the audience.
We're lucky in Boston that a couple of the stations have real tech-heads
for head engineers :-)

>
> I looked again last night and I have stations that cut off the description at
> the ETT max length, but never send anything to concatenate another ETT to get
> the full description here..

I'll take a look once I get DVB drivers running upstairs (main Myth box,
with an actual antenna).  OTOH, is there a way to feed a raw MPEG-TS
testing stream (from a disk file) to dvbrecorder?  I imagine it's tricky
since the driver can't do the filtering.

>>* I have not tested multiple audio programs myself, though this is a
>>sticking point... one of my PBS stations broadcasts descriptive language
>>for the blind on a secondary audio channel and this is the one Myth
>>defaults to (part of playback).  We need to figure out a way to get
>>enough info to the audio-track selection code that it can do a good job.
>>  DVB is probably no worse than HDTV at this point, though.
>
>
> In PS mode there are issues with AC3 transformation, but thats getting
> deprecated sooner than later, so I refuse to troubleshoot it.. In TS mode
> everything makes it into the file 100% of the time, but mpegts.c seems to be
> causing some issues once in a while.. I am trying to fix it but the learning
> curve on avformat is pretty steep as I proved to myself last night..

Glad to hear PS is being deprecated... TS is much more flexible.  I
agree ffmpeg is a big ol' heap of code.  Have you asked specific
questions on the mythtv-dev list?  Of the HDTV guys, I know at least
Daniel and I have poked in there at one point or another.  And of course
it seems every time I've seen a playback bug in ffmpeg core and
mentioned it, Isaac has gone away for about a microsecond and come back
with a fix :-)

>>* I never watch Live TV (well, not since the Olympics), so I have no
>>idea if channel changes, etc. are broken.
>
>
> They always have worked like a champ.. :)  I do all of my testing in LiveTV..
> Recording is such a simplier case

Even when faced with poor signal quality or missing subchannels?

>
>>* The DVB signal-strength reporting stuff seems odd on the HD-2000.
>>Probably a driver issue.
>
>
> Yes. Thats going to be in the frontned.. I set the nxt2002 driver to report 32
> db SNR as 100% signal/noise.. I have no idea what the hd2k driver author did..
>
>
>>* Does recording capture PCR on channels where it's on a separate PID?
>
>
> Its supposed to.. Do you have any channels there that are like this?  I have
> gotten some complaints about it not working, but the only thing I can find to
> blame it at this point is mpegts.c..  If you do i'd love to get you to do some
> testing..

I do not.  John Poet does, or did at one point.

>>Yes, my HD-2000 is working OK with DVB.  It is in my dev (main desktop)
>>machine in my office, hooked up to rabbit ears, so I only get one
>>station.  This is kernel 2.6.11.3, with pcHDTV's 2.0 version driver.
>>You need to make sure Myth's build is picking up the DVB headers shipped
>>by pcHDTV, though I imagine this will get better as more of this code
>>gets into the mainline.  Both DVB and V4L support must be selected (as
>>modules) in your kernel build.  Then modprobe dvb_bt8xx and off you go.
>
>
> Oooo.. I have to use the 2.0 drivers from PCHDTV not the ones from dvb-kernel..
> That must be where I am going wrong..
>
> <snip>
>
>>So... my overall conclusion... DVB for ATSC is close.  Only wider
>>testing will turn up the issues.  I don't think we (Myth) should force
>>people to switch until 2.6.12 is out (since it supposedly has HD-3000
>>support built in).
>
>
> You are correct.. Until all the PCHDTV stuff 2k and 3k make it into a mainline
> kernel I won't be willing to rip it out either, but I really think we need to
> move twoard this sooner than later..  Isaac gave me the blessing to remove it,
> so I just want to make sure I can cover all of the bases ahead of time..
>
> I suppose any replies to this should probbably go on mythtv-dev..

Done.

-Doug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20050328/efd1ea1a/signature.pgp