Video Stutter when using Dolby TrueHD or DTS-MA

[fcorona76 3]

On 1/30/2024 at 9:49 AM, ebr said:

For kicks, try turning it on and see if anything changes.

Starting with the exact same Handbrake custom profile I showed up above, I changed the encoding frame rate from Constant to Variable and the stutter seems to be resolved in both movies I've found them in while using the current Emby for AndroidTV. I haven't re-enabled the logging yet to see if the dropped frames are still there, or just imperceptible, but I'll check that tonight.

Right now the Shield is bone stock settings and Emby for Android TV is bone stock.

~23.97fps constant with any audio in this movie stutters. ~23.97fps with no audio plays well with no stutter. ~23.97fps with Emby server transcoded and downmixed audio plays well with no stutter. ~23.97fps variable with any audio plays well with no stutter. When I say it stutters, it is occasional at repeatable points in the film and not constant throughout.

Is this known or something that can be addressed? No other platform, or player on the Shield, seems to have this problem.

Edited February 1 by fcorona76
added context

[rbjtech 4280]

40 minutes ago, fcorona76 said:

Starting with the exact same Handbrake custom profile I showed up above, I changed the encoding frame rate from Constant to Variable and the stutter seems to be resolved in both movies I've found them in while using the current Emby for AndroidTV. I haven't re-enabled the logging yet to see if the dropped frames are still there, or just imperceptible, but I'll check that tonight.

Right now the Shield is bone stock settings and Emby for Android TV is bone stock.

~23.97fps constant with any audio in this movie stutters. ~23.97fps with no audio plays well with no stutter. ~23.97fps with Emby server transcoded and downmixed audio plays well with no stutter. ~23.97fps variable with any audio plays well with no stutter. When I say it stutters, it is occasional at repeatable points in the film and not constant throughout.

Is this known or something that can be addressed? No other platform, or player on the Shield, seems to have this problem.

So I looked this up to confirm my understanding - and this is what handbrake descibe it as.   Note they say CFR is not recommended ..     

So is handbrake maybe changing a frame rate to a constant frame rate, when you should have left it as VFR to copy the source 1:1

As this is a panning shot (in the example given) they maybe have changed the frame rate to make it look smoother for example.

If you have re-encoded that clip with the recommended VFR and the stutter no longer exists - then this may explain what is happening ?

Quote

Selecting Same as Source allows you to select Variable Frame Rate (VFR), which instructs HandBrake to make your new video’s frame rate an exact copy of your Source frame rate. No frame rate conversion is performed.

Constant Frame Rate (CFR) makes your new video exactly one frame rate throughout. When used with Same as Source, HandBrake will detect the frame rate of your Source and make sure any variable portions are made constant at the same rate. When used with a specific frame rate, HandBrake conforms your entire video to the new frame rate. This method is not recommended except in special circumstances, such as encoding for import into an NLE or for extremely old devices.

 

Edited February 1 by rbjtech

[fcorona76 3]

22 minutes ago, rbjtech said:

So I looked this up to confirm my understanding - and this is what handbrake descibe it as.   Note they say CFR is not recommended ..     

So is handbrake maybe changing a frame rate to a constant frame rate, when you should have left it as VFR to copy the source 1:1

As this is a panning shot (in the example given) they maybe have changed the frame rate to make it look smoother for example.

If you have re-encoded that clip with the recommended VFR and the stutter no longer exists - then this may explain what is happening ?

 

Possibly. But why does the video, with CFR and Same as Source, work flawlessly when I don't encode an audio track? And why does every other player play it fine?

 

I've now changed my encoding profile to tick that VFR box. At least future encodes might not have this issue.

 

Maybe it's an "edge" scenario but it's leaving me frustrated nonetheless.

[ebr 14918]

2 hours ago, fcorona76 said:

But why does the video, with CFR and Same as Source, work flawlessly when I don't encode an audio track?

Because Exoplayer uses the audio track as the main timing "heartbeat" of playback.  So, if the video isn't properly in sync with it, it could cause problems.  Other players may, instead, use the video timecode as the main driver and, in those, you may get discrepancies in the audio instead (and these may or may not be perceptible).

[rbjtech 4280]

16 minutes ago, ebr said:

Because Exoplayer uses the audio track as the main timing "heartbeat" of playback.  So, if the video isn't properly in sync with it, it could cause problems.  Other players may, instead, use the video timecode as the main driver and, in those, you may get discrepancies in the audio instead (and these may or may not be perceptible).

Yep - and I did notice this is AviDemux - the example file had zero key frames - thus seeking to any part of the video was not working, you could only play from the start.  All my other files,  you can seek and use key-frames ....  

[fcorona76 3]

19 hours ago, rbjtech said:

Yep - and I did notice this is AviDemux - the example file had zero key frames - thus seeking to any part of the video was not working, you could only play from the start.  All my other files,  you can seek and use key-frames ....  

Odd, not sure why there would be no keyframes as I am not overriding that value anywhere. standard Handbrake value must be higher than the 14 second (*23.97fps) clip allows. I definitely do not have a problem with seeking in the full encodes nor is there loss of audio sync....just those rare, and nasty, frame drops.