DGMPGDec 1.4.8 Final [Archive]

View Full Version : DGMPGDec 1.4.8 Final

Pages : [1] 2 3

Guest

9th June 2006, 04:13

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

* For streams that specify 1088 as the vertical height for both the encoded and display sizes, a pop-up appears once on file loading (not done for CLI invocation) asking if the video should be treated as if it has a height of 1080.

* Completely rewrote the PAT/PMT parser. Syntactically, it now a) correctly handles sections that cross transport packet boundaries, or that start in the middle of a transport packet following a previous section, b) correctly handles streams with multiple PAT sections, and c) correctly handles streams that put all the program information on one PMT PID. The parser is now fully correct syntactically. Semantically, it now a) correctly labels private stream video, b) labels all scrambled streams so that user can avoid crashing DGIndex by selecting a scrambled stream, and c) properly distinguishes between AC3 audio streams and Teletext streams.

* When showing the film versus video percentage, DGIndex always now shows film percentage if it is greater than or equal to 50%, or video percentage if it is greater than 50%. Of course the sum is 100%.

* Fixed a problem with playback speed control. E.g., if you are running in slow motion and hit Pause, wait a while, and then hit Resume, the video would go real fast for a while until it "caught up".

* DGIndex now supports "Open With" operation. E.g., you can double click a VOB file and have it open right up if your association is correct. Or you have a shortcut to DGIndex on your desktop and then highlight a bunch of VOBs and drop them all on the shortcut; they are opened in sorted order. (It always irritated me that you couldn't do that.)

* DGIndex can now automatically set the transport PIDs to the first program when a stream is opened. This happens
when a new file is opened with the PIDs set to reserved (0x02). The PIDs are set to reserved when DGIndex is
started, so this will happen when a transport stream file is opened after starting DGIndex. Thereafter, the Set PIDs dialog is controlling. The INI file format is changed, so start DGIndex and then close it once before using it in earnest.

* A new option under the file menu was added: Demux Audio Only. This is intended for demuxing the audio from streams that do not contain video.

Shocku

9th June 2006, 05:10

Outstanding. Thanks for all your hard work!

Amnon82

9th June 2006, 15:38

keep on going ... when do you add the feature "writing the informations of d2v file to txt"?

@Rockas and Amnon82

My plan is to address this for 1.4.7.

Do you just want the final Info dialog information to be (optionally) stored in a text file?

The more clearly you state your requirements in this regard, the more likely it will be that your requirements are met.

... yes, my plan was to write the final informations-dialog to txt. thx.

p.s. I'll need also a cli-command for it ...

Guest

9th June 2006, 17:09

I plan to do all that in 1.4.8.

devaster

9th June 2006, 18:40

can you implement some idct that use a gpus ???

Guest

9th June 2006, 21:20

Sorry, I have no interest in that. Source code is available. You can do it.

Amnon82

9th June 2006, 22:59

k, keep on waiting ;)

bond

10th June 2006, 14:07

* For streams that specify 1088 as the vertical height for both the encoded and display sizes, force them to be treated as if they specified a display size of 1080why? what if the stream is really 1088 and not 1080? if the stream is specified as 1088 the decoder should also treat it as such imho, as the content producer propably had reasons for setting up the stream as he did

also if the content producer didnt know what he did the user can still crop afterwards, but he cant add the missing 8 pixels potentially falsely removed by the decoder

Guest

10th June 2006, 14:48

I follow your argument but I ask you to point to any application or broadcast, etc., where the full 1088 is used.

I considered making it optional but didn't see anyone ever using the full 1088.

Have you registered complaints about MPC, VirtualDub MPEG2, etc., that also do this?

I have never heard anyone complaining about losing 8 pixels off 1088 streams, but I have often heard about the "gray line problem" of DGIndex. :)

bond

10th June 2006, 15:03

i dont have such a stream (which doesnt mean that they dont exist), but what are the specs for if not to be followed. if a stream signals 1088 its 1088 imho :)

SeeMoreDigital

10th June 2006, 17:15

I think I have some.....

From what I remember, all the 1088 MPEG-2 sources seem to be "pure" interlaced :scared:

Guest

10th June 2006, 17:22

OK, then I'll take that special case out and users can use the Cropping menu or crop in Avisynth.

bond

10th June 2006, 17:45

OK, then I'll take that special case out and users can use the Cropping menu or crop in Avisynth.i think thats indeed a more accurate solution

Guest

10th June 2006, 18:19

Or I could pop up a message box and offer to interpret it as 1080. Do you like that idea?

Isochroma

10th June 2006, 18:27

Perhaps just giving users the option to/not use coded picture height:

Options > Use Coded Picture Height

bond

10th June 2006, 18:50

Or I could pop up a message box and offer to interpret it as 1080. Do you like that idea?you mean for streams that signal 1088? imho a choice is always a good thing :)

i think for 1088 streams that signal 1080 the cropping can be done automatically, cause thats what the content producer defined

SeeMoreDigital

10th June 2006, 18:51

Or I could pop up a message box and offer to interpret it as 1080. Do you like that idea?I guess if DGIndex can be configured to display the extra 8No pixels (complete with grey line if it has one) then yes, an option to crop them away if they are seen would be a perfect solution ;)

bond

10th June 2006, 19:01

it might be an idea to offer a very flexible cropping option, where the user can set the cropping he wants (eg from 1088 to 1080, but also other values), or to not crop at all even if the stream signals cropping...
dunno how much work this would cause

by default the cropping defined in the stream should be used tough imho

Guest

10th June 2006, 19:11

i think for 1088 streams that signal 1080 the cropping can be done automatically
[and]
by default the cropping defined in the stream should be used though imho It already does that. The case at issue is when the display and encoded sizes are both 1088.

I'd rather not make another option. I think I'll just pop up a message box in this special case and ask the user what she wants.

SeeMoreDigital

10th June 2006, 20:03

Well I guess in reality.... nobody is going to notice 8 pixels (less than 1%) cropped from a 1088 pixel source!

Isochroma

10th June 2006, 20:19

It is important nonetheless. I wouldn't want to lose eight pixels of video frame; it also screws up the aspect ratio.

Thus the best choice is to give users the choice.

SeeMoreDigital

10th June 2006, 23:59

It is important nonetheless. I wouldn't want to lose eight pixels of video frame; it also screws up the aspect ratio.Well personally speaking, I'm not so sure about that.... 1920/1080 equals 1.77777:1 (aka: 16:9). As apposed to 1920/1088 which equals 1.764705:1...... ;)

squid_80

11th June 2006, 02:42

Just a small thing: teletext pids in transport streams are showing up as ac3 in the detect pid dialogs. Hence it can sometimes be confusing which pid is the real ac3 soundtrack.

Guest

11th June 2006, 02:43

Just a small thing: teletext pids in transport streams are showing up as ac3 in the detect pid dialogs. Hence it can sometimes be confusing which pid is the real ac3 soundtrack. Well, you know I need the stream to fix it! Please provide it. Thank you.

squid_80

11th June 2006, 03:10

It appears the last file I sent you (squid/bad.tp) is still there, it should have teletext on pid 240 if I remember correctly.

Guest

11th June 2006, 03:36

Yup. OK, I figured it out. Next beta will have it fixed. Thanks for pointing it out.

EDIT: Tested and working: [stream_type 0x06 plus descriptor tag 0x56] signals Teletext.

Guest

11th June 2006, 15:22

* Changes the 1088 special case handling to a pop-up and correctly distinguishes AC3 audio from teletext.

* Completely rewrote the PAT/PMT parser. Syntactically, it now a) correctly handles sections that cross transport packet boundaries, or that start in the middle of a transport packet following a previous section, b) correctly handles streams with multiple PAT sections, and c) correctly handles streams that put all the program information on one PMT PID. The parser is now fully correct syntactically. Semantically, it now a) correctly labels private stream video, b) labels all scrambled streams so that user can avoid crashing DGIndex by selecting a scrambled stream, and c) properly distinguishes between AC3 audio streams and Teletext streams.

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

Zarxrax

12th June 2006, 21:48

Would it be possible for DGIndex to have an option to automatically do force film when it would make sense? It seems that in most cases force film could be detected automatically, which would in turn require less input from the user, and make it a little easier to use. From the dgindex user manual:
If the clip is not PAL or MPEG1, and the Video Type field in the Information window indicates Film 95% or higher, it is likely that the clip can be treated as 3:2 pulldown material, and so the Force Film option should be selected for generation of the D2V file.
All of these are things that DGindex keeps track of. This could be implemented as a new Field Operation mode called "Automatic", while still leaving the other 3 options.

kohsaf1

12th June 2006, 21:49

Amnon82

13th June 2006, 01:31

I have a question. Your 'Information'-Window shows me for example what field order my movie has. Casanova has in the beginning few frames interlaced + bottom.

Then I used my D2V Parser (http://forum.doom9.org/showthread.php?t=108858) and I got interlaced + TFF. When I start a few frames after 0 in DGIndex I got also TFF.

What is the best way to get the info about a D2V-file?

Guest

13th June 2006, 01:54

Ooh, the B word!

I look at the first data line in the D2V file. I skip the first 6 fields and look at the first flags byte. If the rightmost digit of that seventh field is 2 or 3, it is TFF.

Note that the order can depend on the start point of the range if there is pulldown present.

I too have recently noticed a possible anomaly in the Info box field. I will investigate that and report back.

Isochroma

13th June 2006, 22:18

Minor bug report:

Using version 1.4.8b2 (latest), I've found a .ts that causes the gui to pop up the new 1088 yes/no dialog. However, when I select Yes (ie. discard the last 8 lines), the resulting .d2v file looks right (Picture_Size=1280x1080 line is present), but the file opened in vdub still shows as 1088 lines.

Here (http://www.isochroma.com/Testfiles/Misc/1088-2.rar) is a segment of the file [1.2 MB].

Guest

13th June 2006, 22:59

OK, thanks, I'll fix it.

Zarxrax

14th June 2006, 02:29

B.F.

14th June 2006, 02:55

I think more detal will be good.
Something like
"Film 99,21%"

Guest

14th June 2006, 03:53

When DGIndex finishes indexing, it's supposed to list the frame type (video or film) with whichever was more predominant, shouldn't it?

I just indexed a dvd with it and when its done, it says "video 1%". It makes more sense if it to were to say "Film 99%", right? Yes, of course you are correct. I'm surprised that you got such a result. I'll look into it for the next beta. Thank you for calling it to my attention.

If possible, please keep that project around so that you can test it in the next beta.

Mug Funky

14th June 2006, 04:15

@ Zarxrax:

in my experience it just shows the last type it encountered.

if black was inserted after the feature during authoring (very common practice), and that black footage was encoded as regular 29.97, then you'll most likely have DGindex report "video" instead of "film".

Guest

14th June 2006, 04:21

Yeah, Mug, that sounds right.

Still, we could change it to show the higher percentage, since that is nicer intuitively, isn't it?

SeeMoreDigital

14th June 2006, 10:09

Guest

14th June 2006, 12:52

Any thoughts to the possibility of removing the UserData codes and re-setting the time-stamps to the newly de-muxed .M2V stream? Is that something that Restream can do? I'm thinking that demuxing should just be demuxing.

SeeMoreDigital

14th June 2006, 13:33

Is that something that Restream can do? I'm thinking that demuxing should just be demuxing.Yes ReStream offers quite a few tweaks - not that I know what a lot of them are really supposed to do: -

http://img64.imageshack.us/img64/2663/restream2nv.png

That said, might it not be handy if DGIndex could provide us with elementary streams that were free from some of this data?

Cheers

Guest

14th June 2006, 14:05

* Fixed the 1088->1080 special mapping for DGDecode as directed by DGIndex (no change to D2V format; DGDecode uses the picture height field of the D2V file and compares it to the stream display size to see if the special case handling was selected in DGIndex).

* When showing the film versus video percentage, DGIndex always now shows film percentage if it is greater than or equal to 50%, or video percentage if it is greater than 50%. Of course the sum is 100%.

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

Zarxrax

14th June 2006, 19:16

The film vs video percentage seems to show as would be expected now.

One other question: What exactly does the "frame scruct" mean, and how does this differ from the "frame type"?

Guest

14th June 2006, 20:15

One other question: What exactly does the "frame struct" mean, and how does this differ from the "frame type"? It tells if the pictures are encoded as fields or as full frames. See the MPEG2 video spec for more details.

Isochroma

14th June 2006, 20:45

Your rapid work on this powerful utility is greatly appreciated! Newest b3 works correctly on this file.

One suggestion - frequently I have .ts with bad field order, which is corrected. However, two extra files are produced. They may be useful for debug purposes, but it would be nice to have a switch to suppress their production.

Isochroma

15th June 2006, 04:07

Bug: DTS Detected as MPEG2 on PID 24

On the same .ts file as previous, Haali's splitter & ffdshow audio decoder in MPC report (PIDs in decimal):

24 DTS 1536kbps 5.1 ch.
25 AC3 448kbps 5.1 ch.

However, DGIndex reports "MPEG2 Video on PID 0x24", and the AC3 correctly on 25. I selected "Demux All Tracks", and it only demuxes the AC3 track. Also, on opening it cannot detect the correct PIDs, so I must select them manually. Only one audio stream can be selected, so even if they were both identified, how would one demux both?

I would like to provide a sample, but using the method you previously described will only demux the video. Is there any other tool/method to get a section of the .ts split?

Guest

15th June 2006, 05:53

I can help only with a piece of the TS that shows the problem. Use ChopperXP.

You have to make multiple passes with different audio PIDs set to demux multiple audio. It's already on the list to fix that.

Isochroma

15th June 2006, 06:39

Got it! Used NullPacketSaver (http://users.adelphia.net/~mwilczyn/nullpacketsaver/) to split it into chunks. Here (http://isochroma.com/Testfiles/Misc/t1.000000.ts) is the file (2 MB).

Guest

15th June 2006, 06:56

OK, thanks. I duplicated and fixed it. It'll be in the next beta version.

Isochroma

15th June 2006, 07:56

Your speed and attention to the ongoing process of improvement in DGIndex is exceptional. Thanks to your hard work the world has a bridge to the high-definition future of liquid video. Just think of all the eyes which will get to see for the first (of many) times the true glory of Transport Stream video thanks to this great tool. For decades yet to come it will serve as the key to unlock reams of digital dreams!

Personally, I look forward to Nov. 31st, when I bring home the 37" LCD and start watching all those glorious .ts files in their HD beauty :)