Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th May 2013, 21:46   #1  |  Link
Soukyuu
Registered User
 
Soukyuu's Avatar
 
Join Date: Apr 2012
Posts: 169
Trim causing weird errors when feeding .avs to x264

I'm not sure if this is the right section. I'm using MeGUI (newest version) to encode a couple of MJPEG avi files to h264.

The .avs is quite simple:

AviSource("file.avi", audio = true)
Trim(72,5463)
ConvertToYV12()

It does work for most files, but now I stumbled upon a few that show the following behavior: let's say the video is composed from parts a-b-c-d. If i comment out the Trim() line, the h264 output is as expected, a-b-c-d. However if I leave the Trim() line I get something along the lines of a-b-c-d-d squeezed into the same duration of the original file.

Obviously the audio is out of sync. I also noticed that the encoding process on those files that show this behavior is twice as slow when Trim() is uncommented, so I suspect it might have something to do with avisynth.

From what I see, MEGui uses avs 2.5.8 and I'm using the mp4 muxer to mux the audio and video. Do you have any idea what the problem might be?
Soukyuu is offline   Reply With Quote
Old 17th May 2013, 21:52   #2  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
If it views OK in VirtualDub, then it must be a MeGUI problem.
View in VD and scroll forwards/backwards, is it OK ?
Does "Newest Version" mean development version, or v2341 ?

Zathor visits here so he should see your thread.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 17th May 2013 at 21:54.
StainlessS is offline   Reply With Quote
Old 17th May 2013, 21:58   #3  |  Link
Soukyuu
Registered User
 
Soukyuu's Avatar
 
Join Date: Apr 2012
Posts: 169
The preview is fine in either program, only the encoded output is mangled. By "the newest version" I mean the one served by the update, so yes, 2341
Soukyuu is offline   Reply With Quote
Old 19th May 2013, 18:18   #4  |  Link
Soukyuu
Registered User
 
Soukyuu's Avatar
 
Join Date: Apr 2012
Posts: 169
I tested further and it looks like it's the first parameter of trim that is causing this. For example, if I change the line to Trim(0,5463), everything works fine, but as soon as I change the first parameter to anything else, encoding speed gets halved and the output is mangled.

I have installed avisynth 2.5.8 ST 32-Bit and got the x264.exe (32-bit, 8-bit output) from the x264.nl site and same behavior can be seen.
Furthermore, encoding with virtualdub shows exactly the same behavior as well - no matter the codec.

So for me it looks like 100% avisynth's at fault here.

edit: one more thing: even re-encoding said videos to huffyuv doesn't fix this, so it doesn't seem to be codec-related either. The filesize of the input files is about 1,96GB, so shouldn't be 32-bit limited (although the huffyuv variant is 8GB, so that might be a problem)

edit2: 2.6.0 shows same behavior as well

Last edited by Soukyuu; 19th May 2013 at 18:48.
Soukyuu is offline   Reply With Quote
Old 19th May 2013, 19:28   #5  |  Link
creaothceann
Registered User
 
Join Date: Jul 2010
Location: Germany
Posts: 357
It sounds to me as if the input's video codec can't handle non-linear frame access correctly. I'd dump the raw video data with e.g. x264's lossless mode to a temporary file.

IIRC if you have a codec pack like k-Lite you can select which codec is assigned to MJPEG.

Just fmi, what is your video resolution and framerate?
creaothceann is offline   Reply With Quote
Old 19th May 2013, 19:36   #6  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,340
MJPEG is I-frame only, so source shouldn't have problem with linear access

If the preview is ok, the encode should be ok - so your observation don' t make sense to me...
poisondeathray is offline   Reply With Quote
Old 19th May 2013, 19:42   #7  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Quote:
even re-encoding said videos to huffyuv doesn't fix this
Do you mean you loaded directly into Vdub and re-encoded as HUFFYUV, and THEN retried via avisynth ?

By the way, UT Video is pretty good, I Almost never use HuffYUV now, YV12 and YUY2 codecs available.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 19th May 2013, 21:33   #8  |  Link
creaothceann
Registered User
 
Join Date: Jul 2010
Location: Germany
Posts: 357
Quote:
Originally Posted by poisondeathray View Post
MJPEG is I-frame only, so source shouldn't have problem with linear access

If the preview is ok, the encode should be ok - so your observation don' t make sense to me...
VDub may decode MJPEG internally instead of using a system-wide codec.
creaothceann is offline   Reply With Quote
Old 19th May 2013, 21:51   #9  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,340
Quote:
Originally Posted by creaothceann View Post
VDub may decode MJPEG internally instead of using a system-wide codec.
Yes if you load the video directly.

I think he is checking the .avs script preview AVISource(), which won't use vdub's internal MJPEG decoder - how else would he preview Trim() ?

Eitherway, MJPEG is intra only, and not prone to decoding out of order issues like long GOP formats
poisondeathray is offline   Reply With Quote
Old 19th May 2013, 23:20   #10  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
I'd be suspecting a decoding problem rather than an AVISynth problem as such, although it doesn't seem logical Trim() seems to be working as it should in the preview but not when encoding. Not having any idea why that'd happen.... things I'd try (in no particular order):

Open the AVI with VirtualDub or VirtualDubMod, edit it as required and save it as a new AVI using DirectStreamCopy for the video and audio. Then you can encode the new AVI without using Trim().

If you use AVISource try making sure the frame rate is correct. As an example: AVISource("file.avi", audio = true).AssumeFPS(25,1)

Don't use AVISource. Use MeGUI's file indexer to index and open the video instead.

If indexing the AVI doesn't help, remux the AVI as an MKV with MKVMergeGUI (or MeGUI's muxer) and then open the MKV for indexing and encoding.

Convert the video to a lossless format without Trim() and then use Trim() while re-encoding the lossless version. If you tick MeGUI's "Add pre-rendering job" before adding the video encoding job to the queue, MeGUI should convert it to a lossless format for you. Or you could do it with VirtualDub(Mod) either by opening the AVI directly or via the AVISynth script.
hello_hello is offline   Reply With Quote
Old 20th May 2013, 01:09   #11  |  Link
Soukyuu
Registered User
 
Soukyuu's Avatar
 
Join Date: Apr 2012
Posts: 169
Quote:
Originally Posted by creaothceann View Post
Just fmi, what is your video resolution and framerate?
1080p30, recorded with MSI afterburner

Quote:
Originally Posted by StainlessS View Post
Do you mean you loaded directly into Vdub and re-encoded as HUFFYUV, and THEN retried via avisynth ?

By the way, UT Video is pretty good, I Almost never use HuffYUV now, YV12 and YUY2 codecs available.
Yes, then loaded the huffyuv avi instead of the mjpeg with .avs

Quote:
Originally Posted by hello_hello View Post
I'd be suspecting a decoding problem rather than an AVISynth problem as such, although it doesn't seem logical Trim() seems to be working as it should in the preview but not when encoding.
The funny thing is that other video files recorded with exactly the same parameters are fine while these 5 freak avs (or the decoder) out -_-

Quote:
If you use AVISource try making sure the frame rate is correct. As an example: AVISource("file.avi", audio = true).AssumeFPS(30,1)
Did that, the file got encoded as 21,1fps @_@

Quote:
Don't use AVISource. Use MeGUI's file indexer to index and open the video instead.
No change except the indexer shows around 3.8k frames instead of 5.4k without the indexer

Quote:
Convert the video to a lossless format without Trim() and then use Trim() while re-encoding the lossless version.
Doing this with a x264 lossless version makes both the indexer and MEGui hang, then crash (file size = 3GB)

Quote:
Open the AVI with VirtualDub or VirtualDubMod, edit it as required and save it as a new AVI using DirectStreamCopy for the video and audio. Then you can encode the new AVI without using Trim().
This worked. I remember doing that way back when AVI was the typical container and remember stopping because cutting wasn't frame-exact most of the time. Is MJPEG safe because it doesn't have keyframes?

Still, I'm rather curious what is failing here. Is there any way I can provide more information so that someone could take a look at it?
Soukyuu is offline   Reply With Quote
Old 20th May 2013, 01:48   #12  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
How bout doing last step above, but without any trimming, just direct stream copy to a new file, and then trim in AVS.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 20th May 2013, 01:58   #13  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
Avisynth 2.6.0 alpha 4 include a new filter Preroll(video=0, Audio=0.0) which may help with recalcitrant sources that malfunction with random access.
Code:
...Source("...dodgy...")
Preroll(Video=25, Audio=10.0) # 25 frame video preroll, 10.0 seconds audio preroll
Trim(1234, 5678)
....
It works by detecting any out of order access in the audio or video track, and seeking the specified amount earlier in the stream and then taking a contiguous run up to the desired frame or audio sample. Skipping forward less than the preroll values results in linear access behaviour, i.e. all the intervening samples are accessed and discarded.

For earlier versions you can try adding a ChangeFPS(Last, Last, True) after the source filter, it's linear access feature may give enough protection to circumvent the issue. For audio issues it can be a softer option than the brute force EnsureVBRMP3Sync().

The best solution of course is to use source filters with accurate random access behaviour.
IanB is offline   Reply With Quote
Old 20th May 2013, 09:15   #14  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,821
Quote:
Originally Posted by Soukyuu View Post
This worked. I remember doing that way back when AVI was the typical container and remember stopping because cutting wasn't frame-exact most of the time. Is MJPEG safe because it doesn't have keyframes?
I don't know much about mjpeg but I think it's all keyframes (as such) so you can cut it anywhere as normally you can only cut on keyframes without re-encoding.
If you hold down the shift key while using the VirtualDub navigation slider thingy, it'll only stop on keyframes, and of course there's the keyframe buttons which navigate back and forth between them.

Quote:
Originally Posted by Soukyuu View Post
Still, I'm rather curious what is failing here. Is there any way I can provide more information so that someone could take a look at it?
I used to do a lot of wondering until I realised it was driving me slowly mad. Now I mostly accept it when something works and try not to think about it.
As StainlessS suggested, you could try remuxing the original AVI (DirectStremCopy) without editing it to see if using Trim() will work correctly with the newly muxed version. Maybe the original AVIs have some sort of problem which remuxing will fix? Or you could try remuxing one as an MKV and re-encoding it instead. The "why" is largely over my head.

I tend to be lazy with "problem" video these days. If something won't encode correctly and remuxing doesn't fix it I'll open it with VirtualDubMod via a DirectShow script and convert it to a lossless format and work with that instead. Either huffyuv or ffv1. I've never used x264 lossless myself. For all it's shortcomings DirectShow will generally keep on decoding files which cause other decoding methods to spit the dummy.... as long as you encode the entire video from start to finish.

Video To Video Converter and AnyVideoConverter are a couple of programs which seem to cope with problem files fairly well. Especially when the usual conversion methods cause audio sync issues for no apparent reason. I don't use either program for much else, but if all else fails I'll open a problem video with one of those programs, convert it to a lossless format, then re-encode the lossless version the usual way.
hello_hello is offline   Reply With Quote
Old 20th May 2013, 14:52   #15  |  Link
Soukyuu
Registered User
 
Soukyuu's Avatar
 
Join Date: Apr 2012
Posts: 169
It seems to be a muxing issue after all. I made a direct stream copy and used the same .avs to load the new file and it went without a hitch. The newly muxed .avi also seems to be quite bigger than the original, for example 2,96GB instead of 2,0GB. Maybe MSI afterburner is using some sort of weird compression when muxing the avi? Who knows.

Thanks for the help.
Soukyuu is offline   Reply With Quote
Old 21st May 2013, 10:44   #16  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
VD does clean up junk chunks when you do a direct stream copy (temporary chunks written by some AVI file writers), perhaps it does more corrections,
you probably found the file got a little smaller unless you wrote uncompressed audio (sometimes a good idea).
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 21st May 2013, 12:08   #17  |  Link
Soukyuu
Registered User
 
Soukyuu's Avatar
 
Join Date: Apr 2012
Posts: 169
Hmm, no, the file actually grows after direct stream copy, though not by much. Depends on the file, about 10-20MB for a 2 minute file. Both the source and the resulting one have a 6ch wav as audio.
Soukyuu is offline   Reply With Quote
Reply

Tags
avs, error, trim

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:13.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.