DGMPGDec 1.1.0 version definition

[Wilbert]

I don't understand your request at all. Can you be more be explicit?

I meant the following. From http://www.avisynth.org/index.php?page=ColorSpaces

YV12 interlacing

YV12 handles interlaced chroma differently than compared to YUY2, since YV12 only contains
chroma information for every second line.

To enable interlacing, chroma is stretched across two luma lines in the same field! That
means that luma and chroma isn't directly mappable to lumaline/2 and lumaline/2+1 as
framebased images.

line 0: Chroma for interlaced luma lines 0+2
line 1: Chroma for interlaced luma lines 1+3
line 2: Chroma for interlaced luma lines 4+6
line 3: Chroma for interlaced luma lines 5+7
...etc!

in other words

luma line 0: chroma line 0
luma line 1: chroma line 1
luma line 2: chroma line 0
luma line 3: chroma line 1
luma line 4: chroma line 2
luma line 5: chroma line 3
etc ...

Progressive YV12:

line 0: Chroma for interlaced luma lines 0+1
line 1: Chroma for interlaced luma lines 2+3
line 2: Chroma for interlaced luma lines 4+5
line 3: Chroma for interlaced luma lines 6+7

If I understand it correctly: if your source is progressive encoded as interlaced (thus has an interlace flag) and you want to apply a denoiser/smoother (which assumes progressive YV12), you need to reshuffle the chroma lines (so that the smoother is averaging over the correct chroma lines).
Thus we should have a filter that does the following: chroma lines (0,1,0,1,2,3,2,3,...) -> (0,0,1,1,2,2,3,3,...) (if flag indicates interlaced).

Again, sorry if I'm talking nonsense.

[Guest]

I'll give it to you from my perspective.

First, you talk of a trait 'progressive/interlaced' independent of the encoding, as if it is a disembodied character of the video. But consider a frame with just an arm moving between fields. Most of the frame is "progressive", and just some of it is "interlaced". So I have a problem with your concept to begin with. How will you encode this per-pixel(!) quality? Another case is hard telecining, where some frames are "progressive" and some "interlaced". Do we call that clip progressive or interlaced?

But suppose we take a restricted version of your concept, where we have a progressive movie with never any different pictures between fields, and we encode it as interlaced. You are suggesting that I can do some special trick during upsampling so that succeeding filters that assume progressive sampling will not misbehave. Let's see if that is so.

We will assume naive downsampling and upsampling (no interpolation), because the result doesn't change significantly. Consider first the chroma lines before sampling. A means picture A.

A0
A1
A2
A3
A4
A5
A6
A7

(For interlaced video, we would have had A0, B1, A2, B3, etc.)

Now subsample using interlaced sampling:

(A0+A2)/2
(A1+A3)/2
(A4+A6)/2
(A5+A7)/2

Now consider how to upsample that. If we upsample using interlaced, we get:

(A0+A2)/2
(A1+A3)/2
(A0+A2)/2
(A1+A3)/2
(A4+A6)/2
(A5+A7)/2
(A4+A6)/2
(A5+A7)/2

If we upsample using progressive, we get:

(A0+A2)/2
(A0+A2)/2
(A1+A3)/2
(A1+A3)/2
(A4+A6)/2
(A4+A6)/2
(A5+A7)/2
(A5+A7)/2

You can already choose which of these you want, and I don't see any alternative that would improve things for following filters, because the mixing performed by the sampling cannot be undone. It seems to me that what you are asking for (shuffling the chroma lines) can already be achieved simply by using normal progressive upsampling.

But I suppose I could be suffering from a lack of imagination. So, in terms of my analysis, what exactly are you suggesting that I should do differently with respect to upsampling for the case where a progressive video has been sampled using interlaced?

[Guest]

BTW, I have completed the changes and documentation for the upsampling fix. I'll do some testing and make a release this evening.

[Cyberia]

Step 3.
Revise the new conversion filters to accept hinting of the progressive/interlaced flag. The filters will support 3 modes: auto (follow the progressive/interlaced flag), force interlaced, and force progressive.


What does this imply for the IPP parameter in DGDecode? Is it set internally now...no need for the parameter? Do the other PostProcessing parameters (CPU, CPU2, LumaFilter, BlindPP) need to also be updated to see the hint?

check boxes next to the PID list so i can select which two i want
then when I close the window they are used without needing to open
select pid window.


I think this is a good idea, but it certainly isn't a priority. Perhaps combine all three PID menu options into one dialog with a "Detect PIDs: PAT/PMT" button, a "Detect PIDS: Raw" button, and some way to graphically populate the PID fields from the table. You could also manually specify the PIDS.

However, developers generally don't work on the GUI until they are done and bored! It's a developer thing. Want me to add to to the list (way down)?

[Guest]

Originally posted by Cyberia
What does this imply for the IPP parameter in DGDecode? Nothing. I haven't looked at that stuff yet. But thanks for pointing it out. BTW, it wouldn't need a "hint" per se; it has direct access to the flag. Hints are just needed to pass to an external filter. Hints are hidden in the picture. Don't worry, you'll never see them. In fact, I challenge you to find them -- without looking at the source code!


Want me to add [gui suggestions] to the list (way down)? Sure. Why not? It'll be fun to read them again in a few years. :devil:

[Zep]

Originally posted by neuron2
Yes.

If I had infinite time available, I could spend some of it on stuff like this. Sadly, I do not.
i would think there would be frameworks for such basic tasks
so that you wouldn't need infinite time to re invent the wheel :D

on OSX it comes down to this.

OpenWindow() #just show the text

or

OpenWindowWithEdit() #drop in replacement with basic editing about the level of wordpad


ahhh well i tried ... :)

[Cyberia]

Are they along the right edge of the video?

[Guest]

See! I knew you couldn't find them. Try Subtract().

Actually, I used sub-pixel granularity with a step size of 1/512. And I'm sure you know the significance of that! :)

[eb]

neuron2,

Do you mean end of the text of .d2v file as a hint

eb

[Guest]

@eb

No. Hints are stolen low-order bits of 64 top-edge pixels. I lied to Cyberia. :) The first 32 bits encode a magic word that allows the filter to determine if hints are present, and the other 32 bits are actual hint data.

@all

Gosh, don't you hate it when your house of cards comes tumbling down?

I just realized the upsampling fix I implemented is useless. The problem is that I forgot about RFF flags, a.k.a., pulldown. Suppose we have a nice, well-encoded DVD master of a progressive source using 3:2 pulldown to get to NTSC frame rate. Here are the flags for a cycle:

frame 0: pf=1 rff=1
frame 1: pf=1 rff=0
frame 2: pf=1 rff=1
frame 3: pf=1 rff=0

After pulldown, we will have 5 frames but only 4 pf flags. Oops. But worse, even if we extrapolate pf=1 to the extra frame, it's not right, because two of the frames after pulldown are now interlaced. There's just no way to use the pf's meaningfully in this situation. We could try to save ourself by mutating the pf to 0 when we have made an interlaced pulldown frame, but that isn't even correct if you think about it carefully.

So, what is to be done? Well, it's clear that the upsampling must be done using pf *prior* to pulldown, which completely shoots down the idea of hints and telling an external filter what to do. That means the conversion must be internal to DGDecode.

There is another serious issue as well -- that is the inherent unreliability of pf's in the first place. A careful reading of this article will enlighten you in that regard:

http://www.hometheaterhifi.com/volume_7_4/dvd-benchmark-part-5-progressive-10-2000.html

So, it's back to the drawing board for me. :scared:

[eb]

@ neuron2 wrote:

See! I knew you couldn't find them. Try Subtract().

Such kind of behaviour I already met during my tests on DeLogo filter with VirtualDubMod program, hidden data in the picture.
The case was not so sofisticated as yours but rather trivial one, it was used by popular program for converting video to .avi files.

And assuming that individual pixel can have 32 bytes values of color then using only let say 10 000 such hidden pixels in the whole movie, then all history of the next digital copies can be written there .

During this tests I was thinking that DELOgo engine can be used also to find such pixels.

But all this above it is not connected strictly with kind request to you about DeLogo filter:
namely,

I have ask to you, could you implement special button in the delogo configure that will append actual settings of the sliders and corections bitmaps to the frame number and this settings should be valid to the next such setting point, then to the next and so on. By this way we will be able to set individual parameters up to every frame.

As example when scene change from light to dark, when moving elements under logo are horizontal or vertical then streching repaired areas horizontaly or verticaly we can improve efficiency of the filter.

Seeing you a little relaxed after very hard last days I decided to write this post here, but may it can be moved to VirtualDubMod section.

eb

[Guest]

@eb

I'm wondering why you don't address the DeLogo enhancement request to its author:

Karel Suhajda
kasuha@post.cz

[eb]

neuron2,

I tried several times by e-mail but without any results.
Nowadays spam and viruses making difficult such contacts, if you have another possibility please help.

eb

[Leak]

Originally posted by neuron2
I just realized the upsampling fix I implemented is useless. The problem is that I forgot about RFF flags, a.k.a., pulldown. Suppose we have a nice, well-encoded DVD master of a progressive source using 3:2 pulldown to get to NTSC frame rate. Here are the flags for a cycle:

frame 0: pf=1 rff=1
frame 1: pf=1 rff=0
frame 2: pf=1 rff=1
frame 3: pf=1 rff=0

After pulldown, we will have 5 frames but only 4 pf flags. Oops. But worse, even if we extrapolate pf=1 to the extra frame, it's not right, because two of the frames after pulldown are now interlaced. There's just no way to use the pf's meaningfully in this situation. We could try to save ourself by mutating the pf to 0 when we have made an interlaced pulldown frame, but that isn't even correct if you think about it carefully.

Okay, so in that case your fix might be useless, but what if you select "force film" or "raw encoded frames" in DGIndex, as you probably don't want the telecine before processing anyway?

That should give you (if it really is a film source) 24FPS video that should match the pf-flags, right? And if you really need the pulldown, it's probably a better idea to re-add it at the end of the filter chain with AVISynth than to apply filters to the still/already telecined source... (at least that's what I'd do, especially since I would just speed everything up to 25FPS, being in PAL-land...)

In other words - I wouldn't call it "totally useless"... :)

np: Gescom - Slow Acid (SKA20CD)