On disc? Sure. Via download? Fsck no!irriadin wrote:Could I submit my videos via disc in lossless .AVI using something like Lagarith / UTVideo?
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.Melichan923 wrote:The thing is, I upgraded to the newest version of Zarx in February and I continue to have this issue. My very first encode with it came out fine, but I think that was a coincidence. The demuxing and replacing with a delayed mp3 and remuxing solution works sometimes, but still I can see an ever so slight difference from the test previews with other codecs I render from Vegas. Maybe another container will work like you said.
The playback sync hell is only because of the different ways in which different playback methods handle the files that are often created under different standards. That said, I still prefer x264/AAC MP4 for a main release when x264 is encoded under Level 3.1 or 4.1 standards to have compatibility with other devices, allowing those who download the videos to easily playback the videos on multiple devices. I check the sync of videos on multiple devices before releasing a video to ensure a good cross platform compatibility with the best sync I can offer. I have no problem having multiple downloads and having a MKV version available, but I prefer not to force someone to have to re-encode a video to have the ability to playback the video on their portable devices, gaming console, or Blu-ray player.mirkosp wrote:I'll also note here that muxing with x264 with the l-smash patch and using als audio has proven to be the most sync safe solution in mp4, as extensively tested by Quu. Quite obviously, since als does not employ mdct.
So yes... mp4 and aac make for some major playback hell as far as sync goes. Hence why one should just use mkv and another audio format (ones that don't use mdct) for online distro. Makes it a lot easier. >_>
Or yes, als audio in mp4, if one is so inclined, but you know, fuck that.
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...l33tmeatwad wrote: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.
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.mirkosp wrote: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.
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).Scintilla wrote: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...l33tmeatwad wrote: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.
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?
No, you are forgetting one very important thing that depends on the level as well. REFERENCE FRAMES.l33tmeatwad wrote: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 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.I think the one thing we do agree on is the use of 10bit encoding needing to come about faster.
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.mirkosp wrote: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.
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...mirkosp wrote: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.I think the one thing we do agree on is the use of 10bit encoding needing to come about faster.
Questions:Melichan923 wrote:mirkosp wrote:converting the original PCM Audio to mp3 and adding ___ amount of milliseconds to the beginning like I've been doing...
