View Full Version : DGMPGDec 1.5.3 Final
Pages :
1
2
3
4
5
6
[
7]
8
9
10
11
Guest
26th February 2008, 15:07
@remiche
What is your point in your last post (the one that just shows the dialog box)?
jpsdr
26th February 2008, 18:19
I was not able to reproduce any problems with WAV headers in 1.5.0 RC2, irrespective of demuxing method. Do you still have an issue with this? If so, may I have a test stream? I want to get RC3 out soon, so your response will be appreciated. Thank you.
Hello.
Euh... i've posted a message telling that i've remade
the operation, and the wave was correct... I think...
I absolutely don't know what has append the first time,
and why the wave was incorrect, but unless i re-encounter
the problem, you can consider the issue is gone.
Guest
26th February 2008, 18:22
OK, thanks. I read your message as suggesting that demuxing a single track worked while demuxing all tracks did not. Just wanted to make sure there wasn't a bug lurking there. :)
Guest
4th March 2008, 04:49
* Demuxed MPEG audio files are now given the extension mp1/mp2/mp3 depending on the audio layer. The old behavior can be enabled via an INI file option (see users manual).
* Transport packet resync and M2TS file detection were made more robust.
* Fixed a bug in the Log Timestamps function, whereby a video DTS value was incorrectly shown as a PTS value.
* Fixed a bug in demuxing of DTS audio from transport streams.
* The aspect ratio field of the Info dialog now shows the raw value of the field as well as the corresponding string.
* The display size from a sequence_display_extension is now shown in the Info dialog. This, together with the change above, allows the sample aspect ratio (SAR) to be inferred, according to the MPEG2 specification.
* A default path for saving BMPs can now be specified.
* Fixed a bug whereby tracks selected for demuxing in the INI file were not actually enabled for demuxing until the track selection dialog was saved. Now they are honored on startup as they should be.
* Fixed the CLI to also parse for the = sign at the end of the options to avoid false option detection. E.g., the substring '-aif' anywhere in a file name would be parsed as an option specification.
* Other miscellaneous CLI parsing bugs fixed.
* When doing a preview via the CLI, the playback speed is set to maximum.
* When a Play/Preview/Save Project Operation begins, the focus is now left on the main window. Previously, it annoyingly moved to the Info window.
http://neuron2.net/dgmpgdec/dgmpgdec150rc3.zip
IMPORTANT: Either use the new INI file in the zip file, or delete your old one, start DGIndex and close it once before using it in earnest.
Terranigma
4th March 2008, 16:47
Heya, Thanks for update neuron2. :D
Taurus
4th March 2008, 18:45
When a Play/Preview/Save Project Operation begins, the focus is now left on the main window. Previously, it annoyingly moved to the Info window.
I know it's just cosmetics, but this is just a good one....:)
Thanks for the update, keep on rockin' !
SeeMoreDigital
7th March 2008, 19:00
Hi Donald,
By chance, I discovered that DGIndex is able to parse (MPEG-2 DVD) .ISO file sources.
I had a quick look thru' your manuals, but could not see this feature mentioned.... Is DGIndex supposed to be able to do this?
Cheers
Guest
7th March 2008, 20:00
An ISO is just a dump of the disk, isn't it? So the parser parses through junk like the IFO and BUP and then hits the VOBs and sees start codes, etc.
If it works it's a coincidence as it is not by design. Nor do I think you should rely on it.
SeeMoreDigital
7th March 2008, 20:15
Thanks for the confirmation...
Just to let you know. Navigation and elementary stream de-muxing of "movie only" DVD .ISO file back-up's, works very well indeed :)
Cheers
tre31
9th March 2008, 11:51
Ok I've searched somewhat, tried out a few things, and can't really find a solution (well kinda..you'll see).
It once again relates too Colormetry, and the lovely 'no hints'.
I'll try too make this as painless as possible...
DVB-T Australian HDTV
Frame rate: 25fps
Field order: Top Field First
Picture size: 1440x1088
...
Colormetry: Unspecified video (2)
From what I can gather from what has been previously said if dgindex thinks that the mpeg-2 video is HD (> SD) then it assumes a colormetry of 709, yet there is not really any assumption being made by dgindex - ie. it still throws that annoying 'no hints' error. My workaround so far has been too just remove the 'hints=true' section from within the brackets of the offending .avs, and then no error occurs.
Is this the right thing too do? and the other question is - if HD is assumed too be 709, why not just have dgindex throw out 709 for colormetry and then have no 'no hints' error?
btw this happens with all au HDTV no matter what channel...
Guest
9th March 2008, 13:51
See here:
http://forum.doom9.org/showthread.php?t=132536&highlight=colormatrix
Regarding your suggestion, can you float that in the ColorMatrix thread and see if anybody has any objection to it?
hajj_3
9th March 2008, 20:55
neuron, is it possible for you to add an option in the menu or in the .ini to make dgmpgdec take window priority and beep again once it has finished saving a project as i used to know when it was finished if i was surfing on the net and can go and encode it, now i keep forgetting to look, i prefered the old behaviour alot more.
i like RC3 alot btw:)
Zep
10th March 2008, 14:22
neuron, is it possible for you to add an option in the menu or in the .ini to make dgmpgdec take window priority and beep again once it has finished saving a project as i used to know when it was finished if i was surfing on the net and can go and encode it, now i keep forgetting to look, i prefered the old behaviour alot more.
i like RC3 alot btw:)
yeah I asked for this a few pages back myself. that option would great to have. :)
agilpwc
10th March 2008, 16:47
If I call dgindex like this
dgindex.exe -IF=[%~n2.m2t] -OF=[%~n2] -OM=1 -IA=3 -minimize -exit
It doesn't honer the full path flag (ie I'm getting full paths and I don't want them), but if I open dgindex and go through the gui it works fine.
The Scientist
10th March 2008, 21:50
neuron, is it possible for you to add an option in the menu or in the .ini to make dgmpgdec take window priority and beep again once it has finished saving a project as i used to know when it was finished if i was surfing on the net and can go and encode it, now i keep forgetting to look, i prefered the old behaviour alot more.
i like RC3 alot btw:)Maybe no need? What if it beeped when the GUI was used and not when CLI?
Guest
10th March 2008, 22:12
neuron, is it possible for you to add an option in the menu or in the .ini to make dgmpgdec take window priority and beep again once it has finished saving a project as i used to know when it was finished if i was surfing on the net and can go and encode it, now i keep forgetting to look, i prefered the old behaviour alot more. Waiting for the third release candidate to ask for a feature to be added is pretty rude.
If I call dgindex like this
dgindex.exe -IF=[%~n2.m2t] -OF=[%~n2] -OM=1 -IA=3 -minimize -exit
It doesn't honer the full path flag (ie I'm getting full paths and I don't want them), but if I open dgindex and go through the gui it works fine. This arguably a bug so I will look at it.
hajj_3
11th March 2008, 03:25
Waiting for the third release candidate to ask for a feature to be added is pretty rude.
This arguably a bug so I will look at it.
hehe, it worked fine in RC2 tho neuron, not sure why it was changed, even if we just changed a value in the .ini would be fine, a tick menu item would be prefered, 1 for beep on/off and 1 for application take focus. Hope you might be able to implement 1 of those 3 options for RC4.
thanks for your hard work neuron:)
Guest
11th March 2008, 03:40
hehe, it worked fine in RC2 You mean 1.4.4 RC2? :devil:
No way it worked in 1.5.0 RC2.
Just to demonstrate what a magnanimous chap I am (matching your kind words), I've added an INI file option.
Notify_When_Done:
0=no notify
1=window to foreground
2=beep
3=foreground and beep
4=send email to all 50 forums at which hajj_3 has an account
tre31
11th March 2008, 11:31
See here:
http://forum.doom9.org/showthread.php?t=132536&highlight=colormatrix
Regarding your suggestion, can you float that in the ColorMatrix thread and see if anybody has any objection to it?
Well, after some more testing on my part, and reading the colormatrix thread and understanding why it should remain the status quo.. was dgindexing a SDTV demuxed capture today, same problem (no hints, unknown), now in previous versions I did not have this problem with both SD & HD from both the same 2 channels, so this leads me too believe you have somehow broken compatibility in RC2 with DVB-T in Australia (PAL), unfortunately I don't have samples from the past (for obvious reasons I don't keep MPEG-2 originals), but if you want samples (I'll make them small) of SD/HD let me know.
Finally I think that there is colormetry within these streams however its just not being parsed right by dgindex, it used too work fine, now it doesn't, that implies change, and as far as I know DVB-T in au has not changed, the standards have been set for a while now (except for transport stream properties - ie. epg EIT).
hajj_3
11th March 2008, 12:22
You mean 1.4.4 RC2? :devil:
No way it worked in 1.5.0 RC2.
Just to demonstrate what a magnanimous chap I am (matching your kind words), I've added an INI file option.
Notify_When_Done:
0=no notify
1=window to foreground
2=beep
3=foreground and beep
4=send email to all 50 forums at which hajj_3 has an account
wohoo :)
it certainly worked in 1.5.0 beta 13 and im almost certain 1.5.0 RC2, it took foreground and beeped. thanks for adding this:)
/me does the david brent dance for neuron.
Guest
11th March 2008, 13:19
this leads me too believe you have somehow broken compatibility in RC2 with DVB-T in Australia (PAL), unfortunately I don't have samples from the past (for obvious reasons I don't keep MPEG-2 originals), but if you want samples (I'll make them small) of SD/HD let me know. There are no changes in RC1->RC2 that would affect this. Please provide a sample stream that supports your claim that things are not working as they should.
Guest
11th March 2008, 13:20
im almost certain 1.5.0 RC2, it took foreground and beeped Nah, 1.5.0 beta 13 was the last revision that did that.
Zep
11th March 2008, 20:37
You mean 1.4.4 RC2? :devil:
No way it worked in 1.5.0 RC2.
Just to demonstrate what a magnanimous chap I am (matching your kind words), I've added an INI file option.
Notify_When_Done:
0=no notify
1=window to foreground
2=beep
3=foreground and beep
4=send email to all 50 forums at which hajj_3 has an account
Awesome! #2 for me that is prefect since I tend to be doing other stuff and I forget DGindex is indexing lol
Question for you neuron. DGindex is seeing bad field order errors in my 720p .ts source. Any idea why a progressive source would have such errors? I was under the impression only 1080i would ever get such errors. Anyway, I can not ever fix them as it throws audio sync way off. The not fixed d2v seems to work perfectly so it has me scratching my head since I'm clueless as to what exactly DGindex would be trying to fix on this progressive source. Perhaps the .ts wrapper is just messed up?
huge thx!
Guest
11th March 2008, 23:50
Don't forget that progressive content is often encoded as interlaced.
Also, the user's manual says that sometimes the "bad" D2V will be correct.
You must know that I need a stream sample to tell you definitively what is going on in this particular case. :)
Zep
13th March 2008, 00:42
Don't forget that progressive content is often encoded as interlaced.
Also, the user's manual says that sometimes the "bad" D2V will be correct.
You must know that I need a stream sample to tell you definitively what is going on in this particular case. :)
the manual says that but for me 100% of time fixing the d2v messes up sync on progressive HDTV source. As for 1080i and lower rez interlaced stuff like 704 x 480i about 75% of time audio sync is messed up if I opt to fix.
I have uploaded a small chunk of the .ts file called sample-field.errors.720p.ts
the field errors you will see are all the way through the .ts thousands of them. If I do not fix them it encodes fine as far as I can tell since I watched the final encode just now to be sure.
thanks!
Guest
13th March 2008, 01:44
Zep! You're the man.
The stream you uploaded has only frame repeats and no field repeats. Therefore, field order transitions are not applicable.
I have fixed DGIndex so that it does not report these false field order transitions. DGIndex needs to distinguish frame RFFs from field RFFs using the progressive_sequence indication. After the fix, no transitions are reported for this kind of stream. (When I added support for frame repeats, I neglected to realize that they would falsely trigger the transition detection. I didn't notice it when testing because at the time D2V fixing was not automatically checked for. I know...excuses, excuses.)
Thank you for bringing this issue to light. Here is your brownie point (it has right-handed sucrose, so it will not make you fatter):
http://neuron2.net/misc/brownie.jpg
As for 1080i and lower rez interlaced stuff like 704 x 480i about 75% of time audio sync is messed up if I opt to fix I've been looking for streams like that, which allegedly mess up sync. Feel free to upload one of those.
Zep
13th March 2008, 17:22
Zep! You're the man.
The stream you uploaded has only frame repeats and no field repeats. Therefore, field order transitions are not applicable.
I have fixed DGIndex so that it does not report these false field order transitions. DGIndex needs to distinguish frame RFFs from field RFFs using the progressive_sequence indication. After the fix, no transitions are reported for this kind of stream. (When I added support for frame repeats, I neglected to realize that they would falsely trigger the transition detection. I didn't notice it when testing because at the time D2V fixing was not automatically checked for. I know...excuses, excuses.)
Ahhhh very interesting. I now have a better idea of what is going on. This is awesome cause I always felt like what if the one time it was truly an error I didn't fix it lol
Thank you for bringing this issue to light. Here is your brownie point (it has right-handed sucrose, so it will not make you fatter):
http://neuron2.net/misc/brownie.jpg
no problem. I try to help where I can and I do love brownies! :D
I've been looking for streams like that, which allegedly mess up sync. Feel free to upload one of those.
I will next one I get. I had one over the weekend that did that but I deleted it after the encode. I will find another one and upload it ASAP.
Thank You!
len0x
15th March 2008, 18:26
Was just doing some testing with latest DGIndex in CLI mode (in GUI mode it works fine) and I have a sample TS for which it refuses to demux audio (no errors, just no output file). Worked fine with 1.4.9 though. I didn't see any changes in the change log related to that (only audio id for program streams). Did I miss anything or is it a new bug?
*Edit* I have actually quite a few TS samples for which audio demux seems broken in CLI mode compared to 1.4.9...
Guest
15th March 2008, 18:37
Please provide a stream sample and your CLI invocation line to allow me to duplicate your issue. I'm not aware of any problems in this area.
len0x
15th March 2008, 19:18
Please provide a stream sample and your CLI invocation line to allow me to duplicate your issue. I'm not aware of any problems in this area.
Lets start with this one: http://mirror3.autogk.me.uk/matrix.ts
CLI:
DGIndex.exe -AIF=matrix.ts -IA=3 -FO=0 -YR=1 -DRC=0 -DSD=0 -DSA=0 -VP=011 -AP=014 -OM=1 -OF=matrix -Exit
Guest
15th March 2008, 19:22
You've got OM=1 but no track number specified.
Since it's hard to know what the audio ID is, you should use OM=2. Or you can use the preview capability to get a list of the audio IDs, so you know what to set for your TN option. It's simpler to use OM=2 for transport streams because you can demux only one track anyways, the one whose PID is set.
I'm off to the pool so won't be able to comment again until this evening.
SeeMoreDigital
15th March 2008, 19:33
Lets start with this one: http://mirror3.autogk.me.uk/matrix.ts
CLI:
DGIndex.exe -AIF=matrix.ts -IA=3 -FO=0 -YR=1 -DRC=0 -DSD=0 -DSA=0 -VP=011 -AP=014 -OM=1 -OF=matrix -ExitI've also noticed...
The de-muxed MPEG-2 (.M2V) video stream crashes DGPullDown 1.0.11 when you try and create a 23.976fps stream.
Cheers
DJ Alik
15th March 2008, 20:58
Got an error at the end of saving the project:
Titlebar: Windows - No Disk
Error: Exception Processing Message c0000013 Parameters 75b6bf9c 4 75b6bf9c 75b6bf9c
len0x
15th March 2008, 21:11
You've got OM=1 but no track number specified.
Since it's hard to know what the audio ID is, you should use OM=2. Or you can use the preview capability to get a list of the audio IDs, so you know what to set for your TN option. It's simpler to use OM=2 for transport streams because you can demux only one track anyways, the one whose PID is set.
I'm off to the pool so won't be able to comment again until this evening.
OK, I see what's happening, but I in case I have set audio pid I would have expected that to be demuxed anyway unless -OM=0. But setting -OM=2 works though.
Guest
16th March 2008, 00:25
OK, I see what's happening, but I in case I have set audio pid I would have expected that to be demuxed anyway unless -OM=0. But setting -OM=2 works though. I understand. I'm going to rationalize all that for the next release.
Guest
16th March 2008, 00:27
The de-muxed MPEG-2 (.M2V) video stream crashes DGPullDown 1.0.11 when you try and create a 23.976fps stream. The demuxed M2V has a frame rate of 29.97fps. You cannot pulldown a stream to a lower frame rate!
If you use Force Film you will get 23.976 with len0x's stream.
Still, I see that setting Custom 29.97->23.976 (which is nonsense) does crash DGPulldown. So I will fix it to check for nonsense and reject it gracefully. Thanks for pointing it out.
Guest
16th March 2008, 00:28
Got an error at the end of saving the project:
Titlebar: Windows - No Disk
Error: Exception Processing Message c0000013 Parameters 75b6bf9c 4 75b6bf9c 75b6bf9c Please tell me more details about your source files, etc.
Guest
16th March 2008, 01:36
Still, I see that setting Custom 29.97->23.976 (which is nonsense) does crash DGPulldown. So I will fix it to check for nonsense and reject it gracefully. Thanks for pointing it out. Actually, any setting for this file crashes DGPulldown. The problem is that the stream does not have any GOP headers at all! DGPulldown is parsing for them and gets confused by not finding any. I will fix it.
SeeMoreDigital
16th March 2008, 12:13
Actually, any setting for this file crashes DGPulldown. The problem is that the stream does not have any GOP headers at all! DGPulldown is parsing for them and gets confused by not finding any. I will fix it.
Just to confirm... I entered 23.976 -> 23.976
len0x
16th March 2008, 15:50
OK, now another TS sample. DGIndex does demux audio from it (both 0x60 and 0x61) but doesn't put names of the PIDs into file, so I'm unable to distinguish between multiple tracks afterwards... (it seems to be a problem with all MPA audio tracks in TS).
http://mirror3.autogk.me.uk/tcm_mogambo_fragment.ts
Guest
16th March 2008, 16:03
That's a bug. I'll fix it. Thanks for pointing it out.
Guest
16th March 2008, 20:22
Just to confirm... I entered 23.976 -> 23.976 I have revised DGPulldown to work with streams that have no GOP headers, which is perfectly legal, of course, though unusual. I also defaulted the file input dialog filter to just show MPEG2 elementary streams. I'll release it after some regression testing.
SeeMoreDigital
16th March 2008, 20:59
Will you have the time to incorporate this suggestion too?
http://forum.doom9.org/showthread.php?p=1026570#post1026570
Cheers
Guest
17th March 2008, 01:01
Will you have the time to [set the progressive_sequence flag when clearing pulldown] too? Ouch. Please stop exposing issues. :p
While looking at that, I found that the number_of_frame_centre_offsets (which determines how many bits to consume from the bitstream) is calculated based on the progressive_sequence flag, and so you can't just arbitrarily set it. But that means you can't arbitrarily clear it either, as I am doing! I'll have to investgate this a bit more and get back to you. I'll follow up in the DGPulldown thread.
Atak_Snajpera
19th March 2008, 23:41
Would be possible to have the same log structure in DGIndex?
Stream Type: Transport [192]
Profile: High
Level: 4
Frame Size: 1440x1080
SAR: 4:3
Display Size: 1920x1080
Frame Rate: 29.970030 fps
Colorimetry: BT.709* [2]
Frame Structure: Fields (TFF)
Frame Type: B
Coded Number: 450
Playback Number: 450
Frame Repeats: 0
Field Repeats: 0
Bitrate: 15.743
Bitrate (Avg): 14.882
Bitrate (Max): 15.927
Audio Stream: 1100: AC3 2/0 256
Elapsed: 0:00:00
Remain: 0:00:00
FPS:
Info: Finished!
Guest
20th March 2008, 00:35
@Atak
You're confusing me. You appear to be asking for something that already exists. This is the DGMPGDec thread, not the DGAVCDec thread.
Please unconfuse me.
Atak_Snajpera
20th March 2008, 08:13
It was just an example from DGAVCDec. I still don't know how to save that kind of information to *.log.
Guest
20th March 2008, 13:05
It was just an example from DGAVCDec. I still don't know how to save that kind of information to *.log. Enable the info log, either though Options/Enable Info Log or by editing the INI file.
Inventive Software
20th March 2008, 14:15
The Display Size in the Information window may have a bug in it. For 720x576 video at 4:3 aspect ratio, it says the display size is 540x576, when it should be 768x576.
Guest
20th March 2008, 14:31
Those values are read from the stream, not calculated by DGIndex. If you'd like to post a link to a stream sample, I can investigate further.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.