Intel QuickSync - Repeated Playback

[Nisten 15]

Issue: Once I finish playing a movie or a tv show on the roku, the app goes back several minutes and replays a part of the movie/show that we've already seen.

 

Findings: This doesn't happen when "hardware encoding" is turned off but only seems to happen when its turned on.

 

Is there a way to stop this from happening and still leave hardware encoding on or is it out of Emby's control? Reason I ask is because i can leave "hardware encoding" off for mpeg-ts transcoding but for high profile h264 transcoding (due to low bitrates), "hardware encoding" is a must for my mini-pc.

 

One of the moderators, i think @@Happy2Play, said that H264 decoding wasn't actually working due to a bug with ffmpeg but i think that was pre-netcore so i don't know if it still applies post-netcore

Edited January 22, 2018 by Nisten

[Luke 38850]

we've seen cases where the quicksync encoder creates invalid timestamps and that is probably causing this.

 

@@Waldonnis do you remember where your forum post is about adjusting the command line for this? thanks.

[Waldonnis 148]

I made a post about it ignoring forced keyframes and using an open GOP, which caused segmenting to get a little wacky, but I didn't inspect the timestamps too closely since it wasn't what I was looking at (post was here for reference, and I didn't find a way to fix it with QuickSync at the time).

 

I'll run some tests today or tomorrow and see if timestamp generation is really causing this.  Something never seemed quite right about that, but it was pretty far down the list of things to look into.  Out of curiosity, has there ever been a report of this from a device other than Rokus?  If not, I can look at the Roku player object docs again to see if there's anything else needed for non-static playlists.

[Nisten 15]

Tried testing this with the web app for a tv episode

 

Test 1 (auto play next episode - turned off): Player shows a black screen when done with playback

Test 2 (auto play next episode - turned on): Player shows a black screen when done with playback but doesn't auto play next episode

 

For some reason, there's 12 ffmpeg logs so i only posted the last three.

ffmpeg log 10.txt

ffmpeg log 11.txt

server log (around time of web app playback test).txt

ffmpeg log 12.txt

Edited January 23, 2018 by Nisten

[Nisten 15]

Test 3 (hardware encoding - turned off, auto play next episode - turned on): Player starts loading next episode when done with playback of initial episode.

ffmpeg log 1 (no hardware encoding).txt

ffmpeg log 2 (no hardware encoding).txt

ffmpeg log 3 (no hardware encoding).txt

server log (around time of web app playback 3rd test).txt

[Luke 38850]

I made a post about it ignoring forced keyframes and using an open GOP, which caused segmenting to get a little wacky, but I didn't inspect the timestamps too closely since it wasn't what I was looking at (post was here for reference, and I didn't find a way to fix it with QuickSync at the time).

 

I'll run some tests today or tomorrow and see if timestamp generation is really causing this.  Something never seemed quite right about that, but it was pretty far down the list of things to look into.  Out of curiosity, has there ever been a report of this from a device other than Rokus?  If not, I can look at the Roku player object docs again to see if there's anything else needed for non-static playlists.

 

Yes, I'm pretty sure there has been. 

[Waldonnis 148]

Yes, I'm pretty sure there has been. 

 

Hmm, maybe a closed GOP is going to be required regardless then (it's highly recommended anyway).  This all may be sniffing up the wrong proverbial tree for this problem, but worth looking into since it's one of the most obvious differences compared to libx264 output-wise.  After some light inspection of locally-generated static HLS playlists/segments, I'm not seeing anything overly odd with timestamps, but I haven't looked too closely at segment duration yet.  I'll resurrect my old Roku testing channel and see if I can verify it one way or another.  I just need to find a file in my library that triggers it reliably first     At the very least, it should make durations more reliably predictable than they are currently, and make seeking a bit more accurate when using either nvenc or qsv...as well as eliminating an unknown with the looping issue.

 

FYI, I was wrong about qsv being an open GOP...it was using a closed GOP, but it was 10s long  .  I've had moderate success with reducing that and generating 3s segments with it, so if the issue is segment size, at least qsv probably won't be left out in the cold solutions-wise.  One thing I don't recall ever seeing is if this happens with vaapi....

[Luke 38850]

Thanks for the info.