Fire Stick 4k Max - Random video freeze on some H.264 files

[rbjtech 4284]

Wow -  4-7fps using 4 threads for a 1080p AV1 encode seems excruciatingly slow ?    For 4K encodes it sounds like we are back to 'days' to encode a single film again .. Hmmm.

Thanks for the info though - I'll watch with interest ..

[RanmaCanada 346]

On 27/01/2022 at 19:11, rbjtech said:

Wow -  4-7fps using 4 threads for a 1080p AV1 encode seems excruciatingly slow ?    For 4K encodes it sounds like we are back to 'days' to encode a single film again .. Hmmm.

Thanks for the info though - I'll watch with interest ..

AV1 is more complex than HEVC.  It needs a literal order of magnitude of CPU power to get comparable speeds without using SVT.  The other issue is some of them are only single threaded, and at times the encoders don't respect "threads" command and you'll have only 1 core encoding, and the rest idle.  Hence why I get angry when no one explains switches and why they don't work..  It's a mess and they refuse to acknowledge that.

[ExpedientFalcon 6]

There's certainly acknowledgement that the documentation particularly in aomenc is... lacking. Unfortunately nobody has actually gotten around to writing up details of what every option does. There's also an entirely other layer of "speed features" in aomenc which are hidden from the user and controlled by `cpu-used`. So... it is indeed a mess. Some of us are trying to improve the state of it, but it's a long process, especially since there's not much help on the documentation side coming from AOM engineers.

I'm sorry you've had a bad experience with the AV1 community until now. Most of us try to be open and educational. I'm no fan of gatekeeping either.

Edited January 30, 2022 by ExpedientFalcon

[rbjtech 4284]

This sound like a real shame - especially as the heart of AV1 is 'open source' ... nothing should be behind any sort of gate .. 

[ExpedientFalcon 6]

At long last, I have a solution! Or rather, a workaround, since the hardware decoder on the 4k Fire Stick Max is still broken.

There is a commonality in the broken files. When the integrity of the video stream is checked using

ffmpeg -v error -i brokenfile.mkv -map 0:v:0 -f null /dev/null

A broken file will produce the stderr output "Application provided invalid, non monotonically increasing dts to muxer" (while a clean file will produce no output). Most H.264 decoders will happily ignore this, or at worst, drop a few frames and go on. It seems the Fire Stick 4k Max decoder does not know how to recover from this. Remuxing also does not fix the timestamps, even if attempting to remux with the "fix timestamps" option in either ffmpeg or mkvmerge specifically selected.

But there is a way to fix the timestamps in a broken file without reencoding.

First we extract the video track to raw h264 using mkvextract:

mkvextract tracks brokenfile.mkv 0:video.h264

Then we merge it back with the audio/subtitle/etc. tracks from the original file. But this will now create new, correct timestamps.

mkvmerge --ui-language en_US --output '/home/falcon/encodes/fixedfile.mkv' --language 0:und '(' /home/falcon/encodes/video.h264 ')' --no-video --language 1:en '(' '/home/falcon/encodes/brokenfile.mkv' ')' --track-order 0:0,1:1

The 4k Max stick can now play back through this new file with no issues.

[rbjtech 4284]

5 minutes ago, ExpedientFalcon said:

At long last, I have a solution! Or rather, a workaround, since the hardware decoder on the 4k Fire Stick Max is still broken.

There is a commonality in the broken files. When the integrity of the video stream is checked using

ffmpeg -v error -i brokenfile.mkv -map 0:v:0 -f null /dev/null

A broken file will produce the stderr output "Application provided invalid, non monotonically increasing dts to muxer" (while a clean file will produce no output). Most H.264 decoders will happily ignore this, or at worst, drop a few frames and go on. It seems the Fire Stick 4k Max decoder does not know how to recover from this. Remuxing also does not fix the timestamps, even if attempting to remux with the "fix timestamps" option in either ffmpeg or mkvmerge specifically selected.

But there is a way to fix the timestamps in a broken file without reencoding.

First we extract the video track to raw h264 using mkvextract:

mkvextract tracks brokenfile.mkv 0:video.h264

Then we merge it back with the audio/subtitle/etc. tracks from the original file. But this will now create new, correct timestamps.

mkvmerge --ui-language en_US --output '/home/falcon/encodes/fixedfile.mkv' --language 0:und '(' /home/falcon/encodes/video.h264 ')' --no-video --language 1:en '(' '/home/falcon/encodes/brokenfile.mkv' ')' --track-order 0:0,1:1

The 4k Max stick can now play back through this new file with no issues.

This is probably why I have never had any issues watching h264 content on my FireTV Max then - as I demux and remux (stripping out all the unwanted tracks) as part of my import process ..  

But as you say, the REAL issue is the hardware not being flexible enough to ignore the source file errors (that all others players, including Amazons own previous generation players) can handle without issues..

Thanks for pinpointing the issue !