DGMPGDec 1.4.3 Final!

[neuron2]

Originally Posted by d'Oursse

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]

Originally Posted by neuron2

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

[neuron2]

Originally Posted by d'Oursse

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.

[neuron2]

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.
Have gone back to 1.4.0

[neuron2]

Originally Posted by 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 have NTSC ones.
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

[neuron2]

Originally Posted by Tima

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

[neuron2]

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

[neuron2]

Originally Posted by mgh

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.

[neuron2]

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

input in vdub 1.6.0 looked like this

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

[neuron2]

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]

Originally Posted by neuron2

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.

[neuron2]

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