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.