Decomb521VFR1.0 mod for automated Matroska VFR

[FalconX]

Working with some friends modified Decomb avisynth plugin to add a mode 4 for VFR. Automates generating timecodes file and decimating properly for mixed 23.976 and 29.970. When first opening a file, it has to do a pass through all frames so it knows how many frames its really outputting, reading through all frames can take a bit but there is a gui progress bar. More description in the included reference manual.

Currently only supports cycle of 5 and YV12 video.

http://webpages.charter.net/falconx/decombvfrmod.html

I've been testing it for a while and its been working great for me, if anyone has any questions/comments or finds bugs let me know. When I have some more free time I do plan to add YUY2 support.

[spyder]

OMG...This should be nice. I've thought about something similar. I want to be able to turn the interlaced sections into 60fps progressive and leave the progressive frames as they are. Thanks for the filter, I'll try it tomorrow when I am at home.

Btw, I think someone should add support for looking at a D2V file for rff pattern, that would make detection of the progressive frames rather easy and accurate I think.

[FalconX]

Right now its assuming the video source is 29.97fps. It's on my list of things todo to change that.

[Calculon]

I'll definitely try this! Thanks!

[Dreassica]

I noticed that the dll's in that package are both Pentium optimized. Does it work with amd too. It doesn't want to load the plugin for me. I get the "unable to load.." error msg upon loading in vdubmod.

[Calculon]

Originally posted by Dreassica
I noticed that the dll's in that package are both Pentium optimized. Does it work with amd too. It doesn't want to load the plugin for me. I get the "unable to load.." error msg upon loading in vdubmod.

The "P3" dll works with my AthlonXP 3200+. It's the only one I tried. If it needs SSE instructions it won't work with older Athlons though.

[Dreassica]

I got an Athlon XP 2600, so that's not it.

[Calculon]

Originally posted by Dreassica
I got an Athlon XP 2600, so that's not it.

I forgot since it has been a week since I used the plugin, but the instructions under "Example usage" didn't work for me because "priority=1" was giving me some kind of error. I removed that and it worked. I used this:

Decimate(mode=4,threshold=1.0,progress=true,timecodes="timecodes.txt",vfrstats="video.vfrstats")


If it's something else then I can't help.

[FalconX]

Priority 1 and 3 probably won't work if you're not using Win2k/XP, I guess I should change the example, and add a note to the reference manual.

Dreassica, what version of AviSynth are you using? This plugin requires 2.5+

[lunaticmoon]

I have recognized it as DecombVFR corresponding to VFR by AVI+Timecode. Is it correct?

Although it may be a technical question, what has video in the time of being stored in video and Matroska in the time of being stored in AVI become formally?

In my recognition, I think that an AVI component cannot store VFR. Then, the above-mentioned question boiled.


My thread also deals with the subject of VFR by reference.
http://forum.doom9.org/showthread.php?s=&threadid=78948

[FalconX]

Correct, the AVI only has one descriptor saying what its framerate is, using matroska muxer you specify the timecodes file which informs it which frames are which framerate. Previously people would manually identify which sections were which and manually setup decimation dropping frames) appropiately and the timecodes. If you wanted to use this with something besides matroska that should be possible, as long as you have some way of using the timecodes file.

[Dreassica]

I use very latest 2.55 beta and i am on an XP machine too.

[FalconX]

Hmm, rough guess is that you might not have msvcr71.dll

[lunaticmoon]

@FalconX

Thank you for a reply.
Although it is reproducible with the AVI simple substance in AVI+timecode, the strange way of being visible is adopted.
Is it correct by saying ?

Although it does later

[madness]

I'm sorry for going off topic a little but I just like to know does this filter works for avi file container?

[gizmotech]

I can actually take a pretty good guess at this (It's probably similar to some theories the yatta guys bounced around #darkhold when we were looking at automatic VFR identification).

Most likely it scans the source for frames matches on the first pass. In doing so it can use decombs own matching process for identifying 30fps (decomb can ID it, but can't really fix it via avi). Once it has the metric data from the first pass, it identifies the 30fps components based on an average (configurable? I haven't looked at it yet) of consecutive C matches in cycles of 5. Theorehtically any group of C matches over 30 (1 second) would result in the beginning of a 30fps section, and it could identify the string of C matches as completly 30fps. Then, using a modified form of the override file I would suspect it tells decimate to ignore these 30fps areas (do not decimate the 1 in 5 cycle), and then creates a timecode file which corresponds to these changes.

This should, intheory result in an avi file which is time incorrect. Either too long @ 24fps, or too short @ 30fps. From this point, the avi file is muxed into mkv, using the timecode file the filter created which restores the individual video frame rates in the mkv file. Bang done, you've got a VFR mkv file.

For applications and usage this can come in handy in a number of places.

First off, we've got TV VFR CG crap, ala Star Trek TNG, which uses alot of 30fps on space scenes and in the opening mixed in with telecined 24fps content. It should be able to produce near perfect (if not completely IVTC correct VFR files on this source)

Second we've got VFR anime, which uses both 30 and 24fps sections at random. Though less likely to produce a completely correct IVTC/VFR, due to the fact alot of the VFR sources also have long stretches which will C match (assuming the theory is correct) it can still make sure 24fps and 30fps movement is fluid.

Sound about right Falcon?

Gizmo.

[FalconX]

Yeah gizmotech, except currently it only deals with a single cycle at a time. It might be better to ignore 30fps sections under 1 second, but occasionally i see anime with short pans under 1 second and would prefer it to just go entirely on the threshold.

It's not too modified from standard decomb, a good third of the mod is just the GUI for the 1st pass. It uses the threshold parameter that other decimate modes already had. The AVI it produces it leaves as whatever fps it originally was, and the timecodes file describes the actual framerates.

I believe lunatic moon was asking the same thing as madness, AVI does NOT support variable framerate, it has the framerate described in the avi header and that's it. The specifics of how matroska handles variable framerates can be found elsewhere with much more detail.

Basically you encode an avi with virtualdub or some variant using this plugin in avisynth, then you take the avi and the timecodes and use it with say mkvmerge which has a "timecodes" field and browse button, mux the mkv, then it plas back at the proper rate.

I originally started from this thread: http://forum.doom9.org/showthread.php?s=&threadid=64314 for information on Variable FrameRate with matroska.

[gizmotech]

/me loves when what little bit of work he's ever done is refferenced

**Bows**

You should probably atleast consider 3 cycles ... anything less and the eye will never notice it anyways. Alternatively, looking at the dedup application might also be of some relevence. Pengvado's work on that was quite impressive (imagine dup, but rather then frame duplication, it's frame dropping, w/ individual time code correction)

Gizmo.

[tritical]

Gizmotech's suggestions are on the right track for vfr detection. I've actually done a lot of work in the last few months on video detection and automatic timestamp generation for vfr mkv files (I use my own AviSynth filters for IVTC/Deinterlacing) since I've run into a lot of hybrid (24fps film and 30fps progressive video) anime. I use a two pass system where on the first pass my filters output some text files and info, which are then analyzed at the beginning of the second pass, along with outputting the timestamp file for mkvmerge. For video detection (30fps progressive) vs film (24fps) I require 4 consecutive (5 frame) cycles to be detected as video. The actual video detection I do on a single cycle basis. First, all the frames in the cycle must all be the same match (similar to c, p, n in telecide, theoretically if the video was telecined prior to being put on the dvd and there is an orphaned field due to a bad edit, a 30fps progressive section could have all p or all n matches... though I have yet to see such a case). Second, they must all be above a certain difference threshold (similar to the threshold in decimate), since if it is a still scene you don't care if it is film or video to begin with. Then after doing the single cycle detections I check for the # of minimum consecutive cycles.

After looking at the source code and seeing what was changed, this mod works only partly that way. As FalconX said it still only looks at single cycles as decomb did before, and after disabling hints it only looks at metrics. The problem with using this mod or decomb in general for doing video detection as was described above (deciding using metrics as well as the frame matches together) is currently decomb's hints only hint IN_PATTERN and PROGRESSIVE, which is not useful for 30fps progressive video detection and will lead to a lot of false positives the way it is currently set up (I'm guessing that's why you set hints to false). And using metrics only, especially on single cycles can lead to a lot of false detections, since if you set threshold low enough to catch slow panning scenes it can easily fall below the noise level of the clip causing misdetections. The frame matches themselves really need to be hinted. Of course, that would require the hinting method of decomb to be reworked a little bit. You could probably get by all this if you parsed all the debug output and made overrides files but that I too much manual work for me and probably quite a few other folks.

After doing a lot of testing I think that the combination of frame matches + metrics + minimum # of cycles allows for a process where you can run film or video through it and have reliable enough detection to not need to see if the video is hybrid or not yourself (i.e. on process for all, as long as you are using mkv as a container).

I will definitely have a look at dedup, as I have not heard of it before. Also, sorry for bringing so much AviSynth stuff into the containers forum.

[FalconX]

Well I figure variable framerate is container specific, these are just tools to get there. Avisynth plugins being the best choice.

Any chance of sharing your personal ivtc/deinterlacing filters? I too work on a lot of anime encodes. I'd be interested in trying out yours and looking through the code for ideas.

Manual is evil in my opinion, I'd rather spend days coding an automatic solution that's correct most of the time instead of spending an hour or less manually doing it.

I agree with hints coming from telecide would be best if the hints were appropiate. Mininum # of cycles is something that's a little easier to implement, I'll work on that when I have some free time.

gizmotech you have a url for dedup? quick google search only turned up file duplicate tools...