I am one of those con managers. We talk. If i can provide a reference player platform, and provide proof on why they should move to it, I assure you, more than a couple will.
If I am going to add FLAC to my list of codecs, which encoders should I include, ffmpeg and the main FLAC binaries at
http://flac.sourceforge.net? Should I add Vorbis and Theora? (not going to touch snow, since it is not bitstream locked yet) Dirac? I am guessing that since I added MKV, I should add FLAC, but where do I stop. I like sticking to the MPEG family, i just wish the MP4 container platform was more stable, instead of some muxers being "Part 1", others being mostly "Part 12", and others being "Part 14" and "Part 15". The "MP4 File Format" has 4 different definitions, based on the time the encoder was written, and what the encoder wanted to support. There is a reason I like MKV. I found out about L-SMASH by asking for help, providing examples, and engaging the developers.
(I can't download the mplayer-aua from his site, my work firewall is blocking it based on malicious software flag, it will have to wait until i get home)
Right now my testing is on Sync, not on quality. If the encoders are breaking sync between audio and video, then i don't care how the quality is. Once I have a shorter list of acceptable encoders, I will then test for quality, which is an entire other set of issues. Bitrate can solve for quality. Like i said, hard drives are cheap.
I can't "force" people to do allot of things, even when managing the contests. If I limit it to H.264 CFR with FLAC audio and mkv container (I have had no problems with header compression, not since FFMpegSource2 was updated), what is to stop someone from using QuickTime to encode the video, or with using a two pass encoding, Nero, etc? FLAC being lossless, i don't care what encodes it, or do I? Do I start inspecting the bitstreams to enforce my choice of encoders and settings?
What I have found is that the best thing is to define an open and assessable playback platform, and then a recommended encode path that is optimal to that. Maybe provide a set of compatible choices. Most creators will follow that encode path, and the hard core ones will replicate the playback platform to test their videos, giving them more control. I have been around a while, trust me on that. (The Netstream 2000 was "pushing it" on accessibility, sorry) The best thing I can do is publish the playback platform, and provide a "reference" encode/preparation path.
There is also an existing library of MPEG-2 encoded videos that I need to maintain backwards compatibility with. I originally started into this assuming that timing and the like was defined in the format spec... boy was I wrong. The most bizarre part is that AUDIO is the part giving me the most grief. Video is pretty easy to test, it either works, and decodes to the same amount of frames as the original, with the frame contents matching, or it does not. rather simple and easy to test. The audio, it depends on the decoder, and the encoder agreeing on how many empty sample to include/consume at the beginning. This is why I have to define my playback platform.
I am using VLC 1.2.0-DEVL, which I am building from source. The current public release is 1.1.2 (though 1.1.3 is coming out soon). I have been talking with j-b, and a couple other devs, about VLC. As I find things and fix them, they are willing to review my patch, and if it works, include it into the trunk of VLC, meaning I don't have to maintain it. I have kind of been derailed from this as I started researching the sync issues in the encoders. If you have a video that breaks in VLC, give it to me, I can take it to cormish, j-b, and the like and we can work on a fix. Or then I have an example that I can use to move to another player and test it to.
I like VLC because it is cross platform, hardware accelerated, plays all the test videos I have thrown at it, and I can write a skin, lua plugin, and replace the http interface, without having to patch or recode VLC. IE I can take a stock VLC add a .zip file of my additions, and it is ready to go on any machine. I also like that VLC has no external dependencies. It does not use DirectShow and does not care what filters you have installed.
I had originally (a year ago) started under the assumption that I would be writing my own software from scratch, using ffmpeg and DxVA2, in probably VC++. Then work got stupid busy for me, time became a premium, so I started looking around at more options. As I learned more, my goals changed. Future proofing became more important, along with removing as many dependencies as possible, I do not want anything based on DirectShow. The filters I have installed may/will be different from an AMV creator, so their playback experience might be different. I want consistency. CCCP and DivX7 are not options for me, since other filters installed on a users machine could over ride those with out them knowing.
After I decided to explore other options, I bought an Acer Revo 3610 and installed XBMC on it, thinking I could write a set of plug ins for it, controlling stuff on a second computer via a GWT web app. At the time my imagined "convention setup" was a set of these little computers with a single control computer managing them. Finally VLC 1.1.0 was launched, it was, on paper, everything I wanted (all of your problem references were pre 1.0.0). It is based on ffmpeg and a small set of internal codecs (like FAAD2). It is cross platform, and very extensible, and supports hardware acceleration. There are some warts, but I have source access and am fixing the ones I know about. I have a skin almost finished that allows me to control playback on a dual monitor computer, one being the projector. I have the skeleton of an http interface written with GWT that replicates this skin, allowing me to control the player from a remote interface (such as an ipad on the stage during a panel?). I have also been poking around the lua plug in interface, seeing if I can define new play list modes.
Am I completely sold on the VLC based solution, no, but it is the best I have right now that solves all my needs. It is part of a whole. I can always go back to coding my own solution, or somewhere in between. But for everything I do, it is based on providing the best possible playback at a conventions. Right now, any issues with VLC, i can fix, and at worse, I fork it. (I really don't want to fork it, as the devs have been very open to my changes... they are busy and told me "code it yourself and give us a patch")
I have talked to allot of AMV creators over the years, thought many of the new ones don't know who I am. Many of them can spot a 1 frame error, specially when it is their own video. Also, these errors become cumulative. If your encoder adds a frame, the decoder adds a frame, and then the sound system/video system at the convention adds a frame, you are a 1/10th of a second off. It is in my best interest to minimize any loss during the process, so that when there are unavoidable sync issues, they are alone, and not multiplied by other issues.
HRTF is an audio location system, not a timing thing. It allows for the placement of audio cues and perceptual location tricks to make a listener think an audio source is to the left or to the right, behind them, etc. It would not solve the fact that for a medium sized room (where the VAT is) the audio cues will reach the front row 70 milliseconds before it reaches the back row. That is physics. For larger rooms (such as the main events room at Otakon), the back row will be more than a 10th is a second away from the speakers as the speed of sound is. This is one of those unavoidable delays, which we can only mitigate, not remove.
Take a look at my testing methodology, tell me what I need to improve, what is wrong, what is right. Provide some sample files I can use in my testing (right now I have two synthetic videos). Become part of the process to help me make it better. When I am done, we should have some definitive, repeatable, results that we can then use to make things better. And, as new versions of existing tools come out, and new tools are created, we can add it to the test and check the results. We will "know" instead of "think" what is best, and why.
I will defiantly take a look at mplayer-aua when i get home, thought probably not until after this weekend will i delve deep into it. But do me a favor, and look at vlc 1.1.2 (at least) and help me. Another option I was told to look at was MPC-HT?
The biggest problem I have, is objectively testing the sync of the playback with the player (any player). Is the camcorder method the best you can think of?