Alex Woods wrote: >I don't think so. PVA is quite odd, in that you get ES video packets, >and PES audio packets. The PES packets the driver just uses verbatim, >but for video packets it has to try to create a PES packet for them. >There is a flag in the PVA packet header that says whether the PTS >immediately follows the PVA header or not. If it does, the driver uses >it. In PVA mode, the driver spits out the PVA verbatim, so if that is >just as bad as the TS, then the problem lies elsewhere. > > so, the box is not inserting timestamps in the PVA stream? are you sure? >Something that might be worth looking at is the PCR pid. This seems to >be ignored by scan (unless in vdr mode) and tzap, and I imagine for a >lot of other apps channel configs, since it appears to not be needed. >However, if it's not sent with the video and audio pids to the dec, the >output from the scart will be out of sync A/V-wise. As a hack, the >driver sends the video pid for the PCR, since for most channels this >will work - but Channel 4 is one of the ones that has a different PCR >pid. I never checked the resulting streams from the driver, since they >always use to play in sync... > > > In this case we need the pts of the video stream, not the PCR (that some programs use and others such as mplayer don't).
