[mythtv] Fwd: [linux-dvb] USB DVB-T tuners and MythTV

Daniel Kristjansson danielk at cuymedia.net
Thu Oct 13 15:39:46 UTC 2005


On Thu, 2005-10-13 at 12:09 +0100, Jim wrote:
> > Ah, so the signal monitor is waiting for the list of PIDS before it
> > asks for the PID allocated to the video stream? 
> My guess at what the current flow is something like:
> a) The channel / multiplex tuning request is made using the service 
> identifier
> b) The signal monitor thread is invoked
> c) for DVB-T the monitor waits for a pat and pmt to confirm that the 
> service is available and then sets up the pid filters as defined in the 
> PMT
> d) The front end now waits for confirmation that the correct pat/pmt have 
> been seen before showing the filtered stream
Yep, this is pretty good explanation of what is going on.

> > My box is used during the day mostly by my non-techie Mother-in-law,
> > who wouldn't understand waiting 40 seconds for a channel to tune. And
> > quite frankly, waiting 40 seconds for a picture is something I'd
> > consider a bug (in one piece of the software stack or another). Given
I'd consider that a bug too, but I don't consider it a MythTV bug.
I'm willing to put in any minor hack that would make things work,
but fixing the driver is much more preferable.

> > Monitoring for PMT is just fine, but what better indication is there
> > of correct tuning than a big fat MPEG2 stream crossing the bus?
> might be the wrong stream? Although the above worked for on-air channels 
> the new off-air behaviour (which we need in the UK) didn't - obviously! :)
Yep, many streams are output from DVB hardware, many of them like
the "off-air" streams are unplayable, others are simply the wrong
stream.

> Experimenting a little and trawling the threads I think the story is:
> The signal monitor implementation is very clean/elegant, but it does rely 
> on being able to get the DMX_PES_OTHER packets output on the dvr stream. 
> doing this means the monitor's job is very straightforward - it just has 
> to watch that stream and pick up the PAT/PMT/NIT etc as they repeat - this 
> extends to the DVB-S/C monitoring equally cleanly.
Yes these are the params in fact:
    pesFilterParams.pid      = (__u16) pid;
    pesFilterParams.input    = DMX_IN_FRONTEND;
    pesFilterParams.output   = DMX_OUT_TS_TAP;
    pesFilterParams.flags    = DMX_IMMEDIATE_START;
    pesFilterParams.pes_type = DMX_PES_OTHER;

So we need both PES_OTHER and OUT_TS_TAP support.

> It seems that the DEC driver (and at a guess from the dev threads some 
> other USB tuner drivers) do not support filtering only these packets onto 
> the dvr output - and it doesn't appear to be a buffer filling issue with 
> the DEC - they just don't turn up. (Though I'm still experimenting/trying 
> to follow the driver code here :)  )   
Hmm, the signal monitor would be happier to get all the packets
rather than none of the packets, could that be done?

> I can't see anything in eg the fe info to allow any code to determine the 
> pes_other filtering is not supported so I'd guess that writing generic 
> monitor code to support the 'deficient' usb drivers would mean duplication 
> of code and some sort of database flag - possibly in addition to the 
> 'hardware decode' flag. It would obviously be far more preferable for the 
> usb drivers to support the output transfer.
Without a flag, supporting the USB drivers would probably break
other DVB drivers. But I really dislike adding more flags, esp
if they can't be auto-detected easily.

> still experimenting/learning ...... much more fun than the day job that 
> keeps getting in the way :)
:)

-- Daniel



More information about the mythtv-dev mailing list