Live Media with RunnigText in the bottom - text is moving from side to side

Hi,

We have live media where there is running text from right to left at the bottom of the video

While using this media in Exo Player on Android TV box(especially) we can see video looks ok but the running text is moving from side to side (shaking - that makes you dizzy )or getting stuck for fraction of second

Our media experts says that it is ingested correctly and the media is just fine

I am not sure where issue is and would much appreciate if you could point me for the root cause of this issue. if is it decoders limitations or frames skips or live packets sync or frame rate or if there are any steps Exo Player API can help to make the text running stable and constantly running in fluent manner

this media has 1 50fps(5.4Mbps) track and 25fps tracks in lower bitrates

While playing the media I can see in the log cat errors regarding the decoders that are being used I tried the other decoder in the device instead the awsome2 decoder but I could only see it got worst.

-07 13:39:26.299  4412  9367 E ACodec  : [OMX.amlogic.avc.decoder.awesome2.secure] setPortMode on output to DynamicANWBuffer failed w/ err -2147483648
12-07 13:39:26.304  4412  9367 I ACodec  : codec does not support config priority (err -1010)
12-07 13:39:26.305  4412  9367 I ACodec  : codec does not support config operating rate (err -1010)
12-07 13:40:02.921  4412  9367 D SurfaceUtils: connecting to surface 0xb475e808, reason pushBlankBuffersToNativeWindow(err2)
12-07 13:40:02.992  4412  9468 E ACodec  : [OMX.amlogic.avc.decoder.awesome2.secure] setPortMode on output to DynamicANWBuffer failed w/ err -2147483648
12-07 13:40:02.996  4412  9468 I ACodec  : codec does not support config priority (err -1010)
12-07 13:40:02.996  4412  9468 I ACodec  : codec does not support config operating rate (err -1010)

Versions:

Exo Player v2.15.1 Android TV box - Android (ZTE android 10, NVIDIA SHEILD Android 9, Xiomi mii box Android 9)

I am sending in mail the files that we use (ts format) I am sending the BugReport as well

please notify me how I can help if any issue with reproduction.

10x

GIlad

[Orenbk]

@tonihei - Appreciate if you can provide an update over this critical issue. According to your previous recommendations (sent to @giladna) we were able overcome the live and catch-up scenarios but left with “Seek” been unresolved. Thank you, Oren.

[tonihei]

Thanks for checking!

I have forked the code as you have request and combined both experimentalSetAsynchronousBufferQueueingEnabled(true)

The fact that experimentalSetAsynchronousBufferQueueingEnabled(true) helps very likely indicates a performance problem with the high frame rate streams on these devices (as already suggested above). Using the async mode makes the rendering process a but more performant, but there’s generally not much we can do if the device just isn’t capably of decoding the video fast enough.

Try disabling the frame output timing by passing 0 to releaseOutputBuffer

The fact that this seems to help again points to some device-specific logic outside of our control that tempers with the frame release timestamps (or automatically drops frames). We can keep this issue open to test out potential work workarounds / adaptations to these devices. It’s unlikely we get around to this soon though.

that is better than it was but still not perfect

Have you considered changing the track selection to only selects tracks with a lower frame rate where the device is capable of decoding them fast enough? You can, for example, specify TrackSelectionParameters.Builder.setMaxVideoFrameRate(30) if you know a certain device isn’t capable of playing 50 or 60fps smoothly.