[pvrusb2] Crashes fixed; more questions
Mike Isely
isely at isely.net
Tue Feb 14 08:02:56 CST 2006
On Mon, 13 Feb 2006, Phil Endecott wrote:
> Hi again,
>
> I've made my NSLU2 crashes go away by disabling my NTP server. It was a
> process of trial and error, made more complex by the fact that the
> crashes occur if the ntp server has ever run since boot. In an earlier
> experiment I had stopped it, but that wasn't sufficient; is has to never
> have run. So now I can get on with the real work, hence some more
> questions:
>
> Audio: does "mute" remove the audio bits from the stream, or just reduce
> the volume to 0? If the latter, is there a way to entirely remove those
> bits? I have only one audio channel, which I can connect to either the
> L or R input on the PVRUSB2. If I select "mono", which channel does it
> read? Or does it average them?
Doing "mute" only affects the msp3400 device; the mpeg2 encoder is not
directly affected, so the audio subchannel should still be present in the
stream but sending silence.
>
> VBR: If I set "variable video bitrate"=1, what happens? Which of the
> "peak" and "mean" settings does it use?
For this I recommend you look at doc/controls.txt in the driver snapshot.
That's a summary of all the effects from the various controls that I was
able to determine. It's still up-to-date.
>
> "Signal present": it looks as if this only applies to the TV input; is
> there a way to detect signal present/absent for the composite input?
You are correct; it only tells you if something has been tuned, and when
you switch to another input it is always forced true. In order to make it
detect in that case one would need to query the saa7115 (video digitizer)
instead. I could look into this but nothing is immediately obvious to me
there. I've just made a note of this. However there is a possible
unintended consequence of that change. Right now the "signal present"
value should be valid whether you're streaming video or not - an ability
that is important for scantv to work properly. The saa7115 is only
enabled when streaming, so if signal detection were changed to look at
that chip (assuming this were even possible), then signal detection would
no longer work when not streaming. This needs a little more thought.
>
> Now a more general MPEG question; this probably isn't the best place to
> ask this, so if anyone can suggest the right place, please go ahead. I
> want to have about 3 processes reading the video stream coming from the
> PVRUSB2. This isn't possible with the raw data because any readers
> after the first would be jumping in in the middle of the bitstream. But
> it should be possible to have a "tee" process that reads from /dev/video
> and feeds it via sockets or pipes or whatever to various listening
> processes; it just needs to know where the groups-of-pictures start and
> ensure that each connection begins at one of these boundaries - I think,
> though maybe it is more complicated than that. Does the driver know
> anything about the structure of the MPEG stream, or does it just get
> bits from the USB? Assuming that it knows nothing, I need to parse the
> stream sufficiently to find the groups of pictures. Does anyone know of
> something that can do this? Can anyone suggest an MPEG parsing library
> that could be used to do this? (There are various MPEG decoders out
> there, but I really only need to do the first bit of the parsing.)
>
> Cheers,
>
The driver currently does not do any processing of the mpeg2 stream. It
just passes through what it gets from the hardware. That might not be
true in the future; I've been told that in order to support VBI on the
cx23416, that the driver is going to have to process the VBI data itself
and inject that into the stream. But right now the driver just passes
everything through. As for tools to work on the stream, that's something
others would be better able to answer.
-Mike
--
| Mike Isely | PGP fingerprint
Spammers Die!! | | 03 54 43 4D 75 E5 CC 92
| isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
| |
More information about the pvrusb2
mailing list