Luke 37096 Posted April 6, 2019 Share Posted April 6, 2019 Please try again with the upcoming Emby Server 4.1 release. Thanks. Link to comment Share on other sites More sharing options...
nmbrg 3 Posted April 6, 2019 Author Share Posted April 6, 2019 (edited) Please try again with the upcoming Emby Server 4.1 release. Thanks. Ok, when will it be released? (fyi, i didnt work with the 4.0.3.0 release) Edited April 6, 2019 by nmbrg Link to comment Share on other sites More sharing options...
Luke 37096 Posted April 6, 2019 Share Posted April 6, 2019 Hopefully soon. Link to comment Share on other sites More sharing options...
nmbrg 3 Posted April 6, 2019 Author Share Posted April 6, 2019 ballpark? soon is quite different depending on where you ask. if plex team says soon, its about around the year 3000. if my SO says soon, its about never.. Link to comment Share on other sites More sharing options...
nmbrg 3 Posted April 7, 2019 Author Share Posted April 7, 2019 Are you still having an issue with this? Yes i do. Link to comment Share on other sites More sharing options...
Luke 37096 Posted April 7, 2019 Share Posted April 7, 2019 Please try again with the upcoming 4.1 release as there will be numerous improvements to the throttle feature. Thanks. Link to comment Share on other sites More sharing options...
nmbrg 3 Posted April 7, 2019 Author Share Posted April 7, 2019 Please try again with the upcoming 4.1 release as there will be numerous improvements to the throttle feature. Thanks. Will do. Thanks. Just hope it will be released very soon. Link to comment Share on other sites More sharing options...
nmbrg 3 Posted April 8, 2019 Author Share Posted April 8, 2019 Just tried the 4.1 beta. still dont work. same issue/buffering. Link to comment Share on other sites More sharing options...
nmbrg 3 Posted April 8, 2019 Author Share Posted April 8, 2019 Please try again with the upcoming Emby Server 4.1 release. Thanks. Tried the 4.1 beta. hasnt been fixed. still buffering. Link to comment Share on other sites More sharing options...
Luke 37096 Posted April 8, 2019 Share Posted April 8, 2019 Please attach a new server and Ffmpeg log. Thanks. Link to comment Share on other sites More sharing options...
nmbrg 3 Posted April 8, 2019 Author Share Posted April 8, 2019 Please attach a new server and Ffmpeg log. Thanks. FFmpeg: https://ufile.io/gumrs Server: https://ufile.io/tzd7c Link to comment Share on other sites More sharing options...
Luke 37096 Posted April 9, 2019 Share Posted April 9, 2019 Have you tried lowering the in-app quality setting? this will usually solve buffering. Link to comment Share on other sites More sharing options...
nmbrg 3 Posted April 9, 2019 Author Share Posted April 9, 2019 Have you tried lowering the in-app quality setting? this will usually solve buffering. Not sure what you mean with "in-app quality setting". If you mean when playing the movie, setting a Mb/s value? Then yes, and that seemed only to make it worse. Link to comment Share on other sites More sharing options...
Luke 37096 Posted April 9, 2019 Share Posted April 9, 2019 How did that make it worse? Link to comment Share on other sites More sharing options...
Happy2Play 8296 Posted April 9, 2019 Share Posted April 9, 2019 (edited) Looks like Emby fallback to Software as HW conversion failed. [h264_qsv @ 0000015037995940] Current pixel format is unsupported [h264_qsv @ 0000015037995940] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [libmp3lame @ 0000015037997480] 3 frames left in the queue on closing Conversion failed! From log in post 36. Only about 9 fps on software/cpu. Edited April 9, 2019 by Happy2Play Link to comment Share on other sites More sharing options...
nmbrg 3 Posted April 9, 2019 Author Share Posted April 9, 2019 How did that make it worse? More/worse buffering. Looks like Emby fallback to Software as HW conversion failed. [h264_qsv @ 0000015037995940] Current pixel format is unsupported [h264_qsv @ 0000015037995940] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [libmp3lame @ 0000015037997480] 3 frames left in the queue on closing Conversion failed! From log in post 36. Yes, as i figured. im pretty sure you've got the same issue with Emby as Plex has with their software. I created a post here, but that seems to be removed(?) about that issue. In short i was told this: The root of the problem is that under Linux there is support for QSV zero-copy using VAAPI but under Windows there is not yet. it is dependent on updating the transcoder to the latest FFmpeg. It decodes using software after it fails HW decoding. However it encodes using HW thus you get sub 1.0x transcode speeds. This results in constant buffering. In my testing, HEVC to H.264 transcoding performed at 0.5-0.7x under Windows 10. On Linux using the same NUC, I am able to get 5.0-6.0x HW transcoding and the logs show its QSV decode and QSV encode. This is what is referred to as zero-copy since the transcoding is never copied to CPU and then back to the QSV ASIC. Link to comment Share on other sites More sharing options...
softworkz 3338 Posted May 22, 2019 Share Posted May 22, 2019 @@nmbrg - I apologize for responding late. The logs from post #36 are no longer accessible. Would you be able to re-post just the ffmpeg log? But here's one thing I can already tell to clear up some confusion, also with regards to the other reply you got: This is not a matter of HEVC or non-HEVC, There's an important difference that needs to be made: HEVC SDR (8bit) HEVC HDR (10bit or 12bit) I guess your issue is about #2, right? Link to comment Share on other sites More sharing options...
nmbrg 3 Posted May 22, 2019 Author Share Posted May 22, 2019 @@nmbrg - I apologize for responding late. The logs from post #36 are no longer accessible. Would you be able to re-post just the ffmpeg log? But here's one thing I can already tell to clear up some confusion, also with regards to the other reply you got: This is not a matter of HEVC or non-HEVC, There's an important difference that needs to be made: HEVC SDR (8bit) HEVC HDR (10bit or 12bit) I guess your issue is about #2, right? You're wrong in your assumption. Its a matter of hevc. Doesn't matter if sdr or hdr. So id prefer if you stopped making things up. I don't have emby installed anymore. So can't post logs. And seeing your response now I doubt I ever will be installing it again. Link to comment Share on other sites More sharing options...
softworkz 3338 Posted May 22, 2019 Share Posted May 22, 2019 I'm afraid to hear your reaction. I just wanted to clear up things a bit. Yet the true story behind this is a little different than you were told. Zero-Copy conversion means that no data is transferred back to the CPU for processing. Emby for example does support this with QuickSync on Windows - for HEVC 8bit. But QuickSync has no built-in hardware color-space conversion capability. That's why zero-copy transcoding cannot be done when the source is HEVC 10 bit (the result has to be 8bit for H.264) I'd also wanted to let you know that we're having a few known issues regarding color conversions on which we're currently working. I apologize for the inconvenience and hope that you might consider taking another chance on Emby some time soon. Link to comment Share on other sites More sharing options...
nmbrg 3 Posted May 22, 2019 Author Share Posted May 22, 2019 I'm afraid to hear your reaction. I just wanted to clear up things a bit. Yet the true story behind this is a little different than you were told. Zero-Copy conversion means that no data is transferred back to the CPU for processing. Emby for example does support this with QuickSync on Windows - for HEVC 8bit. But QuickSync has no built-in hardware color-space conversion capability. That's why zero-copy transcoding cannot be done when the source is HEVC 10 bit (the result has to be 8bit for H.264) I'd also wanted to let you know that we're having a few known issues regarding color conversions on which we're currently working. I apologize for the inconvenience and hope that you might consider taking another chance on Emby some time soon. ok, then the issue isnt (just) zero-copy since i have issues with all hevc, both sdr and hdr. but ill take that information and pass it along to the plex team, and see if they can solve it instead. thanks! Link to comment Share on other sites More sharing options...
softworkz 3338 Posted May 22, 2019 Share Posted May 22, 2019 i wish you good luck. Though, with Plex you'll never be able to chat with the responsible developer. Link to comment Share on other sites More sharing options...
nmbrg 3 Posted May 22, 2019 Author Share Posted May 22, 2019 i wish you good luck. Though, with Plex you'll never be able to chat with the responsible developer. yeah, im well aware of that. lets just say that the first team that solves the hw-transcoding issues that we, using windows, has. gets me as a user (dont know if thats good or bad though ) Link to comment Share on other sites More sharing options...
softworkz 3338 Posted May 22, 2019 Share Posted May 22, 2019 Any kind of justified criticism is welcome! This is in fact a weak point at the moment and I hope we'll get this prioritized high enough to get it resolved soon. Link to comment Share on other sites More sharing options...
Luke 37096 Posted February 11, 2020 Share Posted February 11, 2020 This will be resolved in the upcoming Emby Server 4.4 release. Thanks. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now