HEVC playback issue 1080p / stuttering / out-of-sync subs / sound distortion

[softworkz 3339]

Thanks for the logs and the description!

 

In all transcoding situations it's about 10bit videos and this is an area where Emby is not yet perfectly tuned for. It's working in many cases, but not in all. We're still working on this.

 

For the chromecast log, Emby is trying to scale the 10bit video with the hardware, but the H.264 encoder doesn't support 10bit - that's why it fails.

But failures in hardware transcoding are always expected. Normally, transcoding should automatically fall back to software (CPU) transcoding in a way that the users doesn't even notice.

 

So that's the first question: Why doesn't it fall back to software transcoding.

(was there another ffmpeg log immediately after the failed  one?)

 

In case of the chrome browser log it used software transcoding right from the start because the client had requested graphical subtitles to be burnt into the video. There are issues with that and thats why Emby Server used software transcoding for this right from the start.

 

In the 3rd log (Chromecast) it's an issue of color conversion again, similar to the first one.

 

Same question here again: Why doesn't it fall back to software transcoding?

 

 

I'm afraid, this will need some time to investigate....

 

 

Meanwhile, I think your best option would be to disable the QuickSync HEVC decoder. Please try this and report back.

[Kwin 2]

@@softworkz
Thanks for the extensive and elaborate reply Based on what you said, i've tried a few more tests with different configurations ( attached several more logs ).

My findings;
- Playback failed with all 3 HEVC decoders enabled
- Playback failed with all 3 HEVC decoders disabled ( this was unexpected! )
- Playback succeeded with ONLY DX11VA Intel® Iris® Plus Graphics 640 - H.265 (HEVC) enabled   ( 1080p TV SHOW )
- Playback FAILED with ONLY DX11VA Intel® Iris® Plus Graphics 640 - H.265 (HEVC) enabled when I tried to play a movie.  ( also unexpected )

Chromecast tries to connect, gets a connection and then the Emby UI rapidly plays/pauzes the stream but it never actually starts ( guessing it's trying to fallback to a working method? ).
Anyways, I would have thought that disabling the Decoders for H265(HEVC) would've worked, that used to do the trick before Emby 4.0..

My findings for the DX11VA decoder were also strange since it worked for a 60min 1080p 10bit TV show, but failed on 2 movies i've tried.

I've also tried to disable the H264 Preferred hardware encoders to test if it the problem was with the encoder instead of the decoder, but this made no difference.

Hopefully this helps with the investigation If you want me to try more configurations, please let me know.
 

265_movie_log1_failed.txt

265_movie_log2_failed.txt

265_movie2_log1_failed.txt

265_show_log1_succesfull.txt

265_show_log2_failed.txt

Edited May 2, 2019 by Kwin

[softworkz 3339]

@@Kwin - We've done a lot of changes in the recent past. Not all of them haven been applied to the transcoding setup for Chromecast targets. Strange enough, we hadn't got any problems reported in this are during the beta phase. 

 

I think we'll put this on our backlog as a high priority.

 

Just a few notes on the details:

 

That one movie is working because some subtitle burn-in is happening and this leads to color conversion to 8bit - that's why encoding is working.

When you want to test a certain decoder, don't select all three, just one at a time. If it is determine that it doesn't fit for decoding, then the software decoder is automatically used.

If your CPU is powerful enough, then I think your best bet at the moment is probably do turn of hw acceleration completely.

[Kwin 2]

@@Kwin - We've done a lot of changes in the recent past. Not all of them haven been applied to the transcoding setup for Chromecast targets. Strange enough, we hadn't got any problems reported in this are during the beta phase. 

 

I think we'll put this on our backlog as a high priority.

 

Just a few notes on the details:

 

That one movie is working because some subtitle burn-in is happening and this leads to color conversion to 8bit - that's why encoding is working.

When you want to test a certain decoder, don't select all three, just one at a time. If it is determine that it doesn't fit for decoding, then the software decoder is automatically used.

If your CPU is powerful enough, then I think your best bet at the moment is probably do turn of hw acceleration completely.

@@softworkz

 

That's what I did, all 3 options enabled, all 3 disabled and then enabled one at a time ( with a server restart on each change ). But with ALL decoders disabled, it isn't working either.. CPU should be powerful enough, it has been in the past and for other non-chromecast clients.. but it's not even starting the software decoder.

 

In theory, it should start playing even if the CPU isn't strong enough, but it would buffer constantly because it can't transcode quickly enough, but strangely enough this isn't the case. I get the same "Conversion failed" message in the log with all HEVC hardware decoders disabled.

 

I've ran a quick test with HW acceleration turned off completely ( for all decoders ) and tried to stream to a remote client (Chrome, which forces transcode), playback was fine as you can see in the attached log. Playback was a bit laggy at start because transcode/playback position were too close to eachother, but the CPU was doing ok. I'd expect this behaviour on Chromecast as well, but there it doesn't even start.

265_movie_softwaredecoding_chrome.txt

[softworkz 3339]

There seems to a timing mismatch in the audio track.

 

I assume that problem occurs with that specific video only?

[Kwin 2]

@@softworkz
If you're talking about this "Non-monotonous DTS in output stream 0:1; previous: 9308985, current: 9306225; changing to 9308986. This may result in incorrect timestamps in the output file." then yes and no. This occurs on several other movies, but only when transcoding. If it plays by direct stream the movie and audio are fine. That's actually how I started this topic "stuttering / sound distortion" which was very present in Firefox but acceptable on Chrome.

This happens on some HEVC movies, but others work fine and don't generate that log message.

Anyhow, that log was actually meant to show you that non-hardware accelerated transcoding was very much possible on this CPU. But Emby refuses to play on Chromecast regardless which decoders I enable/disable ( or when disabled completely ). To summarize: Even with full software transcoding it doesn't work, meaning it's a litle bit more complicated.


Extra logs show the difference between 2 HEVC movies, 1 with and the other without sound timing issue. I think that is a problem/concern for another day to figure out Since I don't know if it's a problem in the file itself or Emby.


 

265_timing_issue.txt

265_timing_no-issue.txt

Edited May 4, 2019 by Kwin

[softworkz 3339]

For the timing issue I think that's an issue with that specific file.

 

No doubt that your CPU is capable for doing the software transcoding. With regards to Chromecast - as mentioned above - we will need a little time to address this. It shouldn't take too long, but it can't be fixed in a new beta within a few days in this case.

[Kwin 2]

@@softworkz
Aye, I understand that that's not possible I wouldn't expect a quick fix for this.

But I thought the extra info/logs regarding to the work around fix (software transcoding) would be helpful

 

Thanks for the help, eagerly awaiting a solution in the future. Keep me posted!




 

[softworkz 3339]

Just watch for the regular beta releases in a few weeks.

[Luke 37100]

Can you please try the latest beta release to see if it makes any difference? Thanks !

[Kwin 2]

@@Luke
Thanks for the heads up I'll have to give the beta a go from my other PC ( don't want to install it on the actual server ).  I'll report back with new logs

Are there any changelogs for the current beta?

[Luke 37100]

Have you explored the testing area of the community?