P3
FULL PRODUCT VERSION :
A DESCRIPTION OF THE PROBLEM :
On Windows 7 or higher weak devices, javafx H264 video is just CPU hog. It misses frames and disrupts animations and is just not usable.
On Intel NUC Celeron, scene with hd video + single sliding image animation on top barely renders 30-40 FPS and is using 100% CPU.
But even on strongest machines, video is not as smooth as in Media Player or MPC-HC and produces occasional stuttering.
Apparently JavaFX gstreamer version on Windows doesn't use H264 hardware decoding and decodes on CPU.
If I understand properly, GStreamer ddshowwrapper gets frames from MS decoder in the filter graph and after a chain of back and forth jni the frame data is uploaded to texture in JavaFX for every rendered frame.
The proper way to play video smoothly on Windows 7 is to use DXVA2 decoding and render the resulting native texture coming from decoder.
On Celeron, DXVA2 is the ONLY way to play HD.
--------------------------
The way to fix this seems to modify gstreamer/MediaPlayer/MediaView and use a DXVA2 supporting gstreamer plugin and render the resulting native frame texture at JavaFX end.
We have no resources to try that approach.
Instead, we implemented DXVA2 supporting EVR presenter and in a custom NGNode/View we render the resulting frame texture into the scene.
When running on Windows with DXVA2 support, we use this view instead of MediaView.
Two HD 60fps videos + animations are sillky smooth now on Celeron with transparency and all.
This is a bit dirty, complex and not generic solution, but it works for us until and if this issue is fixed.
We did not check yet but it is interesting to know if on Linux HW decoding is used by default MediaView.
Please contact fedor.losev@gmail.com if more info is required.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Play Full HD video with MediaView on Celeron/Intel HD device
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Video plays smoothly, 10-15% CPU
ACTUAL -
Video and all rendering is choppy, 90-100% CPU
REPRODUCIBILITY :
This bug can be reproduced always.
A DESCRIPTION OF THE PROBLEM :
On Windows 7 or higher weak devices, javafx H264 video is just CPU hog. It misses frames and disrupts animations and is just not usable.
On Intel NUC Celeron, scene with hd video + single sliding image animation on top barely renders 30-40 FPS and is using 100% CPU.
But even on strongest machines, video is not as smooth as in Media Player or MPC-HC and produces occasional stuttering.
Apparently JavaFX gstreamer version on Windows doesn't use H264 hardware decoding and decodes on CPU.
If I understand properly, GStreamer ddshowwrapper gets frames from MS decoder in the filter graph and after a chain of back and forth jni the frame data is uploaded to texture in JavaFX for every rendered frame.
The proper way to play video smoothly on Windows 7 is to use DXVA2 decoding and render the resulting native texture coming from decoder.
On Celeron, DXVA2 is the ONLY way to play HD.
--------------------------
The way to fix this seems to modify gstreamer/MediaPlayer/MediaView and use a DXVA2 supporting gstreamer plugin and render the resulting native frame texture at JavaFX end.
We have no resources to try that approach.
Instead, we implemented DXVA2 supporting EVR presenter and in a custom NGNode/View we render the resulting frame texture into the scene.
When running on Windows with DXVA2 support, we use this view instead of MediaView.
Two HD 60fps videos + animations are sillky smooth now on Celeron with transparency and all.
This is a bit dirty, complex and not generic solution, but it works for us until and if this issue is fixed.
We did not check yet but it is interesting to know if on Linux HW decoding is used by default MediaView.
Please contact fedor.losev@gmail.com if more info is required.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Play Full HD video with MediaView on Celeron/Intel HD device
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Video plays smoothly, 10-15% CPU
ACTUAL -
Video and all rendering is choppy, 90-100% CPU
REPRODUCIBILITY :
This bug can be reproduced always.