jackun / openencodevfw

No longer a VFW (video for windows) frontend for AMD VCE H264 encoder
58 stars 12 forks source link

Encoding speed and color issues. #2

Closed PigsOnTheWings closed 10 years ago

PigsOnTheWings commented 10 years ago

Hey man. I've been testing the codec with dxtory the past couple of days, and I've noticed some issues. I'm not sure this is related to your codec or not.

I'm running a AMD HD7950 and I can not get the codec to do 1080p/60 regardless of what quality settings I've used. I've tested CBR, VBR and QT (in increments of 2) from 0-30. In all cases, regardless of quality, I get 37 frames per second encoded.I've also tried with "send frame rate to VCE" off and on. Is this a limitation of AMD's VCE?

Second, the colors in the recordings are a bit off. If the option to set RGB to 16-235 is not checked, the recordings are extremely dark. With RGB to 16-235 set the recordings are dark, but manageable with colorcorrection. Additionally yellow seems to move towards brown, and brown towards black.

Again, is this a limitation of AMD VCE or something that might be fixed from your end?

If these issues can be fixed this will be my go-to encoder as the filesizes/quality are awesome.

EDIT: I've tried with QT4 720p/60 and it works correctly, suggesting that there is some bug with 1080p as bandwidth for 720p/60 should be higher than 1080p at 37fps if I'm not mistaken?

jackun commented 10 years ago

I think it is possibly a PCIe bandwidth issue. The dark colors are bit weird too. I don't think older early 13.x (13.6beta2 +/- few version) drivers had that. OpenCL RGB to NV12 conversion should be correct because "offline" test (just a c++/opencl app) seemed to give 1:1 colors (well, what's left after to/from Y420 conversion anyway).

Anyway hopefully Media SDK 1.1 gives some better apis (read as no need for rgb conversion). v1.0 beta does 1080p/60 fullscreen capture, but stopped recording when i fullscreened BF4 last time i tried.

Edit: If i calculated it correctly 1080p/60 needs up and down direction cumulative bandwidth about 949.219 MB/s. PCIe v3.0 x16 is 15.75 GB/s (128 GT/s) and that shouldn't be hitting DDR3 memory bandwidth either. Hmmm.

Edit-edit: Actually could be still a bandwidth issue. Some use cases can only get some 1-2GB/s

PigsOnTheWings commented 10 years ago

Tried changing the drivers back to 13.12 which AMD recommends for the Media SDK beta. No change in the above mentioned issues. What I can add is that when RGB 15-235 is turned off while recording, it seems like the recording has the wrong gamma (something like y=y+1).

PigsOnTheWings commented 10 years ago

I think I found the culprit. When "Use openCL for NV12 conversion" is ticked, the picture is dark (gamma seems wrong), when not ticked colors are mostly fine but I can't even hit 30 FPS with QP20, which I do without any issues when "Use openCL for NV12 conversion" is ticked.

jackun commented 10 years ago

Hmm. Try the new build. OpenCL should use the same formula that CPU code uses. https://github.com/jackun/openencodevfw/raw/32b26548b7419c13dd351a0723389d2d273c3756/OpenEncode32/OpenEncodeVFW.dll

E: "These aren't perfect inverses of each other. I'll try to do some actual math and get more accurate coefficients soon." Heh, should read some before copy/pasting random stuff from web.

PigsOnTheWings commented 10 years ago

The new build fixed the issue with having to use RGB 15-235, awesome :) I've uploaded two pictures, one screenshow from within the game and a single frame from a video in the same light/position. Top one is the frame and bottom one is the screenshot.

The videoframe seems redder, right?

framefromvideo screenshot

jackun commented 10 years ago

Redder yes, but i think it may be VCE, driver, gpu inaccuracies or mplayer does something with colors. Tested the opencl nv12 conversion code on linux. I think it was 2.8 sdk (don't remember if i installed 2.9 :P ), cpu-only. Converted the second pic to nv12 and screenshotted with imagemagick's convert and mplayer:

convert test-yuv-normal.png -depth 8 rgb:test-yuv-normal.rgb
mplayer -demuxer rawvideo -rawvideo w=1920:h=1080:format=nv12 output.nv12 -vf screenshot -loop 999 #(loop so i got time to press 'S')

https://dl.dropboxusercontent.com/u/235773/shot0001.png : Colors stay same, but get a bit darker right, like contrast gets boosted a bit? https://dl.dropboxusercontent.com/u/235773/out.png : RGB->NV12->RGB even darker.

Crap.

jackun commented 10 years ago

I dunno if formula is correct, but this is boosting 'gamma' to 1.1 across RGB. So it is again a bit too bright. https://github.com/jackun/openencodevfw/raw/8b0ae69900064a9aac40d2b02e27d7a1d13f3899/OpenEncode32/OpenEncodeVFW.dll

https://dl.dropboxusercontent.com/u/235773/out_gammaed.png

PigsOnTheWings commented 10 years ago

Did a similar test as the last one with your new gammaboosting build. It seems to me that the picture just gets washed out. Some of the issues with red and yellow seems to be helped a bit by the new build, but they are still present and if you increase gamma untill they are resolved everything else will be washed out.

Have you seen anyone else having issues with this?

jackun commented 10 years ago

Ok, cpu code does 2x2 square sampling of pixels for UV (which it should). Looks like OpenCL cannot get away with doing just 1x1. Trying to get the opencl code do 2x2 sampling. And then some profiling.

Edit: Looks like no difference, still darker. wtf... convert_float3 is slower then doing 3x convert_float :S

Edit: Using convert_float separately for each RGB channel makes things redder, using convert_float3 or convert_float4 makes (just?) darker.

PigsOnTheWings commented 10 years ago

I want to thank you for using your time to resolve this issue :)

Now, I've been reading around the interwebs a bit without understanding code at all (I've written some C# 7 years ago ^^), but it seems the guys behind gnome desktop manager has done some work on color conversion, maybe you can have a look?

https://mail.gnome.org/archives/commits-list/2012-November/msg05089.html

jackun commented 10 years ago

Better though not 100%: https://dl.dropboxusercontent.com/u/235773/shot0002.png

Damn, nv12 to rgb converter made the image darker. Wasted time there :D

PigsOnTheWings commented 10 years ago

But if you can manage the results you had in the https://dl.dropboxusercontent.com/u/235773/shot0002.png screenshot within the encoder, that would be a major improvement, right?

jackun commented 10 years ago

It should. I'll upload a new version in about 1.5 to 2 hours probably. E: Doesn't seem to improve when going through GPU E2: Just running conversion on GPU, NV12 is pretty much as original. But compressing with VCE, reds get darker and blues get greener, wut.

Fixed Y formula to match UV's, oops: https://dl.dropboxusercontent.com/u/235773/shot0006.png

E3: More testing. CPU gives some 99.9% same quality as original, but GPU still makes darker and redder. Ugh.

jackun commented 10 years ago

Major facepalm. Dxtory captures in BGRA format, that's why the discrepancy or ...

original screencap, converted

PigsOnTheWings commented 10 years ago

Hey again. Tested out your last build, and the colors are awesome :) Good job! My next question (heh) is this: Is it possible to force constant frame rate capture for editing compatibility?

jackun commented 10 years ago

Slide 16

Seems that currently best you can get with current settings is 1080p @ 30. Been trying to optimize CL bits etc. but VCE is always at something like max 1080p@~45 usually 39 fps. So seems that i should add these presets as easily selectable. samples folder has the presets and these can be changed in registry as Readme says.

raldred commented 9 years ago

I know this issue is closed however I'm getting awful colour playing battlefield 4. Everything is very blue. http://i.imgur.com/v60YEwT.png

jackun commented 9 years ago

Do you have the latest build? Red/blue channels are switched, if you want to salvage that footage.

Older one had the 'BGR(A)' checkbox, check that. Newer one has 'switch byte order', uncheck that.

raldred commented 9 years ago

Hey, thanks for speedy reply. I have 14th May build, I guess I should update? I have the BGR(A) checkbox now checked, thanks.

It only seems to be an issue when I output to file. I've been streaming a lot recently and it seems fine with DirectShow output to OBS then onto Twitch.

astrixx commented 9 years ago

Hey Jackun!

I've downloaded and installed this on my Windows 8.1 64bit PC. I'm guessing this doesn't work in fullscreen right? I was able to record BF4 in windowed but in Fullscreen it says INIT and doesn't record.

I am running a 4770K and 2x MSI R9 290x's in crossfire as I am recording 1440p at 120hz.

Is there any way to get it to work in Fullscreen and crossfire?

Thanks for the plugin!