xvid_encraw - Patched with AviSynth input support

[squid_80]

Good Idea ! but don't drop support for old command line zonesI won't. I'm trying hard not to bork any of the original options for backwards compatability.
how are you detecting fake n-vops now?
btw its not possible to deactivate real n-vops placement in xvid
fake n-vop=a n-vop that follows a b-vop when using packed bitstream.
The real ones that show up when frame-drop=0 are identical to the frame before, so the artifacts aren't visible.
about zones: why not simply do it like other cmdl tools (mp4box, mencoder...):
you specify a zone via -zone and than add specific commands you want right after
it with a ":"

like -zone startframe=3000:weight=0.5:cartoonmode:greyscale

that would be straight forward and easy to set and understand
There will be something like that; I was going to go with doom9's suggestion since it's nice and compact ( http://forum.doom9.org/showthread.php?p=702759#post702759 ) but drop the end zone parameter.

Something I forgot: -pass1 and -pass2 default to using xvid.stats as the statsfile if one isn't specified. Also packed bitstream is disabled if avi output isn't used - this may cause slight oversize in the second pass, we'll see what happens.

[bond]

There will be something like that; I was going to go with doom9's suggestion since it's nice and compact ( http://forum.doom9.org/showthread.php?p=702759#post702759 ) but drop the end zone parameter. nice, tough i prefer a = instead of a , for signalling what belongs together, but thats a matter of taste

Also packed bitstream is disabled if avi output isn't used - this may cause slight oversize in the second pass, we'll see what happens. great!
tough disabling packed bitstream or not should not make any difference on the stream (except the n-vops of course) as packed bitstream is only a "packing mode" on how frames are stored. if with or without packed doesnt give the same results there is a bug (maybe its the same bug i mentioned on the maillist)

[squid_80]

tough disabling packed bitstream or not should not make any difference on the stream (except the n-vops of course) as packed bitstream is only a "packing mode" on how frames are stored. if with or without packed doesnt give the same results there is a bug (maybe its the same bug i mentioned on the maillist)

I wouldn't really label it a bug; just that the statsfile is different depending if packed or nopacked is used, due to each fake n-vops taking up a few bytes. I *think* rate-control will compensate for it, if it does the stream will be encoded differently (when comparing packed/unpacked) and if not there might be a slight oversize. I'll have to do more tests.

[bond]

as i understand it the stats file should be exactly the same no matter if packed bitstream is enabled or not

[squid_80]

BUG: when using raw input and not specifying a maximum number of frames, EVERY frame is encoded as a P frame. Whoops!

[squid_80]

New build with -zones parameter, should work as described except there's no end frame parameter; a zone lasts until the start of the next one just like vfw. There will probably be a bug or two, please report any problems.

Edit: sorry, as described here: http://forum.doom9.org/showthread.php?p=702759#post702759

[JoeBG]

New build with -zones parameter, should work as described except there's no end frame parameter; a zone lasts until the start of the next one just like vfw. There will probably be a bug or two, please report any problems.

Edit: sorry, as described here: http://forum.doom9.org/showthread.php?p=702759#post702759


Where is the download? :) :thanks:

[squid_80]

Same as before; ftp://squid80.no-ip.com/xvid_encraw.zip or http://okejl.dk/dunstan/xvid_encraw.zip

[woah!]

hi again.

so i see that the 29fps bug id faxed now as i get 29.97 fps :)

now to the next question, is pass2 borked? i cant get a readable output file from any encode i do pass2 :(

same setting in either quant or bitrate mode is fine, but 2pass crashes mpc.

pity as its nearly there isnt it ..


heres my cmd line:

xvid_encraw.exe -i file.avs -type 2 -pass1 file.stats -framerate 29.970000 -qtype 1 -lumimasking -bitrate 1830

xvid_encraw.exe -i file.avs -type 2 -pass2 file.stats -o file.avi -framerate 29.970000 -qtype 1 -lumimasking -bitrate 1830

no avi output file for 1st pass only for the second

nothing to fancy as you see.

[squid_80]

<edited out rubbish>

-o is for saving an elementary stream. -avi is for saving an avi file. Use -avi instead.

[woah!]

trim(30000, 30230)

file is small as i am trying to get this to work before i go with a full encode.

i am encoding about 44mins of 1920x1080i HD source to 704x400 and i have no issues doing the same avs script using mencoder.

[woah!]

noooooo say it aint so, how did i miss that heh... couldnt see the forest for the trees.. thx for this it is now working great :)

[Doom9]

@squid: are the new zone options actually in and just the cli help is not up-to-date? Also, now that it seems the missing options are supported, any chance of a -threads parameter?

[squid_80]

Yeah I haven't got around to updating the help screen. But they should be working. (except the -zonefile idea I had, haven't done that yet.)
-threads I can put in, but it won't actually do anything until we get a fixed SMP version of xvidcore which doesn't have the number of threads hardcoded.

[JoeBG]

Can I have a list of all options? I just thought zones and mkv are new.

[squid_80]

c:\>xvid_encraw -help
xvid_encraw built at 22:29:08 on Feb 9 2006
Usage : xvid_encraw [OPTIONS]

Input options:
-i string : input filename (stdin)
-type integer: input data type (yuv=0, pgm=1, avi/avs=2)
-w integer: frame width ([1.2048])
-h integer: frame height ([1.2048])
-frames integer: number of frames to encode

Output options:
-dump : save decoder output
-save : save an Elementary Stream file per frame
-o string : save an Elementary Stream for the complete sequence
-avi string: save an AVI file for the complete sequence
-mkv string: save a MKV file for the complete sequence

BFrames options:
-max_bframes integer: max bframes (2)
-bquant_ratio integer: bframe quantizer ratio (150)
-bquant_offset integer: bframe quantizer offset (100)

Rate control options:
-framerate float : target framerate (25.0)
-bitrate [integer] : target bitrate in kbps (700)
-single : single pass mode (default)
-cq float : single pass constant quantizer
-pass1 [filename] : twopass mode (first pass)
-full1pass : perform full first pass
-pass2 [filename] : twopass mode (2nd pass)
-zq starting_frame float : bitrate zone; quant
-zw starting_frame float : bitrate zone; weight
-max_key_interval integer : maximum keyframe interval (300)

Single Pass options:
-reaction integer : reaction delay factor (16)
-averaging integer : averaging period (100)
-smoother integer : smoothing buffer (100)

Second Pass options:
-kboost integer : I frame boost (10)
-kthresh integer : I frame reduction threshold (1)
-kreduction integer : I frame reduction amount (20)
-ostrength integer : overflow control strength (5)
-oimprove integer : max overflow improvement (5)
-odegrade integer : max overflow degradation (5)
-chigh integer : high bitrate scenes degradation (0)
-clow integer : low bitrate scenes improvement (0)
-overhead integer : container frame overhead (24)
-vbvsize integer : use vbv buffer size
-vbvmax integer : vbv max bitrate
-vbvpeak integer : vbv peak bitrate over 1 second

Other options
-noasm : do not use assembly optmized code
-turbo : use turbo presets for higher encoding speed
-quality integer : quality ([0..6]) (6)
-vhqmode integer : level of R-D optimizations ([0..4]) (1)
-bvhq : use R-D optimizations for B-frames
-qpel : use quarter pixel ME
-gmc : use global motion compensation
-qtype integer : quantization type (H263:0, MPEG4:1) (0)
-qmatrix filename : use custom MPEG4 quantization matrix
-interlaced : use interlaced encoding
-nopacked : Disable packed mode
-noclosed_gop : Disable closed GOP mode
-lumimasking : use lumimasking algorithm
-stats : print stats about encoded frames
-debug : activates xvidcore internal debugging output
-vop_debug : print some info directly into encoded frames
-nochromame : Disable chroma motion estimation
-notrellis : Disable trellis quantization
-imin integer : Minimum I Quantizer (1..31) (2)
-imax integer : Maximum I quantizer (1..31) (31)
-bmin integer : Minimum B Quantizer (1..31) (2)
-bmax integer : Maximum B quantizer (1..31) (31)
-pmin integer : Minimum P Quantizer (1..31) (2)
-pmax integer : Maximum P quantizer (1..31) (31)
-drop integer : Frame Drop Ratio (0..100) (0)
-start integer : Starting frame number
-par integer[:integer] : Set Pixel Aspect Ratio.
1 = 1:1
2 = 12:11 (4:3 PAL)
3 = 10:11 (4:3 NTSC)
4 = 16:11 (16:9 PAL)
5 = 40:33 (16:9 NTSC)
other = custom (width:height)
-help : prints this help message

NB: You can define 64 zones repeating the -z[qw] option as needed.
-zones integer,q/w,float[,flags]
integer = start frame of zone
q/w = q for quantizer zone or w for weight zone
float = quant or weight (floating point value)
optional flags = K for start with keyframe, C for cartoon mode, O for chroma optimizer, G for greyscale or an integer for BVOP sensitivity. Order isn't important.
No spaces anywhere in the zones options.
Separate multiple zones with / . Or I guess you could use multiple -zones but I haven't tested it since it wasn't designed this way.
Also there's a -packed option to force packed bitstream on since it's off by default if there's no .avi output. Kinda weird I know but as we've discussed the bitstream setting affects what is written to the statsfile and that in turn has a substantial effect on the final encoded stream.

[JoeBG]

c:\>xvid_encraw -help
xvid_encraw built at 22:29:08 on Feb 9 2006
Usage : xvid_encraw [OPTIONS]

Input options:
-i string : input filename (stdin)
-type integer: input data type (yuv=0, pgm=1, avi/avs=2)
-w integer: frame width ([1.2048])
-h integer: frame height ([1.2048])
-frames integer: number of frames to encode

Output options:
-dump : save decoder output
-save : save an Elementary Stream file per frame
-o string : save an Elementary Stream for the complete sequence
-avi string: save an AVI file for the complete sequence
-mkv string: save a MKV file for the complete sequence

BFrames options:
-max_bframes integer: max bframes (2)
-bquant_ratio integer: bframe quantizer ratio (150)
-bquant_offset integer: bframe quantizer offset (100)

Rate control options:
-framerate float : target framerate (25.0)
-bitrate [integer] : target bitrate in kbps (700)
-single : single pass mode (default)
-cq float : single pass constant quantizer
-pass1 [filename] : twopass mode (first pass)
-full1pass : perform full first pass
-pass2 [filename] : twopass mode (2nd pass)
-zq starting_frame float : bitrate zone; quant
-zw starting_frame float : bitrate zone; weight
-max_key_interval integer : maximum keyframe interval (300)

Single Pass options:
-reaction integer : reaction delay factor (16)
-averaging integer : averaging period (100)
-smoother integer : smoothing buffer (100)

Second Pass options:
-kboost integer : I frame boost (10)
-kthresh integer : I frame reduction threshold (1)
-kreduction integer : I frame reduction amount (20)
-ostrength integer : overflow control strength (5)
-oimprove integer : max overflow improvement (5)
-odegrade integer : max overflow degradation (5)
-chigh integer : high bitrate scenes degradation (0)
-clow integer : low bitrate scenes improvement (0)
-overhead integer : container frame overhead (24)
-vbvsize integer : use vbv buffer size
-vbvmax integer : vbv max bitrate
-vbvpeak integer : vbv peak bitrate over 1 second

Other options
-noasm : do not use assembly optmized code
-turbo : use turbo presets for higher encoding speed
-quality integer : quality ([0..6]) (6)
-vhqmode integer : level of R-D optimizations ([0..4]) (1)
-bvhq : use R-D optimizations for B-frames
-qpel : use quarter pixel ME
-gmc : use global motion compensation
-qtype integer : quantization type (H263:0, MPEG4:1) (0)
-qmatrix filename : use custom MPEG4 quantization matrix
-interlaced : use interlaced encoding
-nopacked : Disable packed mode
-noclosed_gop : Disable closed GOP mode
-lumimasking : use lumimasking algorithm
-stats : print stats about encoded frames
-debug : activates xvidcore internal debugging output
-vop_debug : print some info directly into encoded frames
-nochromame : Disable chroma motion estimation
-notrellis : Disable trellis quantization
-imin integer : Minimum I Quantizer (1..31) (2)
-imax integer : Maximum I quantizer (1..31) (31)
-bmin integer : Minimum B Quantizer (1..31) (2)
-bmax integer : Maximum B quantizer (1..31) (31)
-pmin integer : Minimum P Quantizer (1..31) (2)
-pmax integer : Maximum P quantizer (1..31) (31)
-drop integer : Frame Drop Ratio (0..100) (0)
-start integer : Starting frame number
-par integer[:integer] : Set Pixel Aspect Ratio.
1 = 1:1
2 = 12:11 (4:3 PAL)
3 = 10:11 (4:3 NTSC)
4 = 16:11 (16:9 PAL)
5 = 40:33 (16:9 NTSC)
other = custom (width:height)
-help : prints this help message

NB: You can define 64 zones repeating the -z[qw] option as needed.
-zones integer,q/w,float[,flags]
integer = start frame of zone
q/w = q for quantizer zone or w for weight zone
float = quant or weight (floating point value)
optional flags = K for start with keyframe, C for cartoon mode, O for chroma optimizer, G for greyscale or an integer for BVOP sensitivity. Order isn't important.
No spaces anywhere in the zones options.
Separate multiple zones with / . Or I guess you could use multiple -zones but I haven't tested it since it wasn't designed this way.
Also there's a -packed option to force packed bitstream on since it's off by default if there's no .avi output. Kinda weird I know but as we've discussed the bitstream setting affects what is written to the statsfile and that in turn has a substantial effect on the final encoded stream.


Thanks :)
:stupid:
weight is in percent? Are the following examples ok?

-z 58000, q, 8 -> will start a zone beginning with frame 58000 with q=8
-z 58000, w, 20 -> will start a zone beginning with frame 58000 with 20 % of quality of the main video.

[squid_80]

weight is in percent? Are the following examples ok?

-z 58000, q, 8 -> will start a zone beginning with frame 58000 with q=8
-z 58000, w, 20 -> will start a zone beginning with frame 58000 with 20 % of quality of the main video.
Weight is a percentage but it's in decimal form. 1 = 100%, 0.1 = 10%, 0.001 = 1% etc.

-zones 58000,q,8/58001,w,0.2
A zone starting at frame 58000 with a quantizer of 8 and another zone starting at 58001 with a weight of 20%. Very important that there's no spaces anywhere.

[JoeBG]

Thanks. I updated this info in the german boards. We are all testing :) :)

[buzzqw]

@squid_80

for your bandwith safe here the link at actual (13/02/2006) build www.64k.it/andres/xvid_encraw-13022006.zip

BHH

[dimzon]

@squid_80
Great Job! Can you add cqmintra && cqminter command-line switches to be capable use CQM without cqm file
sample:
-cqmintra 16,16,...,127 -cqminter 32,32,...,32

[bond]

squid_80, someone has posted a patch on the xvid maillist which seems to fix my issues with high framedrop values, maybe you are interested in it (maybe it was you who wrote the patch? :D )

[squid_80]

Yeah it was.

[squid_80]

@squid_80
Great Job! Can you add cqmintra && cqminter command-line switches to be capable use CQM without cqm file
sample:
-cqmintra 16,16,...,127 -cqminter 32,32,...,32
Should be easy enough. I assume the order of the values is just reading the matrix left to right, one row at a time e.g. for a matrix like this:
8, 11, 13
12, 11, 12
12, 12, 13
You would put 8,11,13,12,11,12,12,12,13?
(I know q-matrices are 16x16, I'm just using 3x3 for a small example)
Just wanted to be sure in case someone expects the values to be in the other order that sometimes gets used (which would be 8,12,11,13,11,12,12,13).

[Sagittaire]

Possible to make that ... ???

- pass1 : write always stat files
- pass2 : read stat files

but with pass1 function always active even if pass2 command is enabled:

xvid_encraw.exe -i file.avs -type 2 -pass1 file1.stats ....
xvid_encraw.exe -i file.avs -type 2 -pass2 file1.stats -pass1 file2.stats ...
xvid_encraw.exe -i file.avs -type 2 -pass2 file2.stats -pass1 file3.stats ...

or perhaps other function like -writestats [filename] with exactly the same file structure than 1pass files. With this function it will be possible to make multipass encoding (better target bitrate, better predictibility for frame size, better quality ...)

[squid_80]

BTW, avi output is broken for files > 2gb in size (thanks to avifile). They might be recoverable using vdub with the rederive keyframe flags option, I haven't let it run long enough to find out. mkv and raw streams seem to be ok.
Possible workarounds: a) Get an avi writer capable of producing odml files and use that instead (probably from virtualdub) or b) output multiple files, splitting at 2gb boundaries.
Of course there's option c) ignore it and hope no-one notices.

[squid_80]

but with pass1 function always active even if pass2 command is enabled:

xvid_encraw.exe -i file.avs -type 2 -pass1 file1.stats ....
xvid_encraw.exe -i file.avs -type 2 -pass2 file1.stats -pass1 file2.stats ...
xvid_encraw.exe -i file.avs -type 2 -pass2 file2.stats -pass1 file3.stats ...

At the moment -pass1 will disable -pass2 and vice versa. Whichever option comes last in the commandline is the one that will be active.
I'll run some tests and see if it's worth implementing multi-pass. I'm not sure if they will actually work together to give better results.

[bond]

i think there is a bug in labelling s-vops as the following doesnt make sense for me (framedropratio of 100):
len= 6 | type=P
len= 6 | type=P
len= 6 | type=S
len= 6 | type=S
len= 6 | type=S
len= 6 | type=Sobviously the frames with size 6 are n-vops, still they are labelled as s-vops

[hellfred]

Of course there's option c) ignore it and hope no-one notices.
I saw it, I noticed it, TOO LATE NOW :D

[squid_80]

i think there is a bug in labelling s-vops as the following doesnt make sense for me (framedropratio of 100):
len= 6 | type=P
len= 6 | type=P
len= 6 | type=S
len= 6 | type=S
len= 6 | type=S
len= 6 | type=Sobviously the frames with size 6 are n-vops, still they are labelled as s-vops
Are not-coded S-VOPs against specs? I know why it happens; the decision to drop a frame is made after encoding, based on the number of not-coded macroblocks. If the percentage of not-coded mbs is greater than or equal to the frame drop ratio the whole frame is not coded.
I can definitely see how this could be bad with s-vops. But it's a problem in xvidcore rather than encraw.

[Wilbert]

@squid_80,

I know why it happens; the decision to drop a frame is made after encoding, based on the number of not-coded macroblocks. If the percentage of not-coded mbs is greater than or equal to the frame drop ratio the whole frame is not coded.
Is it possible to make that decision before the encoding?

[squid_80]

It wouldn't really save much since some sort of motion estimation would still need to be done. If you have a source with lots of close to identical frames and expect lots of N-VOPs it would be better IMO to run a filter that removes dupes and dumps a timecode file to be used later. (Assuming there's a filter to do this and it actually works with MPEG4 ASP in mkv; I haven't got around to finding that out, but I plan to.)

[bond]

It wouldn't really save much since some sort of motion estimation would still need to be done. If you have a source with lots of close to identical frames and expect lots of N-VOPs it would be better IMO to run a filter that removes dupes and dumps a timecode file to be used later. (Assuming there's a filter to do this and it actually works with MPEG4 ASP in mkv; I haven't got around to finding that out, but I plan to.)hehe i didnt want to ask for vfr with mkv ;)

[bond]

squid_80, someone has posted a patch on the xvid maillist which seems to fix my issues with high framedrop values, maybe you are interested in it (maybe it was you who wrote the patch? :D )was applied to cvs

squid: is xvidcli supposed to work with the 1.2 line of xvid?

[dimzon]

Should be easy enough. I assume the order of the values is just reading the matrix left to right, one row at a time e.g. for a matrix like this:
8, 11, 13
12, 11, 12
12, 12, 13
You would put 8,11,13,12,11,12,12,12,13?
(I know q-matrices are 16x16, I'm just using 3x3 for a small example)
Just wanted to be sure in case someone expects the values to be in the other order that sometimes gets used (which would be 8,12,11,13,11,12,12,13).
YES EXATLY

[squid_80]

squid: is xvidcli supposed to work with the 1.2 line of xvid?
It should, that's what I'm using. It uses the current version of xvid.h so it should support all versions of xvidcore that are backwards compatible with that.

YES EXATLY
I'll try it but I don't know if specifying 256 values for each matrix will fit in the command line.

What I've been twiddling over the last few days is a -mkvvfr <filename> option, which produces a vfr mkv file by dropping n-vops completely and setting the duration and timecode of each frame appropriately.

[dimzon]

I'll try it but I don't know if specifying 256 values for each matrix will fit in the command line.
I'm not shure but seem's like there are no restrictions in modern OS (Win2K/WinXP)

[bond]

whats the advantage of specifying a cqm via cmdl and not using an external file?

edit:
What I've been twiddling over the last few days is a -mkvvfr <filename> option, which produces a vfr mkv file by dropping n-vops completely and setting the duration and timecode of each frame appropriately.is it necessary to make this vfr option so mkv centric? i mean regarding an hopefully coming mp4 output which also would be able to handle vfr its maybe better to keep as much vfr things as container agnostic as possible

[dimzon]

whats the advantage of specifying a cqm via cmdl and not using an external file?
to avoid unnececary dependencies when creating profiles in MeGUI ;)

[squid_80]

is it necessary to make this vfr option so mkv centric? i mean regarding an hopefully coming mp4 output which also would be able to handle vfr its maybe better to keep as much vfr things as container agnostic as possible
The main reason I'm using -mkvvfr is so -mkv can still be used at the same time in case of errors. If (when) mp4 output is added I can add a -vfr option which will make vfr mkv+mp4 output streams.

[bond]

why not use -vfr right away?

[ImmortAlex]

Hi! I have some questions:

1. In GUI there is option to specify target file size for 2nd pass. In xvid_encraw I see only target bitrate. Is this equivalent? For example, if bitrate calculator tells me that size is 617820 kbytes and bitrate is 821 kbps, is specifing "-bitrate 821" in encraw equals to specifing 617820 in GUI?

2. Are units for VBV options equals to GUI ? Are "-vbvsize 3145728 -vbvmax 4854 -vbvpeak 8000000" right options, equals to "Cinema Plus" profile?

[squid_80]

Hi! I have some questions:

1. In GUI there is option to specify target file size for 2nd pass. In xvid_encraw I see only target bitrate. Is this equivalent? For example, if bitrate calculator tells me that size is 617820 kbytes and bitrate is 821 kbps, is specifing "-bitrate 821" in encraw equals to specifing 617820 in GUI?Yes. I plan to add a -size parameter later.
2. Are units for VBV options equals to GUI ? Are "-vbvsize 3145728 -vbvmax 4854 -vbvpeak 8000000" right options, equals to "Cinema Plus" profile?
Yes they match the VFW options.

[ImmortAlex]

Thanks, but at least -vbvmax is not in kbps.
"-vbvmax 4854" leads to quant=31 for all frames. Maybe I need "-vbvmax 4854000" ? BTW, it shows like "4854.000" in GUI.

Also I don't understand how to set zones. For example, "-frames 2000 -zones 0,w,1.0/1000,w,0.01" doesn't produce a clip with worse quality in its 2nd half. What is my mistake?

[squid_80]

Thanks, but at least -vbvmax is not in kbps.
"-vbvmax 4854" leads to quant=31 for all frames. Maybe I need "-vbvmax 4854000" ? BTW, it shows like "4854.000" in GUI.
I can't check the source code ATM but you're probably right. The value internally is bps, the vfw gui just chooses to show it as kbps and I missed the decimal point when I checked before.
Also I don't understand how to set zones. For example, "-frames 2000 -zones 0,w,1.0/1000,w,0.01" doesn't produce a clip with worse quality in its 2nd half. What is my mistake?
Probably my fault - I made a mistake by not sorting the zones before passing them to the encoder. Try switching the order of the zones e.g. -zones 1000,w,0.01/0,w,1.0 and see if that helps.

[squid_80]

why not use -vfr right away?
Actually I now think it's a dumb idea anyway, because:
- possibly breaks specs; no frame found matching expected timecode (not sure about this, need a mpeg4asp expert)
- Only saves about 6/7/8 bytes per dropped n-vop, not really worth the effort.

[bond]

Actually I now think it's a dumb idea anyway, because:
- possibly breaks specs; no frame found matching expected timecode (not sure about this, need a mpeg4asp expert)sounds more like a container-centric problem?

- Only saves about 6/7/8 bytes per dropped n-vop, not really worth the effort. yeah, but vfr support is a funky feature ;)

[squid_80]

sounds more like a container-centric problem?That's why I need an expert. Each VOP does have a timecode of sorts based on dwrate (I dunno the real terminology, that's the avi term for it, where framerate = dwrate/dwscale; xvid source code uses fbase/fincr), how it is used I'm not sure. It looks like it can be used for determining if a n-vop is real or fake - at least the way xvid does it. Might just be something to do with error correction.
It would be the same as replacing n-vops in avi (real ones) with actual dropped frames - more or less pointless.

[bond]

i would assume that a vfr mkv file simply doesnt have a framerate (dwrate) anymore?

maybe you want to send Mosu a message on how its handled

[foxyshadis]

It has a default duration; frames that deviate from it have their durations embedded in the frame header. I believe mp4 works the same way.