PDA

View Full Version : DGMPGDec 1.4.8 Final


neuron2
9th June 2006, 05: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, 06:10
Outstanding. Thanks for all your hard work!

Amnon82
9th June 2006, 16: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 ...

neuron2
9th June 2006, 18:09
I plan to do all that in 1.4.8.

devaster
9th June 2006, 19:40
can you implement some idct that use a gpus ???

neuron2
9th June 2006, 22:20
Sorry, I have no interest in that. Source code is available. You can do it.

Amnon82
9th June 2006, 23:59
k, keep on waiting ;)

bond
10th June 2006, 15: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

neuron2
10th June 2006, 15: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, 16: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, 18:15
I think I have some.....

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

neuron2
10th June 2006, 18: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, 18: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

neuron2
10th June 2006, 19: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, 19:27
Perhaps just giving users the option to/not use coded picture height:

Options > Use Coded Picture Height

bond
10th June 2006, 19: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, 19: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, 20: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

neuron2
10th June 2006, 20: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, 21: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, 21: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
11th June 2006, 00: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, 03: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.

neuron2
11th June 2006, 03: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, 04: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.

neuron2
11th June 2006, 04: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.

neuron2
11th June 2006, 16: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, 22: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, 22:49
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:

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.

that would be brilliant :)

Amnon82
13th June 2006, 02: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?

neuron2
13th June 2006, 02: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, 23: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].

neuron2
13th June 2006, 23:59
OK, thanks, I'll fix it.

Zarxrax
14th June 2006, 03:29
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?

B.F.
14th June 2006, 03:55
I think more detal will be good.
Something like
"Film 99,21%"

neuron2
14th June 2006, 04: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, 05: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".

neuron2
14th June 2006, 05: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, 11:09
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].Yes I confirm this too!

By-the-way.... Any thoughts to the possibility of removing the UserData codes and re-setting the time-stamps to the newly de-muxed .M2V stream?


Cheers

neuron2
14th June 2006, 13: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, 14: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

neuron2
14th June 2006, 15: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, 20: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"?

neuron2
14th June 2006, 21: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, 21: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, 05: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?

neuron2
15th June 2006, 06: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, 07: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).

neuron2
15th June 2006, 07:56
OK, thanks. I duplicated and fixed it. It'll be in the next beta version.

Isochroma
15th June 2006, 08: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 :)

SeeMoreDigital
15th June 2006, 13:59
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).Sorry to digress,

But I notice your 16:9 HDTV MPEG-2 sample has a resolution of 1280x1080/88... Is that common?

Morte66
15th June 2006, 17:35
Sorry to digress,

But I notice your 16:9 HDTV MPEG-2 sample has a resolution of 1280x1080/88... Is that common?

I've seen it a couple of times.

I collect HDTV samples (I'm thinking of getting a 1080 projector, so I want to be sure of the material). In general, TV broadcasters seem to play pretty fast and loose with the phrases "high definition" and "1080". They often broadcast 1280x1080 actual pixels flagged as 1920x1080 DAR in Asia. In the US it's allegedly common for TV companies to resample down to 1440x1080 and back up to 1920x1080 as a quick and dirty way to drop the resolution/bitrate to fit in their multiplexes. The current BBC h264 tests look a bit suspicious, too -- I gather there's about 720x1080 real resolution (as opposed to pixel count) if you examine stills in Photoshop.

A friend of mine said of the new SkyHD service, "I await the howls of outrage as the channel count goes up and the quality goes down". I'm hoping he's wrong, because I'm thinking of getting it...

SeeMoreDigital
15th June 2006, 22:43
As some of you may or may not know I've been testing the latest MP4Box builds with experimental support for MPEG-1, MPEG-2 and MPEG-4 AVC within .TS... And just thought I'd share the following observations with you guys.

After feeding Isochroma's 2MB source into YAMB/MP4Box, it was able to instantly detect the video stream PID, but none of the audio stream PID's....

Anyway, undeterred I tried entering various PID numbers and found the following: -

http://img377.imageshack.us/img377/2220/yamb7lx.png

So it would seem all the audio streams are in there somewhere.... ;)


Cheers

Zep
20th June 2006, 07:16
So it would seem all the audio streams are in there somewhere.... ;)


Cheers

hmmm yamb is not letting me select .ts files.

How did you get the 1.6.0 version to see them?
(I also have the 6/15 build of mp4box experimetal)

me goes to look in options area again in case i missed one :D

thanks

Mug Funky
21st June 2006, 03:48
In the US it's allegedly common for TV companies to resample down to 1440x1080 and back up to 1920x1080

HDV is 1440x1080 anamorphic in a lot of cases... they're probably receiving their sources at this size, so it's probably not their fault. remember how new HDTV is, and how many pro formats are competing for the industry standard. it's very likely that not everyone in the game owns every piece of equipment for each format...

SeeMoreDigital
21st June 2006, 10:04
HDV is 1440x1080 anamorphic in a lot of cases... they're probably receiving their sources at this size, so it's probably not their fault. remember how new HDTV is, and how many pro formats are competing for the industry standard. it's very likely that not everyone in the game owns every piece of equipment for each format...Indeed... I'm aware of 1440x1080 with aspect ratio signalling.... However, Isochroma's sample appears to be 1280x1080, which seems "a bit of a stretch" to me ;)


Cheers

Zep
22nd June 2006, 13:33
SeeMoreDigital what do i smell or something? :D


You could have told me you were using a special build of yamb that Kurtnoise13 did when you requested .ts support and the link he put up lol

yes i have it now also and it works great :)

SeeMoreDigital
22nd June 2006, 14:09
I'm sorry Zep... I missed your post :eek:

neuron2
22nd June 2006, 14:09
Gents, please stay on topic for this thread. Thank you!

neuron2
23rd June 2006, 04:22
* Fixed Isochroma's bug reported here:

http://forum.doom9.org/showthread.php?p=840614#post840614

* 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.

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

Zep
24th June 2006, 08:32
I'm sorry Zep... I missed your post :eek:


no worries I kinda thought that was what happned :D

You should have seen me! i was scratching my head wondering "HOW is SeeMoreDigital getting YAMB to do that" so then the search began LOL

just shear luck i saw your post in that other thread where you asked for .ts support and I jumped for joy when i saw the link a few post down :)

neuron2
24th June 2006, 14:39
Since you are choosing to ignore my polite request to stay on topic, I am now issuing strikes.

Isochroma
24th June 2006, 19:02
Your work on this application is greatly appreciated, Neuron! I will test b4 against my transport streams and report any further bugs...

neuron2
27th June 2006, 23:05
I'm thinking of implementing a feature whereby when a transport stream is loaded, the PIDs are automatically set to those of the first program. This would avoid most instances of the famous "No data. Check your PIDs." popup.

If I did it, I would remove the INI file storage of the PIDs.

So, my question to the user base is: do you think this is worth doing, or would you prefer to have it stay as it is?

Isochroma
28th June 2006, 00:10
This is the feature I have been hoping for, dreaming for, crying for, but never asked for - because I thought it was so obvious that someone else must have already asked.

So thanks for suggesting it!

neuron2
28th June 2006, 00:30
I never did it before because it required code in a C file to invoke class methods in a CPP file, which is a pain. But since I just converted all the C files to CPP files to have consistent linkage, it is now a relatively simple thing.

Let's wait for a few other users to weigh in.

laserfan
28th June 2006, 04:53
I'm thinking of implementing a feature whereby when a transport stream is loaded, the PIDs are automatically set...do you think this is worth doing?I can't think OTTOMH of any circumstance where this would not work for me--normally by the time I apply DGMPGDec I've already stripped unneeded PIDs out of a ts.

Murphy's law would probably suggest it be an user-definable thing though I suppose. :wishy-washy:

SeeMoreDigital
28th June 2006, 09:31
If such a proposal makes it easier for DGIndex to be incorporated and used within other applications then yes it's got to be a good thing ;)


Cheers

squid_80
28th June 2006, 11:32
Definitely a good thing for me, since the recording program that comes with my FusionHDTV only records one program when doing scheduled recording.

brute
28th June 2006, 16:43
Hi,
is it possible, that this build of DGIndex is incompatible with gordian knot rippack 0.35.0 v2 ?
My whole encoding queue of last night had wrong sizes (up to 300mb to big) and the movie lengh was wrong so that everything wasn't synchronous :(

neuron2
28th June 2006, 16:53
is it possible, that this build of DGIndex is incompatible with gordian knot rippack 0.35.0 v2 ?
I don't know anything about Gordian Knot. Please ask in the Gordian Knot forum.

brute
28th June 2006, 20:04
hm, well now I think it's not DGIndex's fault...should be something other :-\

jmac698
29th June 2006, 05:38
Here's something I really need: able to demux with no video stream present. Yes, I have some sound only channels (.ts) I need to demux and nothing works (projectx, pvastrumento, etc.).
Any chance?
I'm also curious how the song titles are streamed...

neuron2
29th June 2006, 06:00
Here's something I really need: able to demux with no video stream present. Yes, I have some sound only channels (.ts) I need to demux and nothing works (projectx, pvastrumento, etc.).
Any chance? Sure. Can you provide some test streams?
I'm also curious how the song titles are streamed... I don't understand your question.

neuron2
29th June 2006, 14:33
* 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.

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

squid_80
1st July 2006, 02:58
I think I found a regression. The distinguishing of AC3/Teletext streams seems to have gone missing, starting with 1.4.8b4.

neuron2
1st July 2006, 03:24
OK, I know why. It'll be fixed in the next beta. Thanks for pointing it out.

neuron2
1st July 2006, 03:39
@squid_80

Please test this special build. Thank you.

http://neuron2.net/misc/DGIndexSquid.zip

laserfan
1st July 2006, 04:54
I've been converting 1080i HD Grey's Anatomy .ts to Xvid all season, and last week picked-up a repeat I had missed. Applying Beta 5 to it using StaxRip, the thing was way out-of-sync. Upon inspection, the .d2v seemed to be wrong:

Field_Operation=1
Frame_Rate=23976 (30000/1001)

This should have been FO of 0 and FR of 29970 (and apparently why my IVTC didn't work). I tried a couple of other recent 1.4.8 betas and they worked the same, despite that the Stax command invoking DGindex is in all cases:

"C:\Program Files\DGMPGDec\DGIndex.exe" -IF[D:\Grey's Anatomy 204 - Deny Deny Deny.ts] -IA=2 -FO=0 -YR=1 -TN=1 -OM=2 -DRC=2 -DSD=0 -DSA=0 -OF=[D:\Grey's Anatomy 204 - Deny Deny Deny] -exit

I did delete and re-create the INI file when going to b5--am I doing something wrong or did something break?

When I revert to 1.4.7 rc4 it works again:

Picture_Size=1920x1080
Field_Operation=0
Frame_Rate=29970 (30000/1001)

neuron2
1st July 2006, 05:30
How are you setting the PIDs?

I can't duplicate your FO problem. Take off the -exit and invoke it from a DOS window. At the end look at the settings of the Field Operation in the menu. What is it?

laserfan
1st July 2006, 05:44
How are you setting the PIDs?The PIDs are set manually, i.e. DGindex complains, I Set Audio and then Set Video and it starts to running immediately. It does this with b5 also.

I will try your request in the morning; I have 1.4.7rc4 cranking-away at the moment. Thanks!

I forgot to say that the INI file is set for FO=0 also. I will invoke manually in the a.m. :yawn:

neuron2
1st July 2006, 05:47
Must be an operator error. :)

In testing it I found that auto PID detection wasn't working for CLI as it should be. I fixed that.

But I just can't see how the FO could be wrong.

squid_80
1st July 2006, 09:14
@squid_80
Please test this special build. Thank you.

Yep, that's fixed it. Thanks.

neuron2
1st July 2006, 14:30
OK, thank you, squid_80. I want to get laserfan's issue squared away before I make beta 6.

laserfan
1st July 2006, 15:35
In testing it I found that auto PID detection wasn't working for CLI as it should be. I fixed that.

...I want to get laserfan's issue squared away before I make beta 6."Well, HAL, I'm damned if I can find anything wrong with it."

"Yes. It's puzzling."

Re-installing b5, I invoked the same command in MS-DOS as you requested and it worked as expected, w/Honor Pulldown Flags remaining checked in the menu:

D:\Grey's Anatomy 204 - Deny Deny Deny.ts

Stream_Type=2
MPEG2_Transport_PID=31,34
MPEG_Type=2
iDCT_Algorithm=2
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,2101C1

I must have exposed some glitch elsewhere, in my StaxRip setup. :o Sorry about that!

I apologize for not having reported earlier that "auto PID detect" wasn't working for me. I like to check my procedures at least a couple more times before making a report, and just haven't felt disciplined this summer. 100deg days every day just slow me down, dontcha know...

neuron2
1st July 2006, 16:26
No problem, laserfan. Thanks for the feedback.

I'm currently adding support for demuxing audio-only streams, so the next beta won't come out until it is done. I currently have just completed and tested it for AC3 in program streams. I need to implement all the audio types in program, PVA, and transport streams.

jmac698
1st July 2006, 20:06
Great news! Thanks. I'll see what I can do about test streams, but it may be a while.
As to your question, these streams contain the current song title, every 30 seconds or so. I'm curious if I can decode them. Ideally I could get a list of titles and cut points, I can handle the rest! :)

neuron2
1st July 2006, 20:50
Ah, I see. Well, if you're in DVB land it'll be in the SDT table and if you're in ATSC land, it'll be in the PMT descriptors or the PSIP. If you provide a test stream, I can look into extracting it.

laserfan
2nd July 2006, 14:57
Along with the CLI problem I found also a StaxRip oddity, and sorting the issue was enough of a PIA that I would like to make a request: to put the version-used of DGindex into the .d2v file if possible.

I compress & save all logs including .d2v and this would be helpful for the future...

neuron2
2nd July 2006, 14:59
There's a D2V file format number there already. Why is that not sufficient?

laserfan
2nd July 2006, 16:02
There's a D2V file format number there already. Why is that not sufficient?Hmmm, I have only been saving .d2v files since April 9 of this year, but that line has never changed. It is always:

DGIndexProjectFile13

At least it has never changed thru the betas & new releases of the last several months (perhaps a dozen?) and I have been trying to keep-up with those.

neuron2
2nd July 2006, 19:17
It doesn't change unless the D2V file format changes. But that is all that your third-party app should need to know. Are you saying you need to know the specific DGIndex version? If so, why?

laserfan
2nd July 2006, 19:51
Well, the CLI function broke-down wrt my 3rd party app somewhere between 1.4.7 and 1.4.8b5. At least, while my DGindex has changed many times, nothing at all has changed about my StaxRip installation. So I was thinking this might help to sort where the problem started anyway.

Made sense to me to ask about it--but it's your call of course. I will simply make manual entries in my logs...

neuron2
2nd July 2006, 20:38
Well, let's find out the cause. Putting the version now isn't going to help. Can't we talk to the author of the 3rd-party app?

neuron2
2nd July 2006, 20:40
Well, let's find out the cause. Putting the version now isn't going to help. Can't we talk to the author of the 3rd-party app?

All the betas are online. If you can tell me which version broke it I can look to see what changes were made. Access the versions with:

http://neuron2.net/dpmpgdec148b1.zip

...changing the beta number as required.

neuron2
2nd July 2006, 20:43
Ooh, I just found a D2V file change that didn't get a version bump. The FILM % at the bottom:

* 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%.

Could that be the problem?

neuron2
3rd July 2006, 00:56
* 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.

* Fixed the Teletext detection issue.

* Fixed automatic PID detection under CLI.

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

laserfan
3rd July 2006, 05:33
Well, let's find out the cause. Putting the version now isn't going to help. Can't we talk to the author of the 3rd-party app?I dunno--stax is "on hiatus".

I will look at it again, and let you know if I find anything of interest. There WAS a stax change applied in May that I'd forgotten about--maybe that's what broke it and not DGindex. I will try to sort it.

neuron2
3rd July 2006, 05:37
Sorry for the rapid fire betas, but you don't want me to sit on my hands, do you?

* The trackbar is now updated and the Stop (ESC) function works during "Demux Audio Only".

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

jmac698
3rd July 2006, 18:51
audio demuxing:
-new version worked for me, great job!
-sample .ts http://rapidshare.de/files/24837509/060629003459.7z.html
let me know if you can find the song title...

wdmalik
3rd July 2006, 18:52
No offense, but i cant seem to get any version after 1.4.5 work on gordianknot ... any way to solve this problem ?

neuron2
3rd July 2006, 18:56
No offense, but i cant seem to get any version after 1.4.5 work on gordianknot ... any way to solve this problem ? The author of GordianKnot has to update it to accept the revised D2V file format of the later versions of DGMPGDec.

neuron2
3rd July 2006, 18:58
audio demuxing:
-new version worked for me, great job!
-sample .ts http://rapidshare.de/files/24837509/060629003459.7z.html
let me know if you can find the song title... Good to hear. Thank you for the test results.

I'll have a look at the PSI and see what I can do. BTW, how do you know that it is sent every 30 seconds? What else do you know about it?

EDIT: Oh darn, not that 7Z stuff. Can't you use ZIP (because I'm not going to install another archiver)? Or just put it there uncompressed. Or upload it to my FTP site. I helped you, now can you please help me? Thanks.

calinb
9th July 2006, 20:04
The author of GordianKnot has to update it to accept the revised D2V file format of the later versions of DGMPGDec.
Really? I don't see why it needs to be updated, other than to include a newer DGMPGDec in the bundle.

wdmalik, I've been using GKnot all along. Simply replace the dgindex.exe and dgdecode.dll files with the new ones. If you use DGMPGDec with several aps and it exists in several places, best to search the drive to get them all.

Ac3Dc3
10th July 2006, 19:14
Hi neuron2

are you still not inclined to revise the D2V file format to include useful output from parse D2V?

e.g. Displayed_frames=269425 as in this (http://forum.doom9.org/showthread.php?t=108148) thread.

Ac3Dc3.

mod
10th July 2006, 21:27
neuron2 already said that he isn't going to do that.. :)
Btw, what about the cli option? Did I miss any thread or post?

cc979
11th July 2006, 09:31
@neuron2 been testing some .ts files just wondering is there an easy way to see just pids are being used, cheers

neuron2
11th July 2006, 14:25
is there an easy way to see just pids are being used I don't understand your question. I assume you must know about the Stream menu. Please elaborate on your question.

cc979
11th July 2006, 14:33
I don't understand your question. I assume you must know about the Stream menu. Please elaborate on your question.

view which pid in the stream is detected and used by dgindex

sorry my gramma can be bad at times

neuron2
11th July 2006, 14:43
Load the stream and then look at Stream/Set PIDs. It will show what PIDs have been automatically set. Of course, you can change the PIDs in the usual way after loading the file.

wdmalik
12th July 2006, 16:58
Really? I don't see why it needs to be updated, other than to include a newer DGMPGDec in the bundle.

wdmalik, I've been using GKnot all along. Simply replace the dgindex.exe and dgdecode.dll files with the new ones. If you use DGMPGDec with several aps and it exists in several places, best to search the drive to get them all.

nops it is not working for me, both gordianknot and staxrip give error "File is not a valid d2v project, avi or avs file!"

cc979
12th July 2006, 18:57
Load the stream and then look at Stream/Set PIDs. It will show what PIDs have been automatically set. Of course, you can change the PIDs in the usual way after loading the file.

thanks

calinb
12th July 2006, 19:48
nops it is not working for me, both gordianknot and staxrip give error "File is not a valid d2v project, avi or avs file!"GKnot 0.35.0 works for me with any version of DGMPDec on half a dozen machines. I've probably used nearly every beta after each release. The key is using dgdecode.dll/dgindex.exe/.d2v files that are "in sync."

Make sure you've found and updated all the dgdecode.dlls and dgindex.exe files on your system. To be safe, delete all your .d2v files and decode them again with the updated dgindex.

Everytime I think something's broken with a DGMPGDec update, I find that I've got an old .d2v or mismatched dgindex/dgdecode.dll laying around.

Good Luck,

woah!
13th July 2006, 05:28
quick question, what (if any) is the cmd line for the "correct field order" under options that you can tick on?


i like to add it to my bat file i use if i could.

neuron2
13th July 2006, 05:53
You can't control it via CLI. It will be determined by the INI file contents.

woah!
13th July 2006, 05:55
ah ok thx for the fast reply and a great program :)

i will use the program then instead first :)

mod
14th July 2006, 09:58
Yes, I know the 3rd-party applications guys are still waiting for CLI enhancements and exposure of DGIndex's analyses, but I just can't get excited about doing it. That's not to say I won't, just that I'll keep looking for more exciting things to do first. :)
I had missed this one from neuron2 homepage :)

neuron2
21st July 2006, 04:03
DGMPGDec 1.4.8 Final is released. Other than version strings, it is identical to 1.4.8 beta 7.

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