Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mwillems]

So I'm not the most video-literate person and often can't tell the difference between different scaling algorithms, but I recently had an issue with JRVR for a film and am not sure how to correct it.  I tested the file in other video players and the file showed normally in mpv and VLC, which makes me suspect that either I'm doing something wrong or there's a quirk in JRVR. 

The film is a DVD rip of "Night at the Museum" and throughout the movie I was seeing very intense artifacts especially around text or geometric patterns of any kind, but not limited to those.  I'm not sure what the name for this video aberration is but I attached a screenshot showing it clearly.  The credits were particularly noticeable, but it was happening to varying degrees throughout the film and I can post other screen captures if that would be helpful.

Here are the diagnostic steps I've done:
1) I tried using all three presets for JRVR, as well as a few different custom settings.  Some settings showed fewer artifacts, but the artifacts were always present and noticeable, I found no combo of settings that made the artifacts disappear.
2) I tried testing on another machine with different video hardware and saw the same issue in JRVR.
3) I tried viewing the same file in other video programs (mpv and VLC), and both of those players did not display the same problem (no noticeable artifacts at all).

So I'm a little bit stumped.  While I haven't seen these issues on most of my DVD rips, I did notice similar artifacts on a few other DVD releases as well although none were quite this intense.  I haven't encountered any issues with Blu Ray media.

I'm running MC 30.0.93, and any advice or troubleshooting steps would be appreciated!

[Hendrik]

Have you tried to toggle hardware accelerated decoding?
Tried disabling YADIF in JRVR, letting software deinterlacing take over?

The OpenGL legacy renderer, as a last resort for testing?

Just to isolate the source.

[mwillems]

Have you tried to toggle hardware accelerated decoding?
Tried disabling YADIF in JRVR, letting software deinterlacing take over?

The OpenGL legacy renderer, as a last resort for testing?

Just to isolate the source.

So I just tested:

1) disabling deinterlacing made no difference (I'm not sure the source is interlaced?)
2) Switching to OpenGL made no difference, if anything, it made it slightly worse.
3) On the other hand, disabling hardware acceleration made a big positive difference.  There are still artifacts around text and geometric shapes with hardware acceleration disabled, but they are softer and less angular.  The credits in particular look much better.  It's possible that I might not have noticed these artifacts from the couch, but knowing to look for them I can still see them pretty clearly.  With hardware accel disabled, there are still slightly more artifacts than I see in other players like mpv or VLC, but it's close enough that it might just be different scaling algorithms at work?

FWIW, I was seeing the same issues with both with an AMD 5700XT and an Nvidia 960 ti, and in both cases disabling hardware accel made a positive difference.  Are there any downsides to leaving hardware accel disabled for now?

[Hendrik]

Disabling HW decoding makes it use more CPU, naturally. But I'm baffled that it would be a problem with both GPUs, especially since nvidia should use NVDEC and AMD probably VAAPI. Can you post a log? And maybe a sample of the file?

Although I'm a bit glad its not JRVR, but the decoding. Thats in some need of upgrading anway.

[mwillems]

Here's a log initiating playback, followed by about 20 seconds of playback with hardware acceleration enabled.  The artifacts were clearly visible during that time, and this is with the AMD GPU.

I've got a 30 second clip that shows the issue pretty clearly if you want it, but I'm not sure the best way to get it to you.  Is there a private way to send you a link?

[Hendrik]

If you have the clip online somewhere you can just email me a link, hendrik at jriver

[mwillems]

I just sent you a link to dropbox, let me know if that works.

[Hendrik]

Got the clip. I can reproduce the issue as well, I believe.

It seems to be coming from the hardware decoder, I made a quick comparison from NVDEC vs DXVA2 https://slow.pics/c/HGPY6ZqY
What surprises me is that the AMD card has the same artifacts, so the same issue might affect multiple hardware APIs, because NVDEC is certainly not going to be used there..

[Hendrik]

I managed to solve the issue for NVDEC, it was sending some data to the hardware wrong (although a fix will require a ffmpeg library upgrade, so it might be a short while).

The same issue occurring on AMD hardware still baffles me a bit. The VAAPI code looks fine and does not suffer from the same issue, and my testing capability on Linux is a bit limited right now - especially if I cannot test virtually.
Can you re-confirm the same issue exists on AMD, and post a log from AMD so I can rule out any unexpected shenanigans?

[mwillems]

I managed to solve the issue for NVDEC, it was sending some data to the hardware wrong (although a fix will require a ffmpeg library upgrade, so it might be a short while).

The same issue occurring on AMD hardware still baffles me a bit. The VAAPI code looks fine and does not suffer from the same issue, and my testing capability on Linux is a bit limited right now - especially if I cannot test virtually.
Can you re-confirm the same issue exists on AMD, and post a log from AMD so I can rule out any unexpected shenanigans?

I can confirm that I saw the issue on AMD as well (I actually took the screenshot in the first post from the AMD system).  The log I posted upthread was also from the AMD system, so that log is an AMD log.  If there's anything else I can do to test or debug on that system, please let me know.

[Hendrik]

Checking in on AMD stuff, and consulting with some other video people, it seems like thats a Mesa driver issue. These kind of MPEG-2 files are pretty rare (it uses a specific feature thats uncommon).
But without a machine with an AMD card that uses the same driver there is little testing I can do right now. Might need to assemble a new testing box thats not a NUC so I can plug in a GPU.

[mwillems]

Checking in on AMD stuff, and consulting with some other video people, it seems like thats a Mesa driver issue. These kind of MPEG-2 files are pretty rare (it uses a specific feature thats uncommon).
But without a machine with an AMD card that uses the same driver there is little testing I can do right now. Might need to assemble a new testing box thats not a NUC so I can plug in a GPU.

If it's relevant at all, the file is a direct DVD rip using Makemkv with no transcoding, so whatever issues are present were "on the disc."  Let me know if there's anything I can do to help, but in the meanwhile I'll just leave hardware transcoding off as things look pretty good that way.  Thanks for the attention to the issue!