[vdr] PES packets sent to cDevice::PlayVideo: only audio and video?

[Laz]

On Sunday 07 August 2011 10:33:30 Klaus Schmidinger wrote:
> On 01.08.2011 14:25, Laz wrote:
> > I'm getting quite a few errors from avcodec complaining that decoded
> > video frames have width and height set to 0. This tends to be at the
> > start of a stream, i.e. on channel changing or starting playback.
> > 
> > Are there any packets sent which don't contain any "playable" data that I
> > need to test for and handle?
> 
> If you're not sure, I suggest you only explicitly handle the packets
> you know you can handle, and ignore the rest.

I've now changed a few libavcodec, libavformat, etc., functions for their new 
equivalents, which seems to have sorted out some of the random seg faults I 
was getting after a day or so of running.

It all works but it's not perfect: it can't decode a number of frames at the 
start of the stream when vdr starts. I'm now dropping all frames before the 
first I-frame and it seems a bit happier but still complains about the first few 
frames (maybe I should look for the first GOP instead? I'm learning all about 
MPEG formats as I go here! ;-).

I don't think it likes decoding frames when it doesn't know the width and 
height (and it won't let you force default values before decoding!!). I've yet 
to work out whereabouts in an MPEG stream the width and height are to be found 
(I'm scanning the source code of a number of applicaitons in parallel!)

Unfortunately, the documentation for ffmpeg is a bit brief in places and nearly 
all example code I've seen is for video files with a well-defined beginning 
rather than a DVB stream that could be opened at any point!

Maybe it's easier to just ignore the errors for the first few frames..!

;-)

> > Maybe I should bite the bullet and implement a decoder for
> > PlayTsVideo()..!
> 
> That would certainly be a good idea.

I've just been looking into that and it should be fairly easy: change the 
format from "mpeg" to "mpegts" and make sure I only get data with the desired 
PID. I'll need to switch between the two for backwards compatibility.

One thing I have spotted is that if I play something at a slow trickspeed and 
then go back to play, the audio has carried on at normal speed and is a long 
way out of sync. I'm sometimes hearing (choppy) sound during slow trickspeed, 
although that's quite rare! I've not seen either of these before and I suspect 
it's something I've broken along the way. Or could this be down to way the 
data are passed to the output device now?

Cheers,

Laz