AMV Encoders - A/V Sync Test

[SailorDeath]

It would definitely be possible for me to add a convention preset. But, it might be better to have a separate app altogether, specifically for conventions. Maybe it could even be crossplatform? For convention encoding, I think there's probably not really any need for having any options at all, save for maybe a "slow" and "fast" setting.

Something like that would actually really been nice. I've been wanting to attempt converting the mpeg2 videos of the current archive to something that would look good but take up considerably less space. Plus since we've migrated to DVI playback and a software player (and will probably use Quu's once its ready) I've been looking into a x.264 solution. Especially since HD encoded mpeg 2 videos are behemoths. I think one of the 7 minute SD amvs on the archive is close to 500 megs by itself. Encoding it to x264 decreased the file size to 10% of it's original state, meaning I can squeeze a lot more space out of converting all the amvs. (though that might take over a year to complete.

[Zarxrax]

How do we do the second half, testing for quality? which encoder is best, etc... I am still thinking about that. I know some people say use APSNR or just PSNR, but to me, that leads to wrong results. Of course, based on our sync testing, it may not matter, if there is only one encoder that passes, not much cause for a check.

I wonder, what does the placebo setting on x264 mean, or is that identical to "very slow"

There is no need to test quality. For video, the ONLY option is x264. No other encoder should even be entertained as an option. Objective measurements like psnr are completely worthless anyways. They can't tell you anything useful about the actual quality.
Placebo setting in x264 means "this setting is really really slow and the improvement in quality is so minor that there is really no point even using it"

[Quu]

I need to get off my rear and start the testing, i have a DresdenRPG game I am running this weekend, I'l probably start the testing after that then

Any issues so far with my testing methodology and the encoders/tools used?

so far it seams to be H.254 vs. MPEG-2 video,
and MPEG-1 Layer 2 and 3 vs. MPEG-2/4 AAC vs FLAC
and MPEG-4 Container vs MPEG-2 PS/TS vs Mastroska

which of those options are optimal. I have to admit that Mr. Hat's suggestion of H.264/FLAC/MKV looks, before testing, as optimal, so I will go with that as my "bet" and see how the test goes.

and Zarxrax, don't forget, VLC and Handbrake both technically use x264 as their h.264 encoding engine. I chatted with DS on irc last night, and he suggested turning off the decomb filter on high profile in handbrake.

[BasharOfTheAges]

Optimizations are great, just make sure you test compatibility across a bunch of hardware platforms. As nice as it can be to have awesome gear, the reality of con budgets does come in to play for what hardware is needed to pull certain encodes off without a playback lag. It'd be great to have an all-in-one solution to point people to but legacy playback systems can and will exist - especially at small cons with low funds.

[Quu]

Optimizations are great, just make sure you test compatibility across a bunch of hardware platforms. As nice as it can be to have awesome gear, the reality of con budgets does come in to play for what hardware is needed to pull certain encodes off without a playback lag. It'd be great to have an all-in-one solution to point people to but legacy playback systems can and will exist - especially at small cons with low funds.

My "target platform" that I am developing for is a $320 atom/ion computer. Check out the Acer Aspire Revo 3610

I am actually developing on a much more powerful platform than that, the revo is just my target. I compile, ftp over, and test. So yes, I am focusing on a VERY limited budget... I know how tight conventions are, trust me on that.

My goal is to come up with a playback solution where the convention can pick and choose the components as it fits in their budget. You need to have a video and audio out that you can project to the audience (ie make sure it matches your con equipment, vga, s-video, etc), and either a second monitor, or a second computer to control the playback (note, if second second computer then all it needs is a web browser only, ipad could work). the playback computer either needs a good CPU to decode your video, or you need a supported GPU, which can actually be gotten really cheap. I saw an Nvidea GT 240 (vp4) with 1 gig of ram at fry's for $90. AWA has a set of computers with the AMD 785G Chipset (UVD 2) and they were very cheap to build.

My goal is choice, flexibility, and testing. I am doing my testing on what I consider the lowest powered computer that can handle it (Atom CPU with ION GPU), and if it works there, then anything higher will be fine. If you have an older Pentium II computer with a Matrox G200 video card... I might not be able to help you, and I would recommend you stick with the Netstream 2000 for playback.

[Quu]

O yea... at AWA I will be showcasing my test app and reference hardware at one of the side video rooms Saturday night. Saturday night, from midnight to 3am (or later if I feel like it, nothing is scheduled after me) I will be doing a test run of my playback solution in the video room across the hall from the VAT. Kind of like an amvers party or something.

Not quiet a panel, not quiet a display block, it will be something... not sure what yet.

My app will not be used this AWA as the primary playback solution at the con... it is not ready for prime time yet, as I am still testing for stability and for accuracy

[Quu]

as far as video outs, i try to remain flexible
if you get dual DVI (not DVI-D which is digitial only) then you are set. You can get a DVI to HDMI adaptor, you can get a DVI to VGA adaptor, and you can get a VGA to S-VIDEO, Composit, and Component adaptors really cheap.

Of course, the best would be to get a UVD 2 or VP4 video card with an S-Video/VGA/DVI outs, so then youc an just pick and choose.

and if your computer only has one audio out, you can get a USB sound card for $30 and send all of your windows sounds to it, while forcing VLC to use the other audio source, enforcing that the audience never hears a windows ding.

or you could use a Linux computer, or even a mac, as long as you test it first. Grab different versions of http://www.bigbuckbunny.org/ and try playing them with your playback solution... if you can play the H.264 1080p version with no skips or problems, then you are golden. (don't forget, GPU hardware acceleration is not enabled in VLC by default)

[kholaras]

I've been wanting to attempt converting the mpeg2 videos of the current archive to something that would look good but take up considerably less space.

I sympathize, but as quu keeps saying, storage is cheap. Yea, there's some benefits about hitting certain checkpoints (right now 2tb) to keep things simple and on a single drive, so as to not worry about multi-drive enclosures and raid/drive striping but Vlad's been in touch with us all and is confident about that possibility for at least this year and maybe another. coderjoe and I have been discussing ways to help Vlad more quickly identify the redundant bitwise identical copies that are floating around the archive right now (the AWA panel folders are especially good or bad, depending on your viewpoint, about that issue).

It's possible something could be worked out to do a mass re-encode, but you'd have to seriously automate a way to wrap everything in the appropriate avisynth import filters, process, mux, and eventually WATCH all the damned things to make sure they're good.

[Quu]

I do not want to re encode any video that is already in a usable and archived format, such as high bitrate MPEG-2. No matter how careful we do things, there would be some loss in quality, simple mathematical fact. Encoding from MPEG-2 to H.264 can never result in a higher quality file than the original MPEG-2 only smaller. This "quality" can be faked with filters, but then you have to check each one, which is basically remastering.

Now, replacing some of the MPEG-2s with remastered H.264 copies, that is different, but that would require either going back to the creators master file, or a painstaking remaster from high quality source files which can not be automated.

Hard drive space is cheaper than the convenience of storage.

[SailorDeath]

I do not want to re encode any video that is already in a usable and archived format, such as high bitrate MPEG-2. No matter how careful we do things, there would be some loss in quality, simple mathematical fact. Encoding from MPEG-2 to H.264 can never result in a higher quality file than the original MPEG-2 only smaller. This "quality" can be faked with filters, but then you have to check each one, which is basically remastering.

Now, replacing some of the MPEG-2s with remastered H.264 copies, that is different, but that would require either going back to the creators master file, or a painstaking remaster from high quality source files which can not be automated.

Hard drive space is cheaper than the convenience of storage.

When it comes to converting I'm a stickler for quality and I wouldn't sacrifice storage space over quality. It'd be kind of insulting, kind of the reason why I haven't been converting them already.