@VFW/DShow experts: VFR in Avisynth could be good news for Matroska

[spyder]

Technically the MPEG2 isn't VFR because it has a set framerate. But it may have sections that are missing the full 29.97fps and actually have 23.976fps with RFF flags set. This in essence makes a VFR clip. However, I don't know of a decoder that doesn't respect the MPEG-2 specs for decoding this. I think Force-film in DVD2AVI reduces all of the clip to 23.976fps regardless of the actual picture structure of the stream. This would reduce those "real" 29.97fps sections to 23.976. So it is also CFR.

Spyder

[bilu]

And as for using the scripting system, Yes it will be a shame that a number of filters will be unable to work now, however I must be confused as to which part of avs will be broken by this, because I don't know of any filters that I currently use which require knowledge of time, just knowledge of the next and previous frames. (Could these be audio components which will be broken?)Nothing gets broken in that way! But as you said, filters didn't had knowledge of time and a lot of them won't ever need it.
But imagine a fade-in/fade out that gets speed up or down because of a framerate change.
The problem here won't affect audio because IVTC doesn't affect audio too. You have video doing 30 fps -> 34 fps and audio staying the same with IVTC today.
It's just that you shouldn't use temporal filtering on VFR, because even if reworked to look better on VFR, it would be screwed up if you would ever want to convert VFR-> CFR.
Just imagine a speed-up and down fade-in/fade-out on a VFR->CFR conversion.

So they should be avoided EVEN if supported.Technically the MPEG2 isn't VFR because it has a set framerate. But it may have sections that are missing the full 29.97fps and actually have 23.976fps with RFF flags set. This in essence makes a VFR clip. However, I don't know of a decoder that doesn't respect the MPEG-2 specs for decoding this. I think Force-film in DVD2AVI reduces all of the clip to 23.976fps regardless of the actual picture structure of the stream. This would reduce those "real" 29.97fps sections to 23.976. So it is also CFR.Read this post about Force Film:
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?p=836#836

It was about Read or Die anime which a had a very peculiar D2V file.

Bilu

[bilu]

Summary October 26th 2003:

Until now, this is what seems to be needed:

VFR DShow filter
==========
- reads frames and timestamps and increases the frame duration as needed;
- for unmodified VFR muxers;
- VFR AVS preview;

VFR Muxer
=======
- add support for timestamp log reading and translating into timecodes;
- add Max Framerate info into container, grabbed from the VFW header.

VFR AVS source filter
=============
- translate timecodes into frame duration;

Avisynth
=====
- have a frame property with frame duration
- maybe a flag for VFR->CFR so that you know when to copy frames? Or a filter?
- a timestamp log writer (most reliable to write frame duration than translate here to timecodes IMHO)


VFR Encoding Process
=============
Source filter grabs the source and fills the frame duration property.

IVTC filters mark frames with 24fps duration, 30fps duration and drops duplicates.
Dup filters mark frames as (nr dups + 1) frame duration and drops duplicates.

In the end of the script the timestamp log is written and all frames are exported to VFW.
The video stream will be encoded as (Max Framerate) fps stream, this info will be in the VFW header.

The VFR muxer grabs the video stream, Max Framerate info from the VFW header, and the timestamp log with frame duration.
Frame duration is translated to timecodes as frames get inserted into the VFR container.
Max framerate info should be kept in the container header.

VFR -> CFR Conversion
==============
Source filter grabs the source directly from the VFR container, grabs timecodes and translates them to frame duration.Also grabs Max Framerate.
Since you can also do VFR->VFR reencoding, a flag would have to be set, or a filter would have to be used to get the stream into CFR.

IMHO a filter would be better: it would grab Max Framerate and copy frames to fill the duration of the current VFR frame. If VFR frame duration=24fps and Max Framerate=30fps then it would copy a frame every 4 frames to make it like a Telecide() source that needs to be decimated.

Max Framerate info is needed only for this process. I don't know how easy/hard it is to keep this info on the VFR container and in Avisynth's frame properties.


Notes: Audio shouldn't be affected at all just like it isn't now by IVTC filtering. Temporal smoothing should be avoided EVEN if supported if you would ever need to do VFR->CFR conversion.


Best regards,
Bilu

[bilu]

@Gizmo

We'll need VFR streams of course. It's the only way to work on filters.
But for decisions about containers, muxers, Avisynth frame properties, all we need to know is that:

- framerates can change inside Avisynth;
- Avisynth source can have a variable framerate;
- VFW can't handle VFR;

The rest of the conclusions so far could be taken without the source.
About IVTC and Dup filters we know already what they should do, we even have a practical example of a RV9 Dup filter for anime.

To work on filters you're right. But until we get there a lot of work needs and can be done without the VFR source.


Bilu

[gizmotech]

Originally posted by spyder
Technically the MPEG2 isn't VFR because it has a set framerate. But it may have sections that are missing the full 29.97fps and actually have 23.976fps with RFF flags set. This in essence makes a VFR clip. However, I don't know of a decoder that doesn't respect the MPEG-2 specs for decoding this. I think Force-film in DVD2AVI reduces all of the clip to 23.976fps regardless of the actual picture structure of the stream. This would reduce those "real" 29.97fps sections to 23.976. So it is also CFR.

Spyder

@Spyder; like you said, force film, which ignores the rff flags essentially just drops every 5th frame from the source. This does not produce the desired effect, and force film does not work on source w/ hybrid content (30 and 24fps content), as I have never seen a source w/ completely progressive 24fps and 30fps requiring only decimation on the 24fps. Any such mixted sources require IVTC on the 24fps.

@Bilu; Once Again Bilu I think you're thinking about a big picture which isn't needed yet.

Until you have a reliable and efficient way for the people who CURRENTLY encode this stuff en-mass, to produce VFR content though CURRENT means the discussion becomes moot.

What we need is this:
Selective decimation filter to provide time incorrect stream to VFW to create 30fps speedup content.
Method to take an encoded version (mpeg4, rv9) of this file and mux it into vfr container and adjust the time codes.
A text file which is read by both the selective decimation filter and vfr muxer.

See... my NEED list is ALOT smaller. And oddly enough creates a vfr file. So why do we NEED all those other things to create the end result?

I'm just using a little common sense is all.

Gizmo.

[Atamido]

I do believe that Bilu's solution is more correct for the long term, however gizmotech has a very valid point.

The devs do not currently see a reason to redesign their system to support something that they may not use anyway. There is obviously a reason to do it, but it takes a lot of time and work to program it and fix the bugs.

If you made a text file that AVISynth plugins could write to to save framerate, this would save you the trouble of fixing all of the filters to work with the new system. Simply load the produced file as a source in directshow. Then place an easy-to-make timecode fixer filter between the input and the muxer that uses the text file to correct the timecodes of the frames it passes through. The graph should look something like this:

[source] --> [timecode fixer] --> [matrsoka muxer] --> [file writer]

So, the only thing this graph would do is take the file input into it, change timecodes/drop frames/whatever you want using the text file as a guide, and then pass the frames with the corrected timecodes out so that they can be written in a file.

It WOULD work. It WOULD NOT break any compatability.

[nuked]

hey instead of worrying about removing dups... why not never put them there in the first place? Is it not possible to make an mpeg2dec that never generates the extra telecined frames and just keeps the rff flag around, or does mpeg2dec still have the same type of problem of being restricted to a certain total number of frames? I woudln't think so since after all it's the source. Of course for animee removing dups would still be pretty usefull cause there are a bunch of dups that didn't come from telecining but that could be phase 2. As for ones that did come from proper telecining, seems better to increase the length of the frames before and after by 1.5 than the one before by 2. Less jerky and more like the dvd. Of course as mentioned... this is all details far from being relavent yet, except to decide if things can be done in a way that's easy enough to be worth doing. I also don't see the point if one of the codecs doesn't have interlaced support. Why leave the 30fps parts at 30 if you have to deinterlace them anyway, I guess it's a little better than going to 24 but not much. Either fix the issue or don't. Interlaced support is starting to show up but last I checked it still has a ways to go before this whole trick will save more space than it costs. And to preserve as much chroma quality on the progressive sections as you can you'd wan't to leave them un-interlaced which means passing the new chroma interlace flag into the codec or container and interpreting it on playback of course.

[nuked]

p.s.. extra files are great. I think one of the best containers ever made that tends be be forgotten is called a directory. It's expandable and compatible with everything.

[nuked]

by the way mpeg 2 IS VFR. in prgressive sections there are only 24 frames stored on the disk for every second of video, period(unless it's yucky hard telecining). In interlaced sections there are 60 fields for every second of viedeo.. or 30 interlaced frames if you'd rather. dvd2avi along with mpeg2dec telecine it to CFR using the repeat field flags on the disk. The disk only tells how to telecine... it is not actually telecined on the disk. You don't have to ivtc to get back vfr if you never telecine it in the first place. It's mpeg2dec that's CFR, mpeg2 is VFR. Don't make things harder than they are. If you want a description of the frame rates all you need is to look at the dvd2avi file. It's already there. Odd numbers are 1.5*1/30 duration and even nubbers are 1.*1/30 duration. going an extra step to generate your own file is useful for tweaking hard coded telecining or removing more dups, but the info for a first round go at this already exists.

[bilu]

Originally posted by gizmotech
What we need is this:
Selective decimation filter to provide time incorrect stream to VFW to create 30fps speedup content.
Method to take an encoded version (mpeg4, rv9) of this file and mux it into vfr container and adjust the time codes.
A text file which is read by both the selective decimation filter and vfr muxer.

See... my NEED list is ALOT smaller. And oddly enough creates a vfr file. So why do we NEED all those other things to create the end result? Your list seems like a manual way of doing things, because it doesn't mention how do you get the info into the text file. Basically it seems you're suggesting some sort of decomb override where YOU provide this info to both the filter and the muxer. That seems both unnecessary and primitive to me. But I may have misunderstood your point.


Bilu

[bilu]

Originally posted by Pamel
The devs do not currently see a reason to redesign their system to support something that they may not use anyway. There is obviously a reason to do it, but it takes a lot of time and work to program it and fix the bugs. That's why I started to show what the advantages are on my last threads both in Avisynth Development and here.
Moreover, I've linked to former threads on the same subject started by neuron2 and others that also explain the advantages of variable framerate. My first work here was to bring credibility to such a project on how much it is needed.

The second part has been how is it possible to do. That's why I've been working on showing/asking how we can overcome VFW limitations on Avisynth structure. That's why I've been making this lists and that's also why we came to the conclusion that is better to use frame duration inside Avisynth and to translate in the VFR muxer to timecodes because it's much better on the VFR container.

It's better for developers to work with a purpose. Since this is a multi-area project, it has to have communication and coordination between every part. No one wants to develop something for the other guy to use and then the other guy says that what it needs it's just the opposite.

That's why I think my approach has been better than Gizmo's - because I already got some goals for developers to achieve before we get to the final goal - VFR. If you made a text file that AVISynth plugins could write to to save framerate, this would save you the trouble of fixing all of the filters to work with the new system. Simply load the produced file as a source in directshow. Then place an easy-to-make timecode fixer filter between the input and the muxer that uses the text file to correct the timecodes of the frames it passes through. The graph should look something like this:

[source] --> [timecode fixer] --> [matrsoka muxer] --> [file writer]

So, the only thing this graph would do is take the file input into it, change timecodes/drop frames/whatever you want using the text file as a guide, and then pass the frames with the corrected timecodes out so that they can be written in a file.

It WOULD work. It WOULD NOT break any compatability.
Quoting myself:

VFR DShow filter
==========
- reads frames and timestamps and increases the frame duration as needed;
- for unmodified VFR muxers;
- VFR AVS preview;
That was my first idea.If you read the discussion I had with Neo Neko in the beginning of this thread you would know that I only presented the VFR muxer alternative after Neo Neko reminded me that a lot of encoders work only with VFW and not with DirectShow.

If you check the XVID threads you'll notice that DShow XVid encoder is a very recent project, until now VFW was the only interface.


Bilu

[gizmotech]

It is a) Primitive and b) very nessesary.

You yourself have proven on both this forum and the neuron2 forum that d2v files are incapable of generating consistent results for the purpose of determining patern matching, which leads me to question their ability to provide accurate information for this objective as well.

At the moment, I'm suggesting manual determination of frame rate and entry into the file a) Because it will be more reliable b) it can be implemented relatively quickly c) It make sure the encoder is capable of identifying what 30 and 24 fps content is.

Any encoder who is serious about VFR is going to identify the various sections regardless of what tool they are using, so they know what is 30fps and 24fps. I don't see what part of this is unnescessary, because a) Can you get telecide to accurately distinguish between 30 and 24fps content? b) Can you get decimate to automatically distinguish between double frames and just a slow 30fps? (Play with Dup and you'll understand why it CANNOT automatically distinguish correctly on 90% of the sources out there) c) I'm not that lazy in that I can identify these areas while I do my manual telecide override files.

I would ask you this? How many people are going to make successful VFR encodes if they are lazy enough NOT to identify the different frame rate sections?

And lastly back to the primitive point, DAMN STRAIGHT! Simplify man, build in steps, and make direct objectives which can be easily achieved and provide interm results. I want to be doing efficient manual VFR next week, not next year, or in 2 years.... Solve your problems in order and you will see results.

Gizmo.

[gizmotech]

Quoting myself:

That was my first idea.If you read the discussion I had with Neo Neko in the beginning of this thread you would know that I only presented the VFR muxer alternative after Neo Neko reminded me that a lot of encoders work only with VFW and not with DirectShow.

If you check the XVID threads you'll notice that DShow XVid encoder is a very recent project, until now VFW was the only interface.


Bilu [/B]

Yes, but you COMPLETELY missed the point on this.

You don't perform encoding in this step, this is just a time change. Encoding is done on the time incorrect avi file which is complete. After that encoded avi is finished it is then fed into this directshow filter. There was never any discussion of codecs at this point, just modifying time codes on a useable avi file as it was muxed into an mkv.

Gizmo.

[bilu]

You yourself have proven on both this forum and the neuron2 forum that d2v files are incapable of generating consistent results for the purpose of determining patern matching, which leads me to question their ability to provide accurate information for this objective as well.I agree with this. I don't want to get nothing from D2V files.At the moment, I'm suggesting manual determination of frame rate and entry into the file a) Because it will be more reliable b) it can be implemented relatively quickly c) It make sure the encoder is capable of identifying what 30 and 24 fps content is. I do agree that any filter development needs to have sources. My discussion about VFR has been more about Avisynth structure and VFR muxer than filters, because filters need to have the necessary Avisynth infrastructure - that why we've been about what can Avisynth do.Any encoder who is serious about VFR is going to identify the various sections regardless of what tool they are using, so they know what is 30fps and 24fps. I don't see what part of this is unnescessary, because a) Can you get telecide to accurately distinguish between 30 and 24fps content? b) Can you get decimate to automatically distinguish between double frames and just a slow 30fps? (Play with Dup and you'll understand why it CANNOT automatically distinguish correctly on 90% of the sources out there) c) I'm not that lazy in that I can identify these areas while I do my manual telecide override files.

I would ask you this? How many people are going to make successful VFR encodes if they are lazy enough NOT to identify the different frame rate sections?

And lastly back to the primitive point, DAMN STRAIGHT! Simplify man, build in steps, and make direct objectives which can be easily achieved and provide interm results. I want to be doing efficient manual VFR next week, not next year, or in 2 years.... Solve your problems in order and you will see results.I know IVTC Anime is a PITA, and I'm sure neuron2 is the right guy to talk about Dup and IVTC development, not me.
I also know that you know much more about this filters than me, we've been discussing issues many times in neuron2 forum.

1) I can't see what's stopping you from making manual VFR encodes right now. I think the ability to change timecodes is already available. And the sooner we got the real stuff the better ;)

2) Frame properties in Avisynth will keep frame duration. First you should run IVTC and then Dup on IVTC anime.
An IVTC filter would drop duplicates if a duplicate is found at every 5 frames and change the duration of the last 4 frames by adding 25% frame duration to each frame, so that 4 frames get the same time that 5 frames took before, so there won't be any desynchronizations.
A Dup filter would drop duplicates and change the original frame duration to (nr of dups +1) x original frame duration.

The main problem I see is incorrectly identified IVTC on anime. You would see 4 frames taking the time of 5 (the 5th being removed) and that could create some desynch with audio events such as speak during the 5 frames time, i.e. 1/6th of second. I'm sure this already happens now and no one can notice due to the nature of anime.

But your main problem is not this: it's what does a filter recognize as duplicate. That's a filter job both in CFR and VFR. If it can't get solved in CFR then VFR will just have to suffer from the same problem. This has nothing to do with the VFR nature itself: same dup detection, different rendering.


Bilu

[bilu]

Originally posted by gizmotech
You don't perform encoding in this step, this is just a time change. Encoding is done on the time incorrect avi file which is complete. After that encoded avi is finished it is then fed into this directshow filter. There was never any discussion of codecs at this point, just modifying time codes on a useable avi file as it was muxed into an mkv.

But that was precisely my idea. Encode/ frameserve incorrectly, feed into DSHow filter together with the timestamps file, DShow renders correctly.

The only difference is that instead of doing the AVS -> Encoder job, it does the AVI -> VFR Muxer job, so the VFW problem is gone because encoding was already made.

You're right, same idea but different application.
All we've been talking about VFR muxer translations between frame durations in the timestamp log and timecodes in the container would be done by getting DShow frame events into timecodes. That's the main difference IMHO.

Bilu

[bilu]

@Gizmo

Do you wanna get your hands dirty and kindly provide us with some VFR encodes so that developers have something to work with?

It's seems to me that we're getting into Phase II: advocacy phase has passed, now it's time to get the hands dirty on development :D

And I'll be a cheerleader!!! LOL :D

Cheers,
Bilu

[gizmotech]

Not really to be honest.

Because you're asking me to spend a WEEK (we're talking more then 72 hours+) to make 30 minutes of VFR mkv MPEG-4.

So no, I don't intend to do that any time soon. Because guess what. YOU DON'T NEED IT YET!

I'd like you to politely throw out everything you've thought of to date, and reread what I've wrote... Read what I've wrote with a blank slate and you'll finally understand what I'm saying...

At the moment I have no reason to provide it to you because I have no efficient means to create it... you're talking about MODIFYING vfr content, I'm talking about making it... Which one comes first?

S.T.O.P. Stop, Think, Observe, Plan...

Then talk to me... Because I'm done in this conversation. I've made my point clear, and you're soo caught up in thinking about a future which doesn't exist you can't identify the fucking present reality and situation.

Gizmo. **Returning to lurkersville until some sense and objective focus returns.

[bilu]

I think Star Trek hybrid clip would be enough.
But since you put it that way I'll try to do it myself and post it so it can become useful.

Thanks for your help until now. Sorry to have pissed you off.


EDIT: Since you'll support frame duration property both creating and modifying will use this resource. And since we were talking about useful resources I came to the conclusion that max Framerate is also a needed resource if you ever want to come back to CFR.

Because people who do CFR encodes will start complaining about VFR streams.And it seemed a simple enough point to add that it wouldn't destroy the focus. Of course focus will still be making VFR.

EDIT 2: Having a VFR source NOW is useful for the VFR DShow Filter and for the frame duration property development, and most of all, to advocate VFR, since it shows what can be done.


Bilu

[bilu]

VFR script for StarTrek Hybrid. 24 fps will get speeded up. Try it yourselves. I can upload a XVID 1st pass (14 MB) to a public hosting if available, please PM me.


Script
======
mpeg2source("TNGsample.d2v",idct=2,cpu=0)

function FOrder(clip c) {
fo= GetParity(c)? 1:0
return fo
}

a=trim(0,296)
b=trim(297,0).Telecide(order=FOrder(),guide=1,post=2).Decimate().AssumeFPS(a.framerate)
c=a+b
return c



Bilu

[Gaia]

Originally posted by bilu
@Gizmo

It's seems to me that we're getting into Phase II: advocacy phase has passed, now it's time to get the hands dirty on development :D

And I'll be a cheerleader!!! LOL :D

Cheers,
Bilu

@ bilu

Sorry bilu but to me it looks like people are just answering your guestions. Did somebody actually promise to work on any of this stuff? You sure are excited but i am not sure if developers are?

No offence :)

[bilu]

Not offended, you're right.

Bilu
:stupid:

[ChristianHJW]

Relax guys.

Bilu, Gizmo's concept of creating a quick and solid solution to be able to create real VFR MKV files, with existing AVISynth, makes sense to me.

He is right, you are thinking too much ahead into the future. I doubt if it would be the right thing to do to think about a new AVISynth which is VFR capable, as this would require a complete rewrite of the program, as Neo Neko was pointing out.

What you are trying to do is a bit further into the future than what is posible today. But, as you seem to be eager to push this further, i make the following offer to you :

1. I would like to work toegther with Gizmo on the solution he was specifying. It would serve most of the purposes already, without the need to make a new AVISynth. I invite both of you to join our IRC channel on irc.corecodec.com #matroska by time, so we can discuss with Mosu the possibility to read an external timestamp file into mkvmerge to create such files.

2. If you register an account on http://corecodec.org, i add you to the list of helpers for spyder's and jcsston's VFRE project. After all, this tool is exactly what you need and want and it can be programmed that way that existing AVISynth filters can be used in it, spyder is well capable of doing that as he was writing his own filters already for AVISynth and knows the API very well.
VFRE needs a nice, descriptive homepage and with that we could start to raise the interest of more developers also, and then over time we could create a new, true VFR video editing tool, the real successor of Virtualdub for the video editing of tomorrow.

What you think ??

[bilu]

@ChristianHJW

Loved your attitude. Thank you very much :)

About Avisynth development this is what seems to be needed IMHO:

http://forum.doom9.org/showthread.php?s=&postid=391208#post391208

- frame duration property;
- export to a timestamp log file, containing framenumbers and frame durations (maybe a filter?);

This seems to be the easy part but also the most necessary, because it would provide a framework for AVS VFR filter development and timestamp logs for both DShow filter and VFR muxer development.

The hard part seems to me to be also our lower priorities to Avisynth:

- using VFR sources in Avisynth, translating timecodes into frame duration;
- a filter that copies frames for VFR -> CFR conversions;

This should be done far in the future, as it won't be needed anytime soon and AVS core developers have other things scheduled as Directshow audio, as Neo Neko pointed.

The good thing about this top priority developments on Avisynth is that they seem easy and a great benefit for development.I'm just waiting to see Bidoche's opinion.


I will accept your offer as it puts me near enough the developers to know their concerns, and I'll try to do as much as I'm doing now to help. I do want us to get there :)

EDIT: A good thing about you and Gizmo start working on it now is that DShow and VFR muxer development can start sooner without waiting for Avisynth changes. If they eventually happen all that's needed is a timestamp log parsing adaptation.


Thanks again,
Bilu

[bilu]

BTW I never used IRC before :rolleyes:

Which client would you recommend? :D

EDIT: Already mIRCed.

Bilu

[Bidoche]

Reality check :

- Neither Avisynth 2.X, not Avisynth 3.0 is able to handle VFR and they will never be.

- Avisynth 3.0 is able to simulate VFR content over an underlying CFR stream by flagging frames by duration properties.

- Avisynth 2.X cannot tag frames with such properties, but it may able to achieve something using log files.

- Avisynth 3.0 and its properties are far from being released.

- The Avisynth Devs doesn't intend (at least me, but others have their hands full too) to include this in the core, everything can and should be developped as a plugin.

[bilu]

OK.

So a filter could work the same way as Telecide works with Decimate.
We only need IVTC and Dup filters to know about frame duration.
Another filter that dumps this into a log seems also easy.

Time to bug Donald Graft then :D
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?p=2310#2310

Bilu

[bilu]

http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?p=2313#2313

I regret that I haven't had time to follow the VFR threads. My basic stance is that I prefer a proper system architecture for it, and oppose hacks and kludges to try to add it to an architecture that doesn't natively support it.

So now this becomes a VFRE project and stops being an Avisynth project, unless I can convince Kevin Atkinson (SmartDecimate developer) to work on it.


Bilu

[nuked]

At the moment, I'm suggesting manual determination of frame rate and entry into the file a) Because it will be more reliable b) it can be implemented relatively quickly c) It make sure the encoder is capable of identifying what 30 and 24 fps content is.

OK, maybe it's lazy not to be willing to do this, but I can't possibly picutre it gaining any popularity whatsoever beyond one or 2 very hard core users and as a development stage.

If avisynth 3.0 can carry around frame duration codes, and maybe even with a hacked version of mpeg2dec to pull sped up 24 -> 30 stuff right off the dvd with the duration codes and incorrect times, then why not use gizmo's method but use something like this to generate the file for the muxer? Maybe it's slightly more future, but not as future as real VFR in avisynth(which seems like a non-starter for now and maybe forever). Some dvd's are messed up and will still be messed up and EVENTUALLY some filters may be made to fix up the time codes even better but that's all details.


A detail, but a bonus, this also avoids field matching and may thus provide the possibly avoiding alot of headaches with proper chroma sampling due to mixes of interlaced and progressive chroma sampled in weird ways coming off from the extra telecined frames. The fields coming from the telicened frame which never needed to be generated in the first place, will never be able to have as accurate of a chroma as frames that started progressive and remained progressive. Ok Going straight off the dvd also avoids the bad deciscions that gizmo mentioned made by dup or ivtc'ers and such. All your bad deciscions can be blamed on the DVD.

Well anyway, I'm not asking anyone to do any of it as I'll probably buy a DVD burner soon anyway(and because I don't ask people to do stuff... just offer my thoughts), but as an onlooking person who would use something if it did work, it seems to me if anyone is gonna make a process that can't be automated then they better be doing it for their own sake and not so they can feel they generously gave to the comunity, cause not too many people will use it if they have to mark segments by hand. It's cheaper to buy another copy instead of backing up and then spend your time selling lemonaide. If I'm wrong then folks feel free to chime in with an "I would". We'll see if there are more than 5.

[ChristianHJW]

It has been quiet here on this thread as there was a lot going on behind the scenes during the last days to move this forward, and because the matroska team, once again, got warnings from the mod team here to not talk about stuff that could be done, but only to present working code if we have such.

So, if you wnat to give your opinion on what to do here, please dont do it in this thread but contact the matroska team either on the IRC channel or by using our mailing list. Thanks