mpeg2dec3 upsampling to yuy2 or rgb with mixed progressive/interlaced

[nuked]

I'm rediculously busy these days so forgive me if I overlooked a thread about this.

YV12 effectively has 2 diferent formats, interlaced and non-interlaced , and for upsampling to yuy2 or rgb you must know which you are dealing with to do it porperly without causing "CUE" or "ICP" effects. DVD's know this and a have a progressive flag marking frames as progressive or not so the right upsample will be used. Yes I know yv12 for interlaced material is fundamentally flawed anyway, but still upsampling correctly produces much less broken resultsthan upsampling incorrectly. Correct me if I'm wrong so far.

In avisynth 2.5 the yv12 is kept so there's no upsampling and the flag isn't needed. As far as I can tell the flag is not carried around inside avisynth anywhere. That's fine unless you want to upsample somewhere in avisyth using somethig like ConvertToYuy2(). Then you must explicitly state "interlaced=true" but this will apply then to ALL frames. But what if you have mixed content... some progressive and some interlaced? The best soltuion is to use interlaced=true cause this is by far the lesser of the 2 evils, but it still could be be much better and most mixed sources are mostly progressive.

How hard would it be to have an upsampling option in mpeg2dec3 that makes the correct upsampling frame by frame using the flags on the dvd? Even better would be to have a data format in avisynth that carries this flag around... but I guess that would have to be avisynth 2.6. and would require some updates to some filters to take advantage of it.

Someone will probably tell me to deinterlace it first before upsampling, but this is not always desireable and after all... avisynth is supposed to be modular... For that matter as far as I can tell there are probably some inaccuracies in how deinterlacers treat color especially when they inadvertently act on parts they shouldn't... prgressive parts... Keeping the flag could also allow the deinterlacers to know to ignore progressive marked frames if so chosen saving both time and quality.

(yes, there's also the every other broken flag issue in telecined dvd's but the correction for that is known and could be implemented as well.)

[Wilbert]

Even better would be to have a data format in avisynth that carries this flag around... but I guess that would have to be avisynth 2.6. and would require some updates to some filters to take advantage of it.
This flag is present in AviSynth v3.0. I don't know whether Bidoche already changed ConvertToYUY2 for this?

[nuked]

ooh yikes... I am indeed behind the times. I asked a little about this over on neurons site and noone mentinoed a 3.0 so I figured I would at least not be missing by that much. Well if the flag is there then I'm sure the utilities will follow. Quite nice. :) now hopefully it will even work it's way into codecs. :)

[trbarry]

There is also still a version of MPEG2DEC2 around somewhere for Avisynth 2.5 that will use the flags to return YUY2 if you need it.

- Tom

[nuked]

Yes, I found it now ( I think.. will try it later), thanks. I suppose it would be a bit of a stretch to want something like that which works with Grafts new dvd2avi open GOP fixes. I may ask DG about implememnting the yuy2 conversion in his mpeg2dec3 version instead.

[sh0dan]

This might help (on any source), when Don get's time for a proper release.

http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=207 See my second post.

[Bidoche]

I haven't done much on filters yet for 3.0, only some basic edit filters (Trim, Splice and such...)

Anyway don't expect me to write such code, I am good at C++ and architecturing but I am not a video wizard (well now better than before :p)
Besides it will probably be written in assembly which I don't know much.


In that case, convertoYUY2 is easy, it's just child->GetFrame(n)->convertTo(YUY2);
It's VideoFrame convertTo method which must be filled.

Anybody up to the task can do it (msg me for some 3.0 explanations 1st)

[nuked]

@shodan. Nice idea. Not a bad hack for the mean time. Of course stuff that's not combed may well still have it's color represented in an interlaced fashion. But in cases where most stuff is progressive anyway this should alleviate the worst types of problems and preserve quality on the progressive parts.

[sh0dan]

@nuked: No - chroma placement will always be the same for the entire frame.

In general I'd clearly recommed interlaced upsampling for mixed material.

[nuked]

Oh.. no I don't mean it wil be diferent within the frame, of course not, just diferent for diferent frames. Some interlaced frames with no motion may have no combing or not enough to distinguish it from a progressive frame. So some interlaced frames will end up being upsampled in a progressive way with your trick. I agree, if you MUST chose only one.. interlaced is much better for mixed material.

[sh0dan]

I looked a bit more into this. Actually I'm not sure mixed upsampling is a good thing. If you do a:

stackhorizontal(utoy(),vtoy())

after a mixed mode upsampling (I did it on FILM material telecined to NTSC), and apply adaptive chroma upsampling, you'll see chroma in static areas moving around and being reinterpolated. It is not noticeable on the final output, but it will for sure make compression a lot harder.

A simple ConvertToYUY2(interlaced=true) however has static chroma on combed/noncombed frames, which is preferable in any case I can think of. This might be due to the way (some) encoders work, but it does make mixed mode upsampling sound a lot less interesting.

[nuked]

are you saying there is motion because of flipping back and fourth between interlaced upsampling and progressive throughout the telecining pattern? Ok I'll have to read up on teh details again but aren't all telecined frams(assuming no hard telecining) stored with progressive chroma on the dvd normally? It's only the "extra" 5th frame that pops out of mpeg2dec as interlaced isn't it? (I could well be wrong here) So if a good job of field mathcing is done so that these fields get tossed then I don't see why there should be a problem. Of course nothing garauntees such good field mathing. But if you use the flags in you're ivtc algorithm to effectively "force film" on the segments where you can and only field match when you have to(for hard telecining segments which should have constant chroma sampling anyway, or just plain for field mathing on true interlaced segments...yuck), then I thought you should get only progressive chroma frames from the telecined parts. As well, the glitch I described above may also be plagueing static progressive areas if your combing threshold is catching a few frames for random reasons and not others. Well I'll have to play around with it a bit and see for myself I guess. But what I remember from things I've already palyed with is that I've found times when mixed upsampling would help. I just generally think it's a broken standard that really is 2 standards at once but has no information carried along as to which one is being used. If the user(or filter programmer) wants to upsample everything the same anyway then ok, but the filters should be able to know what format the informtion they are dealing with is in.

edit: even you upsample before IVTC I would think you're method would not be able to catch the frame in the pattern with interlaced chroma since there would still be no combing in static scenes and it would still do a progressive chroma upsample on it which would be wrong. Are you sure this isn't the source of your color jitter?