DGMPGDec 1.4.0 Final!

[neuron2]

Here is the next beta. It now can get MPEG audio out of an MPEG1 program stream. I addressed the window problem with tiny MPEG1 files by implementing a minimum window display size for DGIndex of 320x240. I was able to make it size correctly for (e.g.) 160x120, but the trackbar becomes a joke. So this seems like a reasonable solution to always have a usable trackbar.

Note that the chroma siting issue affects only conversion to RGB so it affects only the built-in conversion filter YV12toRGB24 and VFAPI. I would like to remove the built-in conversion filters (YV12toYUY2 and YV12toRGB24) because Avisynth has better ones. Any objections? I will modify VFAPI in a next beta.

Still, there is an interesting issue raised. If you can decode MPEG1 or MPEG2 and send it to Avisynth and then somewhere later a conversion to RGB is done, how does that conversion know whether to use MPEG1 or MPEG2 chroma siting??? Fortunately, the difference is very small and perhaps not of practical significance.

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

Your feedback on this beta will be greatly appreciated.

[SeeMoreDigital]

Originally Posted by neuron2

DGIndex does not modify the GOP in any way. Can you please follow this up with mpucoder?

I did and his reply was: -

Mpeg-1 has always been possible. But the same GOP constraints apply. This is not a Muxman restriction, but DVD. And considering that mpeg-1 has only frame pictures, more than 36 pictures means morethan 36 frames - twice the limit for DVD.
Make sure gop headers are not being removed - look at the original DVD with VobEdit to see how often [gop] occurs in the left pane. It should happen every I frame.

And his more recent reply was: -

A gop must start with an I frame, so if there are not enough I frames to make shorter gop's then the video must be re-encoded.
There is a reason for the gop length restriction, and it has nothing to do with picture quality (arithmetic error accummulation) or any decoder related issues. The gop length restriction sets the maximum size of the most basic unit used to compose a VOBU. And VOBU's in turn have length restrictions as well of 0.4 to 1.0 second except the last of a cell, which may be as long as 1.2 second. Having gop's longer than 0.6 seconds (the difference between the shortest and longest allowable VOBU) would create situations where it is impossible to compose a compliant VOBU.
And a gop longer than 36 frames is either 1.2 or 1.44 seconds long, depending on television standard, which is longer than a legitimate VOBU.
If DVB streams are not DVD compliant then they can't simply be stuffed into a vob to be played on a DVD player, they must be processed before authoring.

Cheers

[neuron2]

Thank you for that useful information, SeeMoreDigital! It does not, however, appear relevant.

You said that you demuxed the video from a DVD. It must therefore have DVD-compliant GOPs. Can you please make that point to mpucoder?

Can you please upload a chunk of the VOB to my server so that I can analyse it? Thank you.

[len0x]

Aspect ratio doesn't seem to be right for mpeg1 sources. For instance for 352x288 PAL source DGIndex displayed 4:3,625 when its clearly should have been 4:3...

[len0x]

More about AR in mpeg1 sources: I've got a few very weird ones - AR is displayed as 0.6735 (30fps 320x240) which is strange coz it doesn't have usual x:y notation at all. Its probably wrongly mastered (its still should have been 4:3) but it would be nice to see format of AR line in d2v file in generic form. Also what is the decimal separator used for AR values? It seems that sometimes its comma (3,625) and sometimes its dot (0.6735)...

[SeeMoreDigital]

Hi len0x,

I have a couple of PAL sources, that are both described as being 4:3, 625 even though they have been professionally encoded using different resolutions: -






And my NTSC sources are described as being 4:3, 525: -



It seems as though the 625 and 525 expressions are with regard to the analogue vertical line count.


Cheers

[len0x]

ah, that explains it! I think that vertical line count could be removed from AR line as its not really needed and just messes up parsers Still wondering about AR of 0.6735 though...

[SeeMoreDigital]

Originally Posted by len0x

ah, that explains it! I think that vertical line count could be removed from AR line as its not really needed and just messes up parsers Still wondering about AR of 0.6735 though...

Which reminds me... Does anybody know of any tools that can re-write the PAR/DAR codes for Mpeg1 streams - without re-encoding?

I've tried ReStream, which although the developer says only works with Mpeg2 streams, it does seem to be able to change the PAR/DAR codes of Mpeg1 streams to either 1:1 and 16:9... but not 4:3.


Cheers

[midnightsun]

it looks to me as if 4:3,625 means 4:3 PAL (625 being the scan lines of a 50Hz PAL tv) and 4:3,525 means 4:3 NTSC (525 being the NTSC counterpart of 625 as explained above)

[neuron2]

The Aspect Ratio field just reports the value from the ISO spec as I mentioned in an earlier posting. You can look at the table in the spec for details. Yes, ",625" means 625 lines, etc. That is the way it is described in the spec. There are oddball values without X:Y counterparts. That's why you see the funny decimal. Why it was used by the encoder I cannot tell you.

[neuron2]

Beta 3 adds multiple instantiation for DGVfapi. Also, DGVfapi can now convert AVS scripts in addition to D2V files! Sort of a bundled AVS2AVI, if you will. Please give a hearty round of applause to tritical for contributing these enhancements.

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

This is close to my release feature set. I want to integrate DGParse and DGFix and add GOP structure printout in DGParse output. Is there anything else that should be considered before drawing the line on the 1.4.0 release?

[mimage]

Originally Posted by neuron2

Beta 3 adds multiple instantiation for DGVfapi. Also, DGVfapi can now convert AVS scripts in addition to D2V files! Sort of a bundled AVS2AVI, if you will. Please give a hearty round of applause to tritical for contributing these enhancements.

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

This is close to my release feature set. I want to integrate DGParse and DGFix and add GOP structure printout in DGParse output. Is there anything else that should be considered before drawing the line on the 1.4.0 release?

It works so great for importing AVS files into Vegas!! Thanks a bunch for this release, it has made my day!

[kikounet]

Originally Posted by len0x

More about AR in mpeg1 sources: I've got a few very weird ones - AR is displayed as 0.6735 (30fps 320x240) which is strange coz it doesn't have usual x:y notation at all. Its probably wrongly mastered (its still should have been 4:3) but it would be nice to see format of AR line in d2v file in generic form. Also what is the decimal separator used for AR values? It seems that sometimes its comma (3,625) and sometimes its dot (0.6735)...

VideoCD standard never had complied to 1:1 Pixel Aspect Ratio (PAR)!
4/3 is 1.3333 but 352/288 is 1.2222 (PAL) and 352/240 is 1.4666 (NTSC)
Professionaly encoded VideoCD complies to standards, so we have to deal with that, sorry...

[len0x]

Originally Posted by neuron2

The Aspect Ratio field just reports the value from the ISO spec as I mentioned in an earlier posting. You can look at the table in the spec for details.

Can you point me to link with the spec, please? (is it hosted in your library?)

*Edit* I found the document on your website (mpgvideo.doc), but the table for pel_aspect_ratio seems to have mostly decimal values without corresponding AR like 4:3 for instance. How do you get values like 4:3,525 from it?

[guada 2]

Neuron and Tritical

Very Big and Good work.

Good bye

[neuron2]

Originally Posted by len0x

I found the document on your website (mpgvideo.doc), but the table for pel_aspect_ratio seems to have mostly decimal values without corresponding AR like 4:3 for instance. How do you get values like 4:3,525 from it?

Here's the table from the document:

pel_aspect_ratio	height/width	example	
0000	forbidden		
0001	1.0000	VGA etc.	
0010	0.6735		
0011	0.7031	16:9, 625line	
0100	0.7615		
0101	0.8055		
0110	0.8437	16:9, 525line	
0111	0.8935		
1000	0.9375	CCIR601, 625line	
1001	0.9815		
1010	1.0255		
1011	1.0695		
1100	1.1250	CCIR601, 525line	
1101	1.1575		
1110	1.2015		
1111	reserved

I have a later version of the spec at works that replaces the CCIR601 with 4:3.

[scharfis_brain]

are you sure, that those values are really the correct ones?

they all seem to be generic PAR, which is not recommended by ITU...

[SeeMoreDigital]

The 4:3 and 16:9 (NTSC/PAL) values are exactly the same settings I use when adding DAR signalling to my Mpeg4 streams.... nice!

[len0x]

Originally Posted by neuron2

Here's the table from the document:
I have a later version of the spec at works that replaces the CCIR601 with 4:3.

Ah, that explains it. Thanks.

[neuron2]

Originally Posted by scharfis_brain

are you sure, that those values are really the correct ones?

they all seem to be generic PAR, which is not recommended by ITU...

I just display the contents of the field as per the MPEG1 spec. Are you asking if the spec is correct?