DGMPGDec 1.4.3 Final!

[Guest]

Version 1.4.3 final offers the following changes over version 1.4.0:

1. DGDecode's fastMC option is enabled for 3dNow.

2. A scanning bug in reading the D2V file in DGDecode has been repaired.

3. The track specification for GUI and CLI has been changed to allow multiple
tracks to be enabled for demuxing. You can, for example, specify tracks 1
and 3 for demuxing. Previously, you could choose one track or all tracks.

4. Added the Skal and Simple IDCTs from DGDecode to DGIndex.

5. Added quant matrix logging.

6. Revised the video error handling to prevent macroblocking in some error
cases, and to prevent incorrect frame delivery leading to AV desync in some
error cases.

7. A default save file name is now set in the Save Project dialog.

8. The CLI now supports demuxing the video (-OFD).

9. Fixes for bugs in YV12 upsampling (tritical).

10. When repeat flags are present give Film/Video percentages instead of
FILM/NTSC percentages. This avoids showing a PAL as NTSC in some cases!

11. The command line buffer has been increased to 4096 bytes. If you use a
DOS shell instead of programmatic invocation, you will be limited by the
capability of the DOS shell.

12. Destroy the Info dialog window upon any of these events: new file(s)
opened, right/left arrow buttons hit, scroll operation on timeline.

13. Various changes/fixes for upsampling by tritical. These apply as
appropriate for DGDecode, DGIndex, and DGVfapi:

* upConv can now be set to 3 values: 0, 1, and 2. 0 = do nothing,
1 = YUY2 output, 2 = RGB24 output... for the case that the input is 4:2:2
then 1 is the same as 0.

* Added iCC parameter. iCC=true uses interlaced YV12->YUY2 upsampling,
iCC=false uses progressive YV12->YUY2 upsampling, and leaving iCC unset
makes it switch based on the progressive_frame flag.

* Fixed a little problem with the 422->444 conversion, fixed a problem with
the 444->RGB24 conversion where it wasn't correctly handling pixel values
that came out as < 0, and added a faster isse 422->444 conversion. I also
modified the 444->RGB24 conversion so that it uses the correct coefficients
(indicated by the matrix_coefficients value).

* Added a way to force DGVfapi (and the DLL access functions) to follow
the progressive_frame flag.

* Added a Colorimetry box to the DGIndex Info dialog.

14. Top-level picture decoding (slice and macroblock layers) was completely
redesigned to dramatically improve resilience to video errors, and to correct
some spurious video errors due to bugs in the old approach. The previous
design is a legacy of the original MSSG reference decoder. The new design
was adapted from fccHandler's excellent VirtualDub MPEG2.

15. Modified the Info dialog display of video errors to show text reasons
instead of numbers.

16. Added "fccHandler" to the credits listing in the DGDecode manual.

17. Revised the playback speed option. It now gives 5 checkables: super
slow (5fps), slow (10fps), normal (plays reliably at the correct frame rate for
the stream), fast (2 times normal), maximum (as fast as possible).

18. A warning box is popped up if Force Film is used inappropriately. The user
can decide whether to proceed anyway or to cancel.

19. The leading number on the file path lines at the top of the file was
eliminated. This makes editing the D2V file to change paths easier. The D2V
file format version is therefore bumped to 11, and you will need to remake
existing projects.

20. Added an item to the Option menu: Force Open GOPs in D2V File. This
should be used when a stream erroneously claims that all its GOPs are closed.

21. Added a user manual for DGIndex! Thank you Cyberia.

22. Vob and Cell ID's are now displayed in the title bar.

23. Added a splash screen that is displayed when no file is loaded.

24. Added single-step mode to the playback speed options.

25. Fixed a bug in the handling of sequence end codes.

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

[Guest]

@Doom9

Please advise if this new track handling satisfies your needs. Please note that the new CLI syntax is TN=x, where x is the decimal representation of a bitmap of the desired tracks. For example, this enables tracks 1 and 2:

TN=3

This enables track 5:

TN=16

Multiple tracks are supported for demuxing, but not for decoding. If you invoke decoding with a bitmap that has more than one bit set, you'll get an error popup. (The AC3 decoder currently does not support multiple instantiations.)

[Doom9]

I guess I have to start coding again now. I have so far advised people not to use betas but I think the problems reported stemmed from the use of beta AviSynth versions, not DGIndex any any other tool (after all pretty much everything I use in MeGUI is beta)

[Zyphon]

Wow a new beat release so fast after the 1.4.0 final version.

Thank you Donald for the update of this excellent tool.

[Guest]

@Zyphon

Finals are just stopping points for releasing the source code. The fun never stops!

@all

Here is beta 2. It adds the Skal and Simple IDCTs from DGDecode to DGIndex.

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

[mg262]

These releases are coming impressively fast. I've had to make a batch file to recreate all my D2Vs to keep up!

@neuron2:

May I ask what iDCT you yourself use?

[Doom9]

how about TN=1,3,5 ? that saves us the trip from integers to bits and back

[Guest]

These releases are coming impressively fast. I've had to make a batch file to recreate all my D2Vs to keep up!

@neuron2:

May I ask what iDCT you yourself use? Check the D2V format number. If it doesn't change there is no need to remake D2Vs for new versions.

Before recently, I just used the default IDCT. Now after looking at them more closely, I like Skal because it is faster.

[Guest]

how about TN=1,3,5 ? that saves us the trip from integers to bits and back You caught me being lazy. Doing it as a bitmap meant that the CLI code did not have to change.

OK, I'll do it that way in the next beta.

[ron spencer]

just checked this forum...was gonna use 1.4.0....but I saw these new betas released fast....is 1.4.1 stable going to be out soon? or is 1.4.0 ok

thganks

[video_magic]

Is there a way to have an option to demux a little extra of the audio track to correct the audio delay?

For example, I have an mpeg1 'vcd standard' video with mp2 audio, and using DGindex I choose the IDCT Algorithm IEEE 1180 REFERENCE. Then I go

Audio-Output Method-Demux Track
Then File-Save Project And Demux Video.

It gives me an *.m1v, and an *.mpa and in the name of the mpa audio file it mentions a delay number in MS

I would like a feature so I could choose a 'corrective demux' which will demux the audio from a few extra samples ahead or behind to correct this delay, if the program knows how much the delay is then is it possible for it to do this?

I am assuming the delay does refer to a time synch issue with the video :o or is it something to do with Multiplexing (or something else)? The resulting mpeg does seem to play alright with the audio and video together but I just wondered. Thanks

[IgorC]

Now Skal SSE MX is enabled by default. Why 32-bit isn't? It´s faster but is there any diffference in quality terms?

[mg262]

@ron,

above:Finals are just stopping points for releasing the source code. The fun never stops!

@neuron2,

Thank you on both counts.

[Guest]

Now Skal SSE MX is enabled by default. Why 32-bit isn't? It´s faster but is there any difference in quality terms? As the developer, I get to choose my favorite default. You have the INI file if you don't like my choice. :)

See here for quality and speed tests:

http://forum.doom9.org/showthread.php?t=96986

Perhaps Simple MMX should be the default.

[Guest]

Is there a way to have an option to demux a little extra of the audio track to correct the audio delay? We have this on the development list already (see the sticky thread).

[Guest]

just checked this forum...was gonna use 1.4.0....but I saw these new betas released fast....is 1.4.1 stable going to be out soon? or is 1.4.0 ok Version 1.4.0 is OK. There may not even be a 1.4.1 final. It depends on how much energy I have and how many features I implement before a new source code drop is indicated. I.e., it may advance a few points, or it might become 1.5.x before a final release. I can't really predict it.

[Guest]

Well, I have to keep Doom9 happy, that goes without saying, and I have to keep @all happy too. So here's a new beta. It changes the CLI track specification to the TN=1,2,3 syntax suggested by Doom9, and adds quant matrix logging. The latter feature is a fun toy. If you enable quant matrix logging in the Tools menu, then after each Save Project you will get a log file that records all the quant matrices that were set by the stream. If the D2V file is named BritneyIsAGoddess.d2v, then the log file will be in the same directory and called BritneyIsAGoddess.quants.txt. Thanks to manono and Rockas for inspiring this feature.

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

And Britney *is* a Goddess.

[Chainmax]

Well, I have to keep Doom9 happy, that goes without saying, and I have to keep @all happy too. So here's a new beta. It changes the CLI track specification to the TN=1,2,3 syntax suggested by Doom9, and adds quant matrix logging.[/url]

You, sir, are a machine :)http://instagiber.net/smiliesdotcom/otn/wink/thumb.gif. However,
Britney *is* a Goddess.
http://instagiber.net/smiliesdotcom/cwm/cwm/eek7.gifhttp://instagiber.net/smiliesdotcom/contrib/sarge/Paranoid_anim.gif

Oh well, even machines can have loose bolts every now and then ;):).

[Emp3r0r]

heh, thanks

[Zyphon]

Thanks for the update neuron2. :)

[fccHandler]

And Britney *is* a Goddess.
:stupid: Yes!!

I LOVE that girl. I don't care what anybody says.

[Doom9]

is beta3 the Britney release then? ;)
Thanks for the updated TN syntax.

[AllTimeSToneD]

@neuron2

I was trying to close the opening-GOP by setting the start marker at the first I-Frame after opening the stream. Once i've opened the demuxed m2v file in DGindex it was telling me again that the opening-GOP is not closed.

I know there are several tools out their to close the opening-GOP but with an little extra feature like "Close Opening GOP"-when demuxing we could skip this "extra tool step". Not only does it save time but also HD space when using tools that have to recreate the m2v stream with a closed-gop.

Its especially time-saving for all those who like to re-author their favourite tv-shows(dvb) to dvd without re-encoding ;)


You can consider this as a feature request :p

[Guest]

Why do you require to close an unclosed opening GOP? Please be specific.

Assuming you do require it, do you mean just setting the closed GOP flag, or actually replacing leading orphaned frames as well?

[Sirber]

Updated RealAnime, thanks!

[AllTimeSToneD]

Why do you require to close an unclosed opening GOP? Please be specific.

Most authoring tools do not accept streams with leading open gops.

Assuming you do require it, do you mean just setting the closed GOP flag, or actually replacing leading orphaned frames as well?

By replacing you mean removing(or stripping?) till the start of the first sequence header right?

[Guest]

No. I mean do you just want the closed GOP flag to be set? Or do you want (in adition to setting the closed_gop flag) leading frames that are missing forward references to be replaced with copies of the first decodable frame?

[AllTimeSToneD]

Yes i would like the Closed GOP to be set, but instead of duplicating the first decodable frame for the missing reference wouldn't it be better and rather mpg conform to drop the leading incomplete GOP frames?

Lets assume the stream starts like this:

stream:
B B I P B B P B B P B B

your suggestion is to duplicate the first decodable frame which would be the I-Frame afaik to replace the forwarding reference so it would end up like this (please correct me if im wrong):
I I I P B B P B B P B B

most tools that close the opening GOP would Drop the two B frames and would start outputting the stream like this:
I P B B P B B P B B

I hope this clears out our misconception :D (if any)

[squid_80]

Before recently, I just used the default IDCT. Now after looking at them more closely, I like Skal because it is faster.

There's a SSE2 version of Skal's IDCT in xvid's source. The output matches the 32-bit SSE2 IDCT already in dgdecode/dgindex so it should give the same quality at greater speed for SSE2 users, if you felt like adding it.

[levick]

Hi Neuron2 and team,

Firstly thanks for a great program, one of the marvels for video work.

I have been following the threads with interest however, could you comment on my findings please.
I have been "save project" on an mpeg file for some years with perfect results.


I decided to use Vob Blanker to get the required Vobs for my project. I then run “save project” and Demux to generate the d2v file needed.

Then using the same script I use for loading CCE (very simple script only) I noted the frame amount appeared correct but the time is different by at least 15 minutes.

If, I then process the demuxed mpeg file by generating another d2v file on the mpeg file and then load the new file into CCE the frames appear the same but the total time is correct.

Any comments would be welcome.

Regards,

Levick

[Guest]

If, I then process the demuxed mpeg file by generating another d2v file on the mpeg filePlease post links to the D2V generated from the original and the D2V generated from the demuxed MPEG file. Or attach them if you wish.

[levick]

Thanks Neuron2, I will need the files from my home system which is currently
transcoding the mpeg file. I will reply later on tonight my time.

Once again thanks.

[Guest]

OK, since you're down under, I'll probably only see it in the morning my time.

[levick]

OK, since you're down under, I'll probably only see it in the morning my time.
As not to offend do I cut and paste or is there another way of sending the files.
my first time for more then "text" postings.

[Matrics]

You can even attach them. It's not big deal, use "Attach Files" from "Additional Options" table; right under "Reply to Thread" table ;)

[Guest]

Or you can upload them to my FTP server and notify me here.

[levick]

Or you can upload them to my FTP server and notify me here.

Well it seems I may have shot of my mouth without further testing.
I had a look at both d2v files and there was not much difference with the
exception of vob and mpeg file location in relation to positioning on the HD.
And the steam type.
So I did a reboot and re generated the d2v file and frame served into CCE.
This run showed the times to be perfect.
I will keep testing, but at this stage, like to apologise for jumping the gun.

Regards,

Levick. :stupid:

[B.F.]

I put DVD on the our server, and link up it using a network drive.
Server was disconnected just fo one or two seconds but encoding just freeze.
I don't know the reason but it is DGDecode or Vdub.

[Guest]

I put DVD on the our server, and link up it using a network drive.
Server was disconnected just fo one or two seconds but encoding just freeze.
I don't know the reason but it is DGDecode or Vdub. I don't have a network to do tests. I suggest not doing encodes across a network, especially if it is error prone.

[Guest]

This beta is revised as follows:

* Revised the video error handling to prevent macroblocking in some error cases, and to prevent incorrect frame delivery leading to AV desync in some error cases.

* A default save file name is now set in the Save Project dialog.

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

[stax76]

:thanks:

[SeeMoreDigital]

My apologies if this has been asked before but... would it be possible to add detection of subtitle streams... together with de-muxing of same?


Cheers

[Guest]

My apologies if this has been asked before but... would it be possible to add detection of subtitle streams... together with de-muxing of same? I don't have any technical information about how to do it. Can you point to any?

[SeeMoreDigital]

I don't have any technical information about how to do it. Can you point to any?I wish I could...

Apart from the subtitles that are available via DVD sources, I guess there will be different types for DVB-C, S and T, as well as for all the other types of std-def and high-def digital TV sources :eek:


Cheers

[fccHandler]

I know a little something about subtitles on DVD...

Like AC-3 and LPCM, they are stored in private_stream_1 and each packet payload begins with a "substream" byte immediately following its PES header. Note that an AC-3 packet includes 3 additional bytes of information (6 for LPCM), but subpictures don't. I believe the substream number ranges from 0x20 to 0x3F for subpictures. The pictures are RLE-compressed bitmaps, 2 bits per pixel.

Demuxing the stream is easy, but detecting the language would probably require you to parse the IFO. That part I know absolutely nothing about...

[ARDA]

vStrip and SmartRipper have demux options for subtitles.

I have never looked into the sources, just a suggestion, I remember to have used Vstrip some years ago, but cant say anymore.
Rejig also uses Vstrip sources to demux subtitles.Dvd2avinic uses vobsub to extract subtitles
Maybe this can be usefull
ARDA

[Cyberia]

We actually had this on the list at one point. It sounds like a great idea at first. But then I actually messed around with subtitles myself. What a mess.

They can come as text or bitmap formats. The bitmap formats must be converted to a text form using OCR. A program called SubRip does this, and it can directly extract from the Vobs.

Then you have to get VobSub and either hard-burn the subs in, or just mux them into an Avi (which again requires a special program, either AviMux, or VdubMod) or you could use an advanced format like MP4/OGM/whatever.

Now... about doing it in DGIndex.

It would be nice to have a one shot everything demuxer. As long as we are talking about the demuxing of the raw streams and not doing something TOTALLY outside of DGIndex's purpose (eg: OCR conversion)

Is Close-Captioning also considered a 'subtitle'? Or does it have yet another stream(s)?

You'll probably have to parse the IFO file to get languages, but this has the advantage that you can also get the AUDIO languages identified too.

[Guest]

Version 1.4.1 beta 5 provides these new features:

* The CLI now supports demuxing the video (-OFD).

* Fixes for bugs in YV12 upsampling, i.e., upConv=true (fixes by tritical).

* When repeat flags are present give Film/Video percentages instead of
FILM/NTSC percentages. This avoids showing a PAL video as NTSC in some cases!

* The command line buffer has been increased to 4096 bytes. If you use a DOS shell instead of programmatic invocation, you will be limited by the capability of the DOS shell.

* The Info dialog window is dismissed upon any of these events: new file(s) opened, right/left arrow buttons hit, scroll operation on timeline.

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

[tritical]

Since dgdecode no longer includes YV12toYUY2(), could a way to force a specific upsampling mode (interlaced vs progressive) when upconv=true in mpeg2source() be added? I am asking mainly for three reasons:

1.) avisynth's conversions are not exactly the same
2.) the progressive frame flag cannot always be trusted (related to 1)
3.) it would make testing/comparisons easier

I was thinking maybe a new parameter similar to iPP such as iCC. Another possibility is changing upconv to an int, but that would break compatibility with anything currently using it as a bool.

[Guest]

Sure, I'll do it tonight. I don't care too much about backwards compatibility for upConv. I never liked the name anyway.

[mic]

They can come as text or bitmap formats. The bitmap formats must be converted to a text form using OCR. A program called SubRip does this, and it can directly extract from the Vobs.

Is Close-Captioning also considered a 'subtitle'? Or does it have yet another stream(s)?

You'll probably have to parse the IFO file to get languages, but this has the advantage that you can also get the AUDIO languages identified too.
Subs are an overlay video track of sorts on a DVD, so you'll always get a stream. It can be OCRed to convert to text, but as when stripping an ac3, you don't always need to. As far as other prog. that strip sub streams, think they do it as DGIndex does tracks -- let the user decide which is which, sort them out.

As far as CC on DVD, there is often a stream, plus CC being stored in the mpg2 itself. Vobsub I think can strip the stream -- I'm unsure if there's a way to access that part stored in the mpg2 other then parsing it with Graphedit (see SCC Tools site).

While CC data is text, it can require a bit of editing to suit a lot of folks. This is changing (or has changed?) with newer DVDs & even digital cable etc. using same basic text as subs, ending the biggest hassle of all, converting from all caps. And that's one difference between subs and CC, the other being the inclusion of sound effects or cues, which are a trivial matter to remove in Subtitle Workshop.

[tritical]

Sure, I'll do it tonight. I don't care too much about backwards compatibility for upConv. I never liked the name anyway.
If you're gonna change it, could I also suggest the ability to have dgdecode output rgb24 as well as yuy2? I've been looking at the other color conversion routines in dgdecode (422->444 and 444->rgb24), and the 422->444 routine is ok except it needlessy duplicates 7 pixels on the right side of the image instead of interpolating, also an isse version could be significantly faster than the current mmx routine. The 444->rgb24 routine is ok except that it always uses BT.709 coefficients instead of following the matrix_coefficients value. Currently those issues would only effect dgvfapi or anyone using the methods at the bottom of AVISynthAPI.cpp. I've got a fix for the 422->444 routine and made an isse version, wondering if I could get the current source to play with? Thanks

[Guest]

How's about I give you the 141b5 source and you can make all the changes? :)

[Guest]

@tritical

Here is the source code for 141b5:

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

@all

This is not an official release. Please do not redistribute it. Thank you.

[Guest]

Version 1.4.1 beta 6 includes various changes/fixes for upsampling by tritical. These apply as appropriate for DGDecode, DGIndex, and DGVfapi:

* upConv can now be set to 3 values: 0, 1, and 2. 0 = do nothing,
1 = YUY2 output, 2 = RGB24 output... for the case that the input is 4:2:2
then 1 is the same as 0.

* Added iCC parameter. iCC=true uses interlaced YV12->YUY2 upsampling,
iCC=false uses progressive YV12->YUY2 upsampling, and leaving iCC unset
makes it switch based on the progressive_frame flag.

* Fixed a little problem with the 422->444 conversion, fixed a problem with
the 444->RGB24 conversion where it wasn't correctly handling pixel values
that came out as < 0, and added a faster isse 422->444 conversion. I also
modified the 444->RGB24 conversion so that it uses the correct coefficients
(indicated by the matrix_coefficients value).

* Added a way to force DGVfapi (and the DLL access functions) to follow
the progressive_frame flag.

* Added a Colorimetry box to the DGIndex Info dialog.

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

Thank you, tritical!

[Guest]

Version 1.4.1 beta 7 provides these major changes:

* Top-level picture decoding (slice and macroblock layers) was completely
redesigned to dramatically improve resilience to video errors, and to correct
some spurious video errors due to bugs in the old approach. The previous
design is a legacy of the original MSSG reference decoder, and was inherited
from DVD2AVI. The new design was adapted from fccHandler's
excellent VirtualDub MPEG2.

* Modified the Info dialog display of video errors to show text reasons
instead of numbers.

This version solves the known outstanding issues with "weird blocks". However, it required a major re-write, actually performed twice, once for DGIndex and once for DGDecode. Although I was very careful and regression tested things for several hours, there could be new minor problems introduced. This version is close to what I want for 1.4.1 final, so your feedback will be greatly appreciated.

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

EDIT: See post below!

[Guest]

Oops. If you downloaded before this current post, please redownload. I had uploaded a local hack (to test no-I-frame streams) instead of the real beta. :)

[Chez_Wimpy]

Sorry if this was asked before, but I just upgraded after a long interval, and I noticed that with DGIndex (as compared to dvd2avi) that the most recent directory saved to (for "Save Project") is not remembered. This is a minor nit, but is it possible to include an option to make it default to the used last directory? Thanks for a great piece of software (and the constant updates!).

[Guest]

I just fixed that last night after Jem pointed it out at my forum. It was a result of adding the default save path feature. It will be in the next beta/RC.

[Zep]

wow great work you two (three?) Just keeps getting better and better
by huge leaps and bounds!


Thx for all the hard work!



Zep

[Guest]

Let's get this puppy out the door! Version 1.4.1 RC1 provides these changes from 1.4.1 Beta 7:

* The Save Project path is now properly saved.

* Added "fccHandler" to the credits listing in the DGDecode manual.

* Revised the playback speed option. It now gives 5 checkable menu
choices: super slow (5fps), slow (10fps), normal (plays reliably at the
correct frame rate for the stream), fast (2 times normal), maximum (as fast
as possible).

* A warning box is popped up if Force Film is used inappropriately. The user
can decide whether to proceed anyway or to cancel.

* The leading number on the file path lines at the top of the file was
eliminated. This makes editing the D2V file to change paths easier. The D2V
file format version is therefore bumped to 11, and you will need to remake
existing projects.

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

[Guest]

wow great work you two (three?) All the users who kindly provide feedback need to be acknowledged too.

You're just in time for 141RC1. Avery (phaeron) told me how to reliably play back at real time rate in a relatively easy way (no messy threads and thread sync).

[fccHandler]

* Added "fccHandler" to the credits listing in the DGDecode manual.
*blush*

I don't think I've ever thanked you for DGMPGDec. I don't do much DVD ripping, but if I did I wouldn't dream of using any other tool. Thanks!

[SeeMoreDigital]

Avery (phaeron) told me how to reliably play back at real time rate in a relatively easy way (no messy threads and thread sync).The revised playback features work very well indeed now... many thanks.

Given that we now have the "Super Slow" feature. Would it be possible to include "Frame Accurate Seeking" by using main slide bar and the keyboards "left" and "right" arrows, while the Preview box is still open?


Cheers

[scharfis_brain]

I have a feature request for DGindex.

I like to create demuxed sound and video off a DVD-ROM-Drive with dgindex.
But after creation of the project file/demuxing, I need to re-run DGindek over the demuxed m2v again, because the initially written d2v-project file refers to my DVD-ROM-Drive instead to the demuxed m2v.

[Guest]

Given that we now have the "Super Slow" feature. Would it be possible to include "Frame Accurate Seeking" by using main slide bar and the keyboards "left" and "right" arrows, while the Preview box is still open? That thought occurred to me as well. The mechanism for pacing playback just inserts a delay before displaying each frame. So if the delay is changed to a wait for a button to be pressed, we could have single-stepping forward. But it would not allow for stepping backward, nor would it allow for performing the other actions that frame accuracy implies, such as arbitrary cut points. However, if it was thought useful, it might be worth adding a new mode called Single Step, and then enabling the right arrow button when in that mode.

Another problem that should probably be fixed, because this mode would make it more noticable, is the possibility of displaying a few macroblocked frames at the beginning of a play/preview. This occurs because the full random navigation code of DGDecode is not present in DGIndex. But adding that code would begin approaching full frame accuracy and would mitigate the need for the single step mode described above.

So I'm still thinking about where to go with this.

[buzzqw]

@scharfis_brain

you can edit the d2v changing the path of m2v... (last time i used this trick the d2v resulting was OK)

BHH

[Guest]

I like to create demuxed sound and video off a DVD-ROM-Drive with dgindex. But after creation of the project file/demuxing, I need to re-run DGindex over the demuxed m2v again, because the initially written d2v-project file refers to my DVD-ROM-Drive instead to the demuxed m2v. Why does it matter? The video served by DGDecode will be the same in both cases. I'm missing your point.

[xDrJx]

Don't know if this belong here but I do know it's more then deserved: :thanks: for all the hard work, it's more then appreciated
:thanks: again

[Guest]

you can edit the d2v changing the path of m2v... (last time i used this trick the d2v resulting was OK) No, because the file offsets recorded in the D2V will be wrong. Linear play from the start might be OK, but random access will be totally screwed up.

scharfi's idea could be difficult to implement. I'll think about it but I am not optimistic.

[SeeMoreDigital]

... we could have single-stepping forward. But it would not allow for stepping backward, nor would it allow for performing the other actions that frame accuracy implies, such as arbitrary cut points. However, if it was thought useful, it might be worth adding a new mode called Single Step, and then enabling the right arrow button when in that mode..... So I'm still thinking about where to go with this.Thanks for the reply.

A "Single Step" forward (or Frame Advance) mode would be very useful for what I use DGIndex for. Would it be possible to make the main slide bar active also? So if you miss the frame you want, you can go back and try again.


Cheers

[Guest]

Would it be possible to make the main slide bar active also? So if you miss the frame you want, you can go back and try again. No, that would require too much hacky stuff. You'd have to stop preview, navigate, and start again.

[Inc]

* The leading number on the file path lines at the top of the file was
eliminated. This makes editing the D2V file to change paths easier. The D2V
file format version is therefore bumped to 11, and you will need to remake
existing projects.

Hi Donald,

I think thats quite a big change for other Apps. which in their state now do parse the resulted d2v for accessing the used source VOB(s). Im not shure but some Apps do readout the d2v at the given line and parse the VOB file for getting informations of the stream which aren't served by openMPEG2Source() i.e..
In most programming Environments does exist a command for eleminating Letters in a string at a given startpos. using a given count, so I think there would be less trouble for exisiting Apps. then just using a string handling command when coding.

;)

Thanks

[Guest]

@incredible

I cannot decipher what you are suggesting or asking.

If you are objecting to a change in the D2V file format, be advised that there have been several since the apps you mentioned were created. If they want to be compatible with the latest DGMPGDec, then they will have to be revised. I cannot halt evolution just because some third-party apps exist.

If you are objecting to the loss of the count field, be advised that it can be easily regenerated programmatically by using strlen().

[len0x]

I was wondering, if CLI was updated to allow multiple audio tracks to be demuxed in one go - does it make sense to do the same for audio PIDs in transport streams?

[Amit]

@neuron2,

I ran the latest build v1.4.1 Beta 7 on a very peculiar movie (NTSC R1). This is an interlace movie but has RFF flags which are playing with the field order. You can get a sample clip and more information at http://forum.doom9.org/showthread.php?t=98921

I would like to see this kind of support in your program since you are basically improving and doing things that original DVD2AVI cannot do.

TIA
-Amit

[Guest]

I would like to see this kind of support in your program Old news; it's already there: Tools/Fix D2V.

[Guest]

I was wondering, if CLI was updated to allow multiple audio tracks to be demuxed in one go - does it make sense to do the same for audio PIDs in transport streams? And multiple video demuxing, too, right? :)

Is this something you really need, or are you just epitomizing Emerson's hobgoblin?

[len0x]

Mutiple video demuxing? Nah :) As a matter of fact I don't find video demuxing a particulary useful feature at all.

About audio: I'm not sure how many people actually process multiaudio TS, but in Europe its pretty common I guess to have multiple languages in digital broadcasts, so if people want to keep some of them then its useful to be able to demux multiple ones. But its not something crucial to the process that I really need - just a thought since normal audio demuxing was improved this way.

[midnightsun]

Hey there neuron2,

would it be possible for dgindex to have the capability to write a .txt-like file of all the I-frames positions in a given video stream? Some sort of "parse .D2V and write I-frames' positions" option; something like

0
12
24
36
44
56
68
78
90
......

[Guest]

would it be possible for dgindex to have the capability to write a .txt-like file of all the I-frames positions in a given video stream? Some sort of "parse .D2V and write I-frames' positions" option Tools/Parse D2V already makes this information available, e.g.:

[GOP]
15 [B]: 15,15...................2
16 [B]: 16,16...................2
17 [I]: 17,17...................2
18 [B]: 18,18...................2
19 [B]: 19,19...................2
20 [P]: 20,20...................2
21 [B]: 21,21...................2
22 [B]: 22,22...................2
23 [P]: 23,23...................2
24 [B]: 24,24...................2
25 [B]: 25,25...................2
26 [P]: 26,26...................2
27 [B]: 27,27...................2
28 [B]: 28,28...................2
29 [P]: 29,29...................2
[GOP]
30 [B]: 30,30...................2
31 [B]: 31,31...................2
32 [I]: 32,32...................2
33 [B]: 33,33...................2
34 [B]: 34,34...................2
35 [P]: 35,35...................2

If you are looking for the specific output format you've given, then you could write a simple utility to generate it from the Parse D2V output, for example (using 'awk'). What is the motivation?

[zettai]

I'm getting blocking when decoding a vob file using RC1 for making the d2v and decoding using avisynth 2.5.5

I've uploaded a demuxed section which should show the problem on frame 150 or so. Look for file VTS_28_PGC_01_1.demuxed.m2v on the ftp to confirm. This problem doesnt appear when using virtualdubmod to load the m2v.

I dont know if this is also a problem with older versions of dgindex yet.

[Esc]

Hi Donald,
I have a problem with RC1. If I drag the scroller with mouse, the information window is closed. I really hope it's not a new feature. :)
Thanks for the great work!

[Guest]

Hi Donald,
I have a problem with RC1. If I drag the scroller with mouse, the information window is closed. Yes, it's a new feature. The information is intended to be valid only during a play/preview operation. What were you using it for?

[Guest]

I'm getting blocking when decoding a vob file using RC1 for making the d2v and decoding using avisynth 2.5.5

I've uploaded a demuxed section which should show the problem on frame 150 or so. Look for file VTS_28_PGC_01_1.demuxed.m2v on the ftp to confirm. This problem doesnt appear when using virtualdubmod to load the m2v. I see that the first two frames are bad because the stream claims that the first GOP is closed but it isn't. If it was properly marked as open, then they would be replaced with the first decodable frame. VirtualDub MPEG2 just discards those frames.

But I don't see any blocking at or around frame 150. Please give me your script and tell me the exact frame number. Also give me the DGIndex settings. I'm not reproducing the problem. A screenshot of the blocking would be useful, too.

[Guest]

I'm getting blocking when decoding a vob file using RC1 for making the d2v and decoding using avisynth 2.5.5. The problem is that every GOP is marked as closed when they aren't. Did you rip this directly off a commercial DVD? I need to know the origin of this VOB before deciding what to do. Is it something you encoded and erroneously forced the setting of the closed GOP flag?

Technical note: If the GOPs are closed, DGDecode doesn't need to decode the previous GOP when trying to decode randomly-accessed leading B frames. But your stream has leading B frames that require the previous GOP, but the GOPs are marked as closed. So strictly it is a bad stream. I could work around it by always assuming GOPs are open, but that would degrade responsiveness of random access.

This problem is present in previous versions because it is in fact a stream problem.

Note that this affects only random access; it doesn't occur if you just play linearly from the start, so your encodes will be OK.

Finally, it's possible to edit the D2V file to make it work (clear the bits that say the frames don't require the previous GOP). It might be worth adding a utility to do that.

[zettai]

It's a commercial DVD I'm afraid. Plus, I actually need to be able to view this with random access if at all possible as I'm editing it in a NLE. I'd be happy to hack the d2v file if that will fix the problem.

[Guest]

OK. I'll add a new entry to the option menu tonight and release a new RC.

[Esc]

Yes, it's a new feature. The information is intended to be valid only during a play/preview operation. What were you using it for?
Those PGC numbers are very handy for tracing anime episodes that are recorded as 1 program. I would slide the scroller looking at them. And if I see 1-3, 1-4, etc., then I am still on ep1. If they have switched to 2-1, 2-2, it's time to stop and go back. Eventually I zero out on the moment where first 1 becomes 2 and it's the best place to cut off the first episode. I mark this point as the end of selection, make my d2v and continue with the second ep, and so on.
Why don't you just blank the incorrect information at the time of scrolling? Isn't that what you used to do in earlier versions, anyway?

[Guest]

@zettai

Try Version 1.4.1 RC2:

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

Set the "Force Open GOPs in D2V File" option before saving your project.

[Guest]

Those PGC numbers are very handy for tracing anime episodes that are recorded as 1 program. Would you be happy if that information appeared in the DGIndex window's title bar?

[Esc]

Would you be happy if that information appeared in the DGIndex window's title bar?
I just need the information. I don't care where does it come from as long as it's usable. :D
How about using status bar instead, btw?

[Guest]

I just need the information. I don't care where does it come from as long as it's usable. I'm going to pretend that you said "That would be fine. Thank you very much."

[Esc]

THANK YOU A GREAT BUNCH! Your work is valuable beyond all limits. DGIndex is one of the most useful utilities in video processing and I praise your talent and dedication every time I open it. I had no intention of offending you since I fully comprehend the fact that your work is one hundred percent voluntary and unrewarded.
I humbly suggest using status bar though. But only because I think it would look cooler and not overcrowd the title bar. Of course, if it is not too much bother.

[Guest]

What have we here?

* New DGIndex users manual created by Cyberia.

* VOB/CELL IDs now displayed in the title bar.

* Log quant matrices menu item moved to Options.

Thank you Cyberia, for the great users manual!

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

[Zep]

All the users who kindly provide feedback need to be acknowledged too.

You're just in time for 141RC1. Avery (phaeron) told me how to reliably play back at real time rate in a relatively easy way (no messy threads and thread sync).

Avery is helping out now too? wow you have one heck of good team i must say :)

What is funny I DL a new version come back 2 days later and there is a
newer version. I can't keep up! (that is a VERY good thing lol )

Thx

[SeeMoreDigital]

Avery is helping out now too? wow you have one heck of good team i must say :)Agreed.... I use DGindex all the time for my part-time projects... I don't know where I'd be without it...

Many, many, thanks guys

[zettai]

Just to let you know, my problems are now fixed with the new GOP options. Thanks!

[Guest]

Avery is helping out now too? Not formally as in contributing code. I had posted at the VirtualDub forum asking how he achieved playback pacing in VirtualDub, and he responded with some valuable ideas. Here is the posting for those interested to see it:

http://forums.virtualdub.org/index.php?act=ST&f=11&t=9985

[Cyberia]

Thank you Cyberia, for the great users manual!

Gonna make me blush. :p

Thank YOU for the great work!

[CptRobby]

OK..I'm having trouble right now working with a DVD that has multiple angles...I wanted to avoid posting a question that's already been posted before, so I did a little searching before hand and found that, apparantly, multi-angle processing is currently not (and/or has no plans to be) supported in DGIndex.

I also found a bit of information on how the multi-angles work, both from searching the forumns and also using tools like Chapter-X-tractor to look at the files and came up with a (workable) solution to this problem and also happens to be a feature I've been hoping to see for a while for other reasons...

Since angles are stored on different vob-ids (ex: with the one I'm working on, angle 1 is on vob-id 8 and angle 2 is on vob-id 9) if you could put in an option to select which part you want to use by vob-id (and possibly cell-id too) (kinda like the way vobsubconfigure works) then I could just select the vob-ids for the angle that I want to use and rip away...

It would certainly be preferable if you could select the vob-ids/cell-ids non sequentially (ie: 1 - 3 - 4 - 6) But if that's not possible, or requires too much meddling, then just being able to create 3 simple D2Vs (1, and 3 - 4, and 6) would be enough. Then I could just create AVS files and throw them together in VirtualDubMod.

The other reason why I would like this feature is because I do alot of anime and TV episodes, and like Esc was saying before, often times you want to just select certain vob/cell-ids at a time. This would certainly make it alot easier to do!

Anyways, it could be that you've already gotten a suggestion along this line and found that it's not possible to do. I didn't find anything when I tried to search for it, but if that's the case, then just slap me with a link to it and continue what you were working on. lol

And thank you very much for all your hard work!
Robby :)

[Esc]

CptRobby, are you trying to use DGIndex directly on DVD? Because DVDDecrypter in ifo mode does select only one of the angles and you have no problem if you rip the dvd with it first.

[Zep]

Not formally as in contributing code. I had posted at the VirtualDub forum asking how he achieved playback pacing in VirtualDub, and he responded with some valuable ideas. Here is the posting for those interested to see it:

ahhh ok


http://forums.virtualdub.org/index.php?act=ST&f=11&t=9985

interesting read. yup he does know the ways of low level timing lol
some of his numbers were surprising. 9x 55ms OUCH.

[Guest]

OK, folks, unless bugs are found, this will be the last RC. This release has two nice little surprises. One is pretty obvious. See if you can find the other one. No fair looking at the changes list! First person to spot it gets an atta-boy.

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

I also added dvd2svcd to the Credits listing in the DGIndex manual, as I had inadvertently dropped him. If I've missed anyone else, please let me know. Thank you.

[Cyberia]

Oh....Oh....Oh.....I know!!!

[CptRobby]

CptRobby, are you trying to use DGIndex directly on DVD? Because DVDDecrypter in ifo mode does select only one of the angles and you have no problem if you rip the dvd with it first.

No, I'm using DGIndex on a ripped copy on my HD...And Yes, I do know about DVDDecrypter's IFO mode...I've tried it once before and it caused the copy I made to not work so I just always used the file mode and copied everything...I've never had a problem like this before...

But really this isn't about making it so that I can get this copy to work, that's not really important since I can just rip it again in IFO mode (hopefully I can figure out how to get it to work this time)

The reason why I made the suggestion was because I think it would be a good feature to have in general. And really what I was suggesting was only a WORKABLE solution to the problem of multi-angles...I wouldn't suggest making an actual solution to the multi-angle situation at this stage because it would require changing alot of stuff in the code (it would have to analize the IFO file to detect multiple angles at the very least along with a bunch of other stuff) in addition to making it able to select specific vob/cell ids. I can't imagine that there would be a way to do it without that functionality.

So anyways, I just think that this is the best next step in the evolution of DGIndex (on this front anyways, I'm sure there are probably other things that others have noticed that might even be more important than this...) ;)

Robby :)

Edit after DLing release:
There's a DGDecode manual...coolness! :)

[CptRobby]

SPIKE! LOL He IS the uber coolness! ;)

[Guest]

Oh....Oh....Oh.....I know!!! Atta boy! ;)

[Guest]

So anyways, I just think that this is the best next step in the evolution of DGIndex... User suggestions are always welcome. Thank you for yours.

[SeeMoreDigital]

User suggestions are always welcome. Thank you for yours.Errrrm!

Could it be possible to make it so we can place our own images/logo's in the start-up panel (I can feel the knives in my back already)?

And how about some links under the "Help" button pointing to those lovely new "html" documents?


Cheers

[Guest]

Could it be possible to make it so we can place our own images/logo's in the start-up panel (I can feel the knives in my back already)? What, you don't like Spike? That has some very sentimental meaning to me, which manono will understand well. And it's got to be an improvement over a black rectangle. I'll consider it for the next version. Skins for DGIndex...LOL.

And how about some links under the "Help" button pointing to those lovely new "html" documents? Done. Thank you for the suggestion.

You seem to have changed your avatar. :confused:

[SeeMoreDigital]

What, you don't like Spike? That has some very sentimental meaning to me, which manono will understand well. I'll consider it for the next version.I thought I'd been hacked when I first fired up RC4 :scared:

If you do decide to offer image selectivity. How about offering it in a similar way to MediaPlayer Classic?

You seem to have changed your avatar. :confused:Yep... It's an still from "House" (http://www.tv.com/house/show/22374/summary.html?q=House) and was cropped from this picture: -

http://tinypic.com/b80lrp.jpg


Wonderful

[Guest]

If you do decide to offer image selectivity. How about offering it in a similar way to MediaPlayer Classic? Would you care to enlighten me about that, as I do not use that software? Thank you.

[SeeMoreDigital]

I'm unable to tell you how it's done... but you are given a choice of stock logo's. Plus the option of navigating and selecting any image of your choice...

Like this: -

http://img6.imageshack.us/img6/3595/mpcexample0ku.gif


Hope that helps?

[Guest]

I'm unable to tell you how it's done... That's the easy part. I didn't know what their UI was for it. I can do that in 1.4.2.

BTW, if you (or anyone else) would like to submit a BMP before I go final, I'd consider using it. It has to be the size of the DGIndex window with no file loaded. It can be a little bigger (due to clipping), but no smaller.

[SeeMoreDigital]

Blimey... I thought this was going to be really difficult to do.... So ideally proposal images need to be 480x270 pixels?


Cheers

[Guest]

So ideally proposal images need to be 480x270 pixels?
498 x 312 is good.

[Cyberia]

I uploaded five pics as my submissions.

cyb_pics.zip

[Guest]

I like the Dali. (But they have to be BMP files, not JPGs.)

I changed DGIndex to use Spike unless you put your own BMP file in the DGIndex.exe directory.

[Guest]

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

[Leak]

I changed DGIndex to use Spike unless you put your own BMP file in the DGIndex.exe directory.
Are you sure Bandai/Sunrise is going to like this? :eek:

(Not that I don't own all of Cowboy Bebop, but still...)

np: Pedestrian - The Toss & Turn (Anticon Label Sampler)

[Guest]

Are you sure Bandai/Sunrise is going to like this? Fair point.

I changed the executable so that it doesn't load a default Spike. If anybody downloads splash screens from my web site and puts them in their DGIndex directory, I don't know anything about it.

[SeeMoreDigital]

Donald you're a star!

Thanks so much for adding the single frame advance feature (while still displaying the frame number).... I feel truly blessed :D


Faaaaantastic!

[Guest]

Thanks so much for adding the single frame advance feature (while still displaying the frame number) You're welcome. But be careful...the frame numbers in the Info dialog start from the point where playback starts; they're not valid frame numbers in the whole file.

[SeeMoreDigital]

As a matter of interest, how much detail can DGIndex be configured to reveal about an MPEG-1 or 2 stream?

For instance, would it be possible to flick thru' a stream, one frame at a time and know whether it's an I, P or B frame?


Cheers

[Tima]

Donald, thank you for your work!

Could you make "Information" window a little narrower? It'd be much more comfortable to use DgIndex at 1024x768. :)

BTW, why dgindex.exe is 2x bigger than 1.40?

[sorry for my bad Eng.]

[Guest]

As a matter of interest, how much detail can DGIndex be configured to reveal about an MPEG-1 or 2 stream?

For instance, would it be possible to flick thru' a stream, one frame at a time and know whether it's an I, P or B frame? I don't know what you mean by "configured" in this context. I could expose anything with appropriate coding.

[Guest]

Could you make "Information" window a little narrower? That's too vague to respond too. Do you mean 1 pixel, 5, 15.... ?

BTW, why dgindex.exe is 2x bigger than 1.40? I'll update the distribution with a version without the "Spike" resource.

[SeeMoreDigital]

I don't know what you mean by "configured" in this context. I could expose anything with appropriate coding.With me not being a techie in such matters I guess I'm using the wrong expressions...

But when I was scanning thru' one of my .VOB files at one frame at a time, I got the idea that it might be kinda neat to know what type of frame (I, P, B) I was on!


Cheers

[Guest]

With me not being a techie in such matters I guess I'm using the wrong expressions... You're not? Now you've disillusioned me.

I've been trying to catch up to your post count for years. Now I'm closing in. Can't you take a vacation or something. I hear Brasil is an attractive destination.

But when I was scanning thru' one of my .VOB files at one frame at a time, I got the idea that it might be kinda neat to know what type of frame (I, P, B) I was on! You can see it in DGDecode's info display, but it might be worth adding to DGIndex. Maybe some extra fields could appear when single step mode is on.

[Tima]

That's too vague to respond too. Do you mean 1 pixel, 5, 15.... ?
I think about something like this:
http://for_spam.gorodok.net/Inf_new.GIF
(sketch, made in mspaint :) )

It is not very much, but IS better, IMHO. I'm not sure this is worth bothering.. well I'm not the one to decide.. :)


And here is a bug suspicion: sample, 428032 bytes (http://for_spam.gorodok.net/VTS_01_1.VOB). DGIndex doesn't decode it properly when stepping forward through frames right after importing. When stepping backwards, it's OK. Also, it's impossible to REselect the whole length of the clip using the timebar and selection buttons.

Thanks.

[Guest]

And here is a bug suspicion Do you guys wait for the release to report these things just to torment me? :)

FWIW, if you generate a project and serve the video it is correct.

I'll look into it.

EDIT: The video has 7 frames, each coded as a sequence with a sequence end code, and each one specifying different quant matrices. The sequence end codes were stopping DGindex from picking up the new quants. I'll fix it in the next beta. Fortunately, it's very unusual video. Thanks for bringing it to my attention.

[SeeMoreDigital]

You're not? Now you've disillusioned me.

I've been trying to catch up to your post count for years. Now I'm closing in. Can't you take a vacation or something. I hear Brasil is an attractive destination. Arrr.... your posts however are.... quality consistent!

When I look back at some of my earlier posts they make me want to cringe! So I don't suppose I'm up to being "Moderator" material ;)

You can see it in DGDecode's info display, but it might be worth adding to DGIndex. Maybe some extra fields could appear when single step mode is on.I must admit in my enthusiasm for DGIndex I've neglected DGDecode.... I must start thinking "outside of the box" more!


Thanks again DG

[Tima]

EDIT: The video has 7 frames, each coded as a sequence with a sequence end code, and each one specifying different quant matrices. The sequence end codes were stopping DGindex from picking up the new quants. I'll fix it in the next beta. Fortunately, it's very unusual video. Thanks for bringing it to my attention.

Wow, It's really unusual :) Thanks for the explanation.

[d'Oursse]

neuron2: there are only "minor" changes in this version (for dgindex) ? No change of design ?

[Doom9]

the size of the executable has gone up dramatically, undoubtedly due to the inclusion of the background image. Since it adds nothing in terms of functionality, somebody has to be the devil's advocate and ask if that kind of cosmetics was really necessary.

[Cyberia]

the size of the executable has gone up dramatically, undoubtedly due to the inclusion of the background image. Since it adds nothing in terms of functionality, somebody has to be the devil's advocate and ask if that kind of cosmetics was really necessary.

He already answered this. (not often I can catch d9, so I had to do it)

I'll update the distribution with a version without the "Spike" resource.

[Cyberia]

@Tima: The width of the Info panel is directly tied to the font it uses. I was going to ask neuron2 if he was married to that font.

@neuron2: Are you married to that font? (That the Info Panel uses?)

[Guest]

neuron2: there are only "minor" changes in this version (for dgindex) ? No change of design ?The changes listing describes at least one major design change regarding the slice/macroblock layer.

Was there something else you were hoping for? I don't recall hearing any suggestions from you.

I'm sorry to have disappointed you. I'll try harder next time.

[Guest]

Are you married to that font? (That the Info Panel uses?) AFAIK, it's determined by Windows. Anyway, what's the big deal? And again, all this time developing 1.4.1 and it's only *after* I release it that it becomes an issue!?

Sometimes I wonder why I bother.

Good night, all. I'll try to do better next time. If there is one.

[Guest]

neuron2: there are only "minor" changes in this version (for dgindex) ? No change of design ? I consider the slice/macroblock parsing changes to be major.

Was there something in particular you were hoping for? I don't recall hearing any suggestions from you. As you know, I always welcome suggestions and I try as hard as I can to respond to issues and problems.

[d'Oursse]

I consider the slice/macroblock parsing changes to be major.

Was there something in particular you were hoping for?
A change of design would have make my previous work useless
I don't recall hearing any suggestions from you. As you know, I always welcome suggestions and I try as hard as I can to respond to issues and problems.
Suggestions ? If I succeed in writing this lib, a big part of the remaining code needs to be rewritten. I didn't made any because when I started that, you were already writing the 1.4.1 version.

ok,, here are some ideas/suggestions (for dgindex only).

The main problem for me is that the gui is not apart from the remain of the code. There are global variables that are used for everything, everywhere, which make the code very hard to read and understand for someone who has not written it. Macros are used in a same manner. All the macros in getbits.c, for example.

So, I would create a global structure that contains all the variables that the gui needs. I would cut dgindex in 3 parts :

1) the parsing/creation of the d2v file/demuxing of audio.
2) the decoding of the video
3) the gui

When I say "cut", I mean that they are really independant. Point 1) and 2) depend only on the global structure that is mentioned above. They are just libs with an API. Point 3) calls the functions that are exported by these 2 libs in their api.

For eah point, i would follow some general ideas. For example, for point 1), I do the following:
a) I create a structure that contains all the needed variables. They can also just lie in a "private" file that is only usuable in this lib.
b) I have separate the audio and the video in separate files and separate directories. At least, someone who reads the code know where to look for if he wants to look at/debug the code.
c) I put the exported function in several files, so that it makes the code more readable.

The advantages:
a) It's easy to make a CLI for each part, which does not depend on useless part of the code. Small code for the work we ask for. No useless code.
b) The gui depends on the lib only by the api, which makes porting dgindex to other platforms (linux :D) easy, as only this part needs to be rewritten (I suppose that point 1) and 2) can be coded in C ANSI).
c) the pleasure of writing a beautiful code :)

Finally, I finish by the structure of the directories I would have create for this project (that thing is important for me):


dgindex
+-build
| +-linux
| +-win32
|
+-doc
| +-API
| +-Manual
|
+-src
+-bin (platform dependant code)
| +- Here lies the binaries, that is the gui_win32.c, gui_linux.c files, and the CLIs.
| Maybe the CLIs can be platform independant, or at least with small modifications.
|
+-lib (platform independant code)
+-parsing
| +-audio
| +-video
|
+-decoding (I have no idea for the directories i would make for the decoding)

I have other suggestions, but I stop here and wait for your comments.

[Guest]

I have other suggestions, but I stop here and wait for your comments. There is zero chance that I would ever undertake such a massive re-engineering. But feel free to tackle it as you proceed with your Linux port.

[Doom9]

He already answered this.I forgot the character was named Spike.

On another matter, would it be possible to turn the source selection into a cutting tool? I guess the video part of it wouldn't be too problematic, but I figure audio might be a pain, especially when audio is not being decoded.

[Guest]

I don't usually like to do this, but I thought it was important to get Tima's bug fixed, i.e., improper handling of sequence end codes. Therefore, here is version 1.4.2. The only change is the fix for sequence end code handling.

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

Source code is released at my web site.

@Tima

Your stream decodes properly with 1.4.2.

@Doom9

Can you please explain more by what you would want in the cutting feature? Thank you.

[davidf]

A small request for the next version of dgindex -(maybe not so small :) ) I looked at the code myself and sorta got lost, plus lack of c knowledge hindered me a little.

Would it be possible with the cli version to output things such as audio filenames and a/v delays to a text file. this would make life much easier when programatically using the cli version then creating scripts to do such things as audio resampling and a/v muxing.

TIA.
David

[Doom9]

Can you please explain more by what you would want in the cutting feature?Right now you have the [ and ] buttons right to the timeline - they allow you to select only parts of the source. There's one "in" cut and one "out" cout and everything in between is indexed when you create a project. Rather than just have one in and out cut, I'd like to have multiple ones, so that if I have a 10'000 frames source for instance, I could create a project containing frames 2000-3000, 4000-5000 and 6000-9999, and all in one project rather than creating three separate projects, one for each of the regions I mentioned.

[Tima]

Here are some other bugs with at least THAT sample:

- DGIndex doesn't displays the second frame when viewing the frames in reverse order (using arrows)

- When _clicking_ on the time bar, DGIndex displays nothing at all. :)

-[not a bug] The Super Slow mode isn't really super slow. :) Maybe 1fps would be more appropriate?

- when changing to any mode except Single Step, the '>' button is greyed out. It restores only after switching to Single Step.

[mgh]

When I load an mpg (1), i get warning saying force film is not advisable and am i sure.This happens regardless of the option chosen.It proceeds only when i say yes and then the d2v fails to load via avisynth. I have tried only with PAL mpgs,don't haveNTSC ones. :confused:
Have gone back to 1.4.0

[Guest]

When I load an mpg (1), i get warning saying force film is not advisable and am i sure.This happens regardless of the option chosen.It proceeds only when i say yes and then the d2v fails to load via avisynth. I have tried only with PAL mpgs,don't have NTSC ones. :confused:
Have gone back to 1.4.0 I duplicated the erroneous warning but not the failure to load via Avisynth. I cranked a new version 1.4.3 to fix the warning. Try it and post again if you still have problems.

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

[Guest]

- DGIndex doesn't displays the second frame when viewing the frames in reverse order (using arrows)

- When _clicking_ on the time bar, DGIndex displays nothing at all. These are well-known deficiencies of timeline navigation inherited from DVD2AVI. Can't say when I'll do anything about it.

- when changing to any mode except Single Step, the '>' button is greyed out. It restores only after switching to Single Step. If a file is not loaded, all the buttons should be greyed. The bug is that when you select Single Step with no file loaded, the > button gets enabled. When a file is loaded, the > button is always enabled when not playing/previewing, and during playing/previewing, it should be enabled only in single step mode. If that is not what you see, please tell me the exact steps you take to make it happen.

[Guest]

@Tima

The timeline bugs are well-known legacies from DVD2AVI. Can't say when I'll ever do anything about it. The > bug needs fixing right away.

@mgh

That needs fixing right away too.

I'll crank out a 1.4.3 tonight with these fixes.

[Guest]

when i say yes and then the d2v fails to load via avisynth Are you sure about that? I duplicated the spurious warning but not this part. Make sure you're not picking up an older DGDecode version (possibly in your plugins folder). Can you please double check and if it is still a problem tell me what the failure message is and if possible upload a source stream to my FTP and tell me the filename.

[mgh]

It says older version of d2v. Not possible because I have a DGIndex folder containing both and I use template.avs with following lines
loadplugin("C:\Program Files\dgindex\\DGDecode.dll")
mpeg2source("__src__",cpu=6)
Newer versions,i extract zip/rar file into same folder overwriting all files and I do not keep DGDecode.dll in my avisynth plugins folder.
Will upload small clip.

[Guest]

You're picking up an invalid DGDecode. You'll have to figure out why.

For one thing, your path has two backslashes.

I would search the harddisk for all copies of DGDecode and remove all but the newest one.

[mgh]

Thanks. Problem solved but a new one now.
Using colourlike filter in avisynth, with dgindex 1.4.0, input in vdubmod looked like this
http://img385.imageshack.us/img385/3518/vdubmod9ct.jpg
input in vdub 1.6.0 looked like this
http://img385.imageshack.us/img385/3217/vdub16105gv.jpg
With dgindex 1.4.2 both look like the first one.
With DGIndex now having capability to tackle mpg1 and the excellent decoder,i am trying to make some of my vcds look better. Deblocking, deringing and better deencoding of dgindex with the colourlike simplified correction of color/brightness using refererence video file was making it a breeze.
The video in question is an overbright video-simple brightness correction does not work well-so have been trying out colourlike and have been happy. I have dark videos, oversaturated videos, undersaturated videos, which are getting corrected satisfactorily with one reference video file.
I am uploading this specific file which is just two seconds in length-file name trialdgindex142.mpg

[Guest]

Can you demonstrate a problem that you attribute to DGMPGDec in the absence of ColourLike? You have to strip the process down to the minimum. I am not going to troubleshoot other people's software in this thread, especially when you have two other threads going about the problem.

[mgh]

Does not happen without colourlike. I think it is a colourspace related problem-vdub1.6.10 uses internal yv12 decoder and vdubmod uses helix yv12 decoder on my pc-so it is possible for same input to look different. Problem is only with some videos using colourspace filter, again not with all. So you are most probably right that it is a problem with related to the filter.
Thanks for your patience.

[calinb]

Version 1.4.3 final offers the following changes over version 1.4.0:
2. A scanning bug in reading the D2V file in DGDecode has been repaired.
http://neuron2.net/dgmpgdec/dgmpgdec142.zip
Thanks, Donald!

But perhaps an old bug is back. DGIndex seems unable to load previously saved project files again :(. 1.4.2 and the last RCs appear to be affected.

[Guest]

Here is version 1.4.3:

1. Fixed a bug that caused the Force Film warning
to erroneously appear for MPEG1 files.

2. Fixed improper handling of the right arrow button.

3. Fixed broken Load Project functionality.

Thanks, calinb, for pointing out bug #3.

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

[agilpwc]

Somewhere since version 1.4.0 the following bug has occured.
When I used the CLI and I specifiy the wrong PID, after correctly setting them using the "Detect PID" menu option. The program saves a project with a blank name '.d2v' instead of using whatever I specified on the command line, and it also uses a blank name for the audio files. In version 1.4.0 and earlier it always used the project name specified.

[Backwoods]

2. Fixed improper handling of the right arrow button.

Sorry, that was my fault. I was pretty drunk and the button just looked so good and...



Seriously though, you're awesome for putting so much attention into this program. Thank you.

EDIT: Just curious, but from 1.4.1 to 1.4.3 the EXE was cut in half meg wise. Pretty large change, how come?

[Rockby]

EDIT: Just curious, but from 1.4.1 to 1.4.3 the EXE was cut in half meg wise. Pretty large change, how come?
The Spash Screen has been removed...

[Guest]

The Spash Screen has been removed... The built-in default one was removed. You can still have one if you provide your own BMP file, as described in the DGIndex user manual.

[Guest]

Somewhere since version 1.4.0 the following bug has occurred. When I used the CLI and I specifiy the wrong PID, after correctly setting them using the "Detect PID" menu option. The program saves a project with a blank name '.d2v' instead of using whatever I specified on the command line, and it also uses a blank name for the audio files. In version 1.4.0 and earlier it always used the project name specified. Please provide the exact series of steps I need to perform to duplicate this. Thank you.

[rig_veda]

Did anybody notice a difference in speed going from version 1.4.0 to 1.4.3? I'm not sure why, but the time necessary to save a given project (without audio) went from around 5 minutes to almost four times as much using the same settings. Another weird thing after switching is that i seem to not get any image preview in vdub 1.6.10 while manually scrolling the time line, while I do in vdubmod 1.5.10. weird.. :confused: looking into this

[Guest]

Did anybody notice a difference in speed going from version 1.4.0 to 1.4.3? I'm not sure why, but the time necessary to save a given project (without audio) went from around 5 minutes to almost four times as much using the same settings. I don't see any difference. Are you sure all the conditions were the same?

Another weird thing after switching is that i seem to not get any image preview in vdub 1.6.10 while manually scrolling the time line, while I do in vdubmod 1.5.10. weird.. :confused: looking into this VirtualDub 1.6.10 works fine for me.

[rig_veda]

I'm quite sure that all settings were the same, but the problem seems to be somewhere else in my setup, I think, since I noticed that I'm not able to get a picture in vdub 1.6.10 at all anymore, unrelated to the dgmpegdec version used. The speed issue also wasn't reproducible. Quite to the contrary: with another sample, the faster version this time was 1.4.3, (again by far, which is weird), so it might have been source dependend. Sorry for the trouble.. I hope i find the error in my system.

[fatxy]

a little suggestion for the template feature

instead of

video = mpeg2source("__src__")

it would be cooler if its only the src name without extension

why? =>

video = mpeg2source("__src__.d2v")
audio = MPaSource("__src__.mpa")

you dont have to edit the avs for audio :)


if someone has time to implement it would be great, thanks in advance

fatxy

[Guest]

video = mpeg2source("__src__.d2v")
audio = MPaSource("__src__.mpa")

you dont have to edit the avs for audio :)
That won't work because the audio file name gets decorated with various audio-specific information.

Also, we already have this issue on the development list stickie. One problem is what to do if there are multiple audio tracks.

[fatxy]

That won't work because the audio file name gets decorated with various audio-specific information.

hehe your thoughts are to 'complicated'

a little example of what meant and which should be simple to add:
i do often record via dvb some tv stuff -> .pva -> demux with pvastrumento
ill get a mystream.mpv and a mystream.mpa
drag the mpv in dgindex, create a project and avs via template

current template
...
video = mpeg2source("__src__")
audio = MPaSource("__src__")
AudioDub(video, audio)

this will result in
video = mpeg2source("X:\mystream.d2v")
audio = MPaSource("X:\mystream.d2v")
so i have to edit always the avs again (changing d2v to mpa or sometimes wav)

thats why a src name without fileextension would be useful imo, i guess the ones that use dgindex to demux vobs or similar with ac3 and stuff dont have a audio part in the template anyway
or maybe they decode them to wav and a ___src___ + .wav would be nice too, thats the good part, you can decide the extension yourself


since a likely feature is already sticky on list it shouldnt take so long to expect in further build, should it? :P

[Guest]

DGIndex is written to be consistent with itself, not with third-party applications. If you can't wait for me to get to this feature, please get the source code and do it yourself.

[Guest]

Somewhere since version 1.4.0 the following bug has occured.
When I used the CLI and I specifiy the wrong PID, after correctly setting them using the "Detect PID" menu option. The program saves a project with a blank name '.d2v' instead of using whatever I specified on the command line, and it also uses a blank name for the audio files. In version 1.4.0 and earlier it always used the project name specified. OK, I've duplicated this. Thanks for pointing it out. I'll fix it in the next beta.

[Guest]

Since version 1.4.3 has gone final, this development thread is now closed. Please open new threads for problems or issues. A version 1.5.0 development thread will be created for the next version.