MPEG-2 Decoding

Realise there are tonnes of threads about this before, but it seems just as sensible to ask this question in a new thread rather than dredge up an old one about HTPCs.

Has anyone tried to decode TV/DVD quality MPEG-2 using the Pi? If so, was the performance OK? If not, how close was it to being OK?

I'm quite keen to get an answer to this because as great as the HD stuff is, I watch 90% of my moving images in SD from TV/DVD sources.

From other threads it appears the Pi should be pretty overclockable (especially if one is happy to overvolt and void the warranty) so my hope is that even if it can't do it out of the box it will be doable with an overclock.

[jamesh]

You will void the warranty if you overclock (if you do overclock, it's permanently recording in the SoC memory - you have been warned). 10-20% should be possible - but may cause a lower lifetime of the SoC. And did I mention it WILL void the warranty?

[dom]

I've been running for more that 6 months at 1GHz with no problems.

Although officially I couldn't recommend it.

If you don't mind blowing the "warranty" bit:

over_voltage=6

arm_freq=1000

might be a good starting point.

do you plan to release a decoder codec-pack addon? (of course with reasonable a fee) probably mpeg2, wmv/vc-1 and ac3, maybe dts would be enough to satisfy many people (as afaik you have only xvid and h264 licensed)

[jamesh]

It's been discussed, but I'm not sure if anything has been done about it yet - more important fish to fry.

robwriter said:

…

Has anyone tried to decode TV/DVD quality MPEG-2 using the Pi? If so, was the performance OK? If not, how close was it to being OK?

…

I just tried this with Openelec XBMC (on real RPi) – and it does not work. However, that may well be a limitation of omxplayer that Openelec is using (I remember reading a comment by Dom that omxplayer does not have software codecs).

So – I'm going to rewrite my (only – for now) SD card and see if any media players on native Debian can handle it.

Just tried it via mplayer on Debian ... and it played (no audio and not full screen ... but am sure that is just config step that I missed).
However, it was a bit jerky.
Am off to experiment a bit more - eg how to make Openelec/XBMC launch mplayer is file extension is .ts

I also tried with vlc (sudo apt-get install vlc) and it played the sound but only showed still image for the video.

Looks like I will have to look at transcoding at the desktop server next.

I wonder how much of the performance issue is due to the unaccelerated video output and how much due to the slow CPU. I would have thought that the CPU was fast enough to decode SD MPEG2. Which -vo option were you using (or which was selected by mplayer...), I can't imagine many of them will even work with the Pi. Also the Debian image isn't very well optimized for the hardware, which may have an impact as well.

I believe there's a patch floating around somewhere (or perhaps it's in the tree now) to add GLES output support to mplayer. Might help also.

Perhaps try a benchmark with -benchmark -vo null -ao null to get a general idea if the CPU is fast enough before a proper driver arrives.

Apparently the R-Pi ARM is roughly equivalent to a 300 MHz Pentium-2. When I first got started in video editing I had a system about like that and it was a real exercise in frustration (and that was definitely SD resolution, or even Super-Video-CD resolution). Maybe with really optimized software it would be better though.

As requested - here is the result of running mplayer in benchmark mode.

I ran it twice - once with -ao null and then with -nosound

pi@raspberrypi:~$ mplayer -benchmark -vo null -ao null mpeg2sample.mpg

MPlayer 1.0rc3-4.4.4 (C) 2000-2009 MPlayer Team

mplayer: could not connect to socket

mplayer: No such file or directory

Failed to open LIRC support. You will not be able to use your remote control.

Playing mpeg2sample.mpg.

MPEG-PS file format detected.

VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 15000.0 kbps (1875.0 kbyte/s)

==========================================================================

Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough

VDec: vo config request - 720 x 576 (preferred colorspace: Mpeg PES)

VDec: using Mpeg PES as output csp (no 0)

Movie-Aspect is undefined - no prescaling applied.

VO: [null] 720x576 => 720x576 Mpeg PES

Selected video codec: [mpegpes] vfm: mpegpes (MPEG-PES output (.mpg or DXR3/IVTV/DVB/V4L2 card))

==========================================================================

==========================================================================

Opening audio decoder: [mp3lib] MPEG layer-2, layer-3

AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000)

Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)

==========================================================================

AO: [null] 48000Hz 2ch s16le (2 bytes per sample)

Starting playback...

VDec: vo config request - 720 x 576 (preferred colorspace: Mpeg PES)

VDec: using Mpeg PES as output csp (no 0)

Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.

VO: [null] 720x576 => 1024x576 Mpeg PES

A: 20.0 V: 20.0 A-V: -0.034 ct: 0.042 498/498 0% 0% 32.7% 0 0

BENCHMARKs: VC: 0.009s VO: 0.005s A: 6.497s Sys: 13.795s = 20.305s

BENCHMARK%: VC: 0.0445% VO: 0.0222% A: 31.9964% Sys: 67.9369% = 100.0000%

Exiting... (End of file)

pi@raspberrypi:~$ mplayer -benchmark -vo null -nosound mpeg2sample.mpg

MPlayer 1.0rc3-4.4.4 (C) 2000-2009 MPlayer Team

mplayer: could not connect to socket

mplayer: No such file or directory

Failed to open LIRC support. You will not be able to use your remote control.

Playing mpeg2sample.mpg.

MPEG-PS file format detected.

VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 15000.0 kbps (1875.0 kbyte/s)

==========================================================================

Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough

VDec: vo config request - 720 x 576 (preferred colorspace: Mpeg PES)

VDec: using Mpeg PES as output csp (no 0)

Movie-Aspect is undefined - no prescaling applied.

VO: [null] 720x576 => 720x576 Mpeg PES

Selected video codec: [mpegpes] vfm: mpegpes (MPEG-PES output (.mpg or DXR3/IVTV/DVB/V4L2 card))

==========================================================================

Audio: no sound

Starting playback...

VDec: vo config request - 720 x 576 (preferred colorspace: Mpeg PES)

VDec: using Mpeg PES as output csp (no 0)

Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.

VO: [null] 720x576 => 1024x576 Mpeg PES

V: 20.0 498/498 0% 0% 0.0% 0 0

BENCHMARKs: VC: 0.009s VO: 0.004s A: 0.000s Sys: 0.986s = 0.999s

BENCHMARK%: VC: 0.9212% VO: 0.4396% A: 0.0000% Sys: 98.6392% = 100.0000%

Exiting... (End of file)

I haven't worked out what the various numbers mean yet ... but it finished a lot more quickly with -nosound

Thanks very much for taking a look at that - I'll try to decode the log this evening.

Looks like some other work may be required - I did wonder if video acceleration (such as via GLES) would be needed, but I'm afraid it's not something I'm knowledgeable about. Looks like sound decoding may also be worth looking at.

Hopefully once I get a Pi I can do some digging - ony a couple of weeks to go!

took me a moment to find the details for decoding that output online.

left to right they show the time taken for :

decode / display / audio playback / used by the OS / total

the number of frames is elsewhere in the output (498/498).

so to work out the FPS for each test then do  number of frames / total

therefore

-ao test – 498/20.305s = 24.5 fps

-nosound test – 498/.999 =  498 fps (it did the whole lot in under 1 second)

looking at the details for the -ao test show where the time went

and running it with real video output and -nosound (i.e. no -vo null) takes around 30-40 seconds - using -vo fbdev or -vo fbdev2 (need sudo for those 2) or starting up X and running -vo x11

498 frames in approx 35 seconds is in the region of 14 fps ... not good

guess it'll get worse when sound is in the mix

dom said:

I"ve been running for more that 6 months at 1GHz with no problems.

over_voltage=6

arm_freq=1000

might be a good starting point.

How do you do this? Any guides anywhere?

Perhaps I am misunderstanding the way the mplayer benchmarking works. It seems that it's not even decoding the video with -vo null, I would expect VC to take much more time if it were actually decoding.

Anyway, what's the source for your test file? The high 'sys' time is somewhat suspicious, I would guess this is time spent in the SD card driver?

zag said:

How do you do this? Any guides anywhere?

The wiki http://elinux.org/RPi_config.txt

error404 said:

Anyway, what's the source for your test file? The high 'sys' time is somewhat suspicious, I would guess this is time spent in the SD card driver?

Yes - I copied the file to the SD card. My guess is that it would not make much difference if it was collecting it over the network via HTTP but I can do that again tomorrow (it is how I first tried but I didn't keep the results but I know that it did not play noticeably better)

I've been doing some looking into mpeg2 today on my pi. Specifically .ts files captured on my HTPC from DVB-T.

All this was done from the debian image from command line, without X running.
VLC was a slideshow, about one frame every 5 seconds - audio was fine though. Seemed to be using SDL for video.

mplayer had varying success, with the different output devices. I got video to play with gl and gl2, but not very fast. directfb and the framebuffer devices were working but not very smooth especially with audio. SDL was the best but the video didn't want to get full-screen. Audio seemed to work well with sdl and alsa.

Its possible to decode with "-nodouble or mplayer -lavdopts lowres=1 -vfm ffmpeg" which did make the video run smooth but very low quality.

omxplayer wouldn't play my videos.

I'm in the process of getting an XBMC image to see what their player is like, I'd like to try GStreamer but cant find any docs of how to use it.

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.

My Pi only seems to overclock to 900Mhz regardless of overvolting, but I've had similar results to those mentioned above. In XBMC (via RaspMC) an MPEG2 file wouldn't play at all, but did have sound.

The TVCatchup plugin does work well once tweaked, and the full suite of iPlayer, 4OD etc should be available in XMBC, but MPEG2 would still be nice.

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!

To play an mpeg2 and see the (unwatchable) video in xbmc you have to right click on the file and select Play using... DVDPlayer.

[jamesh]

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.