jamesh wrote:jacksonliam wrote: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!
There's no encode support on the GPU at the moment (disabled), which limits transcoding. TBH, a licence pack that included encode would probably also include MPEG2 anyway.
The Raspi GPU could decode 6 streams of SD MPEG2 I reckon. It can certainly very easily do 1080p, which is over 6 times the data of SD video.
Ah yeah, I never thought about encoding with the gpu and decoding at the same time. I didn't (don't?) think it would be possible. Won't the camera add on need gpu encoding? Anyway I think the best that would offer would be skipping colour space conversion, you'd probably have to decode most of the mpeg2 on the cpu anyway!
I'm confident that I'll eventually get watchable playback using open gl es to do as much as possible!
It will just take time, if someone else with better skills than me decides to do it I will be happy as it's not easy, im more of a throw other people's code together and use a framework to do the least amount of coding from scratch as possible kind of guy
And I really have to write from scratch, there's a lot of pi specific things that need doing and I need to research which methods of sending the textures to opengl are the least cpu intensive in this particular opengl es implementation!