Jump to content

VA API pixelation on DS416play


Burrito78
 Share

Go to solution Solved by solabc16,

Recommended Posts

Hi,

 

i'm interested in 720p transcoding (2-4 Mbps) of Blu-ray MKV rips. While the 416play software transcoding speed is OK for 720p 1 Mbps, this bitrate is a little low for acceptable quality.

 

Using VA API hardware transcoding results in good speeds above 24 fps but i often experience full frame blocking especially in scene changes even with 4 Mbps (highest 720p bitrate).

 

See logs attached.

 

Cheers,

Burrito78

server-63634543859.txt

ffmpeg-transcode.txt

Link to comment
Share on other sites

I think our vaapi command lines could potentially be improved. 

/var/packages/EmbyServer/target/ffmpeg/bin/ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -vaapi_device /dev/dri/card0 -i file:"/volume1/media/Filme/Drive (2011)/Drive (2011).mkv" -map_metadata -1 -map_chapters -1 -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 h264_vaapi  -b:v 3616000 -maxrate 3616000 -bufsize 7232000 -level 41 -force_key_frames "expr:gte(t,n_forced*3)" -vf "format=nv12|vaapi,hwupload"

@@Waldonnis do you have any suggestions? thanks !

Link to comment
Share on other sites

I think our vaapi command lines could potentially be improved. 

/var/packages/EmbyServer/target/ffmpeg/bin/ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -vaapi_device /dev/dri/card0 -i file:"/volume1/media/Filme/Drive (2011)/Drive (2011).mkv" -map_metadata -1 -map_chapters -1 -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 h264_vaapi  -b:v 3616000 -maxrate 3616000 -bufsize 7232000 -level 41 -force_key_frames "expr:gte(t,n_forced*3)" -vf "format=nv12|vaapi,hwupload"

@@Waldonnis do you have any suggestions? thanks !

 

None that I can think of offhand, but I haven't done much experimentation with VA-API to know what may help here.  Next time I boot up Linux, I'll play around with it more.  I'm assuming that software encoding at the same bitrate of the same source file (and using the same parameters otherwise) isn't producing the same level of macroblocking?

 

Inserting keyframes at chapter markers may help ease some of the blocking issues at those points, but wouldn't help much if the files don't contain chapter information (home/music videos as well as shorts/one-shots, notably).  Doing so at scene changes would be better, but auto-detecting those isn't as easy (or at least not reliably).

Link to comment
Share on other sites

  • 2 weeks later...

Any progress here? Is the problem reproducible? Can it be fixed or is it because of Synology limitations regarding VA API? It seems it CAN work from the link in the previous post.

Link to comment
Share on other sites

Hi, we do not have an update at this time but it is on our list for review. thanks !

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Still happening with 3.2.33.0. Tested today, converted 1080p/10Mbps source to Emby for Kodi (Add-On Setting: Video Quality 6.2 Mbps HD).

Link to comment
Share on other sites

@@Waldonnis is it possible that vaapi isn't respecting the bitrate requested?

 

It should, but I'm not familiar enough with the nuances of the vaapi implementation to know if there are any vaapi-specific options that need to be considered (for example, nvenc didn't respect -crf for a while and you had to use -global_quality instead).  From the documentation, the command line looks fine for a specified bitrate target, though.

 

Is the macroblocking only showing up on scene changes/scenecuts or is it also happening on "fast" action scenes with a lot of camera angles cut in rapid succession?

Link to comment
Share on other sites

@@Waldonnis i also notice that most vaapi examples don't include -maxrate or -bufsize, if that means anything.

 

That's somewhat odd, since the docs mention setting -maxrate equal to -b:v for CBR (which makes sense).  I guess a lot of those examples may be looking to perform a VBR encode.  I can see not using -bufsize in many circumstances, though, depending on the playback scenario or if bitrate fluctuations above the average specified aren't a worry from a bandwidth perspective.  Same really goes for non-VAAPI encoding, though, so the reasons for using either/both options are unchanged and the docs do say that both options are implemented on the ffmpeg/libavcodec side.

Link to comment
Share on other sites

@@Waldonnis the only other thing i can think of is that it doesn't have your keyframe change simply because i wasn't sure if it would support the more complex expression.

Link to comment
Share on other sites

Is the macroblocking only showing up on scene changes/scenecuts or is it also happening on "fast" action scenes with a lot of camera angles cut in rapid succession?

 

 

It's happening on some cuts and sometimes with fast motion. 

Link to comment
Share on other sites

@@Waldonnis the only other thing i can think of is that it doesn't have your keyframe change simply because i wasn't sure if it would support the more complex expression.

 

If it's not a seeking situation, it shouldn't make a difference.  The hardware implementation may explain some of it, but I'm just not sure as yet.

 

It's happening on some cuts and sometimes with fast motion. 

 

Keyframes and reference frames should be helping out in those situations (large-scale changes), if they're being generated properly...albeit at the cost of increasing bitrate during those moments.  I'm wondering if either the hardware is doing something or if the stream is bit-starved during periods of quick transitions or high rates of inter-frame changes/motion.  CBR encoding often runs into these types of things (although not usually as dramatic) because some sequences need more bits than specified to prevent artifacts and some sequences don't need what they end up getting.

 

I'm not sure what the answer would be without inspecting a small sample of the affected output and knowing more about the hardware itself.  It could be that the implementation doesn't do certain things (e.g. hevc_nvenc not being able to create B-frames) or needs additional options that aren't overtly documented.

Link to comment
Share on other sites

It's happening on some cuts and sometimes with fast motion. 

 

Most probable reason is that your VAAPI is too old.

 

There is a huge difference in quality between the latest VAAPI (libva1 & intel-vaapi-driver) and the versions released one year ago. Unfortunately many distros (like Ubuntu 16) do not release updates to VAAPI but stay on the version that existed at the distro release time.

 

I don't know how the Synology packages work, but on normal distros you can check the VAAPI version with vainfo. Here is part of the output of the last 1.0 version (VAAPI 2.0 is on the verge of release):

msrv@MSRV:~$ vainfo
error: can't connect to X server!
libva info: VA-API version 0.40.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_40
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.40 (libva 1.8.4.pre1)
vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 1.8.4.pre1 (1.8.4.pre1)
vainfo: Support...

ffmpeg version has less to do with the VAAPI quality but of course that also matters. However ffmpeg cannot fix any deficiencies in underlying libva1 and intel-vaapi-driver.

 

BR

ANDY777

Link to comment
Share on other sites

I tried to install a current ffmpeg (Package) from synocommunity but it seems the transcoder doesn't pick it up and still uses the old ffmpeg (2015) (and therefore vaapi) that comes with the current Synology DSM.

 

Anything else i could try?

Link to comment
Share on other sites

Did you have a chance to look into this yet? I assume that Emby brings its own FFMPEG (latest) and therefore also the newest VAAPI is used in Emby?

Link to comment
Share on other sites

Im sorry, I was probably unclear:

 

* Vaapi is separate from ffmpeg

* Any newer ffmpeg doesn't help because your problems stems from old vaapi (not ffmpeg)

* Ffmpeg developers do not code/develop Vaapi, instead Vaapi is mostly developed by Intel employees.

* Any ffmpeg shipped with Emby (or not) do not contain "the vaapi"

 

Vaapi and the requisites (libdrm, libva, libva-intel-driver) are components of the linux graphics driver stack. Not Ffmpeg.

 

For some newer features also newer kernel mode driver is needed. This means that the complete linux kernel needs to be upgraded.

 

Hopefully this helps. Your Synology runs on a quite new cpu. Features for those chips were enabled less than a year ago in the kernel.

 

You still need libdrm, libdrmintel, libva, libva-intel-driver which are NOT OLDER THAN TWO MONTHS. These constitute the "new Vaapi"(along with the kernel). NOT FFMPEG!

  • Like 1
Link to comment
Share on other sites

Ok, i think what you are trying to imply here is that vaapi is unreleated to ffmpeg?  :P

 

Thanks for the reply! Much clearer now!

Link to comment
Share on other sites

Yes.

Simplified answer is that:

* Vaapi is part of your graphics driver stack.

* Ffmpeg can use it (but doesn't include it) if it exists on your system.

 

Your main problem is too old Vaapi.

 

The main reason that I myself gave up on NAS systems, and built my "nas' based on Ubuntu so I can update the underlying system/graphics stack to support the latest advances in hw transcode.

 

You can find my frustrated comments about macroblocking and low quality about a year ago. THINGS HAVE NOW CHANGED AND VAAPI QUALITY/PERFORMANCE IS AWESOME! :-)

Edited by Andy777
Link to comment
Share on other sites

Hello

 

A quick update, before any wrong conclusions are drawn, we do support VA API, you’ll find the threads somewhere on the forum from when we undertook this development for Synology. I’ll write more later and provide some more details, when I have a little more time.

 

Best

- James

Edited by solabc16
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...