[vdr] PES packets sent to cDevice::PlayVideo: only audio and video?
laz at club-burniston.co.uk
Sun Aug 7 18:10:04 CEST 2011
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?
More information about the vdr