Black flashes

[Dodgexander 8]

TCL R517 2018 Roku 4.0.44

Server 4.6.0.7 (Linux, docker)

Regular black flashes every minute or so with 1080p 50 h264 mkv 2ch AAC audio. Video below:

https://youtube.com/shorts/O4WNztEMR1Y?feature=share

Doesn't happen on my Android TV, only Roku TV.

Doesn't happen with a force transcode but does with direct play and remux.

Beta 4.0.46 also has the same problem.

Limit frame rate 30fps didn't help.

Roku app log about 1036 and 1106 pm Eastern.

Server log attached.

embyserver.txt

Edited February 22, 2022 by Dodgexander

[Luke 42077]

Hi, was an ffmpeg log file generated as well?

[ebr 16169]

Hi.  There is no evidence of any issue in the app log.  That kind of looks like what happens when a TV changes display mode, but a little faster.  Have you tried remuxing one of these videos to see if this issue goes away?

[Dodgexander 8]

5 hours ago, Luke said:

Hi, was an ffmpeg log file generated as well?

Attached a few that hopefully help. Direct stream would have been when the issue was happening and transcode when it wasn't. I tried several times repeating the problem so if there's something in the logs it should be in every direct stream one.

5 hours ago, ebr said:

Hi.  There is no evidence of any issue in the app log.  That kind of looks like what happens when a TV changes display mode, but a little faster.  Have you tried remuxing one of these videos to see if this issue goes away?

Do you mean remuxing them post playback or remuxing during?

I can perform playback correction to force the server to remux and the issue is still present.

If I perform playback correction twice to transcode, the issue is not present.

ffmpeg-transcode-5165fc6d-14bf-47a0-985d-e90c8e4404c3_1.txt ffmpeg-directstream-aef17164-ee00-4a29-b421-0eed3f0d045f_1.txt ffmpeg-transcode-9d56c333-9447-4eb0-9eb0-d649ca0eccd2_1.txt ffmpeg-directstream-865b3633-1009-4603-b827-4c087e57ef8c_1.txt

[Luke 42077]

This suggests to me that there's something about that video that the Roku video player has trouble with. That's why you see the problem whenever we serve the original video directly, either via direct play or remuxing. But when we do a full transcode, the problem goes away.

We can't automatically transcode it because if you look at the media info, it looks like something the TV supports with direct plays, so it's hard to detect this situation. 

You may want to consider reencoding this file. Is this the only file with the problem?

[ebr 16169]

Hi I meant remuxing the file with something like mkvtoolnix for the reasons Luke mentioned. 

[speechles 2055]

[22:47:55.283 [h264 @ 0x24fdec0] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one

The container cannot be direct played and allow transport control. The TS container must be transcoded to allow seeking. Once that is done the two streams (video and audio) are copied. But it appears the video stream is not following the specs. Whoever encoded that video stream did not follow specifications for compability. They went "off the charts" or "off the map". The reference frames are too high for the resolution. When ffmpeg is serving via HLS it has to discard one of the frames. If one of those happens to be an i-frame/keyframe it will show as black over the entire screen for a moment if this were direct play/stream. A black flash will show for an unknown duration. This is exactly what you are seeing.

You MAY be able to  fix this with MKVToolNix GUI and simply correct the header. Have it write a new header for the file. The Roku will always trust the header of your MKV implicitly. You must first fix the header (or at least rewrite it and make sure it is correct) and see if that fixes the issue. If fixing/rewrite does correct this issue you must also unfortunately re-encode the entire video stream with a lower reference frame count.

 

Edited February 23, 2022 by speechles

[Happy2Play 9780]

11 minutes ago, speechles said:

[22:47:55.283 [h264 @ 0x24fdec0] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one

The container cannot be direct played and allow transport control. The TS container must be transcoded to allow seeking. Once that is done the two streams (video and audio) are copied. But it appears the video stream is not following the specs. Whoever encoded that video stream did not follow specifications for compability. They went "off the charts" or "off the map". The reference frames are too high for the resolution. When ffmpeg is serving via HLS it has to discard one of the frames. If one of those happens to be an i-frame/keyframe it will show as black over the entire screen for a moment if this were direct play/stream. A black flash will show for an unknown duration. This is exactly what you are seeing.

You MAY be able to  fix this with MKVToolNix GUI and simply correct the header. Have it write a new header for the file. The Roku will always trust the header of your MKV implicitly. You must first fix the header (or at least rewrite it and make sure it is correct) and see if that fixes the issue. If fixing/rewrite does correct this issue you must also unfortunately re-encode the entire video stream with a lower reference frame count.

 

So is there a disconnect somewhere in probed info?  Or just overall bad headers?

"RefFrames":1

 

[Dodgexander 8]

I can't seem to find the option when editing the header for reframes in MkVToolnix, anyone know if it's possible?

[Happy2Play 9780]

9 minutes ago, Dodgexander said:

I can't seem to find the option when editing the header for reframes in MkVToolnix, anyone know if it's possible?

Only way to change reframes is reencoding.  But for this example remuxing it with MKVToolnix to see if it is just a header issue.

[Dodgexander 8]

6 hours ago, Happy2Play said:

Only way to change reframes is reencoding.  But for this example remuxing it with MKVToolnix to see if it is just a header issue.

I wasn't sure if I needed to change anything in mkvtoolnix so I just used the default options and the flashing still happened.

Took the same file and re encoded with handbrake and just like transcoding with emby the issue goes away.

If the files are out of spec I'll need to reencode them all, just a shame Roku seems to be so sensitive compared to other clients.

Thanks for everyone's help!

 

[Luke 42077]

Let us know what happens. Thanks.

[Dodgexander 8]

19 hours ago, Luke said:

Let us know what happens. Thanks.

I have, remuxing didn't help. Reencoding did.

Must just be something about the way my friend ripped these files.