[vdr] Re: A/V sync problems with new drivers

[Oliver Endriss <o.endriss@gmx.de>]

Hi,

Reinhard Walter Buchner wrote:
> Yes, I realize that. But since you have been poking around in the
> DVB driver for quite a while ;o)), I was hoping you might be able
> to figure out a work around for now.

Well, I put a work-around into the driver, so it works if vpid==pcrpid.
If vpid!=pcrpid, you have to specify the pcr. I don't think that it is a 
good idea to do PMT parsing in a kernel driver.
Furthermore, PCR values should be cached to speed up channel switching. 
channels.conf is the right place for this. In 1.3.x something like 
Andreas' PMT scanner can be added to update the cache automagically.

> > Basically, vdr should set the PCR. Without the patch it was pure
> > luck that A/V sync worked with the new LL-firmware at all.
> > (I consider this a bug. :)
> > Perhaps channel.conf should be extended to allow something like
> >     BVN:12574:h:S19.2E:22000:164,17:96:0:0:5025:0:0:0
> >                                 ^^^
> > which would allow to specify the PCR pid. If not present, vdr could
> > set the PCR pid to zero or (better) set it to the video pid.
>
> Yes, nice idea! (Klaus seems to like it, too ;o))

He likes upward-compatibility, so it was designed to be compatible. ;-)

Maybe it would be even nicer to use ';' instead of ',' because the comma 
separates entries of the same kind, while ';' gives some additional 
info.

> I also found a few other interesting statements in the TI PDF.

Please keep in mind that the Metzlers apparently re-wrote parts of the 
runtime library. So these statements might not apply to the current 
firmware.

> On page 33 they talk about CPU (ARM) load. There is quite a
> substantial load increase if the needed data  is contained in
> more than one PID (single PID 5-8% // multiple PID: 40-80%)

I think, you got that wrong. All they say is:
- 1 pid with 5 MBit/s (5MBit/s total) --> 5-8% cpu load
- 8 pids with 5 MBit/s each (8x5 = 40MBit/s total) --> 40-66% cpu
You see, the cpu load scales very well.

Also note that 8 pids (with 5MBit/s each) means receiving 8 video 
channels at the same time...

> This may explain why the ARM sometimes crashes. I assume
> that certain situations try to exceed the 100% load, which
> results in a reset of the ARM-7 and crashes the whole thing.

I don't think so, see above.

> - The ARM 7 is capable of hardware scaling (pg 34) If Mplayer
> could utilize this capability, it could make a lot of people with
> low CPU power in their STBs happy. From what I have figured
> out of Mplayer it doesn't make use of this feature when doing
> an output via -vo mpegpes. However, this will probably only
> work with native mpeg 2 input streams ;o((.

I don't see a chance to get firmware support for this. IMHO we should 
not increase the complexity of the (closed-source) firmware.
Anyway, as PC processors become faster and faster, nobody will care 
about that (soon).

> On page 38 they talk about reducing memory usage. I don't know
> if the current DVB driver does a Vsync reset at the moment.
> Maybe Convergence (I know: wrong list ;o)), but I'm not on the
> DVB ML. I just sniff around the archives there now and then)
> can look into this.
>
> Do you have any idea if the DVB driver utilizes the operation
> mode described on pg. 39 (Split Video Input Buffer). It seems
> this method gives the user more free RAM space for the OSD.

IIRC the Metzlers did some efforts to get the OSD size as big as it is 
right now. So I assume that's what they did (but I don't know).

> One last thing. Could you have a look at pgs 94-95. I would like
> to integrate the "dual channel output mode select" into my VDR
> mod. This would allow us to finally be able to view a 2 Kanalton
> movie. By setting the appropriate bits, you can tell the ARM-7
> to output audio channel 0 on both L&R. Another bit combo
> allows the same for channel 1. Do you have an idea how we
> could implement this into the dvb driver? They talk about a bit
> "3:2". The problem is this tells me nothing ;o)) so I don't know
> how I could implement this into the driver.

According to the source code, the driver already supports AUDIO_STEREO, 
AUDIO_MONO_LEFT and AUDIO_MONO_RIGHT ioctls. Did you try them?

Oliver


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.