AMV Encoders - A/V Sync Test

[BasharOfTheAges]

I'll definitely try to make the demo @ AWA.

I'm still stuck on contest DVDs for my contest and I would love a great digital solution... would actually love to have an HD projector even more.

[Mister Hatt]

This thread is overly long and too much of a pain to respond to everything. Quu, is there a chance you can get on IRC and we can chat about this properly?

[Quu]

*edit*

I spoke to soon, it seams that mIRC lets me connect to two servers at once

the things you learn when you care

[Kionon]

Quu, please remember to include a random setting for video playlists.

[Quu]

Quu, please remember to include a random setting for video playlists.

My target is convention use, so the playback modes I need to include is: Straight Playback, Random Playback, Play and Stop

BTW, as far as mplayer-uau goes, I am investigating it. I was able to download it at home... and it does intrigue me greatly, as it is a basic rendering engine, with the GUI being separate (and replaceable). There is not allot of documentation on what is different with the uau branch, and all I get talking to devs is that there was politics, and nobody talks about it.

So I have been using the mplayer main website for documentation. One major flaw against mplayer so far is the lack of hardware decoding... well, except for "vdpau: hardware acceleration for NVidia cards" which is a Linux API. VLC supports many more options for the hardware acceleration. It is possible that the documentation is out of sync, and mplayer supports more, or uau might itself support more... but I am investigating. (IE I am not dismissing what you said Mister Hatt, I take all feedback seriously)

[Quu]

This thread is overly long and too much of a pain to respond to everything. Quu, is there a chance you can get on IRC and we can chat about this properly?

On a side note, I actually prefer forum threads because they are a handy self documenting source of information. Not that I am unfamiliar with IRC (I wrote my first IRC application in '96 for dalnet... it was a dice bot for playing d&d and battletech on irc... and since it was a .exe, not a mIRC script, it was harder to hack), but I find that IRC is good for conversations, and quick answers, but the asynchronous nature of a forum lends itself to better information sharing. Others who have the same questions can come across forums as a start for their own answers.

That aside, I have more information about my testing regime
My playback target is

Code: Select all

%VLC% --sout=#transcode{vcodec=HFYU,acodec=s16l}:std{access=file,mux=ffmpeg{mux=avi},dst=%DEST%} %SAMPLE% vlc://quit

From talking to the VLC developers, and the code review I have done, this is representative of the decoded sample file as it is sent to the screen and the speakers. This will generate an AVI file that is HuffYUV 2.1.1 compatible video encoded and PCM uncompressed audio encoded.

Should I add any other player targets for the testing?

I am tempted to add mplayer-uau, since it is trivial to add it to the work flow, I can output to a YUV file, along with a PCM wav file, which is just as easy to compare as the AVI above. My only issue is that mplayer does not do hardware assisted decoding under windows and under linux on non nvidia cards. Can anybody who likes mplayer either point me to a good mplayer resource site, or defend the player?

also... I am thinking of making the testing be windows batch files. I can make a batch file generator, give it the tools to test, then it will generate the batch file... execute this batch file (piping the output to a log file) and to watch tv in the other room or something, leaving it to churn

[Kionon]

Well, we've been talking a lot on IRC, Quu, but here are my issues:

Even with the changes you suggest, using the 1.1.3 MacOSX build I get these issues on 720p and higher AMVs.

Dropped Frames OR Macroblocking (without one, I get the other). Changing to different types of Output doesn't help. I cannot post a screen cap, because it just happens too quickly intermittently to do so (or I would have provided one already to Cyrix). It is, however, definitely repeatable. I tried your buffer, and at first I thought it had worked, until I realised frames were being dropped.

I used several videos for these tests, but I think a good one to go off is Skittles 60@720p, because it is a popular video many people have. When I use it with the skip-filter all, A) picture is not as clean B) video slows behind music until you can finally recognise the sync is gone about a third of the way in.

Running the latest stable version of MPlayerOSXExtended (Rev13), these files, including Skittles, run cleanly, crisply, with no dropped frames and at 50% less CPU usage than VLC (40% vs 21%). This is no top of the line MacBook either. It is a MacBook White that is two years old. I have changed the ram and harddrive, but the processor and integrated video chipset are far from the best on the market. Another note, QT also runs it fine, as far as I can tell.

I can also do BluRay tests when I get home (at the office now), but I am sure the difference will only be more markedly clear, as I mentioned to you before.

I cannot speak to how this works on windows, but if you are seriously interested in crossplatform, then we need to ascertain why MPlayer provides an experience on MacOS X that VLC cannot match.

[BasharOfTheAges]

Kio - clearly, you're holding it wrong.

[Quu]

This is what I understand about mplayer, and some questions

There is two major "versions" of mplayer (there are two OSX forks... but meh), mplayer, and mplayer-uau. MPlayer comes from the SVN while -uau comes from the GIT. the -uau respository was formed when there was a political fight between some of the mplayer devs, and uau is a fork with out being a fork. Why?

Why is uau considered better? what patches does it have that the SVN does not? is the opposite true, does SVN have stuff the git version does not? Not a vauge "it has more patches"... but WHY is it better, why should I use uau over the svn version... give details.

How difficult is it to build mplayer from SVN or from GIT. looking at things, the git version requires either a second git for the build tools, or using Kov's fork of the fork that combines the two? As they don't make version releases, I will have to probably make builds of it if I decide to use it.

how self contained is mplayer? From what I can tell, very... it is a single executable, not counting the GUI. How much control do I have over the playback details, can I specify a specific sound device to output to, if I am on a computer with 3 sound devices? how easy is it to control the video playback, can I have it take over monitor #2 and make sure to be on top and not display any mouse or anything? ie totally control that monitor?

Does it support hardware acceleration under windows and or mac? I know under linux it supports it with nvidia chips only. I want to be able to play 1080p H.264 video on an Acer Aspire Revo 3610 (Atom 330 and ION graphics card). The revo is my "lowest target"... ie I want players to be able to be on a revo or better.

[Quu]

I cannot speak to how this works on windows, but if you are seriously interested in crossplatform, then we need to ascertain why MPlayer provides an experience on MacOS X that VLC cannot match.

As a note... cross platform does not mean it has to work on a mac mini... just that is has to work on a mac, maybe a more powerful one. The hardware reqs don't have to be identical across platforms. Would i like it to work on a mini... sure.

my requirements for the player is
1) play all of the existing archive with out issues with out changing the archive (no re encodes)
2) be consistent in its playback performance and quality (if it plays a file once, it will do it the same a second time)
3) have no external dependencies nor hooks for external apps to over ride it (ie no DirectShow) by default
4) have a UI, or the ability to make a custom UI, that facilitates normal convention usage
5) playback 1080p H.264 video on an Acer Revo 3610 (my minimum hardware specs)
my wants
1) cross platform - Platform Priority Windows 7 > OSX > Linux
2) be open source (I like having the code to tinker if i want)
3) be as hardware flexible as possible (I used to use a hardware decoder, NS2K)
4) be as future proof as possible
5) allow for an HTTP interface, along with a direct GUI interface