frametype as info in mpeg2source()

[Malcolm]

Hi,
i often do image comparisons (e.g. DVD-Shrink vs. xyz) with avisynth scripts using mpeg2source(). in DVD-Shrink (for example), the mpeg2 frametypes (I,B,P) are handled very different. So it would be great if i could see the type of the current frame! is it possible to add a parameter to mpeg2source(), let's say info=(TRUE|FALSE) or debug=(TRUE|FALSE) and put a small text over the video that shows the frametype? the text should be small, so i can still concentrate on the video. (i hope my needs aren't too specific :) )

a useful addition would be when mpeg2source gives out the frametype to avisynth, so you can modify filtersettings or so based on the current frametype. this would give a lot of new abilities...
this would be just as giving out attributes like BFF/TFF or interlaced/noninterlaced.

Greetings,
Malcolm

[Cyberia]

I agree, and it was already on the to-do list. ;)

Hopefully it wil end up working similar to the Info() filter of AviSynth. Please suggest any more info you want displayed:

Frame Number
Frame Type (maybe GOP info too)
Anamorphic
Interlaced/Progressive
NTSC/PAL
TFF/BFF
Bitrate

[lark]

it would also be great, if the info was available as avisynth variables for conditional filtering.

how about: quant?

regards
t :)

[Malcolm]

bump

Any progress or news?

[tritical]

When I was working on some things last week I hacked this up to check some of dgdecodes internal values: [link removed]. Basically a straight 1.0.12 dgdecode, but with an info parameter (just add info=true into the mpeg2source() call). Is this the type info output your looking for? I stopped working on it because for some reason the quants it was displaying were one frame behind the quants drawn on the screen by the showQ option and I never figured out why. Someone who knows the dgdecode code well could probably figure it out pretty easily. How I did it was pretty hackish (in fact some of the info could be wrong at times), but just wanted to see if this is the type of thing your wanting.

[zettai]

The main issue for me is the colourspace one with mixed frame types (mixed progressive and interlaced encoding). I'd like to see hints available so that colourspace conversions and deinterlacing could be done dependent on what the encoded frame type is. At the moment the only way to have mixed progressive/interlaced source with correct chroma is to go and use the old YUY2 mpeg2dec as it upsamples correctly.

[lark]

and i was looking a plugin that would give me access to the info as avisynth variables (accessible in my own scripts)...

regards
t :)

[tritical]

Adding the ability for dgdecode to upsample internally based on the progressive_frame flag on a per frame basis like old mpeg2dec use to do would be easy. Everything needed for that is already there. However, passing hints so that it could later be done in AviSynth would be a much bigger and more complicated task. Same thing applies to lark's request. Could one or both of you elaborate on exactly how you would want your ideas to work?

[zettai]

Doing the upsampling internally would be totally fine. I actually thought hints would be easier (as you could just do them the same way decomb does them).

[zettai]

To clarify about hints, decomb (for example) can be used to give is_combed hints for use with ConditionalFilter(). I dont know how that is written but the same idea would be applied to frame stats such as a hint mpeg2dec_aspect= or mpeg2dec=progressive=

[Malcolm]

@tritical
thank you very much! this is brilliant! :)

greetings,
Malcolm

[tritical]

Well, it would not be able to work the same way a conditional filter like IsCombed() works. Even though it is part of decomb, IsCombed() is a standalone filter... it takes in the current frame, runs it through its combed frame detection (it just uses decomb's combed frame detection routine) and then returns true or false. If you add a conditional filter to mpeg2dec like IsProgressive() its return value depends on something that only the decoding mpeg2source() knows (the progressive frame flags). How or if you could coordinate the two I have no clue. Though you could probably do it via env->SetVar using an array, but that brings up multi-instance concerns. Or it could have pointer to the instance of mpeg2source() and access info that way i guess. Also, any colorspace up conversion would have to be done before pulldown, so unless your doing raw frames mode the conversion would have to be done internally anyways.

[Cyberia]

@tritical - wonderful! Its exactly what I was wanting. Thanks.

[tritical]

Well, probably not exactly what you wanted because it was wrong :p. The temporal reference wasn't handled correctly so the Frame Type, Quant, and progressive_frame flags were in the incorrect order and were mapped to the wrong frames. I fixed that and now everything lines up (quant numbers and showQ), made a new version: [link removed], also went ahead and made some other changes cause I had too much free time today. Those include:

iPP based on progressive_frame flag
4:2:2 input works now
fixed that BlindPP syntax problem (x vs X)

Should be able to add the internal upsampling based on the progressive_frame flag in a little bit as well.

[tritical]

Third time's a charm hopefully. [link removed]. Changes this time:

- the 4:2:2 support from before was no fully correct so fixed that
- 4:2:2 Planar post-processing support
- fixed a bug in 4:2:0 vertical chroma deblocking (QP pointer being passed was slightly incorrect)
- 4:2:0 to 4:2:2 upsampling based on progressive frame flag (upConv parameter)
- use mmx 4:2:2 to packed YUY2 conversion instead of slow c one
- fixed a small memory leak with FrameList/GOPList

[Cyberia]

@tritical - the change you made to the iPP parameter (changing from boolean to integer) will break apps that create scripts for AviSynth (GK, et al.)

My suggestion is to use a True/False/Auto notation instead. This preserves backwards compatibility.
iPP=True

iPP=False

iPP=Auto (default)

[Leak]

Originally posted by Cyberia
@tritical - the change you made to the iPP parameter (changing from boolean to integer) will break apps that create scripts for AviSynth (GK, et al.)

My suggestion is to use a True/False/Auto notation instead. This preserves backwards compatibility.
iPP=True

iPP=False

iPP=Auto (default)

Ummm... which kind of AviSynth parameter takes the values true, false and auto without being a string parameter that needs quotes around those values?

I fear your solution, while being nice, can't be implemented while being compatible with old scripts... :(

np: Nils Petter Molvær - Frozen (Streamer)

[tritical]

You posted just before I was gonna post one last version :D, which will really be the last one this time since it appears Don is gonna start working on it again :). [link removed] look here instead: http://forum.doom9.org/showthread.php?threadid=88167.

Sorry about the iPP change, I was not thinking about maintaining backwards compatibility.... cause I was thinking of this as more of a take off with a few extra specific features then a main version. But to change it back was easy. I used your suggestion (I think ?) and now if iPP is not explicity set to true or false it defaults to auto (or -1 as I had it before).

The other change this time was YUY2 support for BlindPP, and that's it.

[Cyberia]

Originally posted by Leak
Ummm... which kind of AviSynth parameter takes the values true, false and auto without being a string parameter that needs quotes around those values?

I fear your solution, while being nice, can't be implemented while being compatible with old scripts... :(

Well this is how it works in every version of MPEG2DEC3/DGDecode so far.

EDIT: NM, my mistake.

[Guest]

Originally posted by tritical
You posted just before I was gonna post one last version :D, which will really be the last one this time since it appears Don is gonna start working on it again :). Hi tritical. I've been reviewing your changes and you've done some great things! I'm incorporating your improvements right now. Many thanks for your contributions and "hats off to you".