Hi,
I'm tidying up changes made to the softdevice plugin to get it working with vdr > 1.7.0 which uses TS for recordings. It all works fine pretty much most of but I have some errors I'd like to track down.
Are the PES packets provided to the primary device's PlayVideo function purely video and audio packets? It looks to me like the PAT and PMT are stripped out so that only MPEG2 (no HD for me at the moment) audio and video packets should get to PlayVideo(), and so the primary device should play _all_ packets sent to it. Is this correct?
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?
Maybe I should bite the bullet and implement a decoder for PlayTsVideo()..!
Cheers,
Laz
On 01.08.2011 14:25, Laz wrote:
Hi,
I'm tidying up changes made to the softdevice plugin to get it working with vdr > 1.7.0 which uses TS for recordings. It all works fine pretty much most of but I have some errors I'd like to track down.
Are the PES packets provided to the primary device's PlayVideo function purely video and audio packets? It looks to me like the PAT and PMT are stripped out so that only MPEG2 (no HD for me at the moment) audio and video packets should get to PlayVideo(), and so the primary device should play _all_ packets sent to it. Is this correct?
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.
Maybe I should bite the bullet and implement a decoder for PlayTsVideo()..!
That would certainly be a good idea.
Klaus
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
On Sunday 07 August 2011 17:10:04 Laz wrote:
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!
To reply to myself(!) dropping everything before the first sequence header (00 00 01 B3) seems to have sorted out the decoding errors. I was thinking I'd have to drop a lot of packets between the actual pictures but avcodec seems happy to be fed everything after the sequence header.
Next step, implement PlayTsVideo and PlayTsAudio...
Cheers,
Laz
-
Klaus Schmidinger -
Laz