lenod wrote:I think decoding live mpeg without overclocking and reasonable quality is not really possible.
Have you tried transcoding such a video in xvid or even h264? I would be very interested to know how long it takes. I'll try it when I'll have some spare time.
If it is a reasonable time, then we could estimate the transcoding remaining time, wait long enough and start omxplayer on the partially transcoded file. I assume it would almost not use the cpu (except for audio?), letting this ressource for transcoding.
Another possibility would be to program recording on the pi using a DVB device*, and transcode the recording once finished or during the night (using crontab or something) while it has nothing else to do.
* Has someone managed to do this? Mine isn't recognised.
There's a thread on dvb-t woes which includes a link to an image with dvb support.
Transcoding to h264 is a no, there's some research into doing it quickly but I don't think it will work for us. I think just playing back the sound could use 30 per cent of the cpu.
What I'm trying to do is use openly gl to do the last step of decoding (colour space conversion) which is about 40 per cent of the decoding process.
It might be possible to do motion compensation in opengl too, which is a further 30 per cent saving in cpu use.
This is based on papers I've read. I read a paper where someone claimed to do mpeg2 decoding almost fully in an opengl es shader, but there was no method or code examples in any of the papers I've read.
Someone in a forum said they got 6 mpeg2 streams at the same time on the ipad 2 gpu. There's a little iphone code for colour space conversion and some opengl examples but nothing too useful!
im just learning opengl now but its a long process before i get a good working mpeg2 decoder. im confident it can be done though!