[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