Are there any reliable H.264 decoders for Ubuntu Linux? [Archive]

View Full Version : Are there any reliable H.264 decoders for Ubuntu Linux?

Lancerevo

7th June 2007, 18:35

Hey guys,

I just wanna ask whether are there any reliable h264 codecs for Ubuntu Linux? Currently the ones that are available are not efficient in decoding h264 content. My CPU would skyrocket easily taking up 100% on both cores and the frames would skip.

I'm looking for something like ffdshow's h264 decoder or better yet one decoder for Ubuntu Linux that is on par with CoreAVC.

Are there such codecs or are there none?

Sirber

7th June 2007, 18:41

VLC?

www.videolan.org

Lancerevo

7th June 2007, 18:44

VLC?

www.videolan.org

Yeah VLC is one player that is good with decoding h264 content but it does not do well with softsub content. I'm looking for a decoder that will work on mplayer or some sort.

Sirber

7th June 2007, 18:46

Yeah VLC is one player that is good with decoding h264 content but it does not do well with softsub content. I'm looking for a decoder that will work on mplayer or some sort.

In my testing VLC is better whan mplayer for subs rendering. mplayer render them half transparent while in VLC you can get them plain-color with a border.
Remember that when you change subtitles (OSD) options, you need to restart VLC to take effect.

Lancerevo

7th June 2007, 19:01

In my testing VLC is better whan mplayer for subs rendering. mplayer render them half transparent while in VLC you can get them plain-color with a border.
Remember that when you change subtitles (OSD) options, you need to restart VLC to take effect.

Hmm I have a problem with VLC playing my h264 content. They would glitch up while I play them in windows with MPC + CoreAVC/ffdshow they show up just fine. I think there is something wrong with the built-in h264 decoder in VLC.

So I take it there isn't any other h264 codec for Ubuntu Linux?

Manao

7th June 2007, 19:05

VLC uses the same decoder as FFDShow and mplayer.

Sirber

7th June 2007, 19:12

Hmm I have a problem with VLC playing my h264 content. They would glitch up while I play them in windows with MPC + CoreAVC/ffdshow they show up just fine. I think there is something wrong with the built-in h264 decoder in VLC.

So I take it there isn't any other h264 codec for Ubuntu Linux?

Did you install the proper drivers for your video card or you run in vesa? ;)
IMO VLC isn't the problem, your linux setup is.

Lancerevo

7th June 2007, 19:16

Did you install the proper drivers for your video card or you run in vesa? ;)
IMO VLC isn't the problem, your linux setup is.

Yes I have installed my drivers. FGLRX to be precise. I have this problem in VLC on my XP setup as well. Does that mean my XP setup is the problem while the h264 videos work absolutely fine in MPC + CoreAVC/ffdshow?

@Manao : Maybe VLC's is older and has a bug or something?

Sirber

7th June 2007, 19:21

I have this problem in VLC on my XP setup as well. Does that mean my XP setup is the problem while the h264 videos work absolutely fine in MPC + CoreAVC/ffdshow?
You didn't mention this earlier.

screenshot those "glitch up" things please.

Lancerevo

7th June 2007, 19:36

You didn't mention this earlier.

screenshot those "glitch up" things please.

http://img159.imageshack.us/img159/8683/glitchme9.th.jpg (http://img159.imageshack.us/my.php?image=glitchme9.jpg)

http://img518.imageshack.us/img518/9559/glitch2yr4.th.jpg (http://img518.imageshack.us/my.php?image=glitch2yr4.jpg)

Sirber

7th June 2007, 19:46

those are taken from XP or Linux?
Seems there's a static background around the video. Odd...

Hellworm

7th June 2007, 21:28

Mplayer, videolan and ffdshow use the same (ffmpeg's) decoder. So you have no choice of decoder. However mplayer is not the newest version in ubuntu, you should compile from svn, which might also give a speed boost. And if its still to slow (the decoder is not multithreaded) you can speed it up with the -lavdopts options (see mplayer man page).

foxyshadis

8th June 2007, 00:12

If you compile mplayer with the latest ffmpeg, and it still shows those errors, I'm sure the ffmpeg mailing list would appreciate a piece of the stream so that they can find & fix it.

Hyper_Thread

8th June 2007, 00:16

I'm using VLC on Ubuntu Feisty Fawn (7.04) & all my h264 videos (480p High Profile) are played well.
I'm also using the proprietary fglrx driver for my 9600XT, so make sure Composite is Disabled in your xorg.conf (http://wiki.cchtml.com/index.php/Ubuntu_Feisty_Installation_Guide) coz fglrx does not yet support Composite with DRI on Dapper or feisty.
Also, make sure VLC outputs video in Overlay with frame skip. Hope this can be helpful.

Lancerevo

8th June 2007, 01:04

those are taken from XP or Linux?
Seems there's a static background around the video. Odd...

They are taken in Linux, however on my XP setup it shows something similar to this as well.

I'll try those options provided by other members and I'll report back.

Lancerevo

8th June 2007, 02:26

Ok, I've compiled mplayer using the newest svn and so far everything is still the same. CPU usage is still skyrocketing and frames are skipping. Even with frame drop it doesn't help.

How do you use the -lavdopts flag? During ./configure? It gave out an error when I did this :-

./configure --extra-libs-mplayer=-lavdopts

However it compiles just fine when I leave out the extra commands.

But if it's to be added in the Launcher Properties under Command then I did this :-

gmplayer -lavdopts <fast:threads=<2>>
and
gmplayer -lavdopts <fast:threads=<2>:>

then mplayer won't launch at all. What did I do wrong?

Nevermind I found out why it wasn't launching.

gmplayer -lavdopts fast:threads=2:skiploopfilter=nonkey

Now I have this and the video is doing slightly better but not that good still.

Tack

8th June 2007, 15:35

gmplayer -lavdopts fast:threads=2:skiploopfilter=nonkey

Now I have this and the video is doing slightly better but not that good still.The 'threads' option is ignored with lavc's h264 decoder, and 'fast' only applies to MPEG2. skiploopfilter=all will yield the largest performance increase possible while still leaving the video watchable, although it will degrade quality visibly.

This is the best you'll be able to do until the decoder is threaded. There is some interest in this, and also some recent traction on it. Hopefully by the end of the year ... :)

Hyper_Thread

8th June 2007, 18:35

Hellworm

8th June 2007, 18:42

The good thing about skiploop is that it does not decrease quality much on high quality/high bitrate encodes, because loop isn't used much and heavy. And low quality/bitrate is easy to decode, so skiploop might not be required on such content.

Tack: are you sure "fast" is not working on h264? mplayer man page says the opposite and my test seem to confirm that (around 5% speed increase).

Lancerevo: also report what video output mplayer is using. It should default to xvideo but it might fail. And that would slow down decoding heavily.

Tack

8th June 2007, 21:26

Tack: are you sure "fast" is not working on h264? mplayer man page says the opposite and my test seem to confirm that (around 5% speed increase).
Indeed, I was looking at an older man page. (My MPlayer at work is 1.0rc1.) My apologies.

Some very naive benchmarks based on Apple's 1080p Cornell Ornithology video (http://www.apple.com/quicktime/guide/hd/cornell.html), played with "-nosound -benchmark -vo null" and the extra -lavdopts indicated; average of three runs:

Reference (no extra arguments) - 68.485s
-lavdopts fast - 64.411s (5.94% faster)
-lavdopts skiploopfilter=nonref - 60.734s (11.32% faster)
-lavdopts skiploopfilter=all - 47.045s (31.31% faster)
-lavdopts fast:skiploopfilter=nonref - 56.790s (18.08% faster)
-lavdopts fast:skiploopfilter=all - 43.301s (36.77% faster)

In terms of visual quality, I'm not able to see any degradation with 'fast' and 'skiploopfilter=nonref' but I am with 'skiploopfilter=all' in certain places. (This wasn't a blind test but I'm fairly certain I'd be able to reliably pick out the skiploopfilter=all sample.)

Indeed 'fast' makes a difference of about 5%. By itself, it's probably not enough to matter though.

Lancerevo

9th June 2007, 11:03

Lancerevo, can u list your hardware specifications (CPU & GPU), the Kernel optimization (i386, i686....) and the video render used with MPC on your XP, this can help.

Note : According to the screenshots, your video file is 1080p and this demand a high-end config to be played smoothly (tell me if i'm wrong)

AMD Athlon 64 X2 3800+ Stock Non-OCed
Sapphire ATI Radeon X800GTO with Cats 7.4 (XP 32bit) FGLRX (Ubuntu 7.04 32bit)
MPC + CoreAVC (for h264 videos only) (XP32) , mplayer (Ubuntu 7.04)

Video Output on mplayer is set to xv. MPC in XP however is using System Default.

The video is playing very smoothly in MPC with CoreAVC as the decoder, however it is smooth as well using ffdshow.

The video played in Linux is skipping at random places. Some parts smooth, some parts skip.

Hellworm

9th June 2007, 14:21

Lancerevo

9th June 2007, 15:32

Can you report the difference between -vo null and -vo xv, both together with -benchmark -nosound? If it's smooth in ffdshow it should be smooth in mplayer aswell, decoder wise, so the has to be somewhere else.

Does the video skip frames or is it just very slow, does mplayer report decoding errors?

Perhaps the video is damaged, please try an other one (for example the one Tack used) and report wether this changes something.

It's skipping and slow due to my CPU usage being maxed out. This on happens in Ubuntu and not XP.

The video is not damaged, if it is then how come can I play the video on MPC with no errors at all?

Alright I'll try the benchmark that you mentioned and report back later.

mplayer didn't give off any errors at all while playing the video. Besides, the glitch problem only happens in VLC and not MPC or mplayer. Just that mplayer is decoding the video very inefficiently.

DarkZell666

9th June 2007, 19:06

What if you add -vf scale=720:-2 to the mplayer cmdline ? This is meant to scale the video down to 720*<whatever matches aspect ratio> before being sent to the renderer. On many occasions this has helped me watch hd trailers on a mid-range config (having bandwidth problems too). Dunno if VLC can do the same easily though ...

Hellworm

9th June 2007, 22:39

DarkZell666: If scaling helps then you propably have a problem with xv. At least for me scaling was always slower in mplayer as if done by xv. And I don't have such a slow (X2 5200) CPU which means that scaling with mplayer costs even more on a slower cpu.

Edit: forget it I overlooked the 720. But still prescaling only helps if the problem is the video output.

Lancerevo

16th June 2007, 12:14

Hey guys, sorry for the long delay.

I did -benchmark -nosound and -vo null and I still got sound playing from the video but then I let it run until the video ended but I didn't get any results from mplayer.

16th June 2007, 13:45

What was the full command line you used?

Lancerevo

18th June 2007, 06:07

What was the full command line you used?

gmplayer -lavdopts fast:threads=2:skiploopfilter=nonkey -ass -embeddedfonts -benchmark -nosound -vo null

18th June 2007, 10:07

Use mplayer, not gmplayer.

Hellworm

18th June 2007, 10:08

is this your self-compiled mplayer (did you build it with gui) or the one from ubuntu? Can you try the same not with gmplayer but with mplayer?

Lancerevo

18th June 2007, 14:14

is this your self-compiled mplayer (did you build it with gui) or the one from ubuntu? Can you try the same not with gmplayer but with mplayer?

Sure will do.

Lancerevo

21st June 2007, 11:39

[mkv] Track ID 1: video (V_MPEG4/ISO/AVC) "H.264 Video Stream", -vid 0
[mkv] Track ID 2: audio (A_AAC) "5.1 AAC Japanese Audio", -aid 0, -alang jpn
[mkv] Will play video track 1.
[mkv] No audio track found/wanted.
Matroska file format detected.
VIDEO: [avc1] 1920x1080 24bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Audio: no sound
Starting playback...
VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [null] 1920x1080 => 1920x1080 Planar YV12
V:1499.4 36553/36553 58% 0% 0.0% 0 0

BENCHMARKs: VC: 882.224s VO: 0.171s A: 0.000s Sys: 6.847s = 889.242s
BENCHMARK%: VC: 99.2108% VO: 0.0192% A: 0.0000% Sys: 0.7700% = 100.0000%

Exiting... (End of file)

Here are the flags that I used for the benchmark.

mplayer -lavdopts fast -nosound -benchmark -vo null

I will try to do a -vo xv benchmark soon. So in the meantime anybody find something wrong with the benchmark results? What do those numbers mean?

21st June 2007, 12:03

They mean that it took 882.224 seconds (889.242 overall, including time spent outside the video decoder) to decode the 25-minute video file without rendering or scaling it.

Now you could measure both software scaling and normal hardware scaling, using the same video file (which seems to be a bit long for testing these things; a clip that takes a minute to decode would be more than enough).

Software scaling to 720p before rendering (-sws 2 is bicubic, you can also try bilinear with -sws 1):
mplayer -lavdopts fast -nosound -benchmark -vo xv -vf scale=1280:720 -sws 2

Hardware scaling:
mplayer -lavdopts fast -nosound -benchmark -vo xv

Lancerevo

21st June 2007, 13:52

[mkv] Track ID 1: video (V_MPEG4/ISO/AVC) "H.264 Video Stream", -vid 0
[mkv] Track ID 2: audio (A_AAC) "5.1 AAC Japanese Audio", -aid 0, -alang jpn
[mkv] Will play video track 1.
[mkv] No audio track found/wanted.
Matroska file format detected.
VIDEO: [avc1] 1920x1080 24bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
Error opening/initializing the selected video_out (-vo) device.

BENCHMARKs: VC: 0.000s VO: 0.000s A: 0.000s Sys:-492.315s = -492.315s

Ok I get this when I tried to do software scaling.

Worst of all, now when I try to play any vids with gmplayer, the video doesn't show up. I tried uninstalling through the Synaptic Package Manager and reinstalling a new version from the Manager and the video still doesn't show up. I think I crapped something out somewhere but I don't know where.

Any ideas guys?

EDIT: Nevermind I went into Preference and saw that it wasn't configured to xv. Switched it back to xv and the video shows up now. Back to trying the benchmark again. Will report back later.

EDIT2: Ok it still gives the error that I posted above. I'm guessing there's something wrong with xv and it's backing off to X11. No wonder the video is not smooth. Any ideas how to fix this problem guys?

21st June 2007, 14:18

Lancerevo

21st June 2007, 14:31

Run xvinfo and post the output here. If it says that adaptors are not present, the problem is in your video driver (perhaps X.org is configured to use vesa instead of an accelerated driver). See /var/log/Xorg.0.log for more info and check the settings in /etc/X11/xorg.conf.

X-Video Extension version 2.2
screen #0
Adaptor #0: "ATI Radeon Video Overlay"
number of ports: 1
port base: 115
operations supported: PutImage
supported visuals:
depth 24, visualID 0x23
depth 24, visualID 0x24
depth 24, visualID 0x25
depth 24, visualID 0x26
depth 24, visualID 0x27
depth 24, visualID 0x28
depth 24, visualID 0x29
depth 24, visualID 0x2a
depth 24, visualID 0x2b
depth 24, visualID 0x2c
depth 24, visualID 0x2d
depth 24, visualID 0x2e
depth 24, visualID 0x2f
depth 24, visualID 0x30
depth 24, visualID 0x31
depth 24, visualID 0x32
depth 24, visualID 0x33
depth 24, visualID 0x34
depth 24, visualID 0x35
depth 24, visualID 0x36
depth 24, visualID 0x37
depth 24, visualID 0x38
depth 24, visualID 0x39
depth 24, visualID 0x3a
depth 24, visualID 0x3b
depth 24, visualID 0x3c
depth 24, visualID 0x3d
depth 24, visualID 0x3e
depth 24, visualID 0x3f
depth 24, visualID 0x40
depth 24, visualID 0x41
depth 24, visualID 0x42
depth 24, visualID 0x43
depth 24, visualID 0x44
depth 24, visualID 0x45
depth 24, visualID 0x46
depth 24, visualID 0x47
depth 24, visualID 0x48
depth 24, visualID 0x49
depth 24, visualID 0x4a
depth 24, visualID 0x4b
depth 24, visualID 0x4c
depth 24, visualID 0x4d
depth 24, visualID 0x4e
depth 24, visualID 0x4f
depth 24, visualID 0x50
depth 24, visualID 0x51
depth 24, visualID 0x52
depth 24, visualID 0x53
depth 24, visualID 0x54
depth 24, visualID 0x55
depth 24, visualID 0x56
depth 24, visualID 0x57
depth 24, visualID 0x58
depth 24, visualID 0x59
depth 24, visualID 0x5a
depth 24, visualID 0x5b
depth 24, visualID 0x5c
depth 24, visualID 0x5d
depth 24, visualID 0x5e
depth 24, visualID 0x5f
depth 24, visualID 0x60
depth 24, visualID 0x61
depth 24, visualID 0x62
number of attributes: 12
"XV_SET_DEFAULTS" (range 0 to 1)
client settable attribute
"XV_AUTOPAINT_COLORKEY" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 0)
"XV_COLORKEY" (range 0 to -1)
client settable attribute
client gettable attribute (current value is 30)
"XV_DOUBLE_BUFFER" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 1)
"XV_BRIGHTNESS" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_CONTRAST" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_SATURATION" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_COLOR" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_HUE" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_RED_INTENSITY" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_GREEN_INTENSITY" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_BLUE_INTENSITY" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
maximum XvImage size: 2048 x 2048
Number of image formats: 4
id: 0x32595559 (YUY2)
guid: 59555932-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x59565955 (UYVY)
guid: 55595659-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (YV12)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x30323449 (I420)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)

Lancerevo

23rd June 2007, 15:30

Nobody has any ideas?

Gusar

24th June 2007, 11:39

Try the open source radeon driver. the ubuntu package is called xserver-xorg-video-ati.

Lancerevo

24th June 2007, 15:38

Try the open source radeon driver. the ubuntu package is called xserver-xorg-video-ati.

No can do, my X800GTO won't boot into Gnome if I use any other drivers other than FGLRX.

Gusar

24th June 2007, 19:29

No can do, my X800GTO won't boot into Gnome if I use any other drivers other than FGLRX.Have you reported it to the Xorg developers? Or tried to debug it in any way? As you have noticed, the fglrx drivers are pretty much crap. You're not the first one to have xv problems with them. And since they're closed source, no one can help you. However, you have the luck that your card is supported by the open source radeon driver. Even if it doesn't work perfectly now, developers can and will help you to get it to work. But this is not the correct forum for this discussion, you should post on the Xorg mailing list (http://lists.freedesktop.org/mailman/listinfo/xorg).

The other alternative is to ditch the ati card and switch to nvidia. Their drivers are also closed, but at least they work reliably.

Lancerevo

25th June 2007, 05:05

Have you reported it to the Xorg developers? Or tried to debug it in any way? As you have noticed, the fglrx drivers are pretty much crap. You're not the first one to have xv problems with them. And since they're closed source, no one can help you. However, you have the luck that your card is supported by the open source radeon driver. Even if it doesn't work perfectly now, developers can and will help you to get it to work. But this is not the correct forum for this discussion, you should post on the Xorg mailing list (http://lists.freedesktop.org/mailman/listinfo/xorg).

The other alternative is to ditch the ati card and switch to nvidia. Their drivers are also closed, but at least they work reliably.

Ah ok. I'll try to report the problem to them. Thanks.