DGMPGDec 1.4.3 Final!

[neuron2]

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

[neuron2]

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

[neuron2]

@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

[neuron2]

Originally Posted by 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?

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.

[neuron2]

Originally Posted by Doom9

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

Originally Posted by neuron2

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

@neuron2,

Thank you on both counts.

[neuron2]

Originally Posted by IgorC

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.

[neuron2]

Originally Posted by video_magic

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

[neuron2]

Originally Posted by 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

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.

[neuron2]

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]

Originally Posted by neuron2

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

Originally Posted by neuron2

Britney *is* a Goddess.

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

[Emp3r0r]

heh, thanks

[Zyphon]

Thanks for the update neuron2.