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

["Reinhard Walter Buchner" <rw.buchner@freenet.de>]

Hi Oliver,

> Same here, my spare time is mostly consumed by
> debugging funny  featurebugs. ;-)

;o))

> > in addition. You may wish to have a look at the page 56-59
> > and pg 94 of the AV711x.pdf from TI (page numbers are

> Interesting, it gives an idea what the firmware/hardware does.

You mean "should do" ;o)) I finally took the time to really read
the whole PDF. I was astounded at what the PDF really does
disclose (even if they keep the true *how* a secret)

> But there is not much that could be done in the driver.
> Most of the magic is hidden in the firmware.

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.
 
> 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 wouldn't do it anyway ;o)) What "bothered" me somewhat was that
> > this (the copied message) was in contradiction to what Ralph Metzler
> > wrote a bit before (same day, I think one hour or so earlier).
 
> If I got this right, he said that some newer hardware might need a PCR
> for replay. 

Ah, that might indeed be what he meant to say.

>In this case, wouldn't it be possible to add a (fake) PCR  during replay?

Hmm, interesting idea. I think this would well be worth a try.
We really have nothing to lose ;o))

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

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%)
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.

- 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((.

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.

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.

Greetz,
Reinhard


---
Mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.463 / Virus Database: 262 - Release Date: 17.03.2003



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