All effort stopped in February because of the staffing reduction.
What I’ve learned since then is where the support needs to be placed –
In the GPU host kernel driver (e.g. Nvidia DKMS modules )
Then the host OS (e.g. Ubuntu, etvc)
The VM agent (KVM / QEMU)
lastly, the application has to understand it. (which PMS does)
Since the workforce reduction, we’ve been playing “Catch-Up”
There were a lot of “Need to Fix” tasks which weren’t done.
There was a lot of development support which wasn’t even on the schedule.
We’ve got most of the “Need to Fix” done. Gemini Lake is still problematic but it’s problematic for everyone … just a bit more for us right now.
It’s problematic for us because our FFMPEG is a 2.0 – patched to 3.0 – patched to 4.4. There was no clean ‘git clone’ or ‘git pull’ performed to perfectly sync us with upstream.
With everything that’s happened and the work accomplished so far, and management has been super supportive.
We are making a clean break and jumping directly to FFMPEG 6.1 as our base.
Over the next couple months, we start having new Transcoder tests (Alpha stuff)
and request feedback.
So an update - with H265 transcoding on the horizon, I read that HDR transcoding/tone mapping is no longer required.
The issue above with SR-IOV was that whenever it was tone mapping/HDR transcoding, the ‘tearing’ issue would occur, but straight forward transcoding didn’t exhibit the same behaviour. With H265 we may have a solution that works with the existing intel drivers and solution in VM’s.
Has anyone tested this? @ChuckPa with the new transcoder using H265, is there a time when it would potentially fall back onto H264+Tone Mapping?
If all your players accept HEVC (H.265) then when this is released – you’ll never need tonemapping back to H.264 unless it’s a really really low bitrate that isn’t in the spec (e.g. 2 Mbps 720p – before H265 was invented)
Anything modern will be fine
I was testing more here today with 60 Mbps → 25 Mbps 4K flawlessly.
