DGMPGDec 1.4.5 Released

[Guest]

A bug in version 1.4.4 was found. Random access with multiple elementary stream files loaded was brain-dead. This is fixed in version 1.4.5. That is the only change.

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

[SeeMoreDigital]

Thanks Donald ;)

[Guest]

You're fast, SMD. :)

While analysing this bug, I identified a further theoretical vulnerability in the indexing. It's predicted to be rare and no-one has ever reported it occurring, but it is possible. The effect would be that at a file increment, the new file number is used one GOP too early in the D2V file line. It would affect only random access to that GOP; linear play and encoding would be fine. Even though it has never been observed, I will try to fix it (without breaking anything else!). Unfortunately, the parsing architecture inherited from DVD2AVI is not conducive to robust and provably correct indexing. It needs a redesign, but that would be a giant effort.

And by the way, when I changed the D2V file so that the file path lines don't need a count, I forgot to bump the format version number. So be careful not to inadvertently use the older-style D2V files with 1.4.4 or 1.4.5, because it will fail without a proper error message. Bad, bad kitty!

[d'Oursse]

ha, another modif.
Btw, did you read my pm ?

[Guest]

ha, another modif. I work as hard as I can to improve this tool and add features that users request. Do you have a problem with that?

[d'Oursse]

I have no problem with that. I'm happy that you add features to your program

When you do modifications, i try to put them in the library that I try to write from your code. I just wanted to point that. That's all.

I didnt intend to show you a lack of respect at all. I'm sorry if you think so.

[f@chance]

I used 1.4.4 Final to do a conversion with CCE / AVI Synth by selecting 28 TS files numbered from 0000 to 00027 and by manually setting the Video & Audio PIDs before creating the D2V & AC3 files. The conversion from HDTV to DVD MPEG2 went fine. How is this major bug manifesting itself and is there a need for me to re-encode it?

Thank you very much for this excellent program and many are the ones appreciating your work and efforts.

[Guest]

I used 1.4.4 Final to do a conversion with CCE / AVI Synth by selecting 28 TS files numbered from 0000 to 00027 and by manually setting the Video & Audio PIDs before creating the D2V & AC3 files. The conversion from HDTV to DVD MPEG2 went fine. How is this major bug manifesting itself and is there a need for me to re-encode it? As I said, it affects only elementary streams, i.e., m1v, m2v, mpv, etc. You have transport streams so there is nothing to worry about and no need to re-encode.

[Guest]

I used 1.4.4 Final to do a conversion with CCE / AVI Synth by selecting 28 TS files numbered from 0000 to 00027 and by manually setting the Video & Audio PIDs before creating the D2V & AC3 files. The conversion from HDTV to DVD MPEG2 went fine. How is this major bug manifesting itself and is there a need for me to re-encode it? As I said, it affects only elementary streams, i.e., m1v, m2v, mpv, etc. You have transport streams so there is nothing to worry about and no need to re-encode. Even if they were ES, there would still be no need to re-encode, because it affects only random access, not linear play or encoding.

[f@chance]

Thanks again for the help. I fing the DG Suite :) excellent and are using the DGIndex, DGDecode & DGPullDown extensively and want to thank you for spending your time on perfecting these tools. It definetly has a professional air about it especially the documentation and I know that must have taken a slice of your precious time.

[Guest]

Thank you. Please note that Cyberia created the documents de novo and I did some editing and added a little extra explanation in some areas. So be sure to appreciate Cyberia's efforts. And don't forget the other people involved, as well, as given in the Credits sections of the documents.

[mpeg2fan]

Hello,
Thanks a lot neuron2 for your great work, DGIndex learn me a lot of thinks.
I just would like to clarify something I don't understand and I didnt find anything on the forum.
When IDCT algo is defined in both the d2v and avs file, wich param is take. avs one or d2v one ?
:thanks: to all other people in the credits too...

[midnightsun]

As I understand it, the one specified in the avs. But I'll leave the floor to those who know better.

[Inventive Software]

Hey, neuron2, you double posted! Being a mod, you could delete the extra post, if you really wanted. ;)

Great. Another new version! I don't remember having much problem with 1.4.4, though when I did the second pass of an encode I was doing, something deleted the elementary stream from my hard disk! Turns out I had a virus or something. Not having anti-virus at the time was partly to blame. :(

[Cyberia]

As I understand it, the one specified in the avs. But I'll leave the floor to those who know better.
You are correct, the value in the avs file overrides the value set in DGIndex. If you do not specify a value in the avs, then the DGIndex value is used.

[SeeMoreDigital]

Hi Donald,

As a matter of interest, could DGIndex be upgraded to handle MPEG-1 and MPEG-2 streams within containers such as .AVI and .MP4?


Cheers

[Cyberia]

This would be a lot of work, and I don't think avi supports MPEG-1 or MPEG-2 anyway.

[Leak]

This would be a lot of work, and I don't think avi supports MPEG-1 or MPEG-2 anyway.
Well, I haven't tried it out, but ffdshow supports decoding both MPEG1 and MPEG2 in AVI files, so I guess it's possible.

It'd probably make more sense though to first demux the video from the AVI file and then point DGIndex to the resulting video file...

Also, I don't think it's easy to add yet another rather complex container format to DGIndex...

[SeeMoreDigital]

It'd probably make more sense though to first demux the video from the AVI file and then point DGIndex to the resulting video file...
That's what I kinda hoping DGIndex could do!

Yesterday, while fiddling about, I fed DGIndex with a very short "video only" MPEG-2 in AVI file and after a few seconds it opened it (one of the few applications that can): -

http://img371.imageshack.us/img371/8175/mpeg2inavi7tk.jpg


It could also open "video only" MPEG-2 in MP4 file: -

http://img371.imageshack.us/img371/8691/mpeg2inmp42mb.jpg


DGIndex also allowed me to de-mux the MPEG-2 stream to a RAW .m2v stream and created an .d2v file....

However, things start to go a little wappy when any of the above mentioned contain an audio element too!


Cheers

[tritical]

I've got a .m2v file that causes incorrect random access in avisynth with v1.4.5. I am currently uploading it to your ftp (its roughly 12MBs, and is called bridge-6mbps.m2v). The problem seems to be the position field is not correctly updated when recorded in the d2v file... I traced it to this part of the code in dgindex in gethdr.c: if (HadSequenceHeader == false)
{
// Indexing for the D2V file.
if (picture_coding_type == I_TYPE && picture_structure != BOTTOM_FIELD)
{
// dprintf("DGIndex: Index picture header at %d\n", Rdptr - Rdbfr);
d2v_current.position = start;
}
}
There is never a sequenceheader in the clip except for the very beginning, and every I-frame except for one (about half way through) has picture_structure == BOTTOM_FIELD. So the resultant d2v has the position field set to 0 for half of the I-picture lines and to some other value for the other half. When dgdecode goes to decode a seeked to frame that is in the first half of the file the file pos points to the very start of the stream but # of frames to decode is only back to the last I picture so it ends up in the wrong spot. For fun I removed the "picture_structure != BOTTOM_FIELD" from the above code and everything seemed to work correctly, but I have no idea if it would break everything else. Wanted to have you take a look at it. Thanks.

[Guest]

That's an unusual clip. And not just because of the GOP structure. It's pure interlaced (59.94 fields/sec) anime! No TFM() for that one. And, oh, did you notice the rainbowing? :)

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

When a frame is encoded in the form of two field pictures and the first field is an I picture, the second may be an I or a P picture. In your clip, you have instances of [I - bottom][P - top]. The indexing test fails as you point out. Your fix will work for this case but will fail for [I - bottom][I - top], because both fields will trigger the indexing and the last one will be the effective one (because it overwrites the first one). So you'll erroneously index the second field instead of the first field.

The correct fix appears to be:

if (picture_coding_type == I_TYPE && !Second_Field)

I have to check that Second_Field always has the right value (0) for frame structure pictures and do some regression testing. If you'd like to do some testing with that, too, I would appreciate it.

Good find!

[tritical]

I figured the test was there for some reason. I tested with !Second_Field on that clip and the other vob and m2v clips I have laying around on my hard drive and it seemed fine (the generated d2v files for all the other clips were the same as before).

Not sure where the clip originally came from... scharfis sent it to me to test static area detection on because the motion occurs at just the right rate to confuse motion-adaptive deinterlacers that look at single pixels on only a few (4-6) fields.