GKIDS Evangelion 1.11 and 2.22 corruption while skipping

[sephirothkefka]

Recently I acquired Evangelion 1.11 and 2.22 rereleases from GKIDS and ripped them. After ripping (and also submitting the dumps by clicking the link as MakeMKV recommended) I noticed what appeared to be corruption for my rip while playing in MadVR and MPC-HC while skipping around at random spots which I never noticed before. Both ripped with no errors reported by MakeMKV.



The corruption only lasts for about a frame and then continues on as if nothing happened (it appears that the I-frames are not being properly decoded). It doesn't happen in all spots just very specific areas of the disc. It also doesn't happen if you skip slightly farther back and let it play normally as is. I thought it was maybe because it was something in regards to AACS 82 so i got the KeyDB.cfg and used MakeMKV in tandem with Xreveal yet still shows the same error. Any ideas if this is a MakeMKV bug or a genuine issue with my discs?

[dcoke22]

I don't think it is either a bug in MakeMKV or an issue with your discs. If it only happens when you're skipping around and it only lasts a frame or two, it is probably an artifact of the player trying to display an image before the buffers fully fill and there are enough frames in the pipeline to properly decode the next frame.

You can read about AVC which is most likely the encoding used on the blu-rays you mentioned.

[sephirothkefka]

I don't think it is either a bug in MakeMKV or an issue with your discs. If it only happens when you're skipping around and it only lasts a frame or two, it is probably an artifact of the player trying to display an image before the buffers fully fill and there are enough frames in the pipeline to properly decode the next frame.

You can read about AVC which is most likely the encoding used on the blu-rays you mentioned.

Thats the thing I did the same thing on other discs and got basically the same result and now I'm kind of just confused.

[sephirothkefka]

I also just ran debug mode and other than a Code 2147483648 (which i think is AACS related) it ripped with no issues. Increasing the splitter cache in MPC-HC also had no effect.

[sephirothkefka]

Okay i think i might know whats going on



According to by UB9000 the bitrate is going unusually high in spots where it otherwise shouldn't (isn't the max bitrate for video on Blu-ray 40mbps?) I don't know how makemkv can appropriately cope with this assuming it *can* cope with this. The only other time I've seen bitrates that high is with an episode of Better Call Saul (the episode where Saul impersonates Howard and that was a mere 61mbps).

[ryley]

Increasing the splitter cache in MPC-HC also had no effect.

Which video decoder are you using? It might be worth trying out software decoding via LAVFilters to see if it handles seeking more gracefully than whichever hardware decoder you are currently utilising.

I don't know how makemkv can appropriately cope with this assuming it *can* cope with this. The only other time I've seen bitrates that high is with an episode of Better Call Saul (the episode where Saul impersonates Howard and that was a mere 61mbps).

There is nothing more for MakeMKV to do here. It has done its job of decrypting, verifying and repackaging the content from your disc into a Matroska file. The visual corruption you are seeing is a shortcoming of your playback configuration. It is in no way indicative of corruption within the actual Matroska file.

Remember, MakeMKV isn't acting like an analogue video capture card frantically trying to grab every ephemeral frame on the wire. It is completely indifferent to the bitrate used to encode the content. The bitrate obviously matters for hardware players trying to playback content in real time but MakeMKV would happily rip a disc mastered at 400Mbps if you gave it one. It wouldn't happen in real time but that doesn't matter for its intended use case.

[sephirothkefka]

Increasing the splitter cache in MPC-HC also had no effect.

Which video decoder are you using? It might be worth trying out software decoding via LAVFilters to see if it handles seeking more gracefully than whichever hardware decoder you are currently utilising.

I don't know how makemkv can appropriately cope with this assuming it *can* cope with this. The only other time I've seen bitrates that high is with an episode of Better Call Saul (the episode where Saul impersonates Howard and that was a mere 61mbps).

There is nothing more for MakeMKV to do here. It has done its job of decrypting, verifying and repackaging the content from your disc into a Matroska file. The visual corruption you are seeing is a shortcoming of your playback configuration. It is in no way indicative of corruption within the actual Matroska file.

Remember, MakeMKV isn't acting like an analogue video capture card frantically trying to grab every ephemeral frame on the wire. It is completely indifferent to the bitrate used to encode the content. The bitrate obviously matters for hardware players trying to playback content in real time but MakeMKV would happily rip a disc mastered at 400Mbps if you gave it one. It wouldn't happen in real time but that doesn't matter for its intended use case.

I forgot to reply to this but I'm using MadVR.

[sephirothkefka]

After further experiments MakeMKV is most definitely fault at least during the MKV muxing process. Rolled back a version to make sure it wasnt a faulty update and it still had errors. Did another raw M2TS dump with MKVToolnix (after decrypting with Xreveal) and lo and behold its fixed!