Jump to content

Intel QuickSync - Repeated Playback


Nisten
 Share

Recommended Posts

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 by Nisten
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Waldonnis

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.

Link to comment
Share on other sites

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 by Nisten
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

Waldonnis

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  :P   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 :blink: .  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....

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...