AMV Encoders - A/V Sync Test

This forum is for questions and discussion of all the aspects of handling your footage. If you have questions about capturing/ripping footage, AviSynth, or compression/encoding/converting, look here.

Re: AMV Encoders - A/V Sync Test

Postby mirkosp » Thu Aug 26, 2010 3:50 pm

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...
Image
User avatar
mirkosp
MODkip
 
Joined: 24 Apr 2006
Location: Gallarate (VA), Italy
Status: (」・ワ・)」(⊃・ワ・)⊃

Re: AMV Encoders - A/V Sync Test

Postby BasharOfTheAges » Thu Aug 26, 2010 4:33 pm

You can compare quality-loss in a non-subjective way though. It involves coming up with a method to create a difference matte between the encoded and uncompressed files, compute a total value (or values) of difference in RGB or HLS of each pixel for each frame, then compute the % variance across each metric for each frame and for the video as a whole as a data set. Compute the variance by obtaining the integral of the absolute value of divergence from zero of the previous set. The encode with lowest variance would probably be the best. You'd need to test vs observational results to determine the threshold of it mattering.
Another Anime Convention AMV Contest Coordinator 2008-2014 & Head of the AAC Fan-works Theater - follow us on Twitter: https://twitter.com/#!/AACFanTheater
:sorcerer: :sorcerer: |RD: "Oh, Action!" (side-by-side) | |
User avatar
BasharOfTheAges
Just zis guy, you know?
 
Joined: 14 Sep 2004
Location: Merrimack, NH
Status: Extreeeeeeeeeme

Re: AMV Encoders - A/V Sync Test

Postby kholaras » Thu Aug 26, 2010 4:45 pm

I'm sure you'd love to see some numbers confirm it, but I think throwing the absolute max bitrate at the problem may not be the ideal solution. Yes, it'll give a near perfect result even with a lossy compressor but, if I understood Hatt's pedantic explanation, your decode effort will be directly proportional to the bitstream density. Bitstream density, for a fixed quality encode, will increase proportionally, which is what you were inadvertently testing with higher resolution and frame rate videos. Higher bitrates will also incur higher container overhead and disk transfers. I know you mentioned the bandwidth wasn't much of a concern (and it's not), but the CPU usage on a single core Atom may become a factor.

Dumb question, but do any of the players have an internal profiler to track the time to decode individual frames, either individually or as an average?
kholaras
 
Joined: 23 Jul 2003

Re: AMV Encoders - A/V Sync Test

Postby mirkosp » Thu Aug 26, 2010 4:51 pm

BasharOfTheAges wrote:You can compare quality-loss in a non-subjective way though. It involves coming up with a method to create a difference matte between the encoded and uncompressed files, compute a total value (or values) of difference in RGB or HLS of each pixel for each frame, then compute the % variance across each metric for each frame and for the video as a whole as a data set. Compute the variance by obtaining the integral of the absolute value of divergence from zero of the previous set. The encode with lowest variance would probably be the best. You'd need to test vs observational results to determine the threshold of it mattering.


Nah, that doesn't work. Psychovisual optimisations distort the input, so you will probably get a lower difference with an encode without psys, but when you watch the output the psy-optimised video will look better. So nope, the difference matte way doesn't matter in lossy comparisons.
Image
User avatar
mirkosp
MODkip
 
Joined: 24 Apr 2006
Location: Gallarate (VA), Italy
Status: (」・ワ・)」(⊃・ワ・)⊃

Re: AMV Encoders - A/V Sync Test

Postby Quu » Thu Aug 26, 2010 4:57 pm

kholaras wrote:Dumb question, but do any of the players have an internal profiler to track the time to decode individual frames, either individually or as an average?


I know the mplayer -benchmark does something close, i don't think VLC has anything like it

my plan was to use normal system monitoring tools to tell me the cpu ussage, peak and average, along with memory use, peak and average, as the files are played. Also, to keep a frame drop count along with that... that is stuff I can get from each player
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Quu » Thu Aug 26, 2010 4:59 pm

mirkosp wrote: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
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Mister Hatt » Thu Aug 26, 2010 9:38 pm

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.
Mister Hatt
 
Joined: 25 Dec 2007
Status: better than you

Re: AMV Encoders - A/V Sync Test

Postby Quu » Thu Sep 09, 2010 10:39 pm

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.
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Zarxrax » Fri Sep 10, 2010 10:40 am

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.
User avatar
Zarxrax
 
Joined: 01 Apr 2001
Location: Concord, NC

Re: AMV Encoders - A/V Sync Test

Postby Quu » Fri Sep 10, 2010 12:53 pm

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
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Quu » Fri Sep 10, 2010 2:27 pm

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.
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Quu » Fri Sep 10, 2010 9:23 pm

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
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Zarxrax » Sat Sep 11, 2010 11:44 am

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.
User avatar
Zarxrax
 
Joined: 01 Apr 2001
Location: Concord, NC

Re: AMV Encoders - A/V Sync Test

Postby Quu » Sat Sep 11, 2010 2:12 pm

Zarxrax wrote: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
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Zarxrax » Sat Sep 11, 2010 2:34 pm

Quu wrote:
Zarxrax wrote: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. "
User avatar
Zarxrax
 
Joined: 01 Apr 2001
Location: Concord, NC

PreviousNext

Return to Footage Help

Who is online

Users browsing this forum: No registered users and 0 guests