DGMPGDec 1.5.3 Final

[Zep]

Success! I figured out WHERE the problem is


Ok the following returns the correct frame count length wise VS audio length.
mpeg2source("D:\wholeshow.d2v")



This returns LESS frames (as you predicted) and Audio length ends up being longer
than video length.

v1=mpeg2source("D:\part1.d2v")
v2=mpeg2source("D:\part2.d2v")
v3=mpeg2source("D:\part3.d2v")
v4=mpeg2source("D:\part4.d2v")
v5=mpeg2source("D:\part5.d2v")
v6=mpeg2source("D:\part6.d2v")
return(v1+v2+v3+v4+v5+v6)



This returns MORE frames (it is running the avs 6 times and only working on 1 segment
at a time to make all the first pass video.pass files which are then merged to do the
final 2nd pass)

mpeg2source("D:\part1.d2v")

Now run avs again with change to the part*.d2v
mpeg2source("D:\part2.d2v")

repeat for remaining 4 segments in my example



each segment run ADDS 2 bogus frames to the TRUE count.

This is from projectx
50458 Frames 00:14:01.800 'C:\Demux\part1.m2v'

This is from DGindex
50458 Frames when the index is finished reading from status window.

BUT THIS is what Vdub says in the frame count when doing just this
mpeg2source("D:\part1.d2v")
50460 Frames


Since there are 6 segments and 1 or 2 frames are being added to each segment in Vdub
you can see where the problem. Anyway projectx and VRD and DGindex
all agree on the frame count BUT when the stream is sent to Vdub via an avs it adds
1 or 2 frames to the frame count per segment that is why I see 9 more frames than
I should and why the audio is out of sync and why it goes out more and more as you
watch farther along in the encode.


Now we just have to figure out WHY Vdub is getting the count wrong? is it avisynth
sending the wrong count? or is Vdub itself messing up?

My testing continues :)

[Guest]

This is from DGindex
50458 Frames when the index is finished reading from status window.

BUT THIS is what Vdub says in the frame count when doing just this
mpeg2source("D:\part1.d2v")
50460 Frames
That's unexpected. Can you put part1.m2v on my FTP server?

[Guest]

Zep's problem turned out to be caused by FadeIn() and FadeOut(), which are known to add an extra frame. He thought he had commented them out at the bottom of his script but hadn't.

[Zep]

Zep's problem turned out to be caused by FadeIn() and FadeOut(), which are known to add an extra frame. He thought he had commented them out at the bottom of his script but hadn't.

yup!


However, I still can't believe core calls like fadein and fadeout would
ADD frames and not just fade on the existing frames. It blows my
mind because it throws off sync even if you just use each call once
on a full d2v of the whole show. (in my case 42ms off)

since i used them for years without problems in 2.5.5 and earlier
I never even knew there was a Fadein0 and Fadeout0 added in 2.5.6.
(Until last night lol)

Which has me wondering how fadein and fadeout acted before
Fadein0 and Fadeout0 where added in 2.5.6 :)

(me hunts for old docs)


Anyway, DGindex rocks on :D

[Guest]

* Leading B frames for field structure streams were not counted correctly, causing a possibility to display bad starting frames when serving with DGDecode. Fixed.

* Fixed possible crashes when exiting DGIndex while a play/preview is in progress.

* DGIndex no longer beeps and brings its window to the foreground when a Save Project operation is complete.

* Fixed minor bugs in the MRU list handling.

* The quants displayed by DGDecode's showQ=true did not match the avg/min/max values displayed for info=1 (the showQ display was not re-ordered for display order). Fixed.

* Only half a screenful of values were shown with showQ=true for field structure streams.

* The funny transparency for the showQ display was fixed.

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

This is a release candidate, so this is the last call for bug reports!

[SeeMoreDigital]

This is a release candidate, so this is the last call for bug reports!Any chance for a feature request?

I have noticed in your DGAVCIndex application, you have added the ability to identify the VOP type of each coded frame (ie: I, P, B). Could this be added to DGIndex?


Cheers

[jeffy]

Am I doing something wrong or is this a new feature? For every file I open and select Save Project, there is a new log file created. Is this expected?

DGIndex.ini (MRU list deleted):
DGIndex_Version=DGIndex 1.5.0 RC 1
Window_Position=248,64
Info_Window_Position=577,46
iDCT_Algorithm=6
YUVRGB_Scale=1
Field_Operation=0
Output_Method=2
Track_List=
DR_Control=2
DS_Downmix=0
SRC_Precision=0
Norm_Ratio=100
Process_Priority=1
Playback_Speed=3
Force_Open_Gops=0
AVS_Template_Path=E:\Tools\AIT\template.avs
Full_Path_In_Files=1
Fusion_Audio=0
Loop_Playback=0
HD_Display=0

[Guest]

What you've posted is the INI file, but yes, there is now a log file created automatically.

[Inventive Software]

And that's quite useful, because it saves me having to keep opening the D2V file just to find out whether the bleeding thing's interlaced properly or not.

Kudos on RC1 BTW. When this hits release, I'll see during the holidays about inter-twining DVR-MS support into it. Just to see what could happen. :)

[jeffy]

What you've posted is the INI file, but yes, there is now a log file created automatically.
I know I posted the INI file, since I hoped there is some option allowing me to turn the log off. Could you please make this optional?

[Guest]

Could you please make this optional? Sure, no problem. Thanks for suggesting it.

[Guest]

I have noticed in your DGAVCIndex application, you have added the ability to identify the VOP type of each coded frame (ie: I, P, B). Could this be added to DGIndex? Sure, no problem. [Well, there was a problem but I fixed it. :)] Thanks for suggesting it.

[Zep]

* DGIndex no longer beeps and brings its window to the foreground when a Save Project operation is complete.




YES!!! This one change alone is huge for me. been wanting for this one for years! :P

BTW - can you add an option to make it beep still but NOT bring the window to forground?

Huge thanks for all the awesome work you are putting into this!


Zep

[Guest]

BTW - can you add an option to make it beep still but NOT bring the window to forground? Nah, I don't think I like that.

[Guest]

* Fixed a regression in RC1 for field structured streams that could cause a hang in DGDecode.

* The Info display now shows the picture coding type (I/P/B).

* Added an option to enable/disable the automatic log file generation (default is enabled).

* Added a maximum bitrate field to the Info display.

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

[Terranigma]

Thanks a lot for this update. Can't say I seen it coming. :sly:

[Guest]

Thank you, Terranigma, for reporting the regression in RC1.

BTW, I am deeply wounded because you are an akupenguin/Didée fan, but not a neuron2 fan.

http://neuron2.net/smilies/crying-smiley.jpg

[Isochroma]

I just noticed that this latest release uses a background in the window which says "DGAVCIndex" rather than "DGIndex". It's quite confusing and made me think for a moment that I had installed the wrong executeable.

[Guest]

I never shipped a splash.bmp with the betas and RCs. Are you sure you didn't copy it over by accident from somewhere?

[Terranigma]

Thank you, Terranigma, for reporting the regression in RC1.

BTW, I am deeply wounded because you are an akupenguin/Didée fan, but not a neuron2 fan.

http://neuron2.net/smilies/crying-smiley.jpg

NP, and actually I am a fan. We're only able to use 25 characters for a custom title, and when I originally wrote that, I was trying to get it to say "akupenguin/Didée/neuron2 fan" (30 characters in length), but was forced with the title I currently have. Now if the limit could be changed to 30... :p

[Isochroma]

http://i13.tinypic.com/7wqma00.jpg

I have both DGIndex and DGAVCIndex in my avisynth plugins folder. Shouldn't be a problem should it?

[Guest]

They both look for and open a file called splash.bmp to make the background. For the final release I'll change them to look for files called dgindex.bmp and dgavcindex.bmp. Thank you for pointing it out.

[minaust]

* * DGIndex no longer beeps and brings its window to the foreground when a Save Project operation is complete.


Oh, bless you for that one!

[sunbeam]

Thank you neuron2 for the option to enable/disable Info Log.

[jeffy]

Thank you very much for listening to the different points of view of the different users.

[Zep]

Nah, I don't think I like that.

ahh why not? it would a pref option.


The reason I would love that option it is that I do not know when DGindex is done indexing and I want to be alerted. I just did not like it taking the foreground right in the middle of me typing to someone in IRC etc... :D

[jmac698]

Some DGIndex bugs:
-Can you place the focus back on the display window after F6
-Parse Output frame numbering starts at 0, Information window
starts at 1.

[Guest]

Info window is a count, not frame number.

[jmac698]

After pressing F6, focus is on Information window. Now if I press right arrow, nothing happens. I'd rather the focus to stay on video window so that I can start navigating the video.

[Guest]

I've implemented that and it is indeed more user friendly. Don't know how I lived without it. :)

Thank you for suggesting it.

[jpsdr]

Hello.

I've expecting a potentiel problem with RC2.
I've worked on several DVD wich have PCM audio,
and on one, the wave file seems to have the header
corrupted.
It have the correct size, but, when opened, it doesn't
have the correct duration. It stop around half the normal
duration.
I'll try to analyse the wave header, but, if you can on
your side look at the code of outputing wave header.

[jpsdr]

PS : I've the problem on the wave with both GoldWave
and VirtualDub.

[jpsdr]

Update.

I've redemuxed the audio, but in mode "select track"
instead of "All tracks" (even if there was only one),
and the wave was correct.

[ck]

With timestamp logging enabled, HDV transport streams give bad D2V files. With timestamp logging not enabled, produced D2V files are correct.

Example:
..
900 1 0 18432084 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 20052644 0 0 0 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 21669068 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 23289064 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 24909060 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 26529056 0 0 0 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 28159204 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
..
900 1 0 54068988 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 55697444 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 1 0 58933300 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
..

instead of each line having the same set of frames.

I,B, and P frames are lost.
About 1% of frames are lost.

Tried on m2t files from two different brand cameras. Elementary and program streams seem to be ok, only m2t breaks the parsing.

Same behaviour occurs with 1.4.9final.


Can anyone else confirm this?



Also, I'd like to put my hand up for having 'log timestamps' supported by the command-line interface (ie new switch)

(crossposted to neuron2.net forum)

[ck]

also, in getbit.cpp 'V PTS' instead of 'V DTS' is printed to the timestamps file: fprintf(Timestamps, "V PTS %u [%ums]\n", dts_stamp, dts_stamp/90);

[bob0r]

Messed up MPA audio with dgmpegdec

tested:
dgmpgdec147
dgmpgdec150rc2

Convert audio via .avs to WAV or MPA fails
Source: Satellite MPEG2 dutch channels, package: canal digitaal (most likely all .ts recorded with 192kbps mp2 audio)
Programs used to convert audio: virtual dub and cinema craft encoder, both various versions.

symptoms: audio goes complete silence after a random time, usually within minutes.

The cause seems to be changing audio within the .ts, like commercials or one show to another.

dgmpegdec 1.3.0 does not have this problem.

I hope this information is enough, else ill try make a short sample where it fails.

[Guest]

Update.

I've redemuxed the audio, but in mode "select track"
instead of "All tracks" (even if there was only one),
and the wave was correct. Please provide a test stream that I can use to duplicate your issue.

[Guest]

With timestamp logging enabled, HDV transport streams give bad D2V files. With timestamp logging not enabled, produced D2V files are correct.

...only m2t breaks the parsing.
Please provide a test stream that I can use to duplicate your issue.

[Guest]

I hope this information is enough, else ill try make a short sample where it fails. Please provide a test stream that I can use to duplicate your issue.

[jpsdr]

Hello.

I've made the test again, and this time, everything
have worked fine.
Don't know what have happened the first time...

[burfadel]

Faster decoding of HDTV 1920x1080 would be nice :) normal resolution (PAL 720x576) is very fast, the reason why I bring up HDTV is that editing out adverts from HDTV is rather slow, and for those with slower CPU's than a Core 2 Duo at 2.8ghz I could imagine it being rather painfully slow!

I know I brought up SSE3/SSSE3 optimisations in an earlier post, if I had programming knowledge I would contribute to improving dgdecode, but I do know there's others with knowledge on here that could do it (I guess)!

With an updated, optimised dgdecode.dll it would not only improve the performance of decoding/encoding hdtv, but also standard definition and DVD's :), in fact any encode that used dgindex!

[Guest]

also, in getbit.cpp 'V PTS' instead of 'V DTS' is printed to the timestamps file: fprintf(Timestamps, "V PTS %u [%ums]\n", dts_stamp, dts_stamp/90); Thanks. I'll fix that for 1.5.0 Final.

[josey_wells]

Neuron2,

While looking through the ISO/IEC 14496-2:2004 (MPEG-4 standard) I found that a video_range parameter was added to the extensions header such that for 8 bit video:

Video_Range=0(default with no extension header)
Luminance and Chromaniance [16, 235] & [16, 240] respectively

Video_Range=1
Luminace and Chrominance [0, 255]

I don't have a copy of the new MPEG-2 standard to see whether it applies there or not. If it does could a video_range information field be added to the log file and GUI to display this information? This would be useful for the new ColorMatrix and also my internal color conversion function since full range video uses different offset and scaling factors.

This would also apply to the new DGAVCIndex function.

The standard also mentions that with no extension information BT709 is assumed. If I read through the post correctly DGIndex currently reports this as BT470-2, B, G*. IMO this should be reported as BT709*.

Thanks!

[Guest]

That parameter does not exist in MPEG2.

The standard also mentions that with no extension information BT709 is assumed. If I read through the post correctly DGIndex currently reports this as BT470-2, B, G*. IMO this should be reported as BT709*.

That's how it was for a long time. After several requests and some pratical experiences, this policy was implemented:

* When a stream does not declare the colorimetry, matrix_coefficients=1 is assumed for HD video and matrix_coefficients=5 is assumed for SD video.

[damjang]

When I use DGIndex (1.5.0rc2) and save a project (from VOB) I encounter an error that say "Too many pictures per GOP (>=500). DGIndex wil terminate." When I click OK the prog closes.
What I can do to prevent this error?

thank you
damjang

[Inventive Software]

Couple of things we need to know, firstly what DVD is the VOB from? And secondly, does the error still come up when you decrypt it with either DVD Decrypter or DVDFab Decrypter? If I could pinpoint it, it's likely copy-protection of some sort that has lots of erroneous GOP sizes.

[Pudah]

I often use DGIndex to save BMPs. By default, it saves to the folder from which the source video was loaded. Even if you navigate to a different folder to save an image, subsequent saves also default to the source folder.

This a only a minor inconvenience, so if you don't think it is important enough to spend any time on, I understand completely. But it would be great if the user could specify a permanent folder to store BMPs, or at a minimum, have the program remember a selected folder during an editing session and not go back to the source folder on each save.

[damjang]

Couple of things we need to know, firstly what DVD is the VOB from? And secondly, does the error still come up when you decrypt it with either DVD Decrypter or DVDFab Decrypter? If I could pinpoint it, it's likely copy-protection of some sort that has lots of erroneous GOP sizes.

Yes, it is an error on original dvd. But I rip it with DVDFab and it say that "3 potential bad sector protections are removed". The source dvd is "The Corporation (ita version)"...

[damjang]

I try to play the file (specialy the part with too many pictures per gop) and all the dvd/mpeg players play that part ok. The only error is in DGIndex...

[Inventive Software]

Can you cut a small sample and upload it somewhere?