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.:rolleyes:

[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.:rolleyes:


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.:D
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 :D

[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 :rolleyes: 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...

[gizmotech]

errr... no I don't (It's been a while since I've been playing w/ tools.... DAMN YOU WORK)

If you goto #darkhold on chatsociety and ask there, pengvado, myr, or mentar (among others) should be able to help you out.

Gizmo.

[lunaticmoon]

I tried DecombVFR.

Although I do not have an elaborate discerning eye, there was no sense of incongruity in appreciation.
In appreciation with an AVI simple substance, it also turns out that it is meaningless.

The check has not been carried out, although the talk that timecode file cannot be taken out is also heard, if done MKV is extracted.

I think that it waits for the VCM front end which can treat VFR MKV as input and output easily.Although environment is improved in the rmvb container of RV10, the automatic correspondence to Hybrid Material is hardly fixed.

[Sirber]

Hum...

Could I use that to encode using Helix Producer and have VFR? If so, this could be a great add to Legendary RealAnime :D

[haibane]

Originally posted by lunaticmoon
I tried DecombVFR.

Although I do not have an elaborate discerning eye, there was no sense of incongruity in appreciation.
In appreciation with an AVI simple substance, it also turns out that it is meaningless.

The check has not been carried out, although the talk that timecode file cannot be taken out is also heard, if done MKV is extracted.

I think that it waits for the VCM front end which can treat VFR MKV as input and output easily.Although environment is improved in the rmvb container of RV10, the automatic correspondence to Hybrid Material is hardly fixed.

I think it wouldn't be a problem if mkvmerge automatically store the timecodes file as an attachment. To convert back to avi, just decode the video as constant fps file and have some software to apply timecodes to make it 120fps(or do it manually if no such software are made)...........

[Yusaku]

To demux a mkv file to video and timecode file, you can use http://haali.cs.msu.ru/mp_rel.exe small utility done by haali.

[Sirber]

@FalconX

Do you mind if I include your DLL into RealAnime?

[edit]

Hum... the DLL don't output a VFR stream. How can I use that with Helix Producer? :confused:

[FalconX]

"modified Decomb avisynth plugin", it's part of the very first sentence in this thread. The dll is an AviSynth plugin, avisynth does not support variable framerate far as I can tell. It has the standard method of a global framerate, and every filter must change the number of outputted frames when initialized.If you know something about avisynth that I don't, please tell me.

[Sirber]

Sorry :(

Maybe we would need to set output at 120FPS and create "dropped frames" to get true VFR...

[FalconX]

As it stands it outputs 29.970 and a timecodes.txt that tells which frames are which, I'm not messing with this 120fps stuff.

[Sirber]

ok. I won't be able to use it then :(

[lunaticmoon]

I think that DecombVFR resembles ITVFR.

DecombVFR)
frontend=VirtualDub
output=AVI+timecode=MKV

ITVFR)
frontend=AVIUTL
output=120fpsAVI or AVI+timecode=MKV

By my discerning eye, distinction does not attach whether analysis accuracy of which is good.:D
It is thought that it is based also on sauce.

Does an opinion have you about these ways of using properly?

Please look at the following about ITVFR.:)
http://forum.doom9.org/showthread.php?s=&threadid=80882

[Sirber]

I could use ITVFR with producer if producer could accept more than 60FPS :( I will bug report them :devil:

[darkavatar1470]

Nice work !
This makes VFR a lot more easy.

Starts working for me after downloading msvcr71.dll,
you could add an error message if one does not have it.

Playback is smooth, except when a patteren change occurrs, there might be 2 duplicates in a cycle, thus leaving one left. But it's not too noticeable anyway.

Also found that I can't seek during playback in mpc, is that normal?

[the_free_account]

Thanks a LOT for writing this plugin! It has saved me a lot of trouble!

But I have one question: is it possible to manually override the decisions decomb(mode=4) makes on specific frame areas? I assume this would involve editing the video.vfrstats file, but I can't understand its format.

Thanks,
-Mike

[FalconX]

the vfrstats file currently stores which frame numbers to output as 4 byte integers, however you can use a standard overrides file before generating the vfrstats file and it should accept that.

[the_free_account]

Originally posted by FalconX
the vfrstats file currently stores which frame numbers to output as 4 byte integers, however you can use a standard overrides file before generating the vfrstats file and it should accept that.

Hrm...I'm a bit new at this and I don't quite understand your answer. For example, if I wanted frames 300-400 to be at 30fps but frames 2400-3400 at 24fps, what should I add to the overrides file or the vfrstats file?

Thanks,
-Mike

[Teegedeck]

So, has anyone got a hold of this dedup thing? Or is access intentionally kept restricted to closed communities, in good old releaser-fashion? :p

[Nicholi]

How very negative months later...

http://students.washington.edu/lorenm/src/avisynth/dedup/

Pretty simple to use as it is much like Dup. Most obvious problem I see is small movements in anime are sometimes completely eliminated if the threshold is not very low. Though I used it quite some time ago, not sure what version. It is a very interesting technique, and the ability to override is quite useful. If only there was a nifty app to help create ranges, and such for the ovr in a more lazy fashion :)

Without strict control it seems it might get a little out of hand.

[Teegedeck]

Ahhhh; thankyousirthankyou! Now, let's have some fun. :D

[LoopX3]

A new version is out, which is a major update from v1.01:
http://webpages.charter.net/falconx/decombvfrmod.html

Please read Appendix C in the reference manual, especially the Usage Notes and Known Issues, in addition to the Detailed Function Syntax -> Decimate() section.

Below is a small list of changes/notes after v1.01:
- vfrstats files from v1.01 aren't compatible with this new version
- Override files aren't supported yet
- YUY2 still isn't supported
- Added a mincycles parameter
- Certain parameters can be changed without having to recreate the vfrstats file

[LoopX3]

There is some misunderstanding about the purposes of these filters. They are made for different uses. DeDup is made to remove a string of duplicate frames, while DecombVFR is made to remove a duplicate frame in a cycle.

DeDup's purpose is to remove duplicate frames in order to reduce the video size. DecombVFR's purpose is to remove duplicate frames and pass others for smoothness, such as in panning scenes.

Although DeDup can have a hard limit on the number of duplicate frames removed in a row, you can't change the parameters to guarantee it to remove only 1-in-N frames (except possibly with an overrides file).

[jellysandwich]

I have a few questions.

First, according to the modified reference manual, this
is a typical script:

Telecide(guide=0)
Decimate(mode=4,threshold=1.0,timecodes="timecodes.txt",vfrstats="vfrstats")

When I put that into my avs file, Virtualdub brings
up an error stating that I must set the order. Should
I assume that the "guide" part should actually be "order?"

Second, is the mod affected by any of the telecide
parameters?

For example, would

Telecide(order=0)
be any different from
Telecide(order=1,guide=1,chroma=true,gthresh=0,blend=false)
? Or does the whole mod depend entirely on Decimate()?

Lastly, I'm a bit confused about the vfrstats file.
In Appendix B, it says:

Warning: if the source video is changed or the decimate options such as threshold, you should delete the vfrstats file so the timecodes is recreated and frame decisions redone.

Then, in Appendix C, it says:

You DON'T need to recreate the vfrstats file if you change the 'threshold' or 'mincycles' parameters, so you can experiment with them easily. Other parameters that don't affect the vfrstats file include 'progress' and 'priority'.

Exactly which parameters (in both Telecide and Decimate)
affect the vfrstats file? In other words, when should
we reset the timecodes and frame decisions?

Just in case, this is a copy of the reference file that
I'm referring to:

http://jellysandwich.info/js/DecombReferenceManual2.html

-jellysandwich

[FalconX]

The guide=0 issue is My fault, when writing the new section i started by copying bits from the existing sections. It seems when order was made mandatory the decomb docs were not updated in these sectiosn to reflect that.

The other inconsistency is because at one point the stats file stored the decisions, not the stats it used to make those decisions. LoopX3 changed it to store the stats and regenerate the decisions. Yet it seems he missed a few spots in the docs.

The only times you should need to regenerate the vfrstats file is when you change something that will effect the stats, such as modifying the video coming into decimate. Any changes to telecide parameters have the capability to do this, as does any other filter changes before the decimate line. One parameter, quality, will also change the stats generated.

[LoopX3]

There is a new version of DecombVFR, which will be outlined in the next post. The inconsistencies are fixed in the reference manual.

First, according to the modified reference manual...
As FalconX said, Appendix B wasn't updated when the default value for "order" was removed. DecombTutorial.html has details on how to figure out the correct field order for telecide. We just picked "guide=0" as an example because we usually prefer blind field matching.

Second, is the mod affected by any of the telecide parameters?
Since you usually use telecide before decomb, changing telecide parameters can change the video, so you should recreate the vfrstats file.

Lastly, I'm a bit confused about the vfrstats file...
Yes, I missed taking out that part. The vfrstats file should be recreated when the video changes before using decimate. The timecodes file will always be recreated when decimate is called with mode=4. That also means whenever you open the avs.

Exactly which parameters (in both Telecide and Decimate) affect the vfrstats file?
As said before, you should recreate the vfrstats file when changing telecide parameters. The only decimate parameter that will change the metrics stored in the vfrstats file is "quality" (unless I missed something else). Any other decimate parameter can be changed without recreating the vfrstats file.

[LoopX3]

New version: Decomb VFR 1.2
Still at the same place: http://webpages.charter.net/falconx/decombvfrmod.html

There are two main changes:

Bugfix: With mincycles, it kept the same cycle decision for the following cycles (up to mincycles) on a change failure, but this was only supposed to happen on a change success.

New feature: Added support for an overrides file with
'-' = ignore frame metric
'c' = force cycle decimation

Using overrides is described in the reference manual section "Overriding Decimate() for mode=4 (VFR)" under "Overriding Decomb Decisions".

I'm not going to be developing this filter for some time (a long, long time). I'm working on another project with more functionality, sort of like an auto-YATTA.

[HappyUser]

Yey....

I skipped that thread :/

actually I have a slight problem :

http://forum.doom9.org/showthread.php?s=&threadid=90129

I don't know that much about avisynth, but, is this filter could help me in xvid vfr reencoding (trying to keep vfr, but remove it if necessary) ?
Cuz I have a vfr stream, and I am searching an avs filter that could handle such a vfr stream..

[jellysandwich]

Good stuff, thank yous.

-jellysandwich

[LoopX3]

New version: Decomb VFR 1.3

Still at the same place: http://webpages.charter.net/falconx/decombvfrmod.html

Changes
- Bugfix with using the '-' override. It still used the frame's metric for deciding which frame should be decimated but didn't choose the frame itself. For example, if the '-' frame had the lowest metric in the cycle, the next frame would be chosen.
- Now allows forcing decimation of frame 0 with 'c'
- Added YUY2 support
- Moved most of the VFR code to a separate file.

No further planned updates (by me) except for possible bug fixes.

[Sakuya]

Could you explain the code used in the command line to create a new AVI using the timecodes? I used AVS scripts but it's telling me that the FDecimate filter is corrupted and for me to download another program to fix it. So much troubles! :scared:

[FalconX]

Command line for what? Could you be more specific as to what you are doing and where it's failing, and what error message it is giving. I really have no clue right now what you're trying to do exactly and how it's failing.