Anime Expo 2012 AMV Contest Thread - WINNERS ANNOUNCED!!!

[Scintilla]

That said, for conventions it would be nice if all of them accepted MKV files. As you stated, it's the best way to deliver the files without having to worry about possible sync issues outside of delivering a lossless AVI with PCM audio.

I actually listed "Matroska/MKV" above "MP4" in the list of acceptable containers for the AnimeNEXT contest this year, and yet, I think we still haven't gotten a single MKV yet. Tons of MP4s though...

Haven't noticed sync issues yet, but then, I'm forcing all non-MPEG-2 files through AVISynth anyway rather than playing them straight. Would that make a difference?

[l33tmeatwad]

But mp4 aren't compatible with divx players! You're totally forcing people to re-encode!
Jokes aside, unrestricted x264+flac in mkv is how I usually play it. Plays on Windows, OS X, Linux, and if it plays on other stuff too then it's good. Otherwise, it's fine. Hey, it's an amv. Re-encoding a high quality encode is gonna do little harm, it's not like we're doing srsbiz... and in reality most people WILL just watch a streaming re-encode anyway, perhaps the org preview, but most likely some youtube reupload. So I might as well make sure that those that care enough about quality to download it get the best quality possible (hence why I'd like the 10bit switch to be faster), without getting the filesize too big. They are most likely just going to double click on the file after the download anyway, and most netbooks nowadays can take 720p24 like cake.

That's such a waste to use "Unrestricted" what the current material we as AMV makers are outputting. Since you aren't encoding to 10bit, the resulting 8bit encode will be High Profile Level 5.1 (assuming the video is HD), so really the only thing breaking the video from being able to play back on consumer products is the fact that's it's Level 5.1 instead of 4.1. The reason this is a waste is, the Levels only give you bitrate, resolution, and framerate restrictions, all of which would fall under Level 4.1 standards (unless you are doing a 1080p60 encode). Doing a High Profiles 4.1 encode would change nothing in your overall quality and allow for users to simply dump the video, re-encode the audio, and re-container them both in an MP4 for easy playback on a gaming console or Blu-ray player without having to reduce the video quality by re-encoding.

I think the one thing we do agree on is the use of 10bit encoding needing to come about faster.

That said, for conventions it would be nice if all of them accepted MKV files. As you stated, it's the best way to deliver the files without having to worry about possible sync issues outside of delivering a lossless AVI with PCM audio.

I actually listed "Matroska/MKV" above "MP4" in the list of acceptable containers for the AnimeNEXT contest this year, and yet, I think we still haven't gotten a single MKV yet. Tons of MP4s though...

Haven't noticed sync issues yet, but then, I'm forcing all non-MPEG-2 files through AVISynth anyway rather than playing them straight. Would that make a difference?

The delays in playback can be caused by the splitters, which control delays in how soon the decoders get the audio/video, or simply by the decoders themselves. Assuming that there wasn't a sync issue introduced in the encoding stage (extra frames added to the video, or irregular padding or delay added to the audio encode), AviSynth would remove any possible playback delay issues as long as you use FFmpegsource2 to read the files for frame accuracy (as opposed to using DirectShowSource). You should have the same frame count as the original AVI using this method and as long as the audio encode didn't distort the time length of the audio and/or did not have delay added, the audio encode should maintain good sync with the video. Any variants in the sync will come from the audio compression technique, which considering realistic situations in which users would be encoding, probably would give no noticeable variations. My recommendation would be to convert to audio to WAV before reading it into an AviSynth script to avoid sync issues from the AviSynth audio input plugins (which can and does happen frequently).

[mirkosp]

What? Ok, let me clear things up.

That's such a waste to use "Unrestricted" what the current material we as AMV makers are outputting. Since you aren't encoding to 10bit, the resulting 8bit encode will be High Profile Level 5.1 (assuming the video is HD), so really the only thing breaking the video from being able to play back on consumer products is the fact that's it's Level 5.1 instead of 4.1. The reason this is a waste is, the Levels only give you bitrate, resolution, and framerate restrictions, all of which would fall under Level 4.1 standards (unless you are doing a 1080p60 encode). Doing a High Profiles 4.1 encode would change nothing in your overall quality and allow for users to simply dump the video, re-encode the audio, and re-container them both in an MP4 for easy playback on a gaming console or Blu-ray player without having to reduce the video quality by re-encoding.

No, you are forgetting one very important thing that depends on the level as well. REFERENCE FRAMES.
By unrestricted I just meant that I allow x264 to autoguess whichever level is the most appropriate. I wasn't too clear perhaps, sorry.
So guess what, 720p24 w/ 16 ref becomes a 5.0, since 4.1 limits me to 9 refs for 720p.
1080p24 would be even more limited, since 4.1 allows only 4 refs.
Depending on how the video is edited, more refs can make quite the difference, especially with AMVs, since we do stuff like jump cuts/glitch sync, but anime in general as well, since looped animations are not exactly uncommon either. I haven't done any specific stress tests to push it, but bumping ref to 16 can shave off a few extra MBs, and I did some generic comparisons on common anime footage back in the days (a few years ago). I don't see how this is a waste at all, since I don't care about hardware compatibility. I'd go even so far as to say that not using those extra refs is the waste, heh.

EDIT: Ah, and since we're at it, 5.2 has been recently committed to x264, so you might want to update your build if you are so inclined. I personally prefer JEEB's builds (which haven't been updated yet) and am not concerned about it since I never reach that level with my content, but one never knows.

I think the one thing we do agree on is the use of 10bit encoding needing to come about faster.

I wish more people thought the same in the community. Unfortunately too many editors are still using 2010 software due to the avtech being so updated, so we can't quite "enforce" 10bit yet. Plus the mencoder on the site needs to be updated so previews from 10bit files on local don't screw up.

[l33tmeatwad]

No, you are forgetting one very important thing that depends on the level as well. REFERENCE FRAMES.
By unrestricted I just meant that I allow x264 to autoguess whichever level is the most appropriate. I wasn't too clear perhaps, sorry.
So guess what, 720p24 w/ 16 ref becomes a 5.0, since 4.1 limits me to 9 refs for 720p.
1080p24 would be even more limited, since 4.1 allows only 4 refs.
Depending on how the video is edited, more refs can make quite the difference, especially with AMVs, since we do stuff like jump cuts, but anime in general as well, since looped animations are not exactly uncommon either. I haven't done any specific stress tests to push it, but bumping ref to 16 can shave off a few extra MBs, and I did some generic comparisons on common anime footage back in the days (a few years ago). I don't see how this is a waste at all, since I don't care about hardware compatibility. I'd go even so far as to say that not using those extra refs is the waste, heh.
EDIT: Ah, and since we're at it, 5.2 has been recently committed to x264, so you might want to update your build if you are so inclined. I personally prefer JEEB's builds (which haven't been updated yet) and am not concerned about it since I never reach that level with my content, but one never knows.

True, the reference frame limitation under Level 4.1 for 1080p is a bit low, so that would be the only reason I would resort to Level 5.0 or higher. That said, when you start introducing that many reference frames it can also start causing issues for slower machines such as netbooks and older machines. When it comes to 720p, 9 vs 16 reference frames will only either cause a minor boost in quality, or allow you to shave off a few MB, which is quite pointless in comparison to the compatibility, but we're just arguing apples and oranges as it all comes down to preference.

I think the one thing we do agree on is the use of 10bit encoding needing to come about faster.

I wish more people thought the same in the community. Unfortunately too many editors are still using 2010 software due to the avtech being so updated, so we can't quite "enforce" 10bit yet. Plus the mencoder on the site needs to be updated so previews from 10bit files on local don't screw up.

The lack of a workflow for 10bit video doesn't help either. The fact that there is no way to convert 10bit x264 to 10bit uncompressed AVI is a bit disappointing...

[blaku92]

converting the original PCM Audio to mp3 and adding ___ amount of milliseconds to the beginning like I've been doing...

Questions:
1.) Why did you add "X" amount of milliseconds to the beginning of your mp3? It's been a while since I've compressed XVID Avi's with mp3 audio, but I did one recently in virtualdub and noticed the audio was out of sync compared to the Zarx .mp4/aac compression I made. I want to make sure, if I'm going to make an XVID avi for the contest, that I'm doing it the best I can, but I don't remember ever reading something in a guide that said you have to delay your mp3 audio by a certain amount of milliseconds. Is that normal or always been the case? Is there something I'm missing? I don't mind taking the time to read guides, so feel free to point me in the right direction if I missed something crucial over the years. haha.

2.) And this is a question for everyone really -- is Lagarith truly visually "lossless" for HD video? I've always accepted it as one of the lossless codecs for SD footage, since it has a high bitrate and I never noticed any degradation, but for 720p and 1080p footage, wouldn't the codec's 50Mbps Bitrate possibly result in quality loss? I ask because I know in the professional industry, "Online-quality" for HD content is normally associated with bitrates of 100Mbps and above. I'd prefer to submit my entries as Lagarith AVIs if that is the guaranteed way to prevent audio sync issues. I've been frustrated at cons in the past with out of sync audio. Thanks all!

[l33tmeatwad]

Questions:
1.) Why did you add "X" amount of milliseconds to the beginning of your mp3? It's been a while since I've compressed XVID Avi's with mp3 audio, but I did one recently in virtualdub and noticed the audio was out of sync compared to the Zarx .mp4/aac compression I made. I want to make sure, if I'm going to make an XVID avi for the contest, that I'm doing it the best I can, but I don't remember ever reading something in a guide that said you have to delay your mp3 audio by a certain amount of milliseconds. Is that normal or always been the case? Is there something I'm missing? I don't mind taking the time to read guides, so feel free to point me in the right direction if I missed something crucial over the years. haha.

If you are going to send an AVI, I would recommend keeping PCM audio, there is no point in compressing the audio.

2.) And this is a question for everyone really -- is Lagarith truly visually "lossless" for HD video? I've always accepted it as one of the lossless codecs for SD footage, since it has a high bitrate and I never noticed any degradation, but for 720p and 1080p footage, wouldn't the codec's 50Mbps Bitrate possibly result in quality loss? I ask because I know in the professional industry, "Online-quality" for HD content is normally associated with bitrates of 100Mbps and above. I'd prefer to submit my entries as Lagarith AVIs if that is the guaranteed way to prevent audio sync issues. I've been frustrated at cons in the past with out of sync audio. Thanks all!

Lagarith is lossless as long as you don't allow the codec itself to convert the colorspace, so make sure that is handled before you process the encode.

[Kazemon15]

When...did this become a codec thread? XD


Anyway, I did send off my entries on May 1st, should have arrived yesterday.... no confirmation yet. *starts to worry*

[XStylus]

When...did this become a codec thread? XD

Anyway, I did send off my entries on May 1st, should have arrived yesterday.... no confirmation yet. *starts to worry*

Depends on where you mailed it to. If you sent to the Ventura address, there will be a long delay since it's literally a two hour drive one way for me to go there. I made a trip up there yesterday morning though, and I will be processing those entries tomorrow. My next trip up there will be next Wednesday (which will be after the deadline by then), and one final trip on the following Monday.

As for entries sent to the SPJA address, I will be grabbing more today and will also be processing those tomorrow.

If you've sent your entry and don't get an email from me by 11pm tomorrow, worry.

[Kazemon15]

When...did this become a codec thread? XD

Anyway, I did send off my entries on May 1st, should have arrived yesterday.... no confirmation yet. *starts to worry*

Depends on where you mailed it to. If you sent to the Ventura address, there will be a long delay, though I made a trip up there yesterday morning and will be processing those entries tomorrow. As for entries sent to the SPJA address, I will be grabbing more today and will also be processing those tomorrow.

If you've sent your entry and don't get an email from me by 11pm tomorrow, worry.

Alrighty. I sent it to the new address. Thanks for the heads up. I wasn't sure how often to go to check the mail in the areas.

[Melichan923]

The new Zarx uses L-Smash to mux the videos, which uses a different MP4 standard than previous versions that used MP4Box. That said, there shouldn't be a delay, it's very possible the delay is caused by the splitter handling the MP4 file, then when you remux, it's still off because you are most likely not using L-Smash to recontainer the new video. You could probably run the Zarx encode that is having playback delays through MP4Box and the sync then randomly start working. I can't say for sure since I don't have your particular setup to test from, but I will say this, MP4s that were created with L-Smash give dropbox playback (on the website through a web browser) a wierd problem where it shows the video sideways...simply recontainering using MP4Box eliminates this problem. Although if we bring the audio codec change in Zarx into this too, there could be delay there from the playback...all I can recommend is updating your direct show filters and file splitters and seeing if the problem goes away, as it's most likely the playback that is to blame.

I did some updating last night, and I will update the Direct Show and the file splitters tonight. I hope it works, thank you for your suggestion and help! I got a PM last night also recommending another program so I will try that as well.

I actually listed "Matroska/MKV" above "MP4" in the list of acceptable containers for the AnimeNEXT contest this year, and yet, I think we still haven't gotten a single MKV yet. Tons of MP4s though...

I'm going to try MKV and see if it makes a difference in sync, but I have most of my MPEG-2 encoding done. I used 1080p footage from a Blu-Ray to edit and the quality looks beautiful but after converting to MPEG2 with the bitrates recommended, honestly I'm a little scared to send them as is in fear quality loss will result in deducted points even if MPEG-2 is preferred. Especially now knowing that lots of people have sent in crisp, pretty mp4s. I like to make things a bit easier for the coordinators and that's why I hate sending huuuge files or files that are not preferred. If MKV looks good sync wise and the quality is a vast improvement over the MPEG-2 files I apologize ahead of time if I cave and send those instead. For now, I think I will stay away for MP4 for conventions, but I'll have to see if any of the above mentioned solutions work!

Questions:
1.) Why did you add "X" amount of milliseconds to the beginning of your mp3? It's been a while since I've compressed XVID Avi's with mp3 audio, but I did one recently in virtualdub and noticed the audio was out of sync compared to the Zarx .mp4/aac compression I made. I want to make sure, if I'm going to make an XVID avi for the contest, that I'm doing it the best I can, but I don't remember ever reading something in a guide that said you have to delay your mp3 audio by a certain amount of milliseconds. Is that normal or always been the case? Is there something I'm missing? I don't mind taking the time to read guides, so feel free to point me in the right direction if I missed something crucial over the years. haha.

Don't worry, you didn't miss anything crucial. I only added time to the beginning of my MP3 when I noticed it was out of sync with the MP4. It was trial and error until I found the correct amount of silence that synced up enough. This could help you though in the future if your XviD/MP3 encodes are slightly out of sync. I agree with l33tmeatwad that you shouldn't compress to MP3 with XviD for a convention unless they require it. My XviD/MP3 encodes tend to be more in-sync than my MP4/AAC encodes without any tampering, but I noticed the sync was better with the orginal PCM Audio v.s. the MP3. I found something interesting in a thread once on this issue: If you load your XviD/MP3 encoded AVI into VirtualDub and then go to streams and then report, you can actually see already that the video length and audio length will be different. However, if you import a video encoded with XviD containing PCM WAV audio the length of both the audio and video are identical to the millisecond. So little difference in milliseconds can make a huge difference. Most people probably wouldn't notice a small 20 millisecond difference, but to AMV editors (and especially the creator of the video) they would notice the smallest difference in sync.