AMV Encoders - A/V Sync Test

[Quu]

Quality can only be compared when you keep bitrate low, really. Once you start to have a high bitrate, any codec should be able to have a good ouput, and so even at same bitrate, if it is high enough, all encodes will be looking roughly the same, really. Rather than worrying about quality, you should just worry about playback speed I think. The easier it is, the better, since filesize isn't an issue for you. If you tried doing a ' --tune fastdecode, zerolatency ' encode at crf 16 you could be getting some insanely fast decoding speed...

Right... so my goal is to first test all the solutions for a/v sync... if the decode is out of sync, it fails...
then I test all the a/v sync passed solutions for playback... see if they can be played with out issues
then... assuming i still have one or more solutions that make it this far, make a choice on the "winner" which will most likely be based on final file size and ease of encoding.

I suspect that I will find a bunch that pass the a/v sync, and may be lucky to get more than one playback solution

[Mister Hatt]

What kholaras is pretty much it. Especially for GPU acceleration or decoding where you need to be sending large volumes of data to the GPU which isn't really the fastest transfer ever done. Hence why high bitrate stuff performs better on CPU. If you find at a high bitrate the CPU is being iffy, then you need to reduce the stream complexity or even out/lower your bitrate distribution.

[Quu]

a minor update of sorts (been busy with stuff)

i am not done with my encoder test, but right now x264+flac+mkv is full of awesome for high quality archive level encodes

on the revo : Win32 - MPC-HC and CoreAVC are two solutions that work with all of my H.264 test cases... vlc works with the ASP test cases, and they all work with the mpeg-2 (strangly, vlc is best at mpeg-2)
i am tryign to get the linux testing to work with the revo... i am hoping that mplayer (and -uau) using vdpau blow me out of the water... since right now mpc-hc is the clear winner and sadly it is not cross platform, so mac and linux friends are left out.

[Zarxrax]

Would the interface of MPC-HC be suitable for all the things that you were wanting to do?
MPC can be explicitly forced to use specific directshow filters, so it should be able to work across different PCs, assuming you get the same stuff installed and set it up properly.

[Quu]

the interface to MPC-HC can't be changed (though the web interface might be), they don't support skins or the like... but they do support an IPC interface, so I could write a convention specific interface and control MPC-HC remotely... like i was planning on doing with mplayer's -slave mode. If i could not use MPC-HC to run the con's videos, i would not have tested it ^_^.

my disappointment is that MPC-HC is windows only, which means that if that ends up being the final solution, then I have cut out the linux and mac users. I have high hopes for mplayer under linux... I just need to learn linux gui crap.

I need a working video solution that can perform on two pieces of hardware... the acer revo, and one of AWA's existing playback computers. I don't care what OS i have to run to get it there, it is the minimal hardware targets I have. If i find a solution that is linux only on those two, i can require mac and windows to have more hardware and be happy.

So far, my working solutions are :
MPC-HC + Custom web interface
Advantages : Minimal code ownership by me, i just maintain the web code. Free
Disadvantages : Windows Only, Not as tight control on the play list as i would like. Would require local computer use web interface.

MPC-HC + Custom IPC interface
Advantages : basically total control over the interface. utilize MPC-HC as the render engine, taking advantage of it's sync correction and other tools. Could swap out vlc and mplayer for the render engines with minimal effort if UI is written in java. free
Disadvantages : Windows Only. More to code

DirectShow Custom Code
Advantages : absolute control over the interface and experience. could use the stand alone filters from mpc-hc or others, such as coreavc (free if using MPC-HC filters, cost otherwise)
Disadvantages : windows Only. allot of code to maintain and keep up to date, have to add in sync correction and everything manually.

Solutions yet to test under linux (and I hope work)
VLC + skin + custom web site
advantages : minimal code ownership
disadvantages : requires beefier computer for win32, untested under linux and vdpau

mplayer + custom IPC interface
Advantages : basically total control over the interface. utilize mplayer as the render engine, taking advantage of it's sync correction and other tools. Could swap out vlc and mpc-hc for the render engines with minimal effort if UI is written in java. mplayer is designed for an interface to sit on top of it. free
Disadvantages : only hardware accel is vdpau under linux, otherwise requires beefier computer. have to build copies from svn/git which means additional testing and support

[Quu]

as a side note, xbmc under linux with vdpau was able to play all the test videos perfectly... so I am assuming that one of the linux solutions should work.

[Quu]

tested on linux
Acer Revo running Ubuntu-Notebook 10.10 with the proprietary nvidia drivers
vlc 1.1.4 from the software center, and mplayer build from SVN (./configure;make;sudo make install)
vlc performed identically to the win32 version... ie it failed
mplayer required some work but i was able to get it working as such
"mplayer -framedrop -fs -benchmark -vo vdpau -vc ffh264vdpau runningman_720p@60_normal.mp4"
300 frames dropped (please note, the win32 hpc-hc dropped 7 frames) and it was noticeable, the degraded quality

so unless mplayer-uau can magically perform better, or I messed up (either the linux config, or the mplayer compile config) then I don't know what to do with linux anymore

xbmc under ubuntu is able to play it fine... so i am sure it is something I am doing wrong

[Zarxrax]

You have an option to still use it:
Figure out the maximum bitrate it can handle without dropping frames, and make that the maximum bitrate that people can encode at.

[Quu]

You have an option to still use it:
Figure out the maximum bitrate it can handle without dropping frames, and make that the maximum bitrate that people can encode at.

my problem with that "solution" is that mpc-hc and corevlc under windows... works fine AND
xbmc under linux on the exact same hardware plays the files fine... so I basically know I am doing something wrong

IE i know it is my fault, so am plugging away

[Zarxrax]

You have an option to still use it:
Figure out the maximum bitrate it can handle without dropping frames, and make that the maximum bitrate that people can encode at.

my problem with that "solution" is that mpc-hc and corevlc under windows... works fine AND
xbmc under linux on the exact same hardware plays the files fine... so I basically know I am doing something wrong

IE i know it is my fault, so am plugging away

No, it could simply mean that mplayer is less efficient at decoding and simply can't handle the file.
From the xbmc FAQ: "Note: XBMC for Linux, Mac OS X and Windows do not use MPlayer, they instead use XBMC's in-house DVDPlayer video-player for all video playback. "