DGMPGDec 1.5.3 Final

[Guest]

* Pop-up warning message boxes are now suppressed for CLI operation.

* PSIP PID detection has been added.

* PIDs are now displayed in decimal as well as hexadecimal.

* A new option, Looped Playback, was added. When the end of the timeline is reached during a Play or Preview operation, playback is automatically restarted at the beginning of the timeline.

* A bug was fixed in the transport packet length detection code. This caused some M2TS streams to be parsed incorrectly.

* The file type .m2t was added to the open dialog.

* Some array sizes were increased to prevent crashes in the debugger.

* The next_start_code() function was enhanced to add error resiliency for abnormal slice terminations.

* Because the code never writes to the DirectDraw surface anymore (removed long ago!), the DirectDraw Overlay option was removed. DGIndex now never seizes the overlay.

* When the Use Full Paths option is turned off, relative paths are used. This allows for the source files to be in a different directory than the D2V file. If they are in the same directory, the behavior is the same as before.

* In CLI mode, if a field order transition is detected, it is silently corrected.

* Fixed two problems with .m2ts files: 1) audio on PRIVATE_STREAM_1 was not processed correctly, and 2) video demuxing was broken.

* Fixed a problem that resulted in an abort of processing with the message box popup "Force film mode is not supported with frame repeats".

* Removed the limitation that the AVS and D2V files must be in the same directory when the Use Full Paths option is disabled. Thanks to Rainy for showing the way.

* Added checks for extra robustness against emulated audio start codes for MPEG audio in program streams. This fixes some known streams with emulated audio start codes.

* The infamous GOP warning popup has been removed. The D2V Parse log now shows the open/closed status of the GOPs, so if you need to know if your opening GOP is open, look there.

* The Info dialog position is no longer pegged to the main DGIndex window. It can be independently positioned and its position is saved and restored via the INI file. Also, its font size has been decreased and all the group boxes are now arranged vertically.

* An option was added to control how HD videos are displayed. You can now shrink by half (the previous behavior) or you can view any quadrant of the video. This allows the interlace structure of HD videos to be inspected.

* Fixed a problem that caused DGIndex to miss some audio streams. For example, if AC3 substream 0x80 was present, and MPA stream 0xC0 was present, both would be viewed as Track 1, and only the first one encountered would be detected. The concept of track number is removed (as it is a DVD-specific construct), and it is replaced with the concept of audio id. See the users manual for details.

* For MPEG audio streams, the Info dialog now shows full information: audio id, layer, number of channels, sampling rate, and bitrate. This information is also included in the filename of demuxed MPEG audio streams.

* Whenever the Info dialog is closed, a log file is (optionally) created that contains the same information. This may be invoked by the CLI to silently query the nature of the input file. Please see the users manual for details.

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

* Fixed a bug that caused automatic PID setting for transport streams to use the last audio stream encountered instead of the first.

* Added an MRU list to the File menu.

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

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

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

* Added a maximum bitrate field to the Info display.

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

* Don't check for field order transitions for streams with only frame repeats.

* Use lowest numbered audio ID to expand __aud__ instead of the first audio stream encountered in the source files.

* Fix parsing with log timestamps enabled.

* Correct handling of default matrix coefficients for hints.

* Add option for beeping and focusing when save project finishes.

* Save BMP is now enabled during play/preview.

* Fix regression in transport stream detection.

* The Full Paths option is now honored for CLI invocation.

* Fixed the audio delay calculation, timestamps dump, and analyze sync tool for streams that do not contain GOP headers.

* The analyze sync tool now prompts for the audio ID instead of a track number.

* Fixed incorrect audio demuxing when demuxing audio only.

* Fixed display of field order for field structure streams.

* Fixed bug: Open file, Save Project, then File -> Open -> OK gives an error messge.

* Fixed bug: Save project with decode AC3 to WAV. Repeat that. Each time the WAV file becomes longer. The size was not reset to zero.

* Fixed a problem that caused some program streams to be detected as transport streams.

* Fixed a problem with video demuxing that sometimes caused an extra partial first GOP to be demuxed at the start of the stream.

* Added mousewheel support.

* Added a -RG option to the CLI (define project range).

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

[3ngel]

It seems to work.

I have two question:

Can you add the ability to recognize DTS-HD MA?
You have an example in the stream i sent to you.

It's possible to add the ability to "Select the Main Movie" from a pool of m2ts (movie spread in different m2ts)?

Thanks

[Atak_Snajpera]

Could you add a switch to close DGIndex automatically in case of error?

[buzzqw]

Could you add a switch to close DGIndex automatically in case of error?

i disagree. Rarely and only caused by users are error of DGIndex.

If something goes wrong is most probably due to input file tipe/wrong command line.. and for me is better to inform the user of the error.

I would prefer, about Pop-up warning message boxes are now suppressed for CLI operation.
that in case of "Field Order Transition Detected" error that dgindex (with an option of command line) fix automatically the wrong field order

anyway .. :thanks: for this update!

BHH

[Atak_Snajpera]

I'm just talking about extra optional switch in CLI not in GUI! It wouldn't be used by default!

[ankurs]

also could it tell the field order of the source itself and accurately.. because also meGUI and GK sometimes are wrong in thier analysis and then it has to be checked and tested manually :( .. btw thanks for the playback optionn :D !! sjuperb as usual :)

[Sharktooth]

i think ill add this version and not 1.4.9 to megui due to this:
* Pop-up warning message boxes are now suppressed for CLI operation.

[Terranigma]

Oh nice. Thanks for the update. :D

--
neuron2, could it be a possibility that the iDCT Algorithm, IEEE-1180 reference, was broken or wasn't working properly in the previous (1.49 Final) version, because with this newer version, my custom scripts seems to be decoding at a slower pace, so as a workaround, I have to increase the maximum amount of memory to compensate for the speed loss. Not a big deal, but I am curious to know if there's been some changes made to the algortihms as well that could affect the decoding speed.

[Guest]

Nothing has changed in that regard. Your logic is rather contorted. "My script is running slow, so is the IDCT broken in the old version?" It makes no sense.

[Terranigma]

Your logic is rather contorted. "My script is running slow, so is the IDCT broken in the old version?" It makes no sense.

Well, I was thinking that maybe you had found something that was faulty with that algorithm and maybe corrected it in the new version; so that's where I was coming from. :p
Anyways, that's for the reply, my computer was the culprit-It was updating itself while I was previewing my scripts. :rolleyes:

[G_M_C]

Here is DGMPGDec 1.5.0 beta 1:

* Pop-up warning message boxes are now suppressed for CLI operation.

* PSIP PID detection has been added.

* PIDs are now displayed in decimal as well as hexadecimal.

* A new option, Looped Playback, was added. When the end of the timeline is reached during a Play or Preview operation, playback is automatically restarted at the beginning of the timeline.

* A bug was fixed in the transport packet length detection code. This caused some M2TS streams to be parsed incorrectly.

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

Good to see you're still updating & improving the MPEG2-tools in your portfolio Neuron2 !

Hopefully you AVC-tools will be of equal high quality

[map1742]

Nice. Will try this shortly.

I am using HDVsplit and DGMPGDec to process my Sony HC3/HC7 50i movies. In my experience Sony Vegas 7, Cineform Connect and Canopus Procoder all lose fields at the start and end of a file when compared to DGMPGDec.

One feature request: please add ".m2t" as a file extension in the DGindex open file dialog for MPEG and transport stream files. This is the default type for HDV files from HDVsplit and Vegas.

Thanks :)

[Isochroma]

Thanks for the PID addition!

[SpAwN_gUy]

anything about "relativity" of filepath? ;)

[krisq]

anything about "relativity" of filepath? ;)

do you mean 'options\use full paths'?

[SpAwN_gUy]

do you mean 'options\use full paths'?exaclty ;)
as i wrote in here (http://forum.doom9.org/showthread.php?p=1023814#post1023814)

[Guest]

Refresh my memory please. What is the specific case that necessitates new path handling? Give me the full paths to the D2V, AVS, and source files in your specific case, and tell me how you think DGIndex should handle it.

[SpAwN_gUy]

Refresh my memory please. What is the specific case that necessitates new path handling? Give me the full paths to the D2V, AVS, and source files in your specific case, and tell me how you think DGIndex should handle it.well.. the big part is in the post on the link... and for the rest:

AVS:G:\DVDRiP\AFRO\DVD1\AS01\AS01.VD_LS.avs
G:\DVDRiP\AFRO\DVD1\AS01\AS01.d2v
G:\DVDRiP\AFRO\DVD1\01\VTS_02_1.VOB
AVS Internals:
LoadPlugin("..\filters\DGDecode.dll")
DGDecode_Mpeg2Source("AS01.d2v", info=3)
Crop(2,4,-2,-4)
Lanczos4Resize(864,480)
.d2v internals
DGIndexProjectFile16
7
..\01\VTS_02_1.VOB
Stream_Type=1
MPEG_Type=2
iDCT_Algorithm=5
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=16:9
Picture_Size=720x480
Field_Operation=0
Frame_Rate=29970 (30000/1001)
Location=0,0,1,209c6

d00 1 0 2048 0 1 1 d2 f3 e0 f1 f2 e3 f0 f1 e2 f3 f0 e1
d00 1 0 411648 0 1 1 d2 f3 e0 f1 f2 e3 f0 f1 e2 f3 f0 e1

aviSynth plugins are in here
G:\DVDRiP\AFRO\DVD1\filters\DGDecode.dll
and the AVS, d2v, VOBs are also available from the LAN with theese paths
\\controllerPC\x264farm\
\\controllerPC\x264farm\AFRO\DVD1\AS01\AS01.VD_LS.avs
\\controllerPC\x264farm\AFRO\DVD1\AS01\AS01.d2v
\\controllerPC\x264farm\AFRO\DVD1\01\VTS_02_1.VOB
\\controllerPC\x264farm\AFRO\DVD1\filters\DGDecode.dll so in this situation evrything is working fine.. video is rendered on anotherPC..

the only thing that in nonautomatic is storing of relative paths in the d2v internals.. there are: Full-paths (with "G:\..") and Just-file-names (just "VTS_02_1.VOB")

[Guest]

@SpAwN_gUy

Please explain why it is so important to you to have your D2V and AVS files in a location other than the source files. This will be a non-trivial development so it's up to you to justify the feature request.

[SpAwN_gUy]

heh.. well.. i'm trying to keep things separate (unlike stuff at home :) )..
VOBs are usually in the VOB folder, while d2v's and avses - in separate..
AutoGK stores it's temp-files in separate folder,.. meanwhile storing "fullpaths" in d2v..

but the network part is.. for.. x264farm. agen-based encoding over the network (try first tutorial in my signature). agent-based is when avs-internals are decoded and processed on other farmPC's (it gives a huge speedUP, and lowers controllerPC's CPU usage).
so, suddenly i've discovered a way to organize everything, by changing full-paths to relative-paths manually.
Well, offcource, i have in my mind, that i can open VOBs through Network-path (through the ass, actually), and store full-network-paths... but..

[Guest]

... but.. But what?

[SpAwN_gUy]

But what?

But, maybe, such an option will be more convinient and more universal(can i use this word in this context?)

[Guest]

* The file type .m2t was added to the open dialog.

* Some array sizes were increased to prevent crashes in the debugger.

* The next_start_code() function was enhanced to add error resiliency for abnormal slice terminations.

* Because the code never writes to the DirectDraw surface anymore (removed long ago!), the DirectDraw Overlay option was removed. DGIndex now never seizes the overlay.

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

[Boulder]

Are you interested in taking a look at a sample in which the delay is way off target?

The reason why I ask you first is that the bad VOB is the result of RipIt4Me+FixVTS, a good delay value is found when the disc is decrypted using DVDFab HD Decrypter. PGCDemux does show the correct value from the bad VOB so it is there somewhere ;) The disc is ARccOS protected (a Sony release) if I'm not mistaken.

Since many people still use RipIt4Me, it might be interesting to know whether this odd behaviour could be avoided in DGIndex (which is used by many applications).

[Guest]

Sure. Post a fragment of the start of the VOB. Don't cut the start.

[Boulder]

Here it is : http://www.savefile.com/files/1052641

DGIndex 1.5.0 beta 2 reports delay 81112ms, the correct is apparently -128ms which PGCDemux reports, it is also the same value that DGIndex reports when processing the DVDFab HD Decrypter-ripped VOB.

[SeeMoreDigital]

I've just run your .VOB sample thru' EVOdemux and it reports the same delay time as DGIndex.... Strange eh!

http://img210.imageshack.us/img210/1848/evodemuxhx6.png


Cheers

[Boulder]

Funny thing is that PGCDemux doesn't find any audio tracks when opening the corresponding .ifo file and using "by PGC" mode. The whole audio track can only be found if I use "by VOBId" and choose the correct VOBId. (choosing "by cell" works as well but it shows the delay only for the cell in question)

Maybe this is the reason for the weird delay?

[Guest]

File sharing sites are blocked by my employer so I can't get to it until tonight. But did you try the standard trick of starting the project in by several GOPs (e.g., hit > 5 times and then [ before saving the project)?

[Boulder]

Actually no, this is the first time I've run into this problem. If it solves the issue, what about those applications that use DGIndex, such as DVD-RB? That trick cannot be used with them.

[Boulder]

Yep, jumping a few GOPs seems to work. I wonder how DVD-RB or MeGUI would behave..I think I'll need to run a test project and see what comes out.

[Guest]

Well, it means that there is crap at the beginning and it is confusing the delay calculation. I'll have to think about what can be done for DVDRB, etc., in this regard.

[Guest]

the only thing that in nonautomatic is storing of relative paths in the d2v Just to be completely clear about this...

1. When you say 'relative', do you mean relative to the path location of the D2V file? That path is to be the base location for everything else, yes?

2. You talk about network drives. But I can't make a relative path go to a different drive, i.e., this is not possible from drive c for example:

..\d:\path\file.vob

So how do you intend to use this relative path capability in this scenario?

[Guest]

Yep, jumping a few GOPs seems to work. This has come up so many times now that I have added a warning popup when a large audio delay is calculated. The popup explains the GOP skipping trick.

[Boulder]

That's a good idea - especially because it has been quite rare but apparently has become more common due to the structure crippling protections.

[Rainy]

2. You talk about network drives. But I can't make a relative path go to a different drive, i.e., this is not possible from drive c for example:

..\d:\path\file.vob

So how do you intend to use this relative path capability in this scenario?

Just force the storage of absolute paths. Though it doesn't seem that he'd like to use the relativeness feature this way, but simply being able to move the directory structure including the project file from a local hard drive to a network store, without editing d2v internals manually.

[SpAwN_gUy]

1. When you say 'relative', do you mean relative to the path location of the D2V file? That path is to be the base location for everything else, yes? yes. path to VOBs relative to .d2v-file path.
2. You talk about network drives. But I can't make a relative path go to a different drive, i.e., this is not possible from drive c for example:

..\d:\path\file.vob

So how do you intend to use this relative path capability in this scenario?
Just force the storage of absolute paths. Though it doesn't seem that he'd like to use the relativeness feature this way, but simply being able to move the directory structure including the project file from a local hard drive to a network store, without editing d2v internals manually.yep. exactly. (as i can remember) Windows stores "relative-paths" when files are on the same drive, and "full-paths" when on different..
just store "d:\path\file.vob"

it is, like, for moving files from one drive to another without loosing playability and encodeability.. without editing .d2v's or making another Indexing..

[Guest]

You're not answering my question. What is the point of me adding relative path handling for this networking scenario, which you cited as a reason for adding it? We can already store full paths. If you don't make things clear I'm going to move on.

it is, like, for moving files from one drive to another without loosing playability and encodeability.. without editing .d2v's or making another Indexing.. But if I store the full path, you can't have this movability.

I'm just not seeing the point of all this.

[Rainy]

You're mixing things up: Absolute paths have to be stored whenever the project and video files don't share a common prefix, i.e. are located on different drives, *even* if the user chooses paths to be stored relatively. This is a special handling for the scenario you've mentioned before, since there's no such a thing as relativity between different drives ;) In any other case you simply store relative paths, which makes it possible to move files around and never have to edit the project file.

[Guest]

Ha ha, I'm not an idiot. I'm asking for justification for the feature. If the only thing he wants is to store his source files away from his D2V, then it's too minor to jump ahead of other stuff on my to-do list. If it can support his farming stuff, which he cited, then it might be more worthwhile. But I don't see how it can help in that regard.

[SpAwN_gUy]

If it can support his farming stuff, which he cited, then it might be more worthwhile. But I don't see how it can help in that regard.the reason i started this is just because of "farm" and agent-based encoding.
well, i've been able to handle evrything with "full paths" when i was encoding(and am) on my localPC. (i.e. custom aviSynth filters were in daefault avisynth plugin folder, VOBs on one drive, avses somewhere else.. and with full paths everything worked just fine..).
but when i started farming.. i've noticed, that "d_mn.. my files are NOT encoding at all. Why?"
- because no one can open a C:\path\file.vob from another PC from the network..
then i've UNchecked option "Store full paths".. and what do i get.. i get NO PATHS at all..


well. okay. i give up..
a) yes i've mentioned that behaviour only with x264farm.
b) yes i can do it with my hands.
c) cmon... if you are not in to implementing that.. okay i'll continue doing what i'm doing..
and there allways be a step in "the guide" for x264farm agent-based encoding about "sh@.. you have to modify paths to vobs on your own"

i'm tired to keep asking (i guess today is my bad day..).. i know that this is some kind of minor request (i always did thought so) and i'm thinking of implementing that ONLY IF you have time..
(maybe i'll try to get sources.. and we'll see how could i help you..)

cheers, warezmasta.

[dk75]

You must explain it simpler.

And thats whats going on:
1. one have VOB and do GDIndex and make AVS script
2. one have 6 computers over LAN and want to use them to parallel encode of this VOB to H264
3. to lowering LAN overhaul one use x264farm to that by installing agents at 5 computers and server at 1 computer
4. server program cut this VOB to smaller parts and send them to agents with his part of AVS script
5. each agents works on its part of VOB independently and send done encodings to server
6. server merge encoded parts to final file and you have 5 time faster encodings

For that, first AVS made on server side must work correctly at each agents, but at each computer agents might be installed at different place.

I hope that I've didn't mixed up anything?

[Guest]

dk75, thank you. Someone finally made it clear.

i'm tired to keep asking spawnguy, I've been adding requested features, small and large, for over 4 years. I simply want to understand what I am doing. And if you want to contribute code, it will always be appreciated and properly credited.

[SpAwN_gUy]

You must explain it simpler.
:) ... no coments

And thats whats going on:
1. one have VOB and do GDIndex and make AVS script
2. one have 6 computers over LAN and want to use them to parallel encode of this VOB to H264
3. to lowering LAN overhaul one use x264farm to that by installing agents at 5 computers and server at 1 computer
4. server program cut this VOB to smaller parts and send them to agents with his part of AVS script
5. each agents works on its part of VOB independently and send done encodings to server
6. server merge encoded parts to final file and you have 5 time faster encodings

For that, first AVS made on server side must work correctly at each agents, but at each computer agents might be installed at different place.

I hope that I've didn't mixed up anything?
just few corrections..
there is only ONE AVS, and controller just splits total framecount to some little number of frames..
agents do the encode.
then controller makes ratecontrol and goes to second pass
for x264.exe on an agentPC it looks something like that:
\\controllerpc\farm\x264.exe --seek 4450 -frames 250 \\controllerpc\farm\somedvd\movie.avs
evry agent gets its own startFrame and frameCount..

[Rainy]

Ha ha, I'm not an idiot. I'm asking for justification for the feature. If the only thing he wants is to store his source files away from his D2V, then it's too minor to jump ahead of other stuff on my to-do list. If it can support his farming stuff, which he cited, then it might be more worthwhile. But I don't see how it can help in that regard.

I didn't mean to be offensive, just wanted to help. But as I see, I should stop posting and let everyone else speak for themselves, since I prevent them from doing this all the time.

[Guest]

@Rainy

It's cool. I didn't mean to imply any censure of you. Keep right on speaking up.

[Guest]

Let me know if this does what you want:

http://neuron2.net/guest/DGIndexTest.zip

Don't forget to turn off Use Full Paths.

[SpAwN_gUy]

Let me know if this does what you want:
http://neuron2.net/guest/DGIndexTest.zip
this one works completely incorrect.. :( ..
as i've noticed it stores "nothing", when output=source
and just one "..\" when output != source (on the same drive)
and correctly saves full-path, when on different drives.

but modded 1.4.9 from Rainy (i've got this night) works great..
i've checked:
output=source (stores ".\", maybe that one is not needed..)
output - somewhere in the different folder.. (correctly stores lots of "..\") i.e.
VOB:
G:\DVDRiP\Bakumatsu\DVD1\01\VTS_02_1.VOB
.d2v:
G:\DVDRiP\Bakumatsu\DVD1\TEST\SOMEOTHER\02\off\ddd.d2v
.d2v internals:
DGIndexProjectFile16
1
..\..\..\..\01\VTS_02_1.VOB
tes.avs:
G:\DVDRiP\Bakumatsu\DVD1\TEST\SOMEOTHER\02\off\test.avs
DGDecode.dll:
G:\DVDRiP\Bakumatsu\DVD1\TEST\SOMEOTHER\02\off\DGDecode.dll
test.avs internals:
LoadPlugin("dgdecode.dll")
mpeg2source("ddd.d2v") shows nice picture ;)
and on a different drive.. (stores full-path)

maybe, neuron2, you could use part of theese sources?
http://home.no/rainy/dgindex149src.zip

[Guest]

I was not aware of the PathRelativePathTo() API call, and my attempt to write it from scratch was buggy. I have it working now using that API and it will be in the next beta release.

[SpAwN_gUy]

I was not aware of the PathRelativePathTo() API call, and my attempt to write it from scratch was buggy. I have it working now using that API and it will be in the next beta release.i haven't found it either... when i was searching for som realization..

and :thanks: :)

[Guest]

* When the Use Full Paths option is turned off, relative paths are used. This allows for the source files to be in a different directory than the D2V file. If they are in the same directory, the behavior is the same as before.

* In CLI mode, if a field order transition is detected, it is silently corrected.

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

[buzzqw]

* In CLI mode, if a field order transition is detected, it is silently corrected.

:thanks: !!!

BHH

[SpAwN_gUy]

Yes... Yes... Thanks alot..

Happy vacations to ya :) ..

[Atak_Snajpera]

Neuron could you check this M2ts sample?
http://rapidshare.com/files/59949596/Logo.zip.html

DGindex reports huge audio delay + demuxed AC3 is not playable

m2ts plays fine in MPC (FFDshow + Haali Media Splitter)

[Guest]

@Atak

I found and fixed the audio problem. But I noticed that video demuxing is not working for M2TS. So I'll fix that first before giving a new beta. Thanks for pointing this out.

[Guest]

OK, I got the demuxing working too. New beta tomorrow.

[Guest]

* Fixed two problems with .m2ts files: 1) audio on PRIVATE_STREAM_1 was not processed correctly, and 2) video demuxing was broken.

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

[Atak_Snajpera]

Thanks neuron2!!!

[sunbeam]

Since 1.5.0 beta 2, 3 and 4 there is no way for me to load .m2v and .mpv files into DGIndex.
I see them, load them and then they do not appear in the file list.
This on w2ksp4+ and pal 25fps files and all options tested.
Last working beta in this case is 1.5.0 beta 1 and of course 1.4.9 final.

[Guest]

@sunbeam

There are no changes in beta 2 that would explain that. Please post a link to an M2V file that will not load. Cut it to a manageable size using, for example, VirtualDub's hex editor (extract segment).

[sunbeam]

Hi neuron2,

no way for me to open a mpeg file at all in these 3 last releases. No one else with this problem on w2k around ?
Very small sample as attachment, no space available these days. Excuse me for that.

Greetings,
sunbeam

[Adub]

It would probably be best if you uploaded it to an external site like maxupload, yousendit, rapidshare, etc. Chances are you will get help faster, as the attachment has to be approved first before anyone can look at it.

first of all, what kind of "mpeg file" is it? Are we talking .vob, .mpg, .ts, etc.?

second, what error are you getting? what happens when you try to load a mpeg file into dgindex? can you seek correctly in the window?

[sunbeam]

@Merlin7777:
first of all, what kind of "mpeg file" is it? Are we talking .vob, .mpg, .ts, etc.?vob, m2v, m2p, mpg, all mpeg files.

second, what error are you getting? what happens when you try to load a mpeg file into dgindex? can you seek correctly in the window?
The error is, that they do not show up in the File List anymore.
I can see all of them, load them and then they do not appear in the file list as mentioned in post #59 (http://forum.doom9.org/showthread.php?p=1052627#post1052627)

[Guest]

Works fine for me with your test file. I have WinXP. I'll try with Win2000 at work on Monday.

Any Win2000 users want to try it?

[Rainy]

Drag & drop works, adding files using open dialog doesn't. Tested with different files on Windows 2000 Pro SP4; neither showed up in the list.

[Guest]

Wow, Rainy, that's pretty shocking. Both work on WinXP. The only thing I did was add a new file type to the open types string for the open dialog. Maybe I hit a string length limit for Win2000. I'll check it on Monday and fix it as needed. For now, use drag and drop.

EDIT: I also expanded the lpstrFile buffer. It turns out that it triggered an obscure Windows bug. See below.

[Guest]

It's an obscure Windows bug:

http://www.swiftgear.com/windows_bug.html

You can see that it is the same bug because if you select two or more files it works. I have it fixed and will release a new beta tonight.

[Guest]

* Fixed a problem with PSIP PID detection that could cause programs to be missed.

* Fixed a problem that resulted in an abort of processing with the message box popup "Force film mode not supported with frame repeats".

* Fixed a problem that caused the file open dialog to fail for some earlier versions of Windows. I didn't include this in the formal change list because it was exposed by a change in beta 2 (increased size of internal buffers!), so it is not present in version 1.4.9.

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

[Guest]

I have two question:

Can you add the ability to recognize DTS-HD MA?
You have an example in the stream i sent to you.

It's possible to add the ability to "Select the Main Movie" from a pool of m2ts (movie spread in different m2ts)?
Hey, better late than never, eh?

What is DTS-HD MA? Did you send me a stream?

I don't get the second question at all.

[sunbeam]

* Fixed a problem that caused the file open dialog to fail for some earlier versions of Windows.
Thank you for fixing this, neuron2.

[Inventive Software]

DTS-HD MA is the DTS-HD Master audio stream, sometimes found in, I think, BluRay discs.

[Yoshiyuki Blade]

Hmmm... for some reason, I get this error in virtualdub (and megui) unless I have "Use Full Paths" checked:

MPEG2Source: Could not open one of the input files.

Other than that, it works fine.

[guada2]

Can you add the ability to recognize DTS-HD MA?
It's possible to add the ability to "Select the Main Movie" from a pool of m2ts (movie spread in different m2ts)?

Really Interesting.... BUT

@neuron2
why to update "Dgavcdec" if Dgindex can do all thing (except avc)?

[Guest]

@guada2

I don't understand your question. How about PM me about it so as not to clutter up the thread? Thanks.

@Yoshiyuki

I need a lot more information than that. I need all your file locations, the DV2 file, and the AVS script. I also want you to try it manually and not through MEGUI, because I don't want to get involved with MEGUI.

[Yoshiyuki Blade]

@Yoshiyuki

I need a lot more information than that. I need all your file locations, the DV2 file, and the AVS script. I also want you to try it manually and not through MEGUI, because I don't want to get involved with MEGUI.

I'm not using megui for anything more than loading the avs script to see if it works, just like virtualdub. Both throw the same error, at the same line. It has to do with mpeg2source("C:\...\file.d2v").

Heres the first 4 lines of the d2v file generated without "Use Full Paths" checked (I'm encoding Cowboy Bebop btw):

DGIndexProjectFile16
2
..\DVD\Rips\COWBOY_BEBOP_VTS_06_PGC1\VTS_06_1.VOB
..\DVD\Rips\COWBOY_BEBOP_VTS_06_PGC1\VTS_06_2.VOB


The actual .d2v file is generated to "New Folder" on my desktop, which I specify in the mpeg2source() of the avs script.

When I manually replace the shortened directories with the full paths (C:\Documents and Settings\...etc), it works fine. So it seems to be a problem with the shortened directories.

[Guest]

@Yoshi

For your failing case, I need to know the exact path locations and names of the source file(s), the exact paths as written in the D2V file, the exact path location and name of the AVS script, and the contents of the script. Without all those things I cannot determine the problem. This is my second request for all these things. Thank you.

Everything is relative to the location of the D2V file, and the AVS script must be in the same directory as the D2V file.

[Yoshiyuki Blade]

@Yoshi

For your failing case, I need to know the exact path locations and names of the source file(s), the exact paths as written in the D2V file, the exact path location and name of the AVS script, and the contents of the script. Without all those things I cannot determine the problem. This is my second request for all these things. Thank you.

Everything is relative to the location of the D2V file, and the AVS script must be in the same directory as the D2V file.

Ok, here's how its set up right now:

Location of VOB files (source):

C:\Documents and Settings\User\Desktop\DVD\Rips\COWBOY_BEBOP_VTS_06_PGC1\VTS_06_1.VOB
C:\Documents and Settings\User\Desktop\DVD\Rips\COWBOY_BEBOP_VTS_06_PGC1\VTS_06_2.VOB
C:\Documents and Settings\User\Desktop\DVD\Rips\COWBOY_BEBOP_VTS_06_PGC1\VTS_06_0.IFO (I don't know if this file is necessary or not)

Location of d2v file:

C:\Documents and Settings\User\Desktop\New Folder\VTS_06_1.d2v

Path as written in the d2v:

..\DVD\Rips\COWBOY_BEBOP_VTS_06_PGC1\VTS_06_1.VOB
..\DVD\Rips\COWBOY_BEBOP_VTS_06_PGC1\VTS_06_2.VOB

Location of AVS script:

C:\Documents and Settings\User\Desktop\test.avs

Contents within the AVS script:

loadplugin("C:\Documents and Settings\User\Desktop\Encoding Tools\AVISynth Plugins\awarpsharp.dll")
loadplugin("C:\Documents and Settings\User\Desktop\Encoding Tools\AVISynth Plugins\colormatrix.dll")
loadplugin("C:\Documents and Settings\User\Desktop\Encoding Tools\AVISynth Plugins\dgdecode.dll")
loadplugin("C:\Documents and Settings\User\Desktop\Encoding Tools\AVISynth Plugins\fluxsmooth.dll")
loadplugin("C:\Documents and Settings\User\Desktop\Encoding Tools\AVISynth Plugins\sangnom.dll")
loadplugin("C:\Documents and Settings\User\Desktop\Encoding Tools\AVISynth Plugins\undot.dll")
loadplugin("C:\Documents and Settings\User\Desktop\Encoding Tools\AVISynth Plugins\unfilter.dll")
import("C:\Documents and Settings\User\Desktop\Encoding Tools\AVISynth Plugins\aaa.avs")

mpeg2source("C:\Documents and Settings\User\Desktop\New Folder\VTS_06_1.d2v")

colormatrix()
tweak(sat=1.2)
aaa(1280,720,100,100,1,2,chroma=true)
awarpsharp(depth=30)
fluxsmoothst(15,15)
temporalsoften(10,4,4,30,2)
undot()

EDIT: Oh, It does happen to work when the AVS file is in the same directory as the d2v. I guess using the relative paths instead of the full paths doesn't work too well for me. Is it absolutely necessary to have both the d2v and avs files in the same location? This whole thing was confusing to say the least. Man... I think having "Use Full Paths" off by default was what started this mess. Oh well, thanks for clarifying things.

[Guest]

Regarding the AVS script location having to be in the same directory as the D2V file, I agree that it is an undesirable limitation. I will see if it can be removed. I have also changed the default back to full paths for the next beta.

[Guest]

* Removed the limitation that the AVS and D2V files must be in the same directory when the Use Full Paths option is disabled. Thanks to Rainy for showing the way.

* Restored the default setting of the Use Full Paths option to enabled for backward compatibility with third-party applications. If you turn this off, you are expected to know what you are doing. :)

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

[Sharktooth]

thank you neruon2, this is going to get its way into megui autoupdate :)

[Guest]

thank you neruon2, this is going to get its way into megui autoupdate :) Maybe test it first. :)

[Yoshiyuki Blade]

Tested both with and without Use Full Paths with the setup I have a couple posts up. Both are workin great :). Thanks neuron2!

EDIT: Lots of smilies. I guess everyone is happy so far :P

[Guest]

Say thanks to Rainy too. He told me about PathCanonicalize().

[Rainy]

No need to mention. I'm just glad being able to contribute a little to this community. ;)

[Guest]

* Added checks for extra robustness against emulated audio start codes for MPEG audio in program streams. This fixes some known streams with emulated audio start codes.

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

Not real exciting, but we need some testing exposure to ensure I haven't broken anything.

[Sharktooth]

we'll have feedback soon, since i added this version to MeGUI autoupdate... ;)

[gonwk]

Hi folks,

Where can I find the "Older" versions downloads?

Thanks,
G!:)

[Guest]

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

If you are looking for older DVD2AVI binaries, then please use Google.

[gonwk]

Hi neuron2,:)

Thanks ... No, I just have a habit of keeping the older versions of a program that I like ... just in case the newer version acts up for me.

THANKS Again,

G!:)

[Guest]

With DGMPGDec, newer release versions are always better! :)

That's thanks to the extensive testing and feedback provided by the Doom9 forum members and third-party integrators.

Betas...well, that's why they're called betas.

[Sharktooth]

neuron2: why not integrating avc decoding into dgdecode.dll?

[guada2]

Can you add the ability to recognize DTS-HD MA?

why not integrating avc decoding into dgdecode.dll?

Why not a great update? ;)

Bye :)

[Guest]

The MPEG and AVC syntaxes are so different that the whole edifice would have to change to support both. I don't really see the advantage anyway.

I'm also in a low-energy state right now viz-a-viz development work. I'm trying to shuck off some of my other responsibilities (swimming instruction) that have gotten out of hand to give me time again for development.

[Guest]

* The infamous GOP warning popup has been consigned to the dustbin of history. The D2V Parse log now shows the open/closed status of the GOPs, so if you need to know if your opening GOP is open, look there.

* The Info dialog position is no longer pegged to the main DGIndex window. It can be independently positioned and its position is saved and restored via the INI file.

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

[gonwk]

Hi Neuron2,:)

THANKS for this GREAT Program. I took your advice and tossed away my last versions and using the 1.5.0beta8.

On the "Info Dialog" box ... I guess someone must have asked you to change it so it would not be pegged to the main DGIndex window ... I wonder why would that would have been a bother to someone ... so be it ...

I was wondering if you could go back to the "Square" look for the "Info Dialog" box ... since some of us folks still use the 15.4" screens and the Info Dialog box in it's long Rectangular look goes way below Visible area ... and I have to keep moving it up and down so I can see the "Status Box".

If this is an easy fix ... it would be appreciated.

THANKS,
G!:thanks:

[Guest]

I was wondering if you could go back to the "Square" look for the "Info Dialog" box ... since some of us folks still use the 15.4" screens and the Info Dialog box in it's long Rectangular look goes way below Visible area ... and I have to keep moving it up and down so I can see the "Status Box".
What's your screen resolution set to?

[burfadel]

There seems to be two more bugs with beta 8 that I didn't see earlier.

The first is when I was indexing decrypted vob files, the audio channels refused to appear. They were definately there and it worked fine in 1.4.9 (I ran it with that version too without problems). To quickly sort this issue, I deleted the dgindex.ini file, and then put the IDCT back to my preferred setting (I know it just changes a number in the index file for the decoder), and tried it again and it worked! it was with more than one dvd as well!

The second issue relates to the programme not actually showing upm but apprearing in the taskbar. Again when the ini file was deleted it came up fine!

I was also just wondering, does the mpeg2 decoder in the dgdecode file support instructions up to and including ssse3? (where instructions can be used)

[Guest]

The INI file format changed in beta 8. DGIndex is supposed to detect that and default the INI file but maybe that is broken. If you open DGIndex and then close it, everything should be OK thereafter. Let me know if that is not the case.

DGMPGDec is optimized only for SSE2.

[burfadel]

When I copied over the new version the ini file was renewed. The audio problem occurred after that. I did have change the default settings in the programme the first time and that seemed to stuff it up! The second issue was a bit stranger, the programme was locked in the taskbar, it wouldn't maximise. I ended the process, tried it a few times with the same result. After deleting the INI file again it worked.

[Guest]

I don't understand. Are you having a problem now or not?

[burfadel]

Seems to be fine now! I don't know why I had to delete it twice, but I can't seem to recreate the problem...?!

[Kurtnoise]

Tiny request: replace the [ and ] in the command line stuff by something more usable (like " " or remove it completely). Not for me really but somebody report a bug for MeGUI. However, it was a path name issue (There was already a [....]).

edit: forgot to check the doc...there is already a command for that. Sorry.

[Guest]

* An option was added to control how HD videos are displayed. You can now shrink by half (the previous behavior) or you can view any quadrant of the video. This allows the interlace structure of HD videos to be inspected.

* The font size of the Info dialog was reduced so that it all stays visible with the new vertical arrangement.

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

The INI file was changed again, so open DGIndex and then close it the first time you use it.

[Guest]

Sorry about the quick update, but the fix for emulated audio headers was rejecting some valid headers. I'm pretty sure everything is fully correct now.

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

[Guest]

we'll have feedback soon, since i added this version to MeGUI autoupdate... ;) You better get beta 10, because 7-9 may reject valid MPEG audio in program streams.

[Guest]

Please re-download beta 10. A bad build was uploaded.

[burfadel]

You better get beta 10, because 7-9 may reject valid MPEG audio in program streams.

ah ok! that explains the problem I had earlier :)

[Sharktooth]

You better get beta 10, because 7-9 may reject valid MPEG audio in program streams.
ok...

[zurv]

on beta 10, 00011.m2ts for spiderman3 (which plays fine in zoom (+cccp))
but, DGindex says "no video sequence header found!"

It also works in DSmux (Haali), but not mkvmerge. *shrug*

ideas?

thanks

[Guest]

Is it MPEG2 video?

[zurv]

i was about to edit the post.. i assumed it was because the first track worked and was mpeg2.. but i just looked again and the movie itself is avc - didn't expect to see them mix formats :)

hrmm.. now what to do with avc :)
at worst directshowsource would work.. but that feels dirty :)

I guess demuxing the audio would be the big thing...hrmmm

[Guest]

You can try DGAVCDec for the AVC portion.

[burfadel]

You can try DGAVCDec for the AVC portion.

Are you planning to merge Dgmpgdec and DGavcdec in the future? that would resolve people using the wrong one and being confused with mixed tracks etc :) or even just the need to use two different programmes on mixed tracks!

Just thought it would streamline things a bit :), seeing the programme is of similar nature. I know it kind of contradicts the Dgmpegdec name, but technically avc is mpeg4, so the name still works!

[Guest]

See posts 91 and 93 of this thread.

[jeffy]

neuron2, may I please ask, does this really dering (quant=0)?
BlindPP(quant=0,cpu=0,cpu2="ooooxx")
http://forum.doom9.org/showthread.php?p=675252#post675252

Thank you.

[Guest]

I don't know because I didn't write that filter. Generate a clip with and without it in your script and then do a Subtract() to see if there is a difference. You may need Levels() after Subtract to magnify the differences. I use the Levels filter in VirtualDub as it is easier.

[GR]

Thx neuron2
beside that would be wonderful if dgindex could let me to set the begin & end not only on the key frame but also on each frame -v-
I need to clear some tvrip's advertisement(.ts or .m2ts) completely for save certain fullest scene
it just a problem now - -b

[Guest]

* Fixed a problem that caused DGIndex to miss some audio streams. For example, if AC3 substream 0x80 was present, and MPA stream 0xC0 was present, both would be viewed as Track 1, and only the first one encountered would be detected. The concept of track number is removed (as it is a DVD-specific construct), and it is replaced with the concept of audio id. See the users manual for details.

* For MPEG audio streams, the Info dialog now shows full information: audio id, layer, number of channels, sampling rate, and bitrate. This information is also included in the filename of demuxed MPEG audio streams.

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

This was a major redesign of audio processing so please beat up on anything audio related and try to break it.

To avoid possible hassles, delete your DGIndex.ini file before running this new version.

[Sharc]

DGIndex returns BT.709 as colorimetry info for unflagged mpeg2 streams. Is there a reason for this? Shouldn't it better return "unspecified" - or similar - for unflagged streams?
Sorry if this has been already discussed.

[kumi]

On the point that Sharc raises, could I request that you allow users to override what colorimetry is assumed by DGindex (and passed via hints) when the sequence display extension fields are absent? At present, when fed SD MPEG-2 input, DGindex assumes Rec.709, but Hank315 believes that the default SD MPEG-2 matrix might in fact be Rec.601. See here (http://forum.doom9.org/showthread.php?p=1061536#post1061536).


Thanks for the new beta :)

[buzzqw]

@neuron2

do you know any affidable command line application able to extract audio track pid/id ?

i used bbsummary, but this utility not extract 80,81,C0 info ...

on command line i usually specify -TN=1,2 for extracting the first and second tracks... but with 150b11 dgindex fails extracting tracks even if i specify 80,81...

this is the old command line
c:\dgindex.exe -FO=0 -OM=1 -TN=1 -YR=2 -AIF=[c:\_aaa.vob] -OF=[C:\movie] -exit -minimize

and this is the vob ( 7.81 mb) http://www.64k.it/andres/data/a/_aaa.vob

how i can translate (or detect TN values) in new command line ?

thanks!

BHH

[G_M_C]

On the point that Sharc raises, could I request that you allow users to override what colorimetry is assumed by DGindex (and passed via hints) when the sequence display extension fields are absent? At present, when fed SD MPEG-2 input, DGindex assumes Rec.709, but Hank315 believes that the default SD MPEG-2 matrix might in fact be Rec.601. See here (http://forum.doom9.org/showthread.php?p=1061536#post1061536).


Thanks for the new beta :)

If i remenber correctly the MPEG2 has Rec.709 as the standard (default) colormetry, as part of the MPEG2-standards. So the fact that DGIndex gives 709 as defeult, is a simple (and correct) consequece of the MPEG2 standard.

If your unflagged stream is in fact Rec.601, than basically, the stream isn't muxed/made properly (is should have been flagged !).

[Guest]

@how i can translate (or detect TN values) in new command line? The audio id's work like this:

PVA and transport: one track always 0

all others:
AC3: 80-87
DTS: 88-8f
PCM: a0-a7
MPA: c0-c7

You could ask for the first two of each category:

TN=80,81,88,89,a0,a1,c0,c1

Or you could just demux them all.

The problem is that the concept of track number is DVD specific but DGMPGDec wants to handle all stream types. You might suggest to number them by the order they are encountered in the source. But that's indeterministic because if you start the project at different points you can change the order in which the streams are encountered.

But obviously I want to support third party applications, so can you take the above information into account and tell me what you need to support your application? Maybe I could make a command line option that just creates the audio stream list (as displayed in the Info dialog) and then exits.

[buzzqw]

Maybe I could make a command line option that just creates the audio stream list (as displayed in the Info dialog) and then exits

that's would be enough!

when i know the audio id (80,81,88,89,a0,a1,c0,c1) is very easy to read a "info.dump" created by dgindex

i my suggest, if possibile to include even more info in this "info" file (maybe all those in info panel, if isn't needed all file parsing)

thanks Neuron2!

BHH

[Guest]

Please redownload beta 11. There was a bug in the CLI operation. With the new one, this works for your sample VOB:

dgindex.exe -FO=0 -OM=1 -TN=80,c1 -YR=2 -AIF=[_aaa.vob] -OF=[movie] -exit -minimize

The problem with the log idea is how far do I parse into the file looking for audio streams? I'll do some experiments with some reasonable size.

Why don't you demux them all and parse the resulting file names? :)

[buzzqw]

The problem with the log idea is how far do I parse into the file looking for audio streams? I'll do some experiments with some reasonable size.

in bbsummary i analyze the first 10000 frames, and it's a matter of two seconds

Why don't you demux them all and parse the resulting file names?

well.. i must admit that wont be a problem... just to search for 80 , 81 , c1 in file names...

BHH

[Guest]

Maybe we can map the bbsummary info to audio_ids. Can you post typical bbsummary output for the audio?

[buzzqw]

bbsummary on _aaa.vob (same sample posted before)

bbSummary - based on BBINFO version 1.9

File C:\Programmi\PureBasic402\AutoMKV\test\_aaa.vob is an MPEG-2 Program Stream

Summary:

MPEG Packs = 4000
System headers = 22
Private AC3 Audio Stream 1 packets = 296, total bytes = 597029
AC3 Audio Stream 0 packets = 296, total bytes = 0
Padding Stream packets = 21, total bytes = 12383
Private Stream 2 packets = 44, total bytes = 43956
MPEG Audio Stream 1 packets = 98, total bytes = 197957
Video Stream 0 packets = 3584, total bytes = 7244864

on a TS files
bbSummary - based on BBINFO version 1.9

File C:\Programmi\PureBasic402\AutoMKV\test\_aaa.ts is an MPEG-2 Transport Stream

Summary:

MPEG Transport Packets = 10000
PID 0000, Program Association Table packets = 3, total bytes = 552
PID 001F, Other packets = 1, total bytes = 184
PID 0113, Other packets = 9, total bytes = 1656
PID 0991, Video Stream 0 packets = 8548, total bytes = 1525328
PID 0992, MPEG Audio Stream 0 packets = 719, total bytes = 129930
PID 0993, MPEG Audio Stream 0 packets = 719, total bytes = 129930


other TS file
bbSummary - based on BBINFO version 1.9

File C:\Programmi\PureBasic402\AutoMKV\test\ateme.luxe.tv.hd.eutelsat.w3a.12.jun.2007.whole.ts.sample.ts is an MPEG-2 Transport Stream

Summary:

MPEG Transport Packets = 10000
PID 0000, Program Association Table packets = 25, total bytes = 4600
PID 0011, Other packets = 2, total bytes = 368
PID 0012, Other packets = 15, total bytes = 2760
PID 0020, Other packets = 24, total bytes = 4416
PID 0065, Video Stream 0 packets = 9391, total bytes = 1720842
PID 0100, MPEG Audio Stream 0 packets = 271, total bytes = 49204
PID 0101, MPEG Audio Stream 0 packets = 271, total bytes = 49204

on other vob file


bbSummary - based on BBINFO version 1.9

File C:\Programmi\PureBasic402\AutoMKV\test\_telecine.vob is an MPEG-2 Program Stream

Summary:

MPEG Packs = 10000
System headers = 34
Private AC3 Audio Stream 1 packets = 1855, total bytes = 3740719
AC3 Audio Stream 0 packets = 415, total bytes = 0
AC3 Audio Stream 1 packets = 415, total bytes = 0
AC3 Audio Stream 3 packets = 209, total bytes = 0
DTS Audio Stream 2 packets = 816, total bytes = 0
Padding Stream packets = 34, total bytes = 39246
Private Stream 2 packets = 68, total bytes = 67932
Video Stream 0 packets = 8110, total bytes = 16382960

last vob

bbSummary - based on BBINFO version 1.9

File C:\Programmi\PureBasic402\AutoMKV\test\movimentato.vob is an MPEG-2 Program Stream

Summary:

MPEG Packs = 4840
System headers = 22
Private AC3 Audio Stream 1 packets = 273, total bytes = 548625
AC3 Audio Stream 0 packets = 273, total bytes = 0
Padding Stream packets = 24, total bytes = 29997
Private Stream 2 packets = 44, total bytes = 43956
Video Stream 0 packets = 4544, total bytes = 9175284

BHH

[Guest]

I'll implement the log file, as there is not enough information there to map to audio id.

[Sharc]

If i remenber correctly the MPEG2 has Rec.709 as the standard (default) colormetry, as part of the MPEG2-standards. So the fact that DGIndex gives 709 as defeult, is a simple (and correct) consequece of the MPEG2 standard.

If your unflagged stream is in fact Rec.601, than basically, the stream isn't muxed/made properly (is should have been flagged !).
The background is that there were quite some controversial discussions on standards and on what (unflagged) DVDs (using mpeg2) comply with, and what (most) players do expect, in this thread:
http://forum.doom9.org/showthread.php?p=1061205#post1061205.
I don't know what are opinions and what are facts, and how much room for the interpretation of standards is left to the studios and player/chipset manufacturers. Still it appears that many SD players expect 601.

[kumi]

If your unflagged stream is in fact Rec.601, than basically, the stream isn't muxed/made properly (is should have been flagged !).
Exactly, that's what I thought, too. But there is some good evidence that Rec.601 IS the default, and not Rec.709. And the fact that many (most?) SD players assume 601 is icing on the cake.

[Guest]

The later spec says that if it is unspecified then the colorimetry used is "determined by the application". I could just report "unspecified" but I have to use something for RGB upconversion. Do you want it as an option?

[Guest]

I have the log file working and will release a beta tonight.

Whenever the Info dialog is closed, either manually or automatically by DGIndex, the Info dialog contents are written to a file. For CLI operation, if the new -preview parameter is given, the first 100 frames will be decoded and then the Info dialog will be killed, causing the log file to be generated. Thus, the way to get a silent dump of the data is this:

dgindex -AIF=[zdf.mpeg] -OF=[zdf] -preview -minimize -exit

The output file looks like this:

Stream Type: MPEG2 Program
Profile: main@main
Frame Size: 720x576
Aspect Ratio: 4:3
Frame Rate: 25.000000 fps
Video Type: PAL
Frame Type: Interlaced
Colorimetry: BT.709
Frame Structure: Frame
Field Order: Top
Coded Number: 99
Playback Number: 99
Frame Repeats: 0
Field Repeats: 0
VOB ID:
Cell ID:
Bitrate: 5.016 Mbps
Bitrate (Avg): 5.738 Mbps
Audio Stream: 80: AC3 2/0 384
Audio Stream: c0: MPA L2 2ch 48 256
Audio Stream: c1: MPA L2 mono 48 128
Timestamp: 0:00:05
Elapsed: 0:00:03
Remain: 0:00:10
FPS: 24.96
Info:

[buzzqw]

Excellent!

thanks Neuron2!

BHH

[kumi]

but I have to use something for RGB upconversion. Do you want it as an option?
Yes, but only if it's possible to get the user's choice of default matrix passed into the stream hints. That's the reason for my request, really.

Currently, the 2nd line of this script is a no-op:
mpeg2source("foo.d2v", info=3) #foo.m2v is a MPEG2 SD clip w/ no sequence display extension fields
colormatrix(mode="Rec.601->Rec.709", hints=true)

I wish DGdecode would hint my source with Rec.601 coefficients. Can that be done? Thanks for listening :)

[Sharc]

I second this.
The user's choice should only kick in when the source has no sequence display extension.

If the source comes with with sequence display extension I think it should override the user's choice.

[kumi]

If the source comes with with sequence display extension I think it should override the user's choice.
I agree.

[Guest]

* Whenever the Info dialog is closed, a log file is created that contains the same information. This may be invoked by the CLI to silently query the nature of the input file. Please see the users manual for details.

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

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

I'll wait and see who cries foul about the second bullet item. I'd prefer not to make an option for it.

[kumi]

Thanks a lot! Tested and working A-OK.

I wonder if you might also consider adding an "icing on the cake": how about some sort of indicator in the Info|Colorimetry area, to show when DGindex is applying it's own matrix coefficients? Perhaps something simple, like displaying *BT.470-2 B,G instead of BT.470-2 B,G.

[Boulder]

I'll wait and see who cries foul about the second bullet item. I'd prefer not to make an option for it.I'll try this later today when I get home from work. All my DVB captures show 'unknown' for colorimetry in DGIndex, but I must not use ColorMatrix(mode="rec.601->rec.709") when encoding with CCE or HC. If I use that line, the colors in the resulting video are different from the original video when looking in VDub. I'll need to check whether the difference exists when playing the video on the standalone player.

[buzzqw]

http://www.64k.it/andres/data/a/ateme.luxe.tv.hd.eutelsat.w3a.12.jun.2007.whole.ts.sample.ts (7 mb)

dgindex.exe -preview -OF=[aaa] -AIF=[C:\ateme.luxe.tv.hd.eutelsat.w3a.12.jun.2007
.whole.ts.sample.ts] -minimize -exit

in this case i must know the pid ? since dgindex prompt "No data. Check your PIDS"

... i think i will continue to use bbsummary to extract information and then use dgindex with right command line :o

thanks!

BHH

[G_M_C]

I'll try this later today when I get home from work. All my DVB captures show 'unknown' for colorimetry in DGIndex, but I must not use ColorMatrix(mode="rec.601->rec.709") when encoding with CCE or HC. If I use that line, the colors in the resulting video are different from the original video when looking in VDub. I'll need to check whether the difference exists when playing the video on the standalone player.

Hmmm it would seem that is allready in rec.709 than ?

A theoretical question though;
Is it possible to detect what colormetry is used, simply by scanning the stream ?

[SeeMoreDigital]

;)http://www.64k.it/andres/data/a/ateme.luxe.tv.hd.eutelsat.w3a.12.jun.2007.whole.ts.sample.ts (7 mb)

dgindex.exe -preview -OF=[aaa] -AIF=[C:\ateme.luxe.tv.hd.eutelsat.w3a.12.jun.2007
.whole.ts.sample.ts] -minimize -exit

in this case i must know the pid ? since dgindex prompt "No data. Check your PIDS"

... i think i will continue to use bbsummary to extract information and then use dgindex with right command line

thanks!

BHHHi Buzz,

The sample you provided contains MPEG-4 AVC video and not MPEG-2 video (along with 3No MP2 audio tracks) :o


Cheers

[buzzqw]

:stupid:

DOH!!!

thanks and sorry!!!

BHH

[Boulder]

Hmmm it would seem that is allready in rec.709 than ?Exactly. Which is why I'm not sure if unknown colorimetry really means Rec.601:confused:

[buzzqw]

this sample has problem

the "info" report only 1 audio track but pid detection reveal 2 audio
and dgindex is able to extract the second track

http://www.64k.it/andres/data/a/film_Ac3_5_2.ts (37mb)

is it a stream problem ?

BHH

[Guest]

@buzzqw

It's currently a limitation for transport streams that only the streams whose PIDs are set are processed. Item 16 of the Development List sticky:

"16) Process multiple audio streams at once for transport streams (as is currently done for program streams)."

As a workaround, you can use a CLI table parser to find the audio PIDs (I have one based on the PID detection code in DGIndex), and then retrieve info for each PID in turn.

[Guest]

I wonder if you might also consider adding an "icing on the cake": how about some sort of indicator in the Info|Colorimetry area, to show when DGindex is applying it's own matrix coefficients? Perhaps something simple, like displaying *BT.470-2 B,G instead of BT.470-2 B,G. Will do.

[buzzqw]

@Neuron2
As a workaround, you can use a CLI table parser to find the audio PIDs (I have one based on the PID detection code in DGIndex), and then retrieve info for each PID in turn.

i used bbsummary... :)

but if it possibile to add that cli capability to dgindex is even better (or you want to spare your cli app..)

thanks!

BHH

[Guest]

@buzzqw

I'll do something so that no other external CLI app is needed.

@kumi

Please redownload beta 12. I added your * idea (but at the end of the string).

[kumi]

Neuron2: thanks again! :D

[drmpeg]

this sample has problem

the "info" report only 1 audio track but pid detection reveal 2 audio
and dgindex is able to extract the second track

http://www.64k.it/andres/data/a/film_Ac3_5_2.ts (37mb)

is it a stream problem ?

BHH
The stream is a little weird in that the PMT has three audio entries. The third entry has a descriptor for English language, but the PID is the same as audio stream 2 (in German).

The video stream sets progressive_frame correctly. 1 during the movie and 0 during interlaced portions of the commercials.

I also liked the commercial at the end of the clip. ;)

Ron

[Guest]

We don't get commercials like that here in the US. :(

[Sharc]

http://neuron2.net/dgmpgdec/dgmpgdec150b12.zip[/url]

I'll wait and see who cries foul about the second bullet item. I'd prefer not to make an option for it.

Thank you neuron 2.
Yes, let's wait for users' experience with the new defaults.

[Underground78]

Hi,

I sometimes have some ts files with strange audio tracks : for example in this sample (http://michel93.free.fr/data.mpg), it seems to have this tracks :

http://pix.nofrag.com/c/7/1/c9b73dcf36bbd901745084c0be94f.jpg

but the tracks number 150 and 151 can't be demuxed (the file is not created) ... However track n°151 is the default one so it matters when the CLI is used ...

Is there a way to know which audio tracks really exist and to avoid an invalid track being selected as the default one ?

[SeeMoreDigital]

Quite a while ago somebody sent me a std-def .TS sample complete with "TeleText" data for testing with my Ziova CS505 hardware player.

I've just run it thru' DGIndex Beta 12 and a whole host of PID's appeared: -

http://img136.imageshack.us/img136/6219/pidlayouttl8.jpg

But sadly the audio stream was not detected: -

http://img136.imageshack.us/img136/350/streaminfobb2.jpg

Please let me know if you require the 20.2MB sample

[Guest]

Please let me know if you require the 20.2MB sample Yes, I require it. Don't I ALWAYS ask for the stream? :devil:

It's probably the same problem as described in the following post, but I'd like to see it to be sure. You can just set the PID for the audio to 0x79 and it should work, if it is the same problem. Make sure Audio/Output Method is set to Demux all tracks.

[Guest]

Is there a way to know which audio tracks really exist and to avoid an invalid track being selected as the default one ? If the PAT/PMT says it is there I use it. But your stream turned up a bug that makes it work for your stream. When finding initial PIDs with PAT/PMT, the last audio channel was being used instead of the first. When I fixed that it now finds the first MPA stream, which is fine in this stream. It will be in the next beta.

[SeeMoreDigital]

Yes, I require it. Don't I ALWAYS ask for the stream? :devil:LOL :D

Here you go best mate: -

http://www.mytempdir.com/2058091


Cheers

[Guest]

Same problem: last audio used instead of first, and the last one is not really there. Just set the PID for the MPA stream.

[Underground78]

If the PAT/PMT says it is there I use it. But your stream turned up a bug that makes it work for your stream. When finding initial PIDs with PAT/PMT, the last audio channel was being used instead of the first. When I fixed that it now finds the first MPA stream, which is fine in this stream. It will be in the next beta.

Ok, thank you !

[Guest]

* Fixed problem whereby the automatic PID setting for transport streams used the last audio stream encountered instead of the first.

* Added an MRU list to the File menu.

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

This version also contains a new feature. The first person to find it gets a brownie point. Then I will add it to the change list. Just for some fun!

[Terranigma]

This version also contains a new feature. The first person to find it gets a brownie point. Then I will add it to the change list. Just for some fun!

Thanks for the update. I should find it in no time (or so i hope :p).

---
The ability to quickly navigate to a previously opened file (i.e., bookmarking) with Recent file list?

[Guest]

That is correct. Your brownie point:

http://neuron2.net/misc/brownie.jpg

[Inventive Software]

Mmm, tasty! :D

[Guest]

Hands off! That belongs to Terranigma.

[Inventive Software]

My bad. :(

[Terranigma]

Hands off! That belongs to Terranigma.

Haha, thanks for the treat (and this wonderful update). :)

[Yoshiyuki Blade]

Just a bit curious, do you make any changes to dgdecode.dll for the betas? I replace them each time I check out a new build just in case, but if I don't have to, that'll save me a good 2 seconds of time :).

[Guest]

They are always changed at a minimum to have the right beta version number. I recommend that you always upgrade all components.

[Inventive Software]

Question for Donald, or anybody who could help. I'm having trouble with noticable interlacing lines on the picture, and I have no idea how to deal with them. Encoding it progressive, it'll look horrible, encoding it interlaced I'm not willing to do unless absolutely necessarily. Sample: http://rapidshare.com/files/70550171/FieldSample.zip. Please assist! :)

[Rainy]

DGIndex doesn't seem to recognize the end of your file; the navigation controls remain disabled, when the timeline end is reached and nothing happens. I have to hit escape to return to the initial state.

[Guest]

I had to cut some orphaned data at the end to keep DGIndex from doing that. Bad cut.

Um, this is pure interlaced video (not film). You either have to encode it as interlaced, or deinterlace it.

[Boulder]

Don,

could you please check what is causing the problems when using SetMTMode(2) with tsp's Avisynth build that has multithreading support?

http://forum.doom9.org/showthread.php?p=1065701#post1065701

[SeeMoreDigital]

Sadly the detail in many NTSC TV shows often get completely destroyed when converted to PAL. Especially if the original NTSC source was interlaced to begin with :(

[elfurbe]

I'm not sure if this is specific to the beta or not. I noticed a "new to me" feature, not sure when it showed up, Tools->Analyze Sync. I just decoded a vobset with multiple audio streams, all of which show delays of 0 in their output filenames, but when I ran track 1 through the Analyze Sync tool, the output log file showed delay on every entry, except the first. I'm not sure what to make of that, so I'm wondering a couple things.

1: Does the analyze sync tool do what I think it does or am I misunderstanding? It seems to do a frame-by-frame check of audio sync to video. Is that accurate?

2: If that's what it's doing and it's finding delay, should I/how would I use this info to get proper sync with my video and audio after encoding to a different format? Average all the reported delays perhaps?

[Guest]

could you please check what is causing the problems when using SetMTMode(2) with tsp's Avisynth build that has multithreading support?[/url] I don't have a multi-core machine.

[Guest]

I'm not sure if this is specific to the beta or not. I noticed a "new to me" feature, not sure when it showed up, Tools->Analyze Sync. I just decoded a vobset with multiple audio streams, all of which show delays of 0 in their output filenames, but when I ran track 1 through the Analyze Sync tool, the output log file showed delay on every entry, except the first. I'm not sure what to make of that, so I'm wondering a couple things. When you see a new feature, the first thing to do is to read the users manual:

"This tool allows the user to create a log of the audio delay values that would be generated if the project were to be started at all the I frames of the stream. ... Note that for a displayed delay value to be usable and correct, you must start your project at the corresponding I frame."

1: Does the analyze sync tool do what I think it does or am I misunderstanding? It seems to do a frame-by-frame check of audio sync to video. Is that accurate? See above.

[elfurbe]

Many apologies. RTFM indeed. Thanks anyway!

[remiche]

Number 13 is fatal without doubt-that!

I riping 3 DVDs for 6min!!!
Log file say: no find audio!
HoHoHooo...
I install 1.45 Stable... and all OK :) (successful RIPs OK)

[Guest]

Number 13 is fatal without doubt-that!

I riping 3 DVDs for 6min!!!
Log file say: no find audio!
HoHoHooo...
I install 1.45 Stable... and all OK :) (successful RIPs OK) Please post a link to a portion of the source stream that fails. My guess is that you aren't doing something right.

[ilhyfe]

@neuron2:

I have a feature request:

Sometimes it would be nice if the information window wouldn't close it self so that I can see the timeline while I'm scrolling through the video. Just like dvd2avi.

[squid_80]

Looong standing bug to report in dgdecode: If there's a problem opening the avisynth script (for example the source mpeg file has been moved/deleted or a version mismatch is reported) and an error is thrown, the .d2v file isn't closed and can't be deleted or modified until the host application is closed.

[Guest]

Sometimes it would be nice if the information window wouldn't close it self so that I can see the timeline while I'm scrolling through the video. Just like dvd2avi. You can set single step and then step through with the info window. The problem for jumping around is that some of the fields are not valid unless decoding linearly.

[Guest]

Looong standing bug to report in dgdecode: If there's a problem opening the avisynth script (for example the source mpeg file has been moved/deleted or a version mismatch is reported) and an error is thrown, the .d2v file isn't closed and can't be deleted or modified until the host application is closed.
When I close the D2V and then call ThrowError(), Avisynth takes a system exception. I'd have to trace through Avisynth to find out why and I'm not motivated to do that right now.

[squid_80]

If I had to guess, I'd say the code in CMPEG2Decoder::Close() is wrong:void CMPEG2Decoder::Close()
{
int i;
CMPEG2Decoder* in = this;

if (in != NULL)
fclose(in->VF_File);

Of course in is not going to be NULL. I think the check should be if (VF_File != NULL) and NULL should be assigned to VF_File after it is fclosed.

[squid_80]

Actually now that I'm back from voting and have some time to sit down, I see a better way - change CMPEG2Decoder::Close to CMPEG2Decoder::~CMPEG2Decoder. This requires a few other changes, I've zipped the modified source code files and they're at http://216.75.63.164/andrew/dgdecode_mods.zip (Based on 1.4.9)

[buzzqw]

@squid_80
while you are in modifying.. how about ifo parsing (of decrypted dvd) with pgc selection for demuxing.. ? :thanks:

(i hope Neuron2 don't be angry)

BHH

[squid_80]

I don't know the first thing about IFO parsing.

[buzzqw]

something could be in vstrip source or pgcdemux source

(i want help.. but don't know a single fprint of c/c++)

BHH

[Guest]

No IFO parsing. It's been discussed before.

[Guest]

I think the check should be if (VF_File != NULL) and NULL should be assigned to VF_File after it is fclosed. I did it that way. Thanks.

[ilhyfe]

You can set single step and then step through with the info window. The problem for jumping around is that some of the fields are not valid unless decoding linearly.

I tried. but when I scroll through the video the info window closes itself.

EDIT: I don't need many information, a timestamp only would e enough.

[Guest]

You didn't follow me.

Position on the timeline to the area of interest. Then set Options/Playback Speed to Single Step. Then hit F6 to play. Now you use the > button to single step. The Info window will stay open.

[ilhyfe]

You didn't follow me.

Position on the timeline to the area of interest. Then set Options/Playback Speed to Single Step. Then hit F6 to play. Now you use the > button to single step. The Info window will stay open.

Hm yeah but I don't want to use the single step function. I want to scroll fast through the video to time xyz.

[Zep]

Did I find a bug? (1.5.0 beta 13)

I capped a HDTV show in 6 segments stopping recording at each ad break etc... then editing lead in and lead out ads. basic stuff.

if I choose all 6 edited final segments in DGindex then output to 1 d2v file it is 59997 frames.

mpeg2source("D:\wholeshow.d2v")

and the audio is in perfect sync.




If I index each segment separately then do this

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)

OR

If I encode each section to xvid first pass then merge the first pass video.pass files then run a second pass well.... both of these ways give me exactly 60006 frames and the audio is off more and more as the encode reaches the end.

in fact the audio is BEHIND by just about 320ms (give or take)
in this example as the audio is shorter in each segment by 1 or 2 frames than the video. (about 41ms per frame the audio falls behind and it adds up more and more over the length of the encode as more segments are hit)

is there something I am missing as to why the video frame count would be so different? They should match right? Can this be fixed?

[Guest]

@Zep

If the frame count was less when doing them separately, I could understand it. But you say it is more that way.

You won't like this answer, but you're going to have to give me at least two sections so that I can duplicate your result.

[Guest]

Hm yeah but I don't want to use the single step function. I want to scroll fast through the video to time xyz. You can't always get what you want. I'm sure that with a little creativity, perhaps with the F6 key and different playback speeds, you can find your desired location without too much difficulty.

[ilhyfe]

You can't always get what you want.

I know but since xmas is near and it worked fine in *old* dvd2avi it should be possible to add :P

[Zep]

@Zep

If the frame count was less when doing them separately, I could understand it. But you say it is more that way.


You won't like this answer, but you're going to have to give me at least two sections so that I can duplicate your result.

Ok I have been doing a ton of tests and I am narrowing it down. I no longer think DGindex
is adding frames but only subtracting frames like you said you thought it would do. After a
avisynth fresh install I now only see LESS frames when I do this

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")

video=v1+v2+v3+v4+v5+v6

video=video.Selecteven()
video=video.Crop(8,8,-8,-8)
video=video.Decimate(5)
return(video)

compared to this

mpeg2source("D:\wholeshow.d2v")
Selecteven()
Crop(8,8,-8,-8)
Decimate(5)

same test chunks the first way returns 2 less frames. I have now done it over a dozen times
and always returns 2 less frames. I am curious as to why less frames are returned
and why above you thought that would be? it makes me wonder WHERE the 2 frames are
cut from. (note I use projextx and VRD and edit at the GOP level) If at the very end then no big
deal but if somewhere in the middle then the audio would be about 84ms longer than the video
after it hits those 2 frame cuts)


Anyway, I am still seeing 9 frames added to the final encode. So I will continue to drive on
as it now appears Vdub/Xvid are adding frames and not sticking to what DGindex ---> avs
is sending to them. (I did a fresh install of both Vdub and Xvid also and it didn't help)


I'll post here what I do find in hopes it helps others.


Thanks

[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?

[damjang]

Oh, I watch the video more acurately and found some glitches. And here is the sample (http://www.zshare.net/download/65495003728202/) (cut with projectX)

[LordIntruder]

Hi,


Some months ago I ripped a movie, PAL and progressive, around 1h50 long. From 1h40 to 1h45 suddenly the sequence was interlaced and then the last 5 minutes progressive like the rest of the movie.

This week I encountered the exact same problem with an old serie. In the middle of the episode, around 10 min, suddenly everything is interlaced.

Is there a way with DGIndex that could tell us automatically that the video has both progressive and interlaced content? Because as usual, I always see that AFTER the encoding ;) Grrr... ;)

I thought that maybe when we save the project (F5), at the end in the log file, we could have a report saying:

- Both progressive and interlaced

So that you know you have to use a deinterlacer. We already have such a report in the log, but I tried with my episode and it only report progressive and no interlaced because the final frames are not.

Is it possible to implement that?

At this stage the only way I know is to watch closely all the video and see if a sequence is not interlaced. As I'm rather lazy, I would enjoy an automatic way. :)

Unless there is already a tool that allow to do that?


Thanks :)

[SCIF]

neuron2, check your PM, please. I have a question about translate dgindexmanual.html

[signal]

@LordIntruder

I know it's PAL but when you previewed or played the material wouldn't the "Video Type" in the information window still switch to % Film if interlacing showed up?

[Boulder]

AFAIK, DGIndex uses the flags of the stream to determine progressive/interlaced, it doesn't do any in-depth analysis. Most PAL DVDs are simply flagged as interlaced and the flag doesn't change during the video.

[LordIntruder]

I know it's PAL but when you previewed or played the material wouldn't the "Video Type" in the information window still switch to % Film if interlacing showed up?

Hi,

Yes if you preview at the correct sequence, you have to press "[" and start preview, here the information change from progressive to interlaced, you are right. But if you know that, this is because you already made a search and this is what I want to avoid.

In my case, I open the VOB, I press the Preview button, DGindex does not report me that in the middle of the movie/episode a small sequence is interlaced, I presume it can't know it. It has to go through each frame to determine that.

My guess is when we save the project, DGindex looks at each frame (I suppose it works like that) and knows that some frames are not progressive like the others but interlaced, so that it could reports it in the final log. But my guess may be completely wrong.

If that is impossible while saving the project, maybe a new option similar to preview could be implemented that would do an in-depth analysis and making reports. Because doing a preview at maximum speed, on my machine (4200+) an episode of 50min needs 15min to be fully previewed. Almost half an hour for a 100min movie. I can't stay in front of my machine so long, looking at the information tab without moving my eyes for an hypothetical change here. We could have an option doing preview at maximum speed and get an automatic report log that would tell us:

"oh oh, some progressive and interlaced frames detected". And we could also have the start of those frames.

Say a movie has 150000 frames. Only the changing frame state could be reported

- frame 1: progressive
- frame 58000: interlaced
- frame 65001: progressive
- frame 150000: progressive

So you conclude that between 58000 and 65000 it is interlaced.

You can then examine with your rip program (Gknot, etc...) or directly VirtualDub via an avs those frames.

A friend of mine reported me he also encoutered the same problem 2-3 times on NTSC stuff where 2 min where interlaced. So you can control closely and still miss that unique and very short interlaced sequence.

If that can be done a day, that would be great. If not, I'll continue using my magnifying glass. ;)


Thanks.

[hkazemi]

Here's a keyboard usability note for DGINDEX 1.5.0 rc2:

1.) Using the keyboard navigate the following sequence: Alt-F | File | Open | select a file | hit Enter

2.) you should now see a window called 'File List' come up with ADD/UP/DOWN/DEL/DEL ALL on the right side

3.) observe that you can't use the keyboard to move between the controls. The 'tab' key should work to do this, but it doesn't. If you use the mouse to manually click on 'ADD' and then 'Cancel', you can see the button focus is now on 'ADD', and you can use the arrow keys to sort of select between the options, although they're not selected in order, and the focus gets stuck in the file list again.

[Brewskie]

Hi,

The last version I had where the splash.bmp was working was 1.5.0 beta 10. It does not seem to work in 1.5.0 RC 2. If there was an intentional change that I am unaware of, I am sorry I didn't notice it in the thread. Also, it's not like this hurts DGIndex functionality so it's not too big of a deal! ;)

Thanks!

[Guest]

I'm 15000 miles away from my source code right now, but IIRC, rename the splash.bmp to dgindex.bmp. I did it to allow coexisting with DGAVCIndex. The DGAVCIndex bmp should be called dgavcindex.bmp. I'll fix the manual when I return. Thank you for pointing it out.

[hajj_3]

sse4 optimisation would be nice, divx 6.7 and other programs that use it get UPTO 80% increased performance which is insane. sse4 will be on all 45nm quad core/dual core cpu's that are out in 2 weeks time.

Keep up the good work neuron.

[squid_80]

They use it for motion estimation. As far as I'm aware decoding doesn't need that.

[Atak_Snajpera]

I have one question.

Why MPEG Layer-2 audio is demuxed to *.mpa extension instead of *.mp2 ?

[buzzqw]

@Atak_Snajpera

from vob and ts (mpeg2 video) the audio extension is MPA

BHH

[Atak_Snajpera]

from vob and ts (mpeg2 video) the audio extension is MPA

aaaaaand.... What is your point?

If audio is detected as MPEG Layer-2 it should have *.mp2 extension.

[buzzqw]

look here

http://img122.imageshack.us/img122/7835/screenshot3101200813590ki2.th.jpg (http://img122.imageshack.us/my.php?image=screenshot3101200813590ki2.jpg)

audio reported as mpa, extracted as mpa

(if you want i can post the sample vob , 7mb)

BHH

[Atak_Snajpera]

MPA L2 = MPEG Layer-2 = *.mp2
Do you understand me know?

[buzzqw]

.. i loose a "Why" .. fast read as "How"

BHH

[Guest]

Is it a problem for you?

MPA covers all layers.

[Atak_Snajpera]

I think *.mp2 extension is more logical instead of mpa. If I have Dolby digital stream then I have ac3 extension. If I have PCM then I have wav and so on.

[Guest]

I didn't ask whether you thought it was logical.

If I have MPEG audio then I have *.mpa and so on.

[Atak_Snajpera]

If I have MPEG audio then I have *.mpa and so on.

If this "too" difficult to change then forget it. It looks like I won't convince you to use correct extension.

[Guest]

I asked you a simple question and you refuse to answer. Who is the intransigent one?

http://www.fileinfo.net/extension/mpa

[Atak_Snajpera]

I asked you a simple question and you refuse to answer

Some apps (h264tsto or xport) cannot detect audio type so demuxed stream has always .mpa extension. I use NicMPASource only if I have .mp2 extension so I'm sure that stream will be recognized otherwise DirectShowSource is used (if .mpa). You may ask then Why not use DirectShowSource for .mpa and .mp2? Because I've noticed that Nic's plugin is more stable. Besides It would be easier for user if he had .mp2 extension so knew immediately that he is dealing with MPEG Layer-2 compression.
All I'm asking to be more precise.

http://www.fileinfo.net/extension/mpa
http://www.fileinfo.net/extension/mp2

[buzzqw]

@Atak_Snajpera

you can use a Try / Catch avisynth script, if nicaudio fails go to dss
or try first with Nic, check for audio channels, and if not 2/error -> go to dss

BHH

[Atak_Snajpera]

you can use a Try / Catch avisynth script, if nicaudio fails go to dss
or try first with Nic, check for audio channels, and if not 2/error -> go to dss

It's not very professional solution in my opinion. I will use MediaInfo to rename demuxed mpa to mp2.

[Inventive Software]

WTF? How hard is it to rename it to MP2?

[Guest]

Besides It would be easier for user if he had .mp2 extension so knew immediately that he is dealing with MPEG Layer-2 compression. ...
All I'm asking to be more precise. The layer is already specified in the file name. But I suppose it is not difficult to print an extension of mp1, mp2, or mp3, so I will implement that for you. Thank you for the suggestion.

[The Scientist]

The layer is already specified in the file name. But I suppose it is not difficult to print an extension of mp1, mp2, or mp3, so I will implement that for you.oh no, can we have a vote, lol

[The Scientist]

I suppose it is not difficult to print an extension of mp1, mp2, or mp3, so I will implement that for you.ermmmm, can we vote on that? lol

[Sharktooth]

@neuron2: you may be interested in this: https://forum.doom9.org/showthread.php?t=135055

[Guest]

Here's a keyboard usability note for DGINDEX 1.5.0 rc2 All dialogs fixed per your suggestion. Will be in the next release (probably RC3). Thank you.

[Guest]

This week I encountered the exact same problem with an old serie. In the middle of the episode, around 10 min, suddenly everything is interlaced.

Is there a way with DGIndex that could tell us automatically that the video has both progressive and interlaced content? Because as usual, I always see that AFTER the encoding ;) Grrr... ;)

I thought that maybe when we save the project (F5), at the end in the log file, we could have a report saying:

- Both progressive and interlaced

So that you know you have to use a deinterlacer. We already have such a report in the log, but I tried with my episode and it only report progressive and no interlaced because the final frames are not.

Is it possible to implement that? The problem is that the report of interlaced/progressive is not really telling you if the content of the video is interlaced, strangely enough. It tells you only how the stream was *encoded*. So it's not really suitable for basing a decision on whether a deinterlacer is needed or not. Given, that, it seems to me that your suggestion is moot.

There are tools for determining whether streams are actually interlaced, such as Megui.

[Guest]

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. I have implemented an option to specify an initial directory that should be used for the BMP save dialog. It is stored in the INI file. This will be in the next release. Thank you for the suggestion.

[The Scientist]

The layer is already specified in the file name. But I suppose it is not difficult to print an extension of mp1, mp2, or mp3, so I will implement that for you. Thank you for the suggestion.Can someone please tell me why on TWO seperate occasions my reply to this message has been removed?
My reply was something like "can we have a vote on that... lol" hardly something worth deleting......

[Atak_Snajpera]

I see no reason. What is your problem? Finally DGIndex will use correct extensions instead of mpa which doesn't mean anything. You don't know if you have Layer 2 or Layer 3.
BTW. DGAVCDec has been already adjusted and nobody was complaining.

[hkazemi]

I see no reason. What is your problem? Finally DGIndex will use correct extensions instead of mpa which doesn't mean anything. You don't know if you have Layer 2 or Layer 3.
BTW. DGAVCDec has been already adjusted and nobody was complaining.

I don't know why the posts were removed, but I also don't see why the change would need a vote either.

If you have a script that depends on the .mpa extension, you can workaround this change by adding a script step to rename the .mp2/.mp3/.ac3 to .mpa before going to the next step.

[Guest]

@The Scientist

I deleted them because they appeared to be useless chat to me (rules 3 and 11). Apparently, I made a mistake thinking you were just making jokes in the development thread. So, are you really arguing for the extension to be left as MPA? I know some apps allow the user to define the extensions. Do you think we need something like that?

I restored your messages so that you may decide whether they live or die. I should have PM'ed you about it. My bad.

Oh, I also deleted one of Atak's, so it wasn't personal.

Note to self: Don't put your hand in the suit spinner until it stops spinning. Blood is hard to wash off clothes.

[jeffy]

@neuron2: Unless this is a big issue for you, I agree (this is not a joke) with The Scientist. I have a lot of batch scripts depending on the mpa extension and I don't think I am alone. If it is not much of a hassle for you, would it be possible to have another checkbox or DGIndex.ini option, please? Thank you.

[remiche]

I hate this new version!

[25.2.2008 ã. 00:58:18] AutoGK 2.45
[25.2.2008 ã. 00:58:18] OS: WinXP (5.1.2600).2
[25.2.2008 ã. 00:58:18] Job started.
[25.2.2008 ã. 00:58:18] Input file: D:\Movies\VIDEO_TS\VTS_01_0.IFO
[25.2.2008 ã. 00:58:18] Output file: D:\Movies\VIDEO_TS\Movies.avi
[25.2.2008 ã. 00:58:18] Output codec: XviD
[25.2.2008 ã. 00:58:18] Audio 1: English AC3 6ch
[25.2.2008 ã. 00:58:18] Subtitles: none
[25.2.2008 ã. 00:58:18] Format: AVI
[25.2.2008 ã. 00:58:18] Target size: 1493Mb
[25.2.2008 ã. 00:58:18] Custom resolution settings: fixed width of 720 pixels
[25.2.2008 ã. 00:58:18] Audio 1 settings: Original
[25.2.2008 ã. 00:58:18] Started encoding.
[25.2.2008 ã. 00:58:18] Demuxing and indexing.
[25.2.2008 ã. 00:59:34] Processing file: D:\Movies\VIDEO_TS\VTS_01_1.VOB
[25.2.2008 ã. 00:59:34] Processing file: D:\Movies\VIDEO_TS\VTS_01_2.VOB
[25.2.2008 ã. 00:59:34] Processing file: D:\Movies\VIDEO_TS\VTS_01_3.VOB
[25.2.2008 ã. 00:59:34] Processing file: D:\Movies\VIDEO_TS\VTS_01_4.VOB
[25.2.2008 ã. 00:59:34] Source resolution: 720x480
[25.2.2008 ã. 00:59:34] Found NTSC source.
[25.2.2008 ã. 00:59:34] Source aspect ratio: 16:9
[25.2.2008 ã. 00:59:34] Analyzing source.
[25.2.2008 ã. 01:05:56] Source has percentage of interlacing in motion areas: 45,51
[25.2.2008 ã. 01:05:56] Source has percentage of telecined patterns: 96,97
[25.2.2008 ã. 01:05:56] Source has percentage of progressive patterns: 3,03
[25.2.2008 ã. 01:05:56] Source has percentage of interlaced patterns: 0,00
[25.2.2008 ã. 01:05:56] Source is considered to be FILM.
[25.2.2008 ã. 01:05:56] Output will contain 193339 frames
*************************************
EXCEPTION: Audio is not found.
*************************************
[25.2.2008 ã. 01:05:56] Job finished. Total time: 7 minutes 38 seconds

[The Scientist]

I see no reason. What is your problem?My problem is you moaned and argued like a child to get the option included.

I deleted them because they appeared to be useless chat to me (rules 3 and 11).I see... fine line between "moderater" and "censor"? I was making a 'light-hearted' comment to a slightly more serious issue, if that requires deletion, then expect to lose a chunk of the forum. Anyway this is starting to go off-topic, the point I am trying to make is: It doesn't matter what your program calls the audio files because the programmers that use DGIndex as a third party application can amend their programme code to suit, but you appeared to be 'bullied' into doing so from one person.

[hkazemi]

I hate this new version!

[25.2.2008 ã. 00:58:18] AutoGK 2.45
[25.2.2008 ã. 00:58:18] OS: WinXP (5.1.2600).2
...

*************************************
EXCEPTION: Audio is not found.
*************************************
[25.2.2008 ã. 01:05:56] Job finished. Total time: 7 minutes 38 seconds

The audio filename change wasn't suggested until after RC2, and RC2 is the version currently posted. Where'd you find RC3? If you're on RC2, you may have a different problem.

[Guest]

[25.2.2008 ã. 00:58:18] AutoGK 2.45
*************************************
EXCEPTION: Audio is not found.
*************************************
[25.2.2008 ã. 01:05:56] Job finished. Total time: 7 minutes 38 seconds I am not the author of AutoGK, nor do I support it. If you load your VOB(s) directly in DGIndex, is the audio found? If not please provide a VOB fragment that I may use to duplicate and fix your issue.

As AutoGK is no longer developed, compatibility with evolving versions of DGIndex can no longer be guaranteed. It might be best to stick with the version that comes with AutoGK.

[Guest]

Would you MPA loving guys be happy if I just added a line to the INI file to allow you to revert the extension to the old way, and not bothered making it controllable through the GUI?

[Atak_Snajpera]

Would you MPA loving guys be happy if I just added a line to the INI file to allow you to revert the extension to the old way, and not bothered making it controllable through the GUI?

I think this will be the best solution for those guys

[Taurus]

Would you MPA loving guys be happy if I just added a line to the INI file to allow you to revert the extension to the old way, and not bothered making it controllable through the GUI?
This would be the second best choice.
But this will not prevent some lamers and non-readers to lament and clutter the DGMPGDec threads.
Just my two cents.
@ neuron2: And a big "Thank You" for your ongoing work.

[jeffy]

Would you MPA loving guys be happy if I just added a line to the INI file to allow you to revert the extension to the old way, and not bothered making it controllable through the GUI?
For me yes, and a big "Thank you!"

[Guest]

OK, it's done. INI control only.

[For the record, I prefer not to view any DGMPGDec users as "lamers". Any and all feedback is gratefully received and I will do my best to respond. Sometimes, though, the tone one takes in making a request can be mirrored in the response. :)]

[Guest]

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

[Taurus]

Sometimes, though, the tone one takes in making a request can be mirrored in the response. :)

:goodpost::) :p

[remiche]

http://img168.imageshack.us/img168/5821/99562952jg3.png

[Guest]

@remiche

What is your point in your last post (the one that just shows the dialog box)?

[jpsdr]

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]

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]

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

Heya, Thanks for update neuron2. :D

[Taurus]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

That's a bug. I'll fix it. Thanks for pointing it out.

[Guest]

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]

Will you have the time to incorporate this suggestion too?

http://forum.doom9.org/showthread.php?p=1026570#post1026570


Cheers

[Guest]

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]

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]

@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]

It was just an example from DGAVCDec. I still don't know how to save that kind of information to *.log.

[Guest]

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]

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]

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.

[Underground78]

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.

Can some streams be without this "Display Size" value or is it a bug if I never have this field filled ?

[Guest]

Please read the Users Manual that I spent so much time creating. :p

[Inventive Software]

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.

I will both double-check the manual and make a small sample later. ;)

[Underground78]

Please read the Users Manual that I spent so much time creating. :p

Ok, I find everything about that in the manual, sorry ... :o

[karl_lillevold]

I have a .mpg MPEG-2 HD file that seems to be pretty broken. Only Cyberlink PowerDVD can play it back. The latest DGindex crashes when opening it without saving a log file. It has been captured from broadcast HDTV, and then converted to MPEG. Unfortunately, I no longer have the original TS file.

Does anyone have any suggestions on how it can be repaired before feeding it to dgindex?

Karl.

[Guest]

Can you post a link to the MPEG so that I can see why it is failing?

[karl_lillevold]

OK. I will PM a link.

[laserfan]

...captured from broadcast HDTV, and then converted to MPEG....any suggestions on how it can be repaired...Try mpeg2repair and/or VideoReDo Plus (the latter has free 14 day full-function trial w/registration).

[karl_lillevold]

laserfan: Thanks. However, mpeg2repair appears to work only on transport streams, and VideoReDo Plus crashes :(

[Guest]

The first sequence header of the stream declares a size of 704x480 and then all the rest are 1280x720. But most software will allocate buffers based on the first sequence header. I made your stream work by cutting away the first sequence.

Is this a one-time occurrence for you?

[karl_lillevold]

Very good - thanks!

It is very understandable why it crashes then. I will cut away the beginning as well. Perhaps it was cut right at the transition between a commercial and normal content.

Yes, other streams works just fine. There should be no need to write special cases for this.

Btw, I could have probably figured it out with dgindex source code myself. I will try to complete the compilation, but I am having some trouble with the one asm file requiring ml.exe. I will edit this post once I gain access on my build system, which is out of reach right now, or edit the source code so perhaps this code is not needed.

Thanks!
Karl.

[Guest]

ml.exe is readily available. PM me if you want me to point you to it.

[karl_lillevold]

Yes, the problem is not availability of ml.exe, but which version to use. I get various errors in idctmmx.asm, and have not found an ml.exe version that works.

My latest attempt was with "Microsoft (R) Macro Assembler Version 6.14.8444".


1> Assembling: idctmmx.asm
1>idctmmx.asm(1120) : error A2008: syntax error : xmm
1> DCT_8_INV_ROW_1_s2(2): Macro Called From
1> idctmmx.asm(1120): Main Line Code


ml 8.00.50727.762:


1> Assembling: idctmmx.asm
1>idctmmx.asm(52) : error A2008: syntax error : TEXTEQU
1>idctmmx.asm(1120) : error A2070: invalid instruction operands
1> DCT_8_INV_ROW_1_s2(5): Macro Called From
1> idctmmx.asm(1120): Main Line Code


ml 6.11d:


1> Assembling: idctmmx.asm
1>idctmmx.asm(795) : error A2070: invalid instruction operands
1> movq(5): Macro Called From
1> DCT_8_INV_ROW_1(2): Macro Called From
1> idctmmx.asm(795): Main Line Code


For the older ML versions I have iammx.inc and iaxmm.inc.

I would appreciate if you could point me in the direction of the right ml version.

Thanks,
Karl.

[Guest]

Do you have VC++ 6, Visual Studio 2005 Express, or what?

[karl_lillevold]

VS 2005. The full version, not express.

[Guest]

You need version 6.15 (mine is 6.15.8803). Most people get it from the VC processor pack. You can find it on the web. Let me know if you have any problems finding it. I tested it with VS 2005 Pro and it works fine for assembling idctmmx.asm.

[karl_lillevold]

Thanks, Don! I believe I have the VC proc pack somewhere on one of my older systems, too. I just did not think to try that version.

[morphinapg]

I get "Couldn't open input file in HIDE mode. Exiting" with every file I try to open in Hide mode. I use DGindex in my ASXGui encoder. RC2 worked fine. Should I go back to RC2 or is there a way to fix this?

[Guest]

Please give me your exact CLI line. The syntax is more stringently checked, especially the = signs must all be present,especially with -IF=[...]. I'll test it in the meantime.

EDIT: Yup, it works fine and it fails as you say if I leave the = sign out for -IF=[...]

[morphinapg]

Please give me your exact CLI line. The syntax is more stringently checked, especially the = signs must all be present,especially with -IF=[...]. I'll test it in the meantime.

EDIT: Yup, it works fine and it fails as you say if I leave the = sign out for -IF=[...]

Yeah, that fixed it, thanks

[Guest]

Great! Thank you for putting the issue on the record here, as others may be unaware of the parsing change.

[tre31]

neuron2 ok, did some more testing regarding the previous colormatrix/colorimetry issues (no hints) that I had. dgindex v.1.48 does parse it correctly and the proper values are being reported (hence why I said it used too work as its an old version).

v.1.48:
Colorimetry: ITU-R BT.709

v.1.49b4
Colorimetry: ITU-R BT.709

v.1.49b14
Colorimetry: ITU-R BT.709

v.1.49b17
Colorimetry: Unknown

v.1.49:
Colorimetry: Unknown

v.1.50b2:
Colorimetry: Unknown

So hopefully that can help you narrow it down, its quite obvious that something changed between 1.49b14 - 1.49b17 that affects recognising the correct colorimetry within the mpeg2 stream as the stream does have colorimetry, and I can pretty much assume that whatever changed is affecting all dvb channels within Australia (as I haven't seen colorimetry since 1.49b14 when processing).

here's the sample (3.8mb) so you can draw your own conclusions...
http://rapidshare.com/files/102937966/CH9.1440x1080i.HDTV.AU.m2v.html

I really hope you can solve this problem. ;)
(sorry I took so long, just had other things going on...)

[tre31]

neuron2 ok, did some more testing

I hope you still have all the old versions in source otherwise it'll be somewhat troublesome, but at least I've given you as much idea as what I have on the issue this time...

[Guest]

I've fixed it. It will be in the RC4 release (not the informal performance testing one).

[opieant]

Is it possible to add an option to produce a type-1 timecode file for mkvmerge for variable frame rate input files? DGIndex is already tracking transitions between "film" and "video" modes so I imagine this can be done pretty easily and accurately.

The type-1 format generally starts with:
# timecode format v1
Assume 29.970030
The first line is a comment that happens to specify the format, is checked by mkvmerge, and is therefore required. The "Assume" line has the default frame rate.

The remaining lines in the file specify frame ranges and the actual frame rate, such as
0,571,23.976024
where frames 0 through 571 (inclusive) are at 23.976024 FPS. The next line would begin with the next frame number that has a frame rate other than the default. If a single frame has a different frame rate, that frame number is used as the start and end frame number:
2435,2435,30.0Frame rates may be integers or floating-point numbers. If a range of frames is skipped over, the default rate will be used.

Thanks :)

[Guest]

Not possible unless you do it yourself. Write a utility to generate it from the D2V file.

[opieant]

Don: I already started looking into this possibility but ran into a problem. The D2V file doesn't contain the frame rate info from the sequence headers, just one frame rate at the beginning, so this can't be done based on the D2V file alone unless I'm missing something major.

It may be possible to calculate the picture durations accurately from the flag data, in which case I can generate a type-2 mkv timecode file (specifying every picture's presentation time). I'll look into this further. At a glance it seems like one necessary flag is missing, but I haven't picked apart this type of data in ages so I'll review the standard tomorrow.

FYI, I already tried to use the "timestamps" logging feature in DGIndex to get the PTS values but I discovered that not all pictures and GOPs are showing up in that log file. I can provide a sample input if you're interested in looking into this issue.

Thanks for your help :)

[plugh]

A minor usability request:

Video menu has "HD Display" mode. (Thanks)
However when using the cropping filter, I can't switch mode.

So I have to (for example) switch to 'Top Left', invoke the cropping filter, set top and left, exit the filter, switch mode to 'Bottom Right', re-invoke the filter, set bottom and right.

It gets the job done, but is cumbersome.

:thanks:

[Zep]

I've been looking for streams like that, which allegedly mess up sync. Feel free to upload one of those.

I know I still need to get you a sample that does this but I have only capped 2 480i and no 1080i since that post. 720p basically is all I seem to cap lol. So why am I posting this? Well the one 480i had no field transitions and the other had just 2. Not enough for me to notice if sync was off or not but I did notice the frame count was different by 1 frame when I compared the 2 d2v's and why I am posting now to ask you....

Is that is normal behavior? ( The length of the fixed d2v had 1 more frame than the non fixed and the audio was 41ms shorter than video. The NON fixed one was the exact same length for video and audio )


This week I'm gonna cap some 480i stuff just for you in search of an out of sync one so I can send you a good sample.

thanks

[Zep]

Oh almost forgot. In that same 480i there appears to be a dimension change and DGindex content would change size during preview and what was there before the change stays on the very right side while the new content previews (the DGindex window stays the same size. only the content area changes. looks like it goes from 704 x 480 to 512 x 480)

I never saw that happen before. I would send it but I deleted it by mistake and it was not recoverable. This is another reason why I'm gonna find you some samples this week instead of waiting for a random cap to have problems.



Thanks

[Guest]

If you have a bad transition like:

0->0->2->2

then you can fix it by changing it to this:

0->1->2->2

So a 0 (two fields) got changed to a 1 (three fields). So two such corrections will add two fields, i.e., a frame.

It's obvious that a lot of such fixes can throw off the audio. My contention is that such errors are rare. That's why I keep asking for a stream that shows a lot of the errors. I think that it can only result from some deeper pathology (such as a broken capture card, or dropouts in a transmission due to poor signal, etc.), which is the real thing that needs fixing.

So I'm standing by that position until somebody gives me a real example. If I get one and I agree that something needs to be done, it will be possible to track the added fields and drop frames as needed to keep the AV sync.

[Zep]

If you have a bad transition like:

0->0->2->2

then you can fix it by changing it to this:

0->1->2->2

So a 0 (two fields) got changed to a 1 (three fields). So two such corrections will add two fields, i.e., a frame.

It's obvious that a lot of such fixes can throw off the audio. My contention is that such errors are rare. That's why I keep asking for a stream that shows a lot of the errors. I think that it can only result from some deeper pathology (such as a broken capture card, or dropouts in a transmission due to poor signal, etc.), which is the real thing that needs fixing.

So I'm standing by that position until somebody gives me a real example. If I get one and I agree that something needs to be done, it will be possible to track the added fields and drop frames as needed to keep the AV sync.

the last cap I saw TONS of this error was a 480i show called joes VS pros. Thousands of them and the fixed d2v made sync go way way off and by what you said above I now see why.

The non fixed one stayed in perfect sync but makes me wonder what was wrong with the video, cause when I watched it, I didn't see anything wrong. So I guess DGindex is matching the wrong fields when I stick to the non fixed one? What is the worst case video wise strangeness I should see from this?

thanks!

[Guest]

The non fixed one stayed in perfect sync but makes me wonder what was wrong with the video Me too. But if no one ever gives me such a stream, I have no hope of finding out!

[Zep]

Me too. But if no one ever gives me such a stream, I have no hope of finding out!

well I am doing some 480i tonight so fingers crossed lol


UPDATE: out of 3 hours of just rawing a 480i channel to see what it showed basically 2 corrections per hour was the average
and looked like the following give or take. (this one was from the 10 PM show)

D2V Fix Output

Field order transition: 2 -> 0
d00 5 0 547373193 0 0 0 92 a2
d00 5 0 547396729 0 0 0 90 a0 a0 a0 a0
corrected...
d00 5 0 547373193 0 0 0 92 a3
d00 5 0 547396729 0 0 0 90 a0 a0 a0 a0

Field order transition: 0 -> 2
d00 5 0 819061264 0 0 0 90 a0
d00 5 0 819076508 0 0 0 92 a2 a2 a2 a2 a2 a2 a2 a2 a2
corrected...
d00 5 0 819061264 0 0 0 90 a1
d00 5 0 819076508 0 0 0 92 a2 a2 a2 a2 a2 a2 a2 a2 a2



that was it for tonight. I will try another channel tomorrow night. Gonna be pure random chance to get one as bad
as that pro's VS joes one but I will keep at it.


thanks

[plugh]

I've got one that has me scratching my head...

transport stream file, being processed by RC2.

If I say 'save project' with 'demux all audio' and NO 'log timestamps', at the end dgindex reports bad field transition. When I let it correct it, it shows a SINGLE fix.

If I say 'save project' with 'demux all audio' and ENABLE 'log timestamps', at the end dgindex reports bad field transition. When I let it correct it, well I'm guessing, but it looks like it massages a LOT of the file. (gross metric - .d2v=1300KB, fix.txt=592KB)

Other odd things I've noticed so far:

It is reported as Film ~70%. It does this for pretty much any segment, though the number varies some. As an example, I played a short section; 'Frame type' switched back and forth between Progressive and Interlaced, Playback #=706, Coded #=592, and Field Rpts=228. (706-592=114, 114*2=228), Video Type = Film 76%

mpeg2repair generates error groups every 14 frames(?)
ie "Sequence Frame NN(12-B)" where NN is 28,42,56,...
consisting mostly of 'temporalref gap' and 'unexpected tff/rff flag change'.
At the end it reports,
0 of 273148 video frames found with errors
12 of 333624 audio frames found with errors
0 corrupted video bytes in file
18300.7 seconds of video timestamp gaps

delaycut reports 1533 errors in the dgindex created ac3 file (vs 12 above?) and oftimes has to 'rewind 170 bytes' in order to find a sync word.

Comments?

[Guest]

OK, I found the bug that causes the parsing to be different when timestamp logging is enabled.

Were there any other DGIndex issues you are pointing out to me?

[plugh]

Ah - you replaced your prior reply...
So you don't need the 500MB sample I just finished uploading?
OK, I found the bug that causes the parsing to be different when timestamp logging is enabled.Does this mean, given my description of the stream, that the 'timestamp enabled' case is the INcorrect case?
Were there any other DGIndex issues you are pointing out to me?
I'm not sure. As I indicated, when mpeg2repair parsed the stream it only found 12 bad audio frames. When dgindex extracted the audio, the resulting file was reported as having MANY more than 12 bad frames by delaycut. Further, in many of those cases, it recovered by 'rewinding 170 bytes' to find the ac3 frame sync word. I note the TS packet size is 188 bytes, and wonder if there is a relationship - like hypothetically, did dgindex extract the payload from a ts packet and put it in the ac3 file that it should not have? Or is this perhaps simply related to the parsing error you just fixed?

{Edit:} Hmmm. think I got that backwards. delaycut reports a crc error, then needs to rewind from where it expected to find the next frame; so perhaps dgindex dropped a ts packet, thus producing the crc error and causing delaycut to have to search backwards. hypothetically...{end}

AS AN ASIDE - Based upon your experience, does my description of the video characteristics sound like perhaps this has been subjected to a dgpulldown-ISH process? I note that mpeg2repair reported 273148 frames vs the DGindexed source (with 'honor pulldown flags' selected) reporting 319959.

273148/319959 ~=.85 , 25/30 ~=.83 - Just coincidence? Is that perhaps why mpeg2repair reports 'unexpected tff/rff flag change' all through the file?

Thanks in advance...

[Guest]

When you say the DGIndex demuxed audio had more errors, was that with timestamp logging enabled? Is so, then yes, it is caused by the bug I fixed.

I assume MPEG2Repair reports encoded frames, while DGIndex reports displayed frames when honoring pulldown.

If you want to give me the upload link, I'll have a look at it.

[plugh]

When you say the DGIndex demuxed audio had more errors, was that with timestamp logging enabled? Is so, then yes, it is caused by the bug I fixed.
No. I turned on timestamp in order to try to get additional info about the audio errors (have never used it before, thought it might give PTS for both audio and video frames or some such)

I just went back and tried to recreate my sequence of ops.

--I wanted both the original ac3 5.1 and a decoded stereo mix-down wave--

opened files in dgindex, quick preview.
set audio for 'decode to wave', selected channel 0
made first pass to do the 'prescale decision'
made next pass with Save Project, yeilding .wav and .d2v
made next pass with 'Demux audio only' yeilding .ac3 <=-:eek:

Note1: The Save Project gave me a field transition warning;
I said 'doit', the log showed a _single_ correction.
Note2: Neither of the above audio output files indicates the delay to be used in the filename.

Soooo... I made another short, _aborted_ "save project" pass simply to create another ac3 output file WITH the delay value in the name.

Given my uncertainty about the delay issue, My *next* intent was to evaluate the lengths of the .wav and .ac3. Delaycut will report both duration and frame count for the ac3 file. Ran it, fed it the .ac3, and it gave me Many Errors. Uh oh...

ran dgindex again, this time to demux audio via 'Save Project'
Out of curiosity / desperation, I enabled timestamps.
Did the Save, it completed, reported the field transition (again)
I said 'doit' (again), but THIS time the log showed thousands of 'fixes'

'WTF' I said...

Ran mpeg2repair on the ts files to see what IT thought.
It gave me the confusing result of lots of temporalref and rff/tff errors, but the summary at the end seemed to say the files was OK, and only had a very few audio errors.

WTWTWTF!!

To summarize:

1st save project - one field transition error
2nd save project - zillion field transition errors

demux audio, run through delaycut, mega errors

mpeg2repair, zillion messages but summary says video ok, audio has 12 errors.

:confused: At which point I posted my question

Now...
Regarding the "<=-:eek:" above...

In the process of pulling this narrative together, I discovered:
---taa daa---
"Demux Audio Only" produced my corrupt AC3 file, but
"Save Project" (without 'timestamp' enabled) produces a correct one!

The ts sample can be found here http://www.megaupload.com/?d=Z2VLHXBC

And just to make sure it doesn't get lost in the above narrative,
- neither of the audio output filenames supplied 'Delay'.

[hajj_3]

problem with a dvd of mine using 1.5.0 RC3:

D2V Fix Output

Field order transition: 0 -> 2
d00 5 0 16384 0 2 1 b0 b0 90 a0
d00 5 0 28672 0 3 1 b2 b2 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
corrected...
d00 5 0 16384 0 2 1 b0 b0 90 a1
d00 5 0 28672 0 3 1 b2 b2 92 b2 b2 a2 b2 b2 a2 b2 b2 a2

Attached is the .d2v, .bad, .ifo

if you need the original files let me know and i'll put them on my 100/100mb ftp server for you.

[Guest]

What is the problem?

[hajj_3]

if i click "yes" to fix the .d2v the audio is around 1sec out of sync, if i click no its over 1 sec out of sync. there is no delay on the .ac3 audio either: "VTS_02_1 T80 2_0ch 192Kbps DELAY 0ms.ac3"

[Guest]

If it's a fixed offset, just correct for it in the usual way. If the transition is at the beginning, try starting your project in by a few GOPs. Without a stream, It's hard to help you. People always ask me if I want the stream and I always say yes.

[RunningSkittle]

DGindex 1.5RC3 fails to open this vob cell.

It fails to load the first cell of the main movie from lethal weapon 1,2 and 3.

media player classic, and virtualdubmod open the file without issues.

http://deep.phpwebhosting.com/~mactownkrisp/archive/VTS_01_11.VOB

help!

[Guest]

It's a known problem. Well, *I* knew about it. :devil:

I'll release RC4 tonight with the fix. There was a regression in transport stream detection. RC3 thought your stream was a transport stream. Sorry for the inconvenience.

[Guest]

@hajj_3

Instead of sending me a PM with a link to a 3.5GB download, and then stopping me in the middle to say forget it, take this other one instead, try answering my questions in the thread.

Start your project in by enough GOPs to get a reasonable delay value in your filename.

[RunningSkittle]

Not an inconvenience at all! Im just glad that I wasnt over looking something simple :0

[Guest]

* Don't check for field order transitions for streams with only frame repeats.

* Use lowest numbered audio ID to expand __aud__ instead of the first audio stream encountered in the source files.

* Fix parsing with log timestamps enabled.

* Correct handling of default matrix coefficients for hints.

* Add option for beeping and focusing when save project finishes.

* Save BMP is now enabled during play/preview.

* Fix regression in transport stream detection.

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

[morphinapg]

Works great, thanks

[Zep]

* Don't check for field order transitions for streams with only frame repeats.

* Use lowest numbered audio ID to expand __aud__ instead of the first audio stream encountered in the source files.

* Fix parsing with log timestamps enabled.

* Correct handling of default matrix coefficients for hints.

* Add option for beeping and focusing when save project finishes.

* Save BMP is now enabled during play/preview.

* Fix regression in transport stream detection.

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



awesome! 1 fix and 1 option in this release rock for me. this is the release I have so been waiting for!


thanks!

[hajj_3]

just to remind people of the new options in RC4...

in the DGIndex.ini file if you want the old behaviour of the window coming to foreground and beeping use option 3 from below, default is now 0:

Notify_When_Done:
0=no notify
1=window to foreground
2=beep
3=foreground and beep

If you want audio to be created as a .mpa file like before change the following from 0:

Use_MPA_Extensions=1

thanks alot for your hard work neuron, loving this build:)

[Terranigma]

Thanks for the update, neuron2. You know how much I appreciate your work. :)

[Guest]

I do indeed.

The great users and their feedback are the heroes. I'm a lowly coder.

[plugh]

Using RC4 I indexed a transport stream, with Timestamps enabled. The first part of the output says:
DGIndex Timestamps Dump

frame rate = 29.970030
V PTS 4056924629 [45076940ms]
V DTS 4056917121 [45076856ms]
Decode picture: temporal reference 831[I]
A0 PTS 4056881918 [45076465ms]
PCR 1217062932236 [45076404ms]
I subtract the (converted) 'A0 PTS' from the 'V PTS'
45076465 - 45076940 = -475
which matches the delay in the ac3 filename.

I then did an 'Analyze Sync->Track 1' and gave it this timestamp file. The first part of the output says:
Delay Analysis Output (Track 1)

Decode picture: temporal reference 831[I]
delay = 27252
Decode picture: temporal reference 845[I]
delay = 27711
Decode picture: temporal reference 859[I]
delay = 28170
Decode picture: temporal reference 873[I]
delay = 28630
Decode picture: temporal reference 887[I]
delay = 29122
Decode picture: temporal reference 901[I]
delay = 29581
Decode picture: temporal reference 915[I]
delay = 30040
Decode picture: temporal reference 929[I]
delay = 30499
Decode picture: temporal reference 943[I]
delay = 30990
Decode picture: temporal reference 957[I]
delay = 31449
Decode picture: temporal reference 971[I]
delay = 31909
Decode picture: temporal reference 985[I]
delay = 32368
Decode picture: temporal reference 999[I]
delay = 32859
Decode picture: temporal reference 1013[I]
delay = 33318
Decode picture: temporal reference 3[I]
delay = -390
Decode picture: temporal reference 17[I]
delay = 69
which I can't make any sense out of, given the description of this function in the docs. In particular, I would expect the first 'delay =' line to be either "-475" or "-42711".

Am I misunderstanding the docs, or is there a numerical rollover occuring in your calculations?

Thanks!

EDIT: PS - RC4 is giving me identical 'field transition' and AC3 output files from 'Save Project' with or without Timestamps enabled. (Thanks!) However, 'Demux Audio only' is still producing bad AC3 output file.

[Guest]

You know the rule. I need the stream so I can duplicate the issues.

[GrofLuigi]

Feature request (or something to think about):

A "close project" menu item that would clear all traces of current processing (reload the .ini?).

Basically, the same functionality as "Del All" but in a more 'common' or 'usual' place for Windows programs - in the 'File' menu.

I often use DGIndex on more than one project at a time and find myself confused what to click when switching between projects. That's not to say that current functionality is bad, but... it would be more user friendly for me. If others agree...

GL

[agilpwc]

I have use_full_path set to zero in the ini, but when I call dgindex from the command line like
call dgindex.exe -IF=[%~n2.mpg] -OF=[%~n2] -OM=2 -IA=3 -minimize -exit
The full path of the source file appears in the d2v file.

I reported this earlier and just tested rc4.

[plugh]

You know the rule. I need the stream so I can duplicate the issues.
The link I provided to a sample here (http://forum.doom9.org/showthread.php?p=1121930#post1121930) is sufficient to demonstrate the "Save Project" vs "Demux Audio only" AC3 problem.

I'll have to create/upload a sample for the other item.

EDIT: The first 50MB of the TS that produced the above output is available here (http://www.megaupload.com/?d=69201BRT)

[Guest]

@plugh

Thank you for taking the time to provide samples. I will fix the issues.

@agilpwc

Thank you for reminding me about that. I'll do my best to fix it for 1.5.0 final.

[plugh]

@plugh

Thank you for taking the time to provide samples.
No problem...

On a related topic:

Is it reasonable to assume that if a 'V PTS' or 'A PTS' record is present in the timestamp file, then there is a corresponding video or audio frame output by dgindex?

In the context of glitchy transport streams, can I correlate the timestamps with the output, or is it possible for your code to recognize / output a timestamp but then decide, due to some error in the associated frame, to drop the frame? (or vice versa - ie output a frame with no associated timestamp)?

Or perhaps even better, would it be possible to include in the timestamp file 'something' that would unambiguously tie the PTS to an audio / video frame? For example, with audio, perhaps the output file address of the start of the ac3 frame? For video I'm not sure what would be useful, given coded vs flagged frames... perhaps frame number??

FYI and FWIW, I've been pondering how to approach maintaining A/V sync in the presence of TS glitches, wherein sometimes A or V frames get dropped. As a first step, it occurred to me that a tool that would 'put' each frame on a timeline at its specified PTS (for its implied duration), and thus allow one to 'see' where the gaps occur might give clues on strategies to 'fix-up' such streams to maintain A/V sync.

As one (extreme) example - I recently had a stream with a major glitch, where I ended up hacking out about 40 frames from the AC3 file to bring the A back in line with the V. (Apparently dgindex skipped a chunk of video but managed to output audio, leading to the desync). I had to do this by trial and error, cutting out larger / smaller audio section until things looked 'ok' on playback (ie in sync after the glitch). Being able to tie timestamps to A/V frames (and 'seeing' the gaps) would have made this a snap.

Anyway - perhaps that explains my interest in the timestamp file and why I ask about correlating them...

[sidewinder711]

...The great users and their feedback are the heroes....

hehe... well said, BUT...

we have to thank you for your hard work...:thanks: very much appreciated, neuron ;)

Greetz

[Guest]

@sidewinder711

Thank you.

@plugh

I have the bad AC3 demux with audio only fixed. The issue with the timestamps arises because that stream has no GOP headers (legal but unusual). I'm going to have to think that one over for a while because there is no obvious simple solution. Regarding your new questions, patience, please, I want to fix the bugs first.

@GrofLuigi

Sorry but 1.5.0 is frozen for new features. Maybe in the next version.

[plugh]

@plugh

I have the bad AC3 demux with audio only fixed.Cooll! Will it include 'delay' value in the filename?The issue with the timestamps arises because that stream has no GOP headers (legal but unusual). I'm going to have to think that one over for a while because there is no obvious simple solution.Ah - I assumed you were just keying off I-frames for the delay calc.
Does this mean the info in the timestamp file is invalid? The actual PTS's are ok, correct?
Is there something in that file (or d2v or log files) that would alert one to this case? If 'Analyze Sync' doesn't work for this 'unusual' case, so be it - as long as we know that.
Regarding your new questions, patience, please, I want to fix the bugs first.
OK - Thought you might know off-hand if the timestamps were 'correlatable' or not. Adding info to timestamp file would be new functionality (though only you can judge if it is a trivial mod or not) so I'll understand if you want to defer that.

Many Thanks for ALL your efforts.

[Guest]

Cooll! Will it include 'delay' value in the filename? Not for Demux Audio Only.

Ah - I assumed you were just keying off I-frames for the delay calc. The code incorrectly assumed that the first frame in coding order has temporal_order 0, which it would if it was preceded by a GOP header. So my calculation goes haywire when GOP headers are missing. I have redesigned it and am now regression testing it.

Does this mean the info in the timestamp file is invalid? The actual PTS's are ok, correct? Correct.

Is there something in that file (or d2v or log files) that would alert one to this case? If 'Analyze Sync' doesn't work for this 'unusual' case, so be it - as long as we know that. I'm fixing it so that GOP headers are not required.

OK - Thought you might know off-hand if the timestamps were 'correlatable' or not. I haven't had time to think about it yet. Didn't I ask you to be patient? :)

[stax76]

@neuron2

I'm currently puzzled if StaxRip should stay with RC3 or update to RC4, I'm also working towards a stable release.

[Guest]

RC5 will be out shortly, so upgrading to RC4 seems pointless. I'm trying to get to 1.5.0 Final, but people keep finding new issues. :(

I think we're getting close.

[stax76]

Good to know, thanks.

[Guest]

I have use_full_path set to zero in the ini, but when I call dgindex from the command line like
call dgindex.exe -IF=[%~n2.mpg] -OF=[%~n2] -OM=2 -IA=3 -minimize -exit
The full path of the source file appears in the d2v file.

I reported this earlier and just tested rc4.
I'm not able to duplicate this. Can you provide a command line that fails without all the %~n2 stuff? There's no way I can verify that it expanded out correctly for you.

I ran with this:

dgindex -IF=[G:\THE_MATRIX_16X9LB_N_AMERICA\VIDEO_TS\VTS_02_1.VOB] -OF=[G:\THE_MATRIX_16X9LB_N_AMERICA\VIDEO_TS\VTS_02_1]

...and the resulting D2V has:

DGIndexProjectFile16
1
VTS_02_1.VOB

So, the onus is on you to show that there is a problem. The code looks correct to me.

[Guest]

I'm not able to duplicate this. I investigated some more and found the failing case. It is when your -OF option does not specify a full path. I have fixed that and now my testing shows everything working as it should for the CLI. I'll release RC5 later tonight.

[Guest]

* The Full Paths option is now honored for CLI invocation.

* Fixed the audio delay calculation, timestamps dump, and analyze sync tool for streams that do not contain GOP headers.

* The analyze sync tool now prompts for the audio ID instead of a track number.

* Fixed incorrect audio demuxing when demuxing audio only.

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

[CodeOptimist]

Thanks for your great work on DGIndex, neuron! I had an AC3 audio decoding issue with an earlier version, but after upgrading to RC4 it works like a charm.

Keep up the good work - it's definitely appreciated!

[josey_wells]

I am using DGIndex to parse Das-Boot The Director's Cut Disc 1. The movie has 4 VOB's. VOB 1-3 are progressive and VOB 4 is interlaced.

When I run all 4 VOB's simulatenously through DGIndex it reports the entire series as interlaced.

Shouldn't DGIndex report the movie as progressive or majority progressive since the interlaced part is only 10%?

[Guest]

When I run all 4 VOB's simulatenously through DGIndex it reports the entire series as interlaced. DGIndex reports progressive/interlaced on a per-frame basis, so your statement makes no sense.

[burfadel]

It depends whether you select 'honour pull down flags', 'ignore pull down flags', or 'forced film'.

Try 'ignore pull down flags'?

[josey_wells]

Let me see if I can make this more clear:

I am talking about the summary dialog and log file here.
A video can be purely progressive, purely interlaced, or a hyrbid of the two.

When I run VOB's 1, 2, & 3 through seperately DGIndex reports progressive in the summary window.

When I run VOB's 4 through seperately DGIndex reports interlaced in the summary window.

When I run VOB's 1-4 through as a group the summary window reports interlaced.

My question is why can't the summary window list the percantage of progressive or interlaced frames since it is checking each frame, i.e. Progressive(90%), Interlaced(10%)

[Guest]

Sorry, but this is the thread for 1.5.0, which is now frozen for new features. You'll have to ask again when the next version thread starts.

[SeeMoreDigital]

Hi Donald,

Is the "Display Size" outputting the correct information?

For example DGIndex reports this about the elementary 720x576 MPEG-2 stream with 16:9-PAL (aka: 64:45) aspect ratio signalling: -

http://i30.tinypic.com/2mrdsmu.png


Whereas DGAVCIndex reports this about the elementary 720x576 MPEG-4 stream with 64:45 aspect ratio signalling: -

http://i28.tinypic.com/bjijyp.png


Cheers

[Guest]

Please post a link to a sample of the stream.

EDIT: I've looked at the code and DGIndex just prints the display size values from the stream. So I would assume that the problem is in the stream itself.

[SeeMoreDigital]

Please post a link to a sample of the stream.Here you go: -

http://www.sendspace.com/file/fzu9m7


Cheers

[Guest]

The stream is specifying the display size as 720x576, just as I supposed.

[vlada]

Hi,

I have a question - is there a CLI switch to let DGIndex process only a part of an MPEG file?

I would like to explain my situation and idea. I'm working on an Avisynth transcoding application. During onpening a file, I want to use AviSynth and Autocrop filter to detect cropping. But I don't want it to take to much time. My idea is to index only 1s pieces from 10 parts of a DVD and use them to detect cropping.

Is this a good idea? Can this be done? If I use GUI I can select only a part of and MPEG file, so I do believe I can do the same from command line, but I couldn't find it in manual.

[Guest]

@vlada

Features are frozen for 1.5.0. Ask again when the next development thread starts.

[SeeMoreDigital]

The stream is specifying the display size as 720x576, just as I supposed.In that case, I suspect all MPEG-2 DVD sources will report a "Display Size" of 720x576 (for PAL) or 720x480 (for NTSC)... ie: it will be exactly the same as the "Frame Size"....

EDIT: Yes, this seems to be the case.... Does anybody have any spec MPEG-2 files where the "Display Size" and "Frame Size" are different?


Cheers

[vlada]

neuron2> Sorry, I thought the possibility might be there and just isn't mentioned in manual.

Another question - I use this command line:
exe\dgindex.exe -if=[D:\VIDEO_TS\VTS_01_1.VOB,D:\VIDEO_TS\VTS_01_2.VOB] -OM=2 -OF[C:\video\index] -EXIT


During the indexing the video preview window is black. Is this normal? If I do the same from GUI, the video is displayed.

Thank you for your reply and work on your applications.

[Guest]

neuron2>During the indexing the video preview window is black. Is this normal? If I do the same from GUI, the video is displayed. It's normal. No decode thread is kicked off when you tell the CLI to make a D2V file.

[stax76]

@vlada

Another thing you could try is the ffdshow source filter that appeared some time ago.

[vlada]

It's normal. No decode thread is kicked off when you tell the CLI to make a D2V file.

And can this be changed via a CLI parameter or should I keep this possibility for my 1.6 wishlist? ;-)


@vlada
Another thing you could try is the ffdshow source filter that appeared some time ago.

I never heard about it before. But ffdshow is "only" a video/audio decoder, it doesn't contain any splitters/demuxers. Also I'm afraid this wouldn't be a portable solution. I want to make my application portable. Thanks to avs2yuv and SoundOut it is possible to use Avisynth even if it's not installed.

Could point me to a source with more information about ffdshow source? I can't find anything myself.

Sorry for the OT.

[plugh]

I have the bad AC3 demux with audio only fixed.Cooll! Will it include 'delay' value in the filename?Yes.
I did a 'Demux Audio Only' on a VOB with RC5 (have not tried a TS yet).

No delay value in filename.

[stax76]

@vlada

I've confused it with ffmpegsource.

[Guest]

I did a 'Demux Audio Only' on a VOB with RC5 (have not tried a TS yet).

No delay value in filename. 'Demux audio only' does not give a delay value by design. What would it be referenced to, the non-existent video? If the delay is significant, then there is video. If there is video, then you use Save Project.

[plugh]

It is demuxed from a source that has video; seems reasonable to me that you would provide the time offset between the two, just like when indexing the video.

Refering to the work-flow I posted at the beginning of this post -
http://forum.doom9.org/showthread.php?p=1121930#post1121930
--I wanted both the original ac3 5.1 and a decoded stereo mix-down wave--

opened files in dgindex, quick preview.
set audio for 'decode to wave', selected channel 0
made first pass to do the 'prescale decision'
made next pass with Save Project, yeilding .wav and .d2v
made next pass with 'Demux audio only' yeilding .ac3

Neither of the above audio output files indicates the delay to be used in the filename. Soooo... I made another short, _aborted_ "save project" pass simply to create another ac3 output file WITH the delay value in the name.
Yes I can get the delay, by indexing the video twice.

If that is 'by design' so be it. It seems like an oversight.

[Guest]

Make your second pass with Save Project. Is it so hard to understand that Demux Audio Only is intended for streams without video? I explicitly say that in the User Manual. Isn't it clear?

[plugh]

I apologize. I missed that statement. The work-flow and the available menu functions seemed to be made for each other.

Many thanks for your efforts and patience.

BTW, is now a good time to revisit my questions about correlating the timestamps?

[G_M_C]

Make your second pass with Save Project. Is it so hard to understand that Demux Audio Only is intended for streams without video? I explicitly say that in the User Manual. Isn't it clear?

Yes i've read that too ... and if i remember correctly i asked why that is/was exactly. Cause i used this option to demux the audio only from my Pink Floyd "The Wall" DVD, for intentions of making a CD of the music for @ work (in the car and so forth). Didn't really matter, cause save project & demux audio gave me the audio anyways, but demux the audio only would have been a bit simpler

(in an ideal world " demux audio only" while also splitting the audio on chapterpoints would have been the most ideal option, giving me ready-to-convert audio indexed to tracknumber for my CD ;) But hey ... the world isn't ideal, and i made my CD anyways :) )

[Guest]

Yes i've read that too ... and if i remember correctly i asked why that is/was exactly. Cause i used this option to demux the audio only from my Pink Floyd "The Wall" DVD, for intentions of making a CD of the music for @ work (in the car and so forth). Didn't really matter, cause save project & demux audio gave me the audio anyways, but demux the audio only would have been a bit simpler If you are just taking the audio to make an audio CD, the delay value is useless. You're not making any sense. And I don't see how it is simpler either.

Maybe I need to change the option string to:

Demux 'Audio Only'

[plugh]

That might be enough to trigger people to read that section of the docs. ;) I confess I interpreted the function to mean 'ONLY demux the audio', versus Save Project == 'index the video AND demux the audio'.

Hmmm... Is 'decode to wave' "mode" applicable to the 'demux audio only' "function"? If so, 'demux' probably isn't the best choice. Perhaps " Process 'Audio Only' " or some such?? That phrase would definitely have prompted me to check the docs.

[SeeMoreDigital]

How about: -

http://i27.tinypic.com/zwzy1u.png


Cheers

[Guest]

How about using text to say it, as I am blocked from storage sites at work?

[unskinnyboy]

Feature request: In the DGIndex GUI, can a menu item be added under Options (or under maybe File if it makes more sense) to say After indexing and with sub-options Do nothing (the current default), Close DGIndex, Shutdown, Hibernate & Sleep. I am requesting this feature because often I open multiple DGIndex windows and set DGIndex to index 8-10 set of VOBs in a shot. Once done, I'd like for all of the windows to automatically close and not wait for me to get back to the PC and close them manually. So, to be precise, I am currently interested in only the Close DGIndex option, but maybe someone else might the other options useful.

I hope this wouldn't be too difficult to implement. If it is, then I can live with how things currently are. Thanks.

[Guest]

I'm not paying any attention to new feature requests until 1.5.0 is out. I didn't hear a word you said. :) Please wait for the next development thread and repost your request there.

[masta_g_86]

I'm not paying any attention to new feature requests until 1.5.0 is out. I didn't hear a word you said. :) Please wait for the next development thread and repost your request there.

Hmm...

Something tells me 1.5.0 final is right around the corner!

[unskinnyboy]

I'm not paying any attention to new feature requests until 1.5.0 is out. I didn't hear a word you said. :) Please wait for the next development thread and repost your request there.What, I should repost? Don't you maintain a "new feature request" database wherein you enter all these?!




J/k, DG. I'll repost this in the new dev thread when it's up. Thanks! :)

[3ngel]

I don't know if this is already signaled as bug,

but after the 1.49 final (so these RCs), sometimes frames are bad decoded in a way like a "green court" over all the frame.

It's 1 frame in a long arch, then another 1 random greenish frame. Something in the decoding routine?

[Guest]

I don't know if this is already signaled as bug,

but after the 1.49 final (so these RCs), sometimes frames are bad decoded in a way like a "green court" over all the frame.

It's 1 frame in a long arch, then another 1 random greenish frame. Something in the decoding routine? Please post a link to a source stream fragment that I can use to duplicate your issue.

[3ngel]

Yes, next time i encounter it i'll post, atm i don't have the samples.

[starsky]

ver: 1.5.0 RC5
condition: Added VOB files and "Save Project" complate.

If I don't exit the program, there are two problems.
1. File -> Open -> OK ==> Error dialog.
2. the length flag of PCM Audio will not reset to zero.
(the 25min wave file become to 50min wave file when I save project again)

[Guest]

@starsky

Thank you for the bugs report. I'll fix it for 1.5.0 final.

[ChiDragon]

I've got a 1-frame "still pic" MPEG-2 from a Blu-ray that I can't get to play in any software except when PowerDVD plays the disc itself. It's actually Sony's "wrong region code" video, but I'm curious...

In DGIndex, I just get a wrong-sized black frame window, although it is able to deduce that the file is 1920x1080. In DGDecode, I get a garbled frame with proper picture at the top and green in the rest.

Now the weirdest part is that I managed to decode it by opening it along with another 1920x1080 MPEG-2 TS in DGIndex's File List. Any old file with the right res seems to work, but I've uploaded the one I used as a relatively small example. Opening the single frame vid before the additional clip works nicely, opening it after has issues if you don't seek normally.

00082.m2ts (474KB) (http://chidragon.thedessie.com/00082.m2ts)
00000.m2ts (24MB) (http://chidragon.thedessie.com/00000.m2ts)

Would it maybe be possible to get it to decode without the workaround, or could you explain what the issue might be?

Edit: In fact, adding 00082.m2ts alone to the list TWICE also decodes perfectly, but DGIndex's arrow controls don't like it.

[Guest]

Would it maybe be possible to get it to decode without the workaround, or could you explain what the issue might be? It's interesting, because if I demux the video with XMuxer Pro and then open the M2V, everything works normally. So it's some quirk with single frames in transport. I'll investigate.

[dbzman1995]

How about: -

http://i27.tinypic.com/zwzy1u.png


Cheers

thanks!!

[Guest]

* Fixed detection of field order for field structure streams.

* Fixed bug: Open file, Save Project, then File -> Open -> OK gives an error messge.

* Fixed bug: Save project with decode AC3 to WAV. Repeat that. Each time the WAV file becomes longer. The size was not reset to zero.

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

[Taurus]

It's getting better all the time!
Thanks a lot,
and looking at the change log, I can see how much work you've got.
Really appreciated:thanks:

[SeeMoreDigital]

Hi Donald,

AAC audio (with MPEG-2) streams placed within .TS container are recognised in the "Information" bar as containing "MPA L2 2ch 44.1 free" audio.


Cheers

[Guest]

AAC audio (with MPEG-2) streams placed within .TS container are recognised in the "Information" bar as containing "MPA L2 2ch 44.1 free" audio.
Thanks for waiting for the release to tell me.

Do you have a stream I can use to duplicate it?

[SeeMoreDigital]

Thanks for waiting for the release to tell me.

Do you have a stream I can use to duplicate it?
I know, I know.... I'm useless :eek:

Here's a link to a sample: -

http://rapidshare.de/files/39518752/MPEG-2_with_6Ch_AAC.zip.html

[ChunkyNorwich]

Hi neuron2,

I think I found a bug in DGIndex 1.5.0. I'm trying to use the "Analyze Sync" feature but my audio ID contains three hex digits. The output file is called "trim.timestamps.delayTb1.txt" (only two hex digits) even though the audio track is 0x4b1. The output file is virtually empty:

<file>
Delay Analysis Output (Audio ID b1)

Decode picture: temporal reference 2[I]
</file>

Here's a clip:
http://rapidshare.de/files/39561574/SpamClip.ts.html

Thanks

[Guest]

The audio ID is not the same as the audio PID. The audio ID is the one shown in the audio box of the info dialog. For transport streams, it is always 0. If you specify 0 as the audio ID everything will work as expected.

The users manual does state in the "Select Tracks" section that the audio ID is always 0 for transport streams, but I'll add that to the Analyze Sync section as well.

[ChunkyNorwich]

Ah, my bad. It's working now, thanks.

[alfixdvd]

Wit the same group of VOB's

Version 1.49 indicates colorimetry is BT.709
Version 1.50b10 indicates colorimetry is BT.709
Version 1.50 Final indicates colorimetry is BT.470

I pay attention to the final version or to the previous ones ?

[Guest]

Colorimetry reporting changed. Please see the release notes.

Post a link to your stream if you want me to look at it and tell you why DGIndex reports what it does.

[alfixdvd]

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

DGMPGDec/DGINDEX versions starting with 1.5.0 beta 12 (released Nov 9, 2007)(including the current 1.5.0 RC2), report BT.709* for HD video and BT.470-2* [aka BT.601] for SD video when colorimetry information is not specified by 'sequence_display_extension'. The asterisk (*) means the stream did not declare the colorimetry. from http://forum.doom9.org/showpost.php?p=1090272&postcount=93

Thanks, neuron2

[3ngel]

@neuron2

I was reading the DgDecode manual and and i have some doubts. It says

upConv: 0 to 2 (default: 0)

Upsample from 4:2:0 to YUY2 (4:2:2) or RGB24.
- 0: Do not upsample
- 1: Upsample to YUY2 (ignored if input is already 4:2:2)
- 2: Upsample to RGB24


The points 0 and 1 are clear, but point 2 doesn't say what matrix uses in order to do YUV->RGB conversion.

Does it uses an arbitrary fixed matrix (Bt.601,Bt.709,SMPTe etc) possibly mismatching, or it does use the "declared in the stream" matrix (always correct result)?
Moreover after the conversion i get a 16-235 or 0-255 range?

Thanks

[Guest]

The matrix is read from the GOP lines of the D2V file. The range is read from the YUVRGB_Scale line of the D2V header section. Refer to the DGIndex users manual for documentation of the D2V file format.

[3ngel]

Thanks. So i see PC/TV levels refers to luma range, while the calorimetry is taken from the information provided by DgIndex.

But, at this point, looking at the information given by DgIndex when the calorimetry is not declared

Note that if the stream does not declare the colorimetry, then ITU-R BT.709* is reported for HD video,
and ITU-R BT.470-2* is reported for SD video.
The * character indicates that the stream did not declare the colorimetry.


I see from an NTSC dvd it goes on BT.470 B,G* wich means it did not declare.

But reading around many place (and i was wondering from some time about this) i read that BT.470 is used as a reference for "Analog" devices, while the BT.601 is the "Digital Counterpart". So i think this is the first "ingruence" we can say. The label would to be 601 instead of 470.
Moreover from this site (http://www.scanline.ca/ycbcr/) wich gives a good calorimetry explanation, the ITU-R BT.470-2 System M would to be used on NTSC source while the ITU-R BT.470-2 System B, G would to be used on PAL sources.

So on my example, on NTSC dvd (altough from what i've read the 470 definition is not exactly correct) it would to use the M scale instead of the BG scale. But in the most correct way from what i've understood the BT.601 scale (or it is only a label strictly correspondy to the BG or M counterpart?) would to be used.

Moreover from this site (http://www.kolumbus.fi/pami1/video/pal_ntsc.html) when there are excerpt from the original "ITU Reference" wich unfortunately isn't publicy available, we have that the BG PAL assume a gamma of 2.8 while the M NTSC a gamma of 2.2.

Now because all the monitors sRGB have a gamma of 2.2 i think that it would be an even more reason to use the M matrix colorimetry instead of the BG colorimetry actually used by DGIndex on SD video.

What do you think?

[Guest]

I think that if you don't like the choice that DGIndex makes, then you can upsample outside of DGDecode.

This has been discussed a lot and there is a lot of conflicting information. The choice I made is based on feedback from users.

The MPEG2 specification allows for 470-2 System B,G matrix coefficients. There is no way to specify System M for matrix coefficients. It does allow for System M for color primaries and transfer characteristics, but DGMPGDec doesn't use those in any way.

For our purposes BT.601 is synonymous with 470-2 System B,G.

[3ngel]

Mine was not a critic. 'Cause i was going a more deep in the colorimetry i reported some observations of mine.

In this sense i don't know how the YUV->RGB conversion is done by DGindex but i saw in the sites above

ITU-R BT.470-2 System M (NTSC/USA) (0.67, 0.33) (0.21, 0.71) (0.14, 0.08)
ITU-R BT.470-2 System B, G (PAL) (0.64, 0.33) (0.29, 0.60) (0.15, 0.06)

So i assumed that in the YUV->RGB formula those different value for the RGB cromacity could make a difference in the final result.

I obviously can choose a different colorimetry (with a conversion) if i don't like, but that was not the point :)

Hope you didn't misundestand me, mine was just "for the sake of the knowledge" :)

[Guest]

I still don't understand your point. What is it? What are you asking me to do to DGMPGDec? This is the DGMPGDec thread, you know.

Just because you saw something in a site somewhere, it is not necessarily reliable. The only fully reliable sources are the specifications themselves.

So i assumed that in the YUV->RGB formula those different value for the RGB cromacity could make a difference in the final result. Did you miss the part where I told you that it is not possible to specify System M for matrix coefficients, and that it is only the matrix coefficients that are used for upsampling?

[3ngel]

My point is that in the references the two BT.470-2 (M and G,B) are different and were made for two different television systems, PAL and NTSC that used two different phospores system in the consumer television, so the trasmission had 2 different color palettes.
Because you in DGIndex explicity say "System B", i made you note the fact that SystemB with a gamma of 2.3 could not be indicated on our monitors with a gamma of 2.2, while System M uses the same gamma, so using the System M pheraps would yeld more precise results.

But you say that there is no way you can use SystemM matrix (wich differentiate from the System B for the cromacity values i posted before). But at this point if you can't differentiate M from B, on wich basis you say you're using system B?
In other words if you can't differentiate from the two system, because from what you've said you don't use the cromacity values which are the difference between the twos, how can you say you use SystemB? Pheraps, you're using BT-470, but inside this there are other 2 color subsystem palettes. And if you can't differentiate between the two, pheraps saying only BT-470-2* would be more correct.

Moreover i can't find anywhere that BT.470-2 = BT.601.

So pheraps you're using BT.601 wich doesnt have the M,B differentiation being done for a digital environment.

In the end i was misleaded by the fact that you say using BT.470-2, System B when you say you are not able to distinguish from System M (part of 470-2 too), and the assertion you say BT.470-2 = BT.601 wich in my opinion (and from what i've read everyware) is not.

And because you say cromacity values dont' fit in your YUV formula i can suggest (in the end of all this) you change the label from BT.470-2 PAL G (wich refer to a color subsytem of an analogue system), to BT.601 wich doesn't have cromacity value differentiation (not referring to a analogue phosphor system) and is the right digital counterpart to BT-709.

BT.470-2 everyware i read is used in relation to analogue/signal/TV phospors systems.

BTW sorry for this long OT in the thread, if you want i'll delete all these posts.

Obviously good work and thanks.

PS: The whole point of all my dissertion was to add reproduction and formal preciseness to DGDecode.

[Guest]

Why do I say System B,G?

See here:

http://neuron2.net/library/mpeg2/iso13818-2.pdf

Table 6-9 specifies B,G for value 5. So that is what I report.

Perhaps you could profit from doing a little homework on the relevance of color primaries, transfer characteristics, and matrix coefficients in the analog and digital domains. Recall that it is only the matrix coefficients that influence upsampling by DGMPGDec.

My point is that in the references the two BT.470-2 (M and G,B) are different and were made for two different television systems

Analog television systems. DGMPGDec remains wholly in the digital domain.

[3ngel]

I'm very glad you post the table because at page 68 just after table 6-9 it states:

In the case that sequence_display_extension() is not present in the bitstream or colour_description is zero
the matrix coefficients are assumed to be those corresponding to matrix_coefficients having the value 1.

That is:
if the portion of the stream containing the colorimetry is not present in the stream then switch to value 1 that is

1 Recommendation ITU-R BT.709
E¢Y = 0,7154 E¢G + 0,0721 E¢B + 0,2125 E¢R
E¢PB = -0,386 E¢G + 0,500 E¢B -0,115 E¢R
E¢PR = -0,454 E¢G - 0,046 E¢B + 0,500 E¢R

This clausole of "default switching" is present in every section above the 6-9 table.

So in our case, because we were talking about "not present colorimetry" (that is no information pesent in the stream) the right setting according to the Reference would be BT.709

[Guest]

That's what I used to do, but user feedback led me to the new approach. As I said, if you are not happy with it, just upsample with Avisynth's ConvertToRGB(), and specify the matrix that you prefer.

[3ngel]

Oh i finally understand your point.
Thanks, but i could not imagine you had gone different from reference 'cause of user feedback.

Now it's all clear :)
Now i know it, i'll try to do some conversion when i have occasion and if you like i'll post the screenshots (in contrary case, no problem, important thing it's knowing what's going on).

PS:
Strange enough the SystemM doesn't appear in table nor even BT601...

[Guest]

You may find this thread enlightening, if you have not already seen it.

http://forum.doom9.org/showthread.php?t=82217&highlight=ColorMatrix

Please don't get the wrong idea: I am always receptive to suggestions for improvement. One should try to be careful to review previous developments, if possible. Thank you for your information.

[3ngel]

I'll read it.
(Thanks again for having posted the reference, having an official reference as discussion basis is good)

[3ngel]

Now, i'm trying to shred some light again (i go till the end eheh).
So from here (http://www.scanline.ca/ycbcr/), from the reference file posted above and from this ITU601 reference (http://inst.eecs.berkeley.edu/~cs150/Documents/ITU601.PDF) (page 6) that is BT.601

ITU-R BT.470-2 System B, G
E'Y = 0,587 E'G + 0,114 E'B + 0,299 E'R
E'PB = -0,331 E'G + 0,500 E'B -0,169 E'R
E'PR = -0,419 E'G - 0,081 E'B + 0,500 E'R

ITU-R BT.601
E'y = 0.299R' + 0.587G' + 0114B'
E'CR = 0.500 E'R – 0.419 E'G – 0.081 E'B
E'CB = – 0.169 E'R – 0.331 E'G + 0.500 E'B

ITU-R BT.470-2 System B, G = ITU-R BT.601

I had to be matematically sure :D

You can write if you want (in order to avoid confusion) in DGIndex (the more known) BT.601 instead of BT.470-2 System B, G

PS:
I've read all the thread that pushed you to differ from the reference suggestion BT709, and it seems strange to me that software/hardware houses would so massively default to BT601 when the reference says different. I'll do test if i have time.

[Wilbert]

PS:
I've read all the thread that pushed you to differ from the reference suggestion BT709, and it seems strange to me that software/hardware houses would so massively default to BT601 when the reference says different. I'll do test if i have time.
Your reference iso13818-2.pdf is outdated. In "ITU-T Rec.H262 (2000 E)" they state:

In the case that sequence_display_extension() is not present in the bitstream or colour_description is zero the matrix
coefficients are assumed to be implicitly defined by the application.

We had this discussion a while ago: http://forum.doom9.org/showthread.php?t=131169 . Some more info about his subject: http://forum.doom9.org/showthread.php?t=133982

[3ngel]

In thruth it seems really strange to me that a reference would say "if you don't know, do as you please".
From what i've read from the References pieces we can find around, they are very precise on everything.

BTW you can access the official references? They are not public and require a login. In this case you sure have the latest version?

As a side note, after doing some tests i can say that from a visual taste BT601 seems give to me a balanced tone while BT709 colors seem little overexposed assuming a kind of little "exasperated" tint (speaking about DVDs).

Much interesting is your second links, in wich at a glance it appears that "BT601 for SD and 709 for HD"
And this statement i've personally read in clear or between the lines on many places.

[Wilbert]

In thruth it seems really strange to me that a reference would say "if you don't know, do as you please".
:)

BTW you can access the official references? They are not public and require a login. In this case you sure have the latest version?
They are freely accessible since a while: http://www.itu.int/rec/T-REC-H.262/en

Much interesting is your second links, in wich at a glance it appears that "BT601 for SD and 709 for HD"
And this statement i've personally read in clear or between the lines on many places.
Yes, many people say so. But at the end, only the dvd specs can give a definite answer. Unfortunately i don't know anyone who has them.

A separate issue is what the players and renderers do when playing video. Many of them are ignoring that setting in the mpeg-2 header. There is a lot of discussion about that too in those threads.

[3ngel]

I've just read the ITU601.PDF posted by me.
When i post it i read only the part regarding the colorspace matrix, but now i've read it entirely so i think it can be considered the angle stone of our dissertion. This because

1) It's called
ENCODING PARAMETERS OF DIGITAL TELEVISION FOR STUDIOS
So it refers exclusively to Digital Domain, and is dedicated to "Studios" that is the "source" of all productions, both TV, and DVD regarless the format. So we could have a 4:4:4 Lossless YUV at the studio wich is then converted to 4:2:0 YUV DVD maintaining the colorimetry of the 4:4:4 that is what this reference suggest.

2) This reference is dedicated exclusively to 565/625 lines (PAL/NTSC) and moreover it explains "officially" the right method to convert from "analogue lines" to "digital lines", so it can be considered the real bridges between the two world. In other words it's dedicated to all "digital 576/480 vertical size" both DVD or DVB.

So in my opionion this reference (http://inst.eecs.berkeley.edu/~cs150/Documents/ITU601.PDF) confirm what we have read on many places "BT601 for SD".

[Harukalover]

Sorry in advance for reporting an issue after the final release but I couldn't find a reliable way to reproduce the following problem till now.

When using IEEE-1180 Reference iDCT algorithm for creation of a d2v, the resulting stream will sometimes output corruption in the form of random blocks appearing.

http://www.mediafire.com/?dymxfez1qoj

In the Test.7z uploaded I have included two pictures of frame 72. The one with the suffix of _okay was saved from the Fine.avs script, that used the d2v generated by Skal SSE MMX. The other pic is saved from the output of the Broken.avs script using the opposite IEEE-1180 Reference d2v.

I have commented lines in the Broken.avs script to explain how to reproduce the issue. dfttest() seems to just act as a trigger for it to appear. If you remove dfttest() after triggering it the blocks will not disappear from the output.

Thanks in advance.

[Guest]

I have commented lines in the Broken.avs script to explain how to reproduce the issue. dfttest() seems to just act as a trigger for it to appear. If you remove dfttest() after triggering it the blocks will not disappear from the output. What are you using to view the AVS scipt when this is seen? When you say you comment out the dfttest() and it still stays broken, what do you mean exactly? Do you exit the application and restart it?

I'm suspecting that dfttest() is responsible. Are you able to cause this problem without it?

[Harukalover]

What are you using to view the AVS scipt when this is seen?
Have seen it in AvsP and yatta. Another person who reported the same issue to me has seen it in yatta and Virtualdubmod and also had it encode into his resulting encodes. For me the blocks never encoded into another video.

When you say you comment out the dfttest() and it still stays broken, what do you mean exactly? Do you exit the application and restart it?
After I add dfttest() the blocks will appear in the frame as shown in frame_72_bork.png. If I remove dfttest() the blurring from the filter disappears but the blocks do not. If I exit and reopen the application the blocks will disappear until I seek about with dfttest() on again.

I'm suspecting that dfttest() is responsible. Are you able to cause this problem without it?
I'm not really sure anymore... >_> (I first found this issue a while ago and don't really remember what was used then to trigger it)

But could it actually be dfttest() causing it even though dfttest() will not cause the same issue with the d2v that didn't use IEEE-1180 Reference iDCT?

Either way I'll try asking the other person who experienced this same problem if their avs script used dfttest()

[Guest]

But could it actually be dfttest() causing it even though dfttest() will not cause the same issue with the d2v that didn't use IEEE-1180 Reference iDCT? Yes, because memory and stack layouts are different in the two cases.

So I have to install dfttest() and Avsp to duplicate this and you've never seen it without them?! Sorry, but I'm not going to spend any time on that. If you can demonstrate an issue with DGMPGDec, then I'll look at it.

[squid_80]

Maybe the compiler is using floating point instructions for the reference IDCT and dfttest is missing an emms instruction... Virtualdub's normally pretty good at catching those though.

(Who uses the extremely slow reference IDCT anyway?)

[SpAwN_gUy]

(Who uses the extremely slow reference IDCT anyway?)
me is using it from time to time with no purpose :) ... just fo fun :)

[GrofLuigi]

(Who uses the extremely slow reference IDCT anyway?)

Me too. When I'm faced with choice of speed over (supposed) quality, I chose the latter.

I don't understand what's the fuss about DGIndex's speed anyway. It's not slow, even on my aging Barton...

GL

[jpsdr]

Same for me.

[Tima]

Donald, hi!

I noticed a strange behaviour of DGIndex 1.5.0. I have a DVD with 4 episodes of a show: first ep is in vob 1 cell 1-2, second is in vob 1 cell 3-4 and so on. I saved 4 projects -- one for each episode. When looking into d2v, in last 3 files there are improper (I think) cell id's for first two GOPs. Also (when comparing each episode's d2v to d2v for the whole timeline) there's one GOP with different 'position' value.

I attached 5 d2v-s -- please have a look at them. Problem with first two lines of GOPs exists with eps 02-04; problem with different position for one GOP is in ep 02.

Thanks!

[Guest]

@Tima

I need the corresponding VOB fragments to do anything with this.

This doesn't affect the decoding, right?

[Tima]

The bug with wrong cell ids -- doesnt affect decoding.

An issue with different timestamps -- don't know.

Working on delivering vob parts to you..

[vlada]

Hi,

I have 2 questions:

1) Are there any plans for 1.6.0 so I could post my feature requests?

2) Why not join DGMPGDec and DGAVCDec into one application?

[Guest]

1) Are there any plans for 1.6.0 so I could post my feature requests? http://forum.doom9.org/showthread.php?p=1147283#post1147283

2) Why not join DGMPGDec and DGAVCDec into one application? It's been discussed several times. The architectures are so different that the result would be a nightmare.

[Guest]

The bug with wrong cell ids -- doesn't affect decoding. It's a cosmetic thing that is hard if not impossible to fix. You can set a project range (either explicitly or by means of cutting the source file), such that an I frame is encountered before a navigation pack. Then for that I frame line in the D2V file the current cell ID is not yet known, and DGIndex will print either the initial default 0/0, or the last one seen.

It's cosmetic and doesn't affect encoding because it's purely informative. So I don't plan to do anything about it.

In a PM you told me not to bother with the second issue as you think it is related to a corrupt VOB file.

[Guest]

I am nowing closing this thread. Please continue with feature requests for 1.6.0 here:

http://forum.doom9.org/showthread.php?p=1147283#post1147283

For bug reports in 1.5.x, please create threads as needed.

Thank you to all Doom9'ers who posted in this thread with your ideas and bug reports.

:thanks::thanks::thanks:

[Guest]

* Fixed a problem with video demuxing that sometimes caused an extra partial first GOP to be demuxed at the start of the stream.

* Added mousewheel support.

* Added a -RG option to the CLI (define project range).

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

I'll release the source code tomorrow.