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