PDA

View Full Version : X264 encoding with VFW gets desynched


3ngel
2nd April 2006, 00:06
Hi,
i've encoded and avi with the latest buil of x264 on Virtualdub. I encode in .mkv but the audio in the output .mkv results desynched, more exactly results anticipated by various msecs.
What's the reason?

Sirber
2nd April 2006, 00:15
settings?

foxyshadis
2nd April 2006, 00:17
Same reason anything else gets desynched. You have the wrong framerate, didn't correct for a delay in the audio, or both. This has nothing to do with x264, which can only add a fraction of a second delay in a single encode (unless you're re-encoding from another x264 avi for some bizarre reason?).

shon3i
2nd April 2006, 00:21
what is format of audio mp3,aac something elese, if you use aac you should be get desynch and did you apply delay value.

3ngel
2nd April 2006, 00:23
@Sirber
These are the settings
http://img447.imageshack.us/img447/1338/pic13ir.png
http://img447.imageshack.us/img447/3139/pic27qa.png
http://img308.imageshack.us/img308/6193/pic32jc.png

@shon3i
The format is Ac3

@foxyshadis
I'm not a newbe, so please stop doing such useless posts... thanks.

shon3i
2nd April 2006, 00:38
If you have fps 23.976 then in min/max IDR interval put 24/240 becouse 23.976 is almost 24 not 23, but that is less important.Is in that ac3 filename show some delay 23ms or something like that, other optinos seem to be fine, and you can incrase litle ref frames, min 3.

ChronoCross
2nd April 2006, 00:39
Your a n00b if your using vfw with x264. anyway if your making a mkv using virtualdub mod it may not be compatible as the mkv libs it's using are outdated by a few years. you should be outputting to avi then merging using mkvtoolnix. also vdubmod doesn't output vfr very well.

3ngel
2nd April 2006, 01:00
@shon3i
No, the delay is more than 23ms. Ok i'll increase ref frames anyway.

@ChronoCross
Using VFW has nothing to do with noob, 'cause it's a my precise choice using Vdub, even because Megui crashes on my system when i try to input the .avs.
Anyway, i suspected it was a Vdub question regarding mkv and vfr. Even if i remux the resulting mkv with mkvtoolnix the results is (obviously) the same.
So apart from vdub (possibly outdated) and MeGui (that doesn't work on my system), what are other x264 GUIs available?

dragongodz
2nd April 2006, 05:48
Anyway, i suspected it was a Vdub question regarding mkv and vfr.
if thats true then this is the wrong section to be posting in.

since you posted here i have to assume you atleast suspect it may be x264 related aswell. since you are using VFW the thread you should probably have posted to is this one if you think its a bug
http://forum.doom9.org/showthread.php?t=108569

i will say though looking at your settings the first thing i would suggest is to change the max consecutive B frames to 1 and try again. or even 2 with use as reference unticked.

EDIT: i have reported this thread to bond so he can decide what should happen to it and where it should be.

foxyshadis
2nd April 2006, 06:13
b-frame = 1 frame lag = 40 ms. b-pyramid = 2 frame lag = 80 ms. If this doesn't describe your symptoms then you screwed up elsewhere. Note that when I said, "didn't correct for a delay in the audio" I meant both the dvd as well as the b-frame lag if applicable.

Now, if you mux to mkv with timecodes from avi, any number of insane things could happen due to that lag, unless you first extract to raw, mux to mp4, and remux to mkv.

Try mencoder, SUPER, or MKVMagic as alternates to .net 2 guis.

Sirber
2nd April 2006, 06:32
also, 1 ref is not much. Get 8 or 12 with mixed refs :)

dragongodz
2nd April 2006, 07:18
b-frame = 1 frame lag = 40 ms. b-pyramid = 2 frame lag = 80 ms. If this doesn't describe your symptoms then you screwed up elsewhere.
look at his settings and you see he has max B frames set to 4 and use as reference(b-pyramid) ticked aswell.

foxyshadis
2nd April 2006, 07:30
I saw, I'm just laying it out so he knows.

bond
2nd April 2006, 11:14
there are two possible reasons for desync:
1) if constant desync: wrong audio/video delay
2) if increasing desync: wrong video framerate

3ngel
2nd April 2006, 12:11
First, thanks for the replies.
Now back to the matter. In the end i managed to startup Megui so i did a test with the cli version and the output was perfect without desynch. So i thought it was something related with the VFW version.
But analyzing better the VirtualDub results, i noted that even correcting the initial lag there was along the time a sort of "weaving" lag, that is now a little anticipated, some time after a little delayed and so on.
This is a clear sign of a variable bitrate behavior, and so my conclusion is that suggested some posts above, that is VirtualDub mkv routine is outdated and isn't able to cope with vfr properly.
At this point i don't know any other program that can use vfw and output correct mkv (excluding Graphedit+matroska muxer), and so until the vdub routine will be updated, there is no way to use the VFW version in a productive way.
Some of you knows about some other VFW virtualdub like that are able to output correct mkv?

@foxyshadis
I dont's like .net programs so i'll try then, thanks.

@dragongodz
I had the suspect first of x264 and as last chance of vdub, for this reason i posted here. Anyway atm i don't know for sure it's a vdub related question, 'cause i don't know other vfw apps to do comparison.

dragongodz
2nd April 2006, 12:16
could you try with max b frames set to 1 anyway and see if that shows the same behaviour or not ?

3ngel
2nd April 2006, 12:21
Yes, i can do it. Vdub with bframe=1. Not exactly now, but as soon as.

foxyshadis
2nd April 2006, 12:30
Are you actually using vfr, with dedup or tdec mode 5, with fps set to the average fps? Or importing a vfr file with directshowsource without using convertfps? Those absolutely won't work in avi, and mkv in vdub is basically just avi wrapped in mkv (which can support vfr, but only without b-frames). Ripping to a raw stream or creating one from the start is basically the only way to fix it, and you'd still have to have the correct timecodes to do it.

However, if you aren't using dedup or tdec mode 5, or dss, vfr wouldn't have anything to do with it.

3ngel
2nd April 2006, 13:14
It's a simple avi with fixed frame rate, so i think it can be what you say
(which can support vfr, but only without b-frames)
I'll test vdub with no-bframe (1b frame) to see its behaviour.

bond
2nd April 2006, 13:19
there are two possible reasons for desync:
1) if constant desync: wrong audio/video delay
2) if increasing desync: wrong video framerate<- so which one is the case for you?

LoRd_MuldeR
2nd April 2006, 13:21
So apart from vdub (possibly outdated) and MeGui (that doesn't work on my system), what are other x264 GUIs available?

You should give AviDemux a try :)
Looks similar too VDub, but built-in x264 and XviD encoders. Plus a lot of output formats...

http://img45.imageshack.us/img45/8413/avidemux8wx.th.png (http://img45.imageshack.us/my.php?image=avidemux8wx.png)

3ngel
2nd April 2006, 13:31
@bond
A new case
03) Waving desynch (first too soon, then too late)
:D

@LoRd
Thanks, i'll give it a try
EDIT : i've seen that AviDemux doesn't support .mkv output so it's not useful to my needing

dragongodz
2nd April 2006, 13:52
03) Waving desynch (first too soon, then too late)
ok WTF ? that does sound more like a VFR problem but you say
It's a simple avi with fixed frame rate

i see you say the audio format is ac3, is that input or output ?
can you go in to a bit more detail exactly what you are doing ?

3ngel
2nd April 2006, 14:03
No, the input is ac3 avi cfr, but the output will be x264 mkv vfr, and at this point vdub (i think) mess up in creating the vfr matroska (containing the x264).

bond
2nd April 2006, 14:34
virtualdub uses vfw and vfw can never handle vfr...

shon3i
2nd April 2006, 15:08
@bond i must ask you one simple question: How to make vfr with XviD or x264, i read mp4 guide but i can understand anything. Is good to use vfr for DVD backups.

bond
2nd April 2006, 15:21
well i still believe in vfr being a nice thingie and with squid's xvid_encraw its already possible to encode with xvid directly into a vfr mkv file

i would say vfr makes sense the most for videos where lots of very similar frames are used (eg cartoons aso), for other videos it might not bring that much (but hey, its still an interesting tech :D )

DigitalDeviant
2nd April 2006, 16:13
How to make vfr with XviD or x264, i read mp4 guide but i can understand anything. Is good to use vfr for DVD backups.

Vfr mkv files are usualy created by using avisynth filters (dedup and tdecimate modes 3 and 5.) This creates a video file with all your frames and a timecode file. You then mux the timecode file wilth the video file in another application like mkvtoolnix. Vdubmod cannot do this.

shon3i
2nd April 2006, 18:04
@DigitalDeviant can you explain this litle more better or give some sample of avs script. Thanks

Wilbert
2nd April 2006, 18:20
http://www.avisynth.org/VariableFrameRateVideo#create-vfr-mkv

DigitalDeviant
2nd April 2006, 18:38
It would also be helpful if we knew more about your source and what you're trying to accomplish here. Why exactly are you trying to make a vfr file out of this cfr avi?

3ngel
2nd April 2006, 19:06
It's x264 that automatically makes it vfr.

Sirber
2nd April 2006, 19:14
x264 is not VFR...

ChronoCross
2nd April 2006, 19:21
x264 does direct output of a vfr. however it doesn't play correctly cause it does not create a timecoded mp4 or mkv. YOu have to remerge it with audio using an external vfr file. Then it works fine. This features does not work in vdub matroska. which is why you shouldn't be using it to make vfr mkv.

shon3i
2nd April 2006, 19:42
@Wilbert Thanks.

foxyshadis
2nd April 2006, 20:19
Next time I edit the VFR page (I have one or two other things I want to add later) I'll make sure to add a strong warning that VFR cannot work with virtualdub/vfw with b-frames, unless you play the avi->raw->mp4->mkv dance (and link to bond's batch file for it).

VFR makes great sense, in fact it's the only sensible way to store hybrid dvds in progressive form. (I don't consider 120 fps sensible, unless you use avi.) For regular animation using dedup is more of an advanced bit of wanking, it's going to make your life harder for very little end gain and much messier 3rd party tool support (though I continue to do it xD).

3ngel, since you're using vfw-mode perhaps you should use 120 fps instead. Wilbert linked to the docs for avi_tc above.

3ngel
2nd April 2006, 21:00
No foxy, now we have discovered vdub isn't able to cope with vfr, i think i'm forced to use cli encoder with gui (or at least Graphedit + MatroskaMuxer if tests are positive on this last).

foxyshadis
2nd April 2006, 22:13
MatroskaMuxer.ax will only mux to vfr if your source file is already in vfr. Since your avi isn't, it won't work.

3ngel
2nd April 2006, 22:30
But putting into MatroskaMuxer the result of x264 compression (that is vfr) it should to work.

Avi -> VideoCompressor(x264) -> MatroskaMuxer -> FileWriter(.mkv)

foxyshadis
2nd April 2006, 23:41
No, it won't. Codecs can't do vfr, that's a container thing. ASP (xvid) with n-vops is the only thing that comes close, and it's fairly random, although by muxing to mp4 or mkv it'll drop those frames. AVC does not have null frames, the output of x264 is always cfr, except through DirectShow. (Although if the parser was smart enough it might be able to recognize entire skip frames and cut them out, none do.) Your method could work if you were coming from a vfr file directly, but avi is also always cfr, so you'll waste a lot of time to end up with what you had before. Unless that avi is the original with 120 fps, which brings a whole new set of issues.

You still haven't explained exactly what you're doing, so I have to try to guess and play psychic, but I'd say you're importing an existing vfr video and setting it to its average fps (ie, 27.67 or whatever). Thus, it's incorrect before it ever touches the x264 compressor, so how could the muxer realize it's vfr and resync it? If you are doing that, you need to extract the timecodes from the original and remux with them.

Hans Ohlo
3rd April 2006, 09:06
hi,
i lately have a very similar problem with nero recode (AVC) files.
i prepare a normal ivtc avs script for a 1080i to 720p conversion. the d2v source is done with the latest dgindex. i used telecide() and decimate() as well as the TIVTC functions with the same result.

now after muxing (mkvtoolnix) the audio to the mp4 file the sound is correct at the beginning and totally off at the end (to early). i can fix thes with the stretch option in mkvmuxgui but this is no satisfying solution for me.

foxyshadis
3rd April 2006, 10:06
This is a normal fps problem, compared to 3ngel's vfr problem. Even if you aren't muxing from raw the framerate must be getting reset somewhere, try muxing to mp4 using -fps 23.976 or muxing to mkv with a timecode file like below. This should correct your drift.


# timecode format v1
Assume 23.976000


If not, find out what the current framerate is and how far off the audio is at the end, see if you can calculate what fps you want and use that instead.

3ngel
3rd April 2006, 10:30
Foxyshadis, i'm not doing something off the world: i have a simple progressive 23.976 avi with audio, that i want to compress to x264. With vdub and x264 the result is a desyinched vfr .mkv. With Megui the result is correct. As far as now we've understood vdub isn't able to costruct a properly vfr .mkv, so i thought pheraps graphedit + matroskamuxer would do the job, because VFWx264 compressor (used by vdub) generates a vfr raw 264, but that is not written correctly by vdub in mkv. So pheraps MatroskaMuxer would write correctly the vfr gerated by x264. That's all.

Hans Ohlo
3rd April 2006, 11:02
This is a normal fps problem, compared to 3ngel's vfr problem. Even if you aren't muxing from raw the framerate must be getting reset somewhere, try muxing to mp4 using -fps 23.976 or muxing to mkv with a timecode file like below. This should correct your drift.
i tried demuxing the mp4 and muxing it with the fps option, but it still remained desynced.


# timecode format v1
Assume 23.976000


i will try that, thanks.