Possibility of a Lossless iDCT Algorithm Option?

[DeadSkullzJr]

As the title implies, I wanted to know if there is any possibility for a lossless iDCT algorithm that can be integrated into DGMPGDec, DGIndex to be more specific. I have been examining and doing work on some of my DVD backups, restoring and repairing some of them, eventually planning to use these results for a larger and more complicated work in progress project of mine. The problem is, the algorithms DGIndex offers while great, isn't up to the standards that I want and need for the work in progress project. I put a lot of focus on quality as much as possible, speed, let alone file size, is not of any concern to me, as such, using one of the slower options, IEEE-1180 Reference, while more accurate than the rest of the iDCT algorithms (minus the 64-bit float option, which seems to produce the same results as IEEE-1880 upon frame examinations), there definitely is still a lot of damage on a per frame basis that I notice here and there with the naked eye. Interestingly enough, FFmpeg actually has automation that occurs whenever you attempt to process a VOB or stream copied MKV, removing pulldown, performing frame decimation, and even seems to have similar traits to DGIndex with indexing the individual frames, however it isn't perfect for every source, some cases frames get inserted, other cases important frames that shouldn't be removed end up being removed. Minus the frame rate quirks, upon comparing frames between the source and what FFmpeg produces, many of the original frames remain untouched, leaving the pulldown removed frames as the only real difference. While I haven't figured out what FFmpeg is doing internally (the developers didn't exactly make it easy to pinpoint this information), the fact FFmpeg can preserve the data better means something is definitely possible, especially for a solution like DGIndex. I decided to pick a frame out of the original source (DVD VOB in this case) to use as a means to demonstrate the issue, I then pulled the exact same frame out of the IEEE-1180 version of the same video produced by DGIndex, and created a precise calculated comparison image demonstrating the differences between the two sources.

Hopefully what I am asking and saying makes sense and isn't too much to ask for.

Original Source:


DGIndex (IEEE-1180 Reference):


Comparison: (Gray means no differences between the frames, red means differences between the frames)

[Rocky]

Welcome to the forum.

I assume that the frame you labeled Source was created by ffmpeg. If so, then you have shown only that the iDCT algorithm that ffmpeg uses is different from the DGIndex IEEE-1180 reference algorithm. There is nothing to point to one of them as being more correct.

If you can provide your ffmpeg version number and command line used to produce the Source frame, I can do some research to see what iDCT ffmpeg is using and we can go from there.

ffmpeg has an option to select the iDCT to be used. The actual implementation of the various iDCTs has changed substantially over the years. If you'd like to have one of them ported to DGIndex, you'll have to be able to identify the specific algorithm and make a case for why it is needed in DGIndex. Be aware that, absent actual bugs, the differences between the iDCTs are small enough to be considered inconsequential.

[DeadSkullzJr]

No, the frame labeled "source" came directly from the DVD VOB itself with no modifications and or alterations. The "IEEE-1180" image is the result of the d2v index generated from the original VOB sources, and imported using an AviSynth+ script straight into VirtualDub2. Nowhere in between was any frames altered, no filters were applied, and in fact I intentionally left out TFM and TDecimate from the script just to examine the frames as-is. FFmpeg's result matches the "source" image, hence why I didn't bother including an image from FFmpeg, and that's also why I mentioned that FFmpeg seems to have performed better with preserving the original frames, leaving only the pulldown removed frames being the only real difference. The problem is I have no way of knowing what FFmpeg is doing, even after using -report and using the debug features so far, unless I'm missing something. Either way, again, the "source" frame is straight from the VOB itself, right from the DVD.

Edit:
Excuse me for missing the quote feature. Mobile is a terrible platform to use a forum on.

[Rocky]

No, the frame labeled "source" came directly from the DVD VOB itself with no modifications and or alterations.

That is not possible. The frame is coded in MPEG2 on the DVD and to get a frame for display you must decode the MPEG2. Decoding includes application of the iDCT.

Just tell me exactly how you made the Source frame that you posted.

[DeadSkullzJr]

No, the frame labeled "source" came directly from the DVD VOB itself with no modifications and or alterations.

That is not possible. The frame is coded in MPEG2 on the DVD and to get a frame for display you must decode the MPEG2. Decoding includes application of the iDCT.

Just tell me exactly how you made the Source frame that you posted.

I used MakeMKV to create a decrypted ISO backup of the film. Then directly opened the decrypted ISO with 7-Zip, grabbed the first VOB for the film, tossed that VOB into VirtualDub2, then went straight for the frame in question and exported that frame as a PNG. No idea what it uses internally for that because there is no mention of iDCT algorithms in the software whatsoever, that I could see anyways. Seems to respect the algorithm choices that are set in the D2V indexes though, unless that's AviSynth handling everything and VirtualDub2 is just the viewer still in that instance.

[Rocky]

Seems to respect the algorithm choices that are set in the D2V indexes though, unless that's AviSynth handling everything and VirtualDub2 is just the viewer still in that instance.

No, the virtualdub2 MPEG2 plugin is doing the decoding.

OK, so virtualdub2's MPEG2 plugin uses an iDCT "adapted from xvid", which I know nothing about.

Look, here's the best I can do for you. If you can specify and provide source code for an iDCT that you would like to have added, then I can consider adding it. I just don't have time to go on an ill-defined research project about iDCT algorithms for you. Or, if you can show a bug/issue with any of the existing algos then of course I will look at it. But just differing from some other random iDCT algo is not necessarily a bug.

Some background:

https://guru.multimedia.cx/the-mpeg124-and-h26123-idct/

If you are talking about one encode-decode generation with different iDCTs then if the decoded difference is greater than +/- 1 for any given pixel, then there could be something to look into.

[DeadSkullzJr]

I never classified the algorithmic issues as a bug, it's the nature of them being lossy that is the issue, at least that's what it appears to be on my end, the whole idea of me comparing the differences was to demonstrate the degradation of the video quality when using even the slowest and best option(s) in DGIndex. I wanted a means to handle my sources in lossless fashion rather than lossy. DGIndex offers many iDCT algorithms, however their apparent lossy nature is the primary reason why I asked if it was possible to have a lossless iDCT algorithm for MPEG-2 streams, that way the data is preserved properly when using the d2v indexes. The fact you have lossy options isn't the issue, in fact they are useful for cases where speed matters more, but as stated in the main post, I am focused on quality, not speed, and not file size. I can always encode into a lossy state if I really want a lossy output, given the MPEG-2 streams are already lossy, doing more algorithmic damage is not optimal if it can be helped.

Unfortunately researching into iDCT algorithms, I kept running into brick walls on finding specific lossless standards (I barely found much under the same terminology for even the lossy standards). The information of what little is stated seems really confusing and in some cases, it's rather difficult figuring out if these algorithms are just video and or audio codecs, or different algorithmic standards entirely. FFmpeg lists some video decoders in their codec section, but there is no information on the format compatibility for any of them, even their custom "snow" format doesn't mention any specific formats. Researching each of these individually doesn't yield format specifics either, just statements of the format capabilities and such... Even when I looked up the codecs I use for encoding, none of them mention any of the standards related to these iDCT algorithms, so are they one in the same or different, it's not expressed in a way that says one or the other. Further research into FFmpeg's lists landed me on their avcodec page, there appears to be mentions of DCT and iDCT algorithms starting at line 1,552. No idea if this is all of them, but clearly I know nothing about these other than "auto" which is self explanatory. At a glance, I'm thinking the reason why what I pulled from VirtualDub2 and from the FFmpeg encoded version of the same video yielded the same result is due to both solutions using the XVID iDCT algorithm for decoding...

The list to save you time:

Code: Select all

     int dct_algo;
 #define FF_DCT_AUTO    0
 #define FF_DCT_FASTINT 1
 #define FF_DCT_INT     2
 #define FF_DCT_MMX     3
 #define FF_DCT_ALTIVEC 5
 #define FF_DCT_FAAN    6
 #define FF_DCT_NEON    7
  
     /**
      * IDCT algorithm, see FF_IDCT_* below.
      * - encoding: Set by user.
      * - decoding: Set by user.
      */
     int idct_algo;
 #define FF_IDCT_AUTO          0
 #define FF_IDCT_INT           1
 #define FF_IDCT_SIMPLE        2
 #define FF_IDCT_SIMPLEMMX     3
 #define FF_IDCT_ARM           7
 #define FF_IDCT_ALTIVEC       8
 #define FF_IDCT_SIMPLEARM     10
 #define FF_IDCT_XVID          14
 #define FF_IDCT_SIMPLEARMV5TE 16
 #define FF_IDCT_SIMPLEARMV6   17
 #define FF_IDCT_FAAN          20
 #define FF_IDCT_SIMPLENEON    22
 #define FF_IDCT_SIMPLEAUTO    128

I did look into XVID and it isn't expressed explicitly if it only handles streams in lossy fashion only or not, but given the apparent broad nature of its adoption for MPEG-2, I would assume lossy. Here is the source code for that if you are interested.

http://websvn.xvid.org/

I honestly have no idea where to source the rest of the information out... I also ran across this along the way, but again, no mentions of whether or not it's even compatible with MPEG-2 or not, it does mention being able to perform lossy and lossless decoding and encoding though.

AVS2 Decoder:
https://github.com/pkuvcl/davs2

AVS2 Encoder:
https://github.com/pkuvcl/xavs2

I can't even tell if this is official source material or not, that's assuming this even remotely comes close to being an iDCT algorithm or not...

Here I am thinking that while I am certainly no expert in videography, I knew a lot about video handling and such, only to get a face full of foreign standards that I have never seen or heard of, even within the confines of most of the resources I have utilized thus far, and I certainly haven't integrated any of them into my personal custom scripts. So I guess what I do know so far is minuscule.

I really don't understand why these standards are posted around in convoluted form with very vague and or very little information about them, such a sub-optimal and very impractical way to push standards around in my opinion.

[Rocky]

It's clear you don't understand the theory and what is going on. You admit to it. As I mentioned I don't have time to teach you about coding/decoding theory. Therefore, I can only repeat what I said before. If you can specify and provide source code for an iDCT that you would like to have added, then I can consider adding it.

I suppose you're going to say add the xvid iDCT. I'll wait for your source code.

I'm going to try one last time: The decoding iDCT is not defined. Period. That means all decoders have to choose something. They do not all make the same decision about that. You are concerned that one of the DGIndex iDCTs does not give the same result as xvid's iDCT. Well, boo hoo. What happens when you discover that NVDec also doesn't use the xvid iDCT for MPEG2. Are you going to run around saying they are degrading the video?

At a glance, I'm thinking the reason why what I pulled from VirtualDub2 and from the FFmpeg encoded version of the same video yielded the same result is due to both solutions using the XVID iDCT algorithm for decoding...

Now you're making sense.

I could argue that the reference iDCT is the closest to "correct" and that it is xvid that is "degrading the video". Don't you get that?

So I guess what I do know so far is minuscule.

OK.

I really don't understand why these standards are posted around in convoluted form with very vague and or very little information about them, such a sub-optimal and very impractical way to push standards around in my opinion.

With your minuscule knowledge you have no problem ranting about things! The standards must be very precisely defined. They are far from vague! The MPEG2 iDCT is an exception in that it was left undefined. This mistake was recognized and later formats fully define the iDCT.

[Wonder Woman]

You know I'm trending, right?

[Natasha]

You and Snow White.

[Britney]

Nothing is impossible. With faith we overcome. Not even a doubt.

[Wonder Woman]

Awoman.