AMV Encoders - A/V Sync Test

[Quu]

for the transfer rate, this is balanced by codec complexity. On the revo, with windows, I played back the higher bitrate mpeg-4 asp version of the same video that failed with the h.264 version, played fine

that is what caused me to look at the mpeg-4 asp

and, I am just exploring right now, expanding my options, narrowing the details

[Zarxrax]

for the transfer rate, this is balanced by codec complexity

AVC is very flexible though, and its "complexity" can be modified. I would say that its probably possible to make an avc encode that is both smaller and less taxing on the cpu than an asp encode.

I just did a very informal test myself comparing the decoding speed of x264 vs xvid on my system.
Source footage was nostromo's running man with lots of grain added.
A normal x264 encode with crf 18 decoded in 124 seconds. (filesize was about 3gb)
Same settings, except using Fast Decode preset came to 55 seconds.
An xvid encode at quantizer 2 (needed almost twice the bitrate as the x264 encodes) decoded in 164 seconds.
An xvid encode at quantizer 4 (roughly same bitrate as the x264 encodes) decoded in 118 seconds.

So although its a very informal test, you can see that bitrate has a much larger effect than the codec choice. And by using fast decode in x264 we can gain significant decoding speed.

[Quu]

I am curious, what is the file size difference between fastdecode vs normal (3gb)
and I would be curious if fastdecode detrimentally affects quality? (My guess is it just makes the size larger)

[Zarxrax]

Normal was 2.9gb, fast decode was 3.05gb. Quality should be roughly the same.

[Quu]

yea... that quality things... gets hard to test and compare... all the objective methods fail... or can be gamed
which i why I was counting on "insane" settings to be comparable in quality

[mirkosp]

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...

[BasharOfTheAges]

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.

[kholaras]

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?

[mirkosp]

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.

[Quu]

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