DGMPGDec 1.4.0 Final!

[neuron2]

Originally Posted by len0x

Does current version open DAT files (VCD) directly without renaming to mpg extension?

Yes, but they won't show up in the open dialog unless you choose "All files" in the "Files of type" pulldown, or drag them onto the DGIndex window. CLI of course can specify them directly.

BTW, I've seen an MPEG1 that had a height not a multiple of 16. But DGMPGDec is riddled through with the assumption that the display width/height are the same as the encoded width/height. The result is a black bar at the bottom. The workaround (for now) is to put Crop() in the script.

[len0x]

ok, thanks.

[Cyberia]

FYI: drag-n-drop also works for dat files.

[neuron2]

This addresses a bug in transport parsing. For details, see here: http://forum.doom9.org/showthread.php?t=93190

DGMPGDec 1.4.0b8:

http://neuron2.net/dgmpgdec/dgmpgdec140b8.zip

[neuron2]

Here is 1.4.0 release candidate 1. The changes from beta 8 are as follows:

* Removed YV12toYUY2() and YV12toRGB24() because they duplicate Avisynth native filters.

* Changed the LumaFilter() offset parameter default to 0 (from -2).

http://neuron2.net/dgmpgdec/dgmpgdec140rc1.zip

[Cyberia]

I thought we had those colorspace converters because AviSynth did not have the necessary information to upsample interlaced formats correctly some of the time? (ie: PROGRESSIVE_FRAME flag)

EDIT - See this thread: http://forum.doom9.org/showthread.ph...12toYUY2%28%29

EDIT2: I remembered in the old MPEG2Dec3 manual the lumaoff parameter was set to -2 with a comment "for iago", so I did a search for "iago mpeg2dec3" and found this thread: http://forum.doom9.org/showthread.ph...iago+mpeg2dec3 which basically says MarcFD set the lumaoff to -2 to avoid luma blocks. It is a long thread, but just look for iago and MarkFD's comments.

Summary: iago did some extensive testing and saw blocks in the black areas, but seting lumaoff=-2 tweaked the luma just enough to remove the blocks without changing the original image in a perceptable way. MarkFD accepted it, but thought it was not the best solution.

[neuron2]

Originally Posted by Cyberia

I thought we had those colorspace converters because AviSynth did not have the necessary information to upsample interlaced formats correctly some of the time? (ie: PROGRESSIVE_FRAME flag)

Nope. Those filters did not, and could not, use the progressive_frame flag. They receive decoded video from MPEG2Source(). And anyway, if you need that capability, you use upConv=true.

Summary: iago did some extensive testing and saw blocks in the black areas, but seting lumaoff=-2 tweaked the luma just enough to remove the blocks without changing the original image in a perceptable way. MarkFD accepted it, but thought it was not the best solution.

Users can set -2 if they like it. Mention it in the manual if you like. But it sounds silly to me.

[ARDA]

@neuron2

I address you about this subject for second time
First time here http://forum.doom9.org/showthread.ph...698#post655698
As I think I couldn't make me understand I''ll try to be more clear now

LumaFilter had serveral bugs and special features

First time a bug was detected was about LumOffsetMask and LumGainMask
http://forum.doom9.org/showthread.ph...136#post322136
I've spotted to Nic but for what I've seen just half of the bug has been
fixed.The way the variables were declared (__declspec(align(8)) static __int16)
didn't allow a second instance of the filter in the same chain; cause it repeat the
first input parameters; are still present in two cases in DGDecode.dll.
In fact what I've done was completely change the way to pass the parameters

Another question it has not parameters controls.In some cases it can output corropted
images.I've also included that.

There also an important feature which I've also pointed
in this thread http://forum.doom9.org/showthread.php?t=71452
more than a year ago.Nobody answered.
Finally I've believe that when MarcFd tested LumaFilter was in time when there
was a SeparateFieldsYV12 in MPEG2Dec3 0.94 which worked creating two real new frames
in different memory areas.SeparateFields the internal one just redifine the size of pitches
and readjust the pointers.That is why any filter built over frame area (pitch*height)
will not work correctly.To avoid that I've include row loops when vi.IsFieldBased()=true
By now is an easy solution but I'm not sure if it is the best.
Anyway for my own use I've modified a little bit SeparateFieldsYV12 as an idependant plugin
If anyone is interested to bring it up just ask.

Obviously the -2 parameters as default you've already corrected

And finally I've made separate assemblers codes for SSE2 ISSE and MMX
where I've added some optimizations.
There is a lot of duplicated code and I hope as always you can be generous
in your opinions. This plugin was renamed as you can see for one I've found more
appropiate and to avoid conflicts

Many would ask why all this; just to improve perfomance and in some of my machines
more than 50%.
***********************************************************************************
LumaYV12 plugin for Avisynth 2.5 by ARDA.

LumaYV12 is a new version of LumaFilter included in MPEG2DEC3.dll by MarcFD.

It assumes [0->255] YUV range, and not CCIR 601 [16->235].
Use limiter() afterwards if you think you need it.

Syntax: LumaYV12(lumoff=param,lumgain=param) or LumaYV12(param,param)

WARNING!!WARNING!!

lumoff=-256 to 256 (integer) ; default 0 and will do nothing.
lumgain=0 to 2.0 (float) ; 1.0 is default and will do nothing.
************************************************************************************
WARNING!!WARNING!!

This plugins was done for my own use trying to achieve a better perfomance
in my pentium4 cpu; I've also included Integer SSE and MMX routines but
perfomance was not tested.
It must run on any SSE2 machine but perfomance is not guaranteed.

I've also included row routines to avoid first line problem after separatefields.
Seems there is not real two frames, but a redefintion of pointers and pitches.
Maybe there's another way to avoid that problem but I couldn't find an easier one.
Row loops will be here till SeparateFields could be modified.

Actually they are exercises; so there are a lot of unnecessary duplicated code.
There must be a lot of spanglish variable names; my apologizes for that.

Please be patient!.-
I'm an eternal newbie coder.-
************************************************************************************


download
http://ardaversions.iespana.es/lumayv12.7z

As always I hope this can be useful.
ARDA

[neuron2]

Originally Posted by ARDA

The way the variables were declared (__declspec(align(8)) static __int16) didn't allow a second instance of the filter in the same chain; cause it repeat the first input parameters; are still present in two cases in DGDecode.dll.

Agreed. Thanks for pointing it out.

Another question it has not parameters controls.In some cases it can output corropted images.

Range checking? Fair enough.

There also an important feature which I've also pointed
in this thread...

I've duplicated this and it is a bad problem. I'm not sure I like the way you've fixed it. I have to think about it.

And finally I've made separate assemblers codes for SSE2 ISSE and MMX where I've added some optimizations.

That sounds useful.

I'll test your filter version and if it appears OK, I'll replace the existing broken one with it. Thanks for your contribution.

Also, if you could report your issues in the development thread prior to the release candidates appearing, it would be appreciated.

[Marius-the-Mad]

neuron2, thank you very much for MPEG 1 support. DGDecode is great and now it's even better.

I have a question connected to MPEG 1 support. DGDecode seems to output YV12 by default for MPEG 1. Is it intended behaviour ? If it is, does using upconv=true result in original YUY2 or is it the upsampled version ?

Sorry if I'm being silly, but I couldn't find anything about it.

[neuron2]

Originally Posted by Marius-the-Mad

DGDecode seems to output YV12 by default for MPEG 1. Is it intended behaviour?

Yes. Do you think it shouldn't be?

If it is, does using upconv=true result in original YUY2 or is it the upsampled version?

I don't know what you mean by "original YUY2".

[Marius-the-Mad]

Sorry. It was my impression that MPEG 1 used YUY2 instead of YV12. I thought it would be nice to have it in YUY2 by default.

Again, sorry if I'm confusing things.

[Cyberia]

Without YV12toRGB24() do we still need the TVScale option in DGIndex?

[neuron2]

Can anyone give a reason why LumaFilter() should not be dropped altogether since the Avisynth native filter ColorYUV() is more capable?

[ARDA]

Originally Posted by neuron2
I've duplicated this and it is a bad problem. I'm not sure I like the way you've fixed it. I have to think about it.

I agree with both affirmation

Originally Posted by ARDA
By now is an easy solution but I'm not sure if it is the best

Row loops will be here till SeparateFields could be modified.

Also, if you could report your issues in the development thread prior to the release candidates appearing, it would be appreciated

You're right my apologizes next time I'll just upload that parts of code I think
could be usefull.

But I hope you understand after looking at the sources that I've used such filter as exercise for many other things.

Your mate
ARDA

[ARDA]

Just one with the optimizations I've done the difference in perfomance would be giant.
Obviously in those functions with similar results.
That could be a simple reason if speed is important in some cases.

ARDA

[neuron2]

Originally Posted by Marius-the-Mad

It was my impression that MPEG 1 used YUY2 instead of YV12.

Oh, I see your point now. MPEG2 supports 4:2:0 and 4:2:2, but MPEG1 supports only 4:2:0. Even if it had 4:2:2 it could be handled in the same way as MPEG2 (leaving aside chroma siting).

[neuron2]

Originally Posted by ARDA

Just one with the optimizations I've done the difference in perfomance would be giant.
Obviously in those functions with similar results.
That could be a simple reason if speed is important in some cases.

OK, thanks.

[Marius-the-Mad]

Originally Posted by neuron2

MPEG2 supports 4:2:0 and 4:2:2, but MPEG1 supports only 4:2:0. Even if it had 4:2:2 it could be handled in the same way as MPEG2 (leaving aside chroma siting).

Thank you for the explanation. I have to remember that.

[SeeMoreDigital]

Hi Donald,

Earlier today approached mpucoder about with the following suggestion: -

Hi mpucoder,

Would it be possible to increase the range of the of the "Delay" settings [of MuxMan]. The current range is between -300ms to +300ms.

Earlier today I used DGIndex to de-mux 5No clips (with different run times) from within the same .VOB file and obtained audio streams at -320, -160, -448ms, -224 and -288.

However, when I used MuxMan to re-mux the -448 .AC3 stream to the .M2V stream, it was sadly out by miles

Followed by my second post: -

...I often receive "Show Reel" DVD's from people within the media industry that contain multiple short clips of their work - TV/cinema commercials mostly, pop promos, short films and the like...

A typical TV/cinema commercial can run anything from between 10 to 90 seconds and usually a DVD arrives on my door step with several clips running one after another, burned into one .VOB and with no chapter breaks!

What I currently do is use DVD Decrypter to drag the .VOB file(s) onto my PC and then DGIndex to separate and select the start and end points for each clip.... But this creates individual de-muxed clips with very different audio delays!

If the delays are no greater than -300 to +300ms I can correct them perfectly with MuxMan... but not, if the are outside of those limits

To which mpucoder replied: -

...this is caused by not de-multiplexing the audio properly. When extracting elementary streams, does it not make sense to extract the streams in sync? That is, to extract the audio that corresponds to the video. Why not go here [your DGIndex thread] and ask for a fix to the problem.

And if there are de-multiplexers that do this properly, my apologies for not mentioning them - feel free to speak up.

(If you require reading all the posts please look here)

I wonder, is this a DGIndex problem or an I going about this entire exercise the wrong way?


Regards