DGMPGDec 1.4.7 Final

[Sharktooth]

BTW, version 1.4.8 will revamp the CLI and make all parsing information available to 3rd-party apps.
that means we will stick for a while with 1.4.7 until we update the commandline generation for the new CLI :cool:

[Guest]

Or maybe it will support both. :)

[clone83]

why not update the GUI aswell... maybe add some new menus or something like that...?

[Guest]

why not update the GUI aswell... maybe add some new menus or something like that...? What new menus did you have in mind?

[clone83]

hmmmz maybe a new encoding feature with the selection of divx, xvid, x264/avc and any other ones u decide to use...? that i think would top off ur program from the others... because you are able to create the d2v file and you can give them the option to encode their file aswell. or you could make an automated option to do it all at once. but these are just thoughts what does everyone else think should be added?

[Sharktooth]

no problems reported yet ;)

[Guest]

no problems reported yet Oh, goodie.

I found one, though. You can't process MPEG1 video in a transport stream. I have it fixed in my last build and it'll be in the 1.4.7 final.

Thank you for your feedback.

[bond]

hi neuron2

looking at this clip (http://www.one.seemoredigital.net/Temp_Files/Pure_Interlaced_HDTV_MPEG-2_Source.zip) i noticed that dgdecode doesnt seem to automatically remove the bottom 8 pixels (making it 1920x1080 from x1088). both libmpeg2 and libavcodec do this

i guess with hdtv 1080i/p becoming more popular this thing might become more important too

thanks!

[Guest]

That's been discussed before but may be worth revisiting. I'll see what I can do about it.

[Guest]

At first I thought I could just detect a height of 1088 and then set the clipping GUI for 8 off the bottom. But it turns out it is more complex.

Instead of observing the vertical_size field in the sequence header, or the display_vertical_size field in the sequence display extension, DGIndex uses the coded picture height, i.e., 16 times the number of macroblocks vertically. Usually this is OK, because the intended display size is usually a multiple of 16. But 1080 is not a multiple of 16. Your test stream correctly specifies a display size of 1080, but DGIndex ignores it.

DGIndex should be revised to properly use the specified display size and not to use the coded picture height. I believe jackei made some changes in this area for his latest version of DVD2AVI, but I don't know if he addressed this specific issue. It's a major change and so I will defer it to the next version. The workaround for now is to use the GUI clipping or Crop() in your AVS script.

In the next version, as well as fixing this, I will clean up the clipping GUI.

[Isochroma]

Sounds like an excellent idea! Trouble for me, is that I made lots of .avs with crop() set for each of the transport streams to get rid of that bottom edge. With the new version, they will need to be revised. In the long run however, this change will save me significant quantities of labour. It is a welcome change :)

[bond]

:thanks:

[Guest]

* Fixed problem that made it impossible to demux MPEG1
video from transport streams.

* Fixed a problem that caused a long delay before a play or
preview operation begins for some transport streams.

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

[Adub]

Yes!! Now I feel totally safe to update completely. Good work yet again, neuron2!

See Ya, Dude!

[Guest]

Had to crank a new version to fix a DTS/AC3 detection problem for transport streams using stream_type 0x06.

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

[Kostarum Rex Persia]

neuron2, can DGMPDec 1.47 read H.264 transport stream?

[SeeMoreDigital]

MPEG-1 and MPEG-2 within .TS at the moment ;)

[Kostarum Rex Persia]

And, what about *.264, *.26L, *.H264 files? Soon, or not?

[check]

.264 and .h264 are both h264 files. As SeeMoreDigital said, it can only read MPEG1 and MPEG2 streams, no MPEG4 streams. You'll have to check with neuron2 about any plans for the future though.

[JnZ]

Thx a lot,at last great tool for HD ts. demuxing including DTS.
Your work is highly appreciated.
:thanks:

[MichalHabart]

Thx a lot,at last great tool for HD ts. demuxing including DTS.
Your work is highly appreciated.
:thanks:
We know that :)

[Guest]

I found one more case of improper detection of DTS/AC3 in a transport file. I added full processing of the registration descriptor in the PMT to resolve that. It seems to be fully reliable now.

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

[Guest]

Yes, I know you're getting lots of release candidates one after the other, but I thought this fix was important to get into this version. Thanks to bond for motivating it.

* Fixed the issue of DGMPGDec using the coded picture size
(always a multiple of 16) instead of the stream declared
display size. This caused 1080i streams to be treated as
1088i, for example.

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

[Fishman0919]

Is dgmpgdec 147 Final going to include the updated Skal's idct?


Link to NaN post (http://forum.doom9.org/showthread.php?p=834294#post834294)

[Guest]

Is dgmpgdec 147 Final going to include the updated Skal's idct? I tested it and the gain was imperceptible. Convince me that the risk is worth taking. :)

It will include improved Luminance and Cropping dialogs, however; I have them working in my private build.

[Fishman0919]

I tested it and the gain was imperceptible. Convince me that the risk is worth taking. :)

It will include improved Luminance and Cropping dialogs, however; I have them working in my private build.

No convincing from me, either/or works just fine...the difference was minimal in the tests I did

32-bit SSEMMX (Skal Org) 99.68% 1:45
32-bit SSEMMX (Skal New) 99.78% 1:43
32-bit Simple MMX (XviD) 99.72% 1:46

Was just wondering if it was going to make it's way in.

[Guest]

That's a perceptible but small improvement. I'll look at it more closely for the next version. Thank you for the test results.

[bond]

Yes, I know you're getting lots of release candidates one after the other, but I thought this fix was important to get into this version. Thanks to bond for motivating it.

* Fixed the issue of DGMPGDec using the coded picture size
(always a multiple of 16) instead of the stream declared
display size. This caused 1080i streams to be treated as
1088i, for example.

http://neuron2.net/dgmpgdec/dgmpgdec147rc4.zip:thanks:

[Guest]

I pulled the trigger on 1.4.7 final:

* Improved the Luminance and Cropping filters in DGIndex.

* Corrections and additions to documentation.

http://neuron2.net/dgmpgdec/dgmpgdec.html

Thank you to all who contributed code, ideas, and testing!

[shpitz]

and thank you for the masterful piece of work!

[dirio49]

Thank you.:D
:thanks: :thanks: :thanks:

[laserfan]

Great stuff! I especially appreciated this one:

14. Fixed the issue of DGMPGDec using the coded picture size (always a multiple of 16) instead of the stream declared display size. This caused 1080i streams to be treated as 1088i, for example.

;) :thanks:

[Guest]

Murphy's Law strikes again.

Please redownload 1.4.7 if you already have. I found a problem in the distribution zip. It is all tidied up now. Sorry for the inconvenience. (Luminance dialog initialization failed if either of the values was negative.)

I know, I'd never get hired at my company. :)

[Adub]

Yes! Now I can upgrade. Thanks alot for the Luminance and Cropping filters inprovement by the way. They rock!

[Audionut]

Thanks. Great tool.

[guada 2]

@neuron2

Great job.
:thanks:

[Mug Funky]

i wonder, would it be possible to output stats to stdout or something similar? in -HIDE mode it's hard to tell what's going on... (though i'm really greatful for the hide mode, as it means i can use overlay at the same time as DGindexing a big pile of m2v's).

i'm thinking something that'd allow us to make a command line window show a progress percentage in the top, just for a little feedback. it's by no means vital.

thanks again for the updates :)

[Isochroma]

Today after finishing the indexing of a transport stream, I was somewhat surprised that the file when opened in vdub showed 1920x1088, rather than the coded picture height of 1080. This is using 1.4.7 final, which so far has delivered 1080 for all the .ts I've tested it on.

I can provide a sample but need a decent tool to cut .ts, any ideas?

[Guest]

Some streams actually do have a display size of 1088 specified. But I'll be happy to have a look. Just use DGIndex to demux a small part of the video and provide that. Set a range and then "Save Project and Demux Video".

If that is the case, we would need to consider whether we detect and handle that as a special case, or whether we should honor the specified display size and then crop in the script if needed.

[Isochroma]

As you suggested, here are the files:

1088.demuxed.m2v (http://isochroma.com/Testfiles/Misc/1088.demuxed.m2v) [2.6 MB]
1088.d2v (http://isochroma.com/Testfiles/Misc/1088.d2v)

[Guest]

Yes, it is as I thought. The stream specifies the encoded size *and* the display size as 1088.

I will add a special case (maybe optional) for this to force it to be treated as 1080.

[Isochroma]

Ah, just as I suspected! Thanks very much for checking this out so rapidly :) I can always use crop() in the script so it's no big deal...

[SeeMoreDigital]

I must admit, whenever I find the odd 1080 streams with a 1088 header, I feed it into ReStream and re-write the sequence resolution...

Isochroma Souce .D2V file: -
DGIndexProjectFile13
1
L:\1088.ts

Stream_Type=2
MPEG2_Transport_PID=11,14
MPEG_Type=2
iDCT_Algorithm=6
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=16:9
Picture_Size=1920x1088
Field_Operation=1
Frame_Rate=23976 (24000/1001)
Location=0,F881C,0,F8D76

900 1 0 2084626532 0 0 71 d2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2
900 1 0 2085499416 0 0 73 d0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0
900 1 0 2086468368 0 0 71 d2 f3 e0 f1 e2 f3 e0 f1 e2 f3 e0 f1 e2 ff

FINISHED 100.00% FILM



ReStream Corrected .D2V file: -
DGIndexProjectFile13
1
D:\Documents and Settings\SeeMoreDigital\Desktop\1088.ReStream.Corrected.m2v

Stream_Type=0
MPEG_Type=2
iDCT_Algorithm=6
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=16:9
Picture_Size=1920x1080
Field_Operation=0
Frame_Rate=29970 (30000/1001)
Location=0,0,0,507

900 1 0 0 0 0 31 92 b3 a0 b1 a2 b3 a0 b1 a2 b3 a0 b1 a2
900 1 0 817368 0 0 33 90 b1 a2 b3 a0 b1 a2 b3 a0 b1 a2 b3 a0
900 1 0 1728584 0 0 31 92 b3 a0 b1 a2 b3 a0 b1 a2 b3 a0 b1 a2 ff

FINISHED 100.00% FILM



Cheers

[Guest]

I must admit, whenever I find the odd 1080 streams with a 1088 header, I feed it into ReStream and re-write the sequence resolution DGIndex 1.4.8b1 does that now, which means you can avoid this extra processing step.

Closing this thread to move the discussion to the new beta thread.