exoplayer-amazon-port: FTV Stick 4K interlaced video playback leads to media player crash

Following the latest update (6.2.6.4) interlaced videos can crash FTV Stick 4K’s media player, which won’t be able to play any more content until a complete device restart.

video of the issue

samples that will crash the MP:

1, 2, 3

Fire OS 6.2.6.4 (NS6264/1995)
Fire TV Home Version 6.1.6.0-727

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 5
  • Comments: 303 (11 by maintainers)

Most upvoted comments

Oh dear… so many misunderstandings here. Let me summarize what has happened:

  • Interlaced MPEG2 videos only displayed a green picture (#58). Status: FIXED
  • Interlaced H264 videos crashed the player and required a reboot (#81). Status: FIXED (the exact video samples provided by the original author are playing perfectly now)
  • Interlaced H264 videos in unusual color formats (best theory so far thanks to the research by @leone007) still crash the player. Status: YOU ARE READING THIS THREAD RIGHT NOW

Nobody had discovered the final problem in the previous thread, because there were sadly no sample files provided with that newly discovered crashing format… so they’ve only fixed the general deinterlacing issue, but had missed the fact that there was another way to crash the player too… and literally nobody knew about it until now… 😦

Software or Hardware problem?

Answer: Software problem. The hardware decoder chip has a firmware (kind of like a BIOS) which decides what parts of the hardware to use for decoding various features of various video formats, and in what way…

To fix this final issue, Amazon has to tell the decoder chip manufacturer to fix their firmware again, for this newly discovered separate problem. Amazon does not have the source code for the hardware manufacturer’s chip (that’s their proprietary trade secret).

How long will it take to fix?

It depends on the hardware chip manufacturer. The only thing Amazon can do for us is to ask them to hurry up this time.

Releasing a fix took the the hardware chip maker around 4 months last time, because their process is as follows (it was described by Amazon in the previous H264 ticket):

  • Identify the problem.
  • Code a fix, which takes time.
  • Test all other formats again over a period of time, to ensure the fix didn’t break anything else instead.
  • Release the new firmware.

After receiving the fixed firmware, Amazon has to do their own internal testing and OS development too, which took 2 months last time.

  • Test the new fix.
  • Ensure that everything in the system is still stable.
  • Release the fix together with the next OS update.

Hopefully this time they’ll skip step 3 and do a quick “out-of-order” update of the decoder firmware. But unfortunately they may not be able to do that due to company routines. Sigh… From what we learned in the last thread, Amazon does all testing on their latest in-development (non-public) OS version and releases everything new “all at once” in a single finished OS update package, rather than risking bugs from sending out separate bugfixes to people running older software than what they themselves use in their development area…

But please, break that tradition this time. As soon as you receive the firmware fix, please do testing on the current public OS version and then release the fix for all of us! I can see that people are going to be very angry and it will cause a lot of ill-will towards Amazon if people have to wait 6 months yet again for the final fix… it will damage the reputation of the Amazon FireTV and it will be known as a device where fixes “take forever, if ever” to arrive…

My hope and advice is that you therefore strongly pressure the hardware chip vendor for a quicker fix for the final problem, and that you release it to us as soon as possible on the current OS version.

However…

The last we heard from Amazon was in the previous thread, where @rinoshs acknowledged this final problem and asked us to make a ticket. We haven’t heard anything since then. It’s still only been 7 days, but we would really appreciate hearing from someone at Amazon to know what work is being done.

We’re all ready to help you do the research but we’re at a point where we need your input as well… To test the various samples in this thread and trying to figure out if it’s indeed a colorspace issue (BT.709 colors might be the cause of the crashes).

The bright side!

It’s a software issue. It only affects a few TV channels. It’ll be fixed. And I’m very happy with my FireTV 4K. It’s cheap. It’s small. It has a great remote control (lots of tactile buttons; far better than NVidia Shield TV or Apple TV). It’s super powerful at running any software. It’s 4K. It’s HDR/Dolby Vision/Dolby Atmos. It’s great!

@dopsy @gb160 Upon finding out that this page (hello, you are reading this page right now) is not controlled by the video-decoder team within Amazon, and that @rinoshs has absolutely nothing to do with the video-decoder team, and that we are writing our complaints on a completely unrelated webpage (wrong place)… your reaction is to… continue blaming someone who isn’t responsible for the issue, even though he’s not responsible for the issue, and is now a really good chance for us to forward some information from the actual internal team.

I would maybe agree that he could have been faster in forwarding information to/from the team, closing and locking this ticket if necessary. But then I looked at his activity:

https://github.com/amzn/exoplayer-amazon-port/commits?author=rinoshs

It’s clear that rino works for amazon but he isn’t a super active GitHub member, isn’t active on this page (exoplayer-amazon-port), and he isn’t on the relevant team. WE are on the wrong webpage. Stop blaming an innocent unrelated worker. And yes, rino suggested that we make this new ticket, but he probably thought some other team member would pick it up since he isn’t active on this site. Blame them if you want, but not him. That’s all I am saying. Have some respect.

Furthermore, I checked all other tickets on this page (open tickets and closed tickets), as well as the commit history (no activity since end of May 2019), and yeah… it turns out that we (who are on the wrong webpage, remember?) are posting on a very inactive, unrelated project, and blaming unrelated workers who are barely on this page…

This is the basically-inactive webpage for Amazon’s version of a video player called “ExoPlayer” (by Google). It has nothing to do with video decoding hardware at all and clearly isn’t monitored for activity very often… I am not even sure why customers decided to start making these hardware bug tickets here… (I just came here from Google and other forums… like all of you…)

Anyway, dopsy and gb160, since you have so much energy, which one of you is going to contact Amazon customer support and try to get a support agent to fetch the information from the internal team? I mean… you may as well put your energy and passion to good use by following rino’s suggestion for how we can get more information from the right team. Do either of you want to do that? If not, why not? Why should someone else (like rino) have to do it for you?

Personally I don’t care much anymore, after finding out that the appropriate team is working on the issue internally (thanks to rino popping back in). Sure I’d love to know more details about the status (mostly whether the hardware decoder 3rd party has begun programming the new firmware yet), but I also know that me knowing about their internal work won’t speed up a potential fix in any way. It’ll come when it’s ready either way…

If one of you contacts customer support, please share the information.

@aditya-gu When I was investigating this issue last year, I discovered that OMX.MTK.VIDEO.DECODER.AVC can stall unless h264 NALUs for slices have zero padding at the end.

So a little bit more on this, after consulting and testing with one of our dev guys at work, he’s been able to pinpoint the problem to missing timestamps in random packets which crash exoplayer.

Due to using DVB-T, we thought this could probably be circumvented by using a different source…ie DVB-S, but no, certain channels are broadcast with packets that have these missing timestamps, why im not sure, but they are purposely broadcast in this fashion (In the UK)

Its quite easy to view and reproduce these errors…the simple way is to get the url of one of the affected channels, via Tvheadend (DVB-t) or OpenWebif (DVB-s), pipe that into FFmpeg (using ‘-c copy’ so no transcoding is taking place)…let it run and sometimes instantly, sometimes after a while this will appear in the log:

[mpegts @ 0x1b1db50] Timestamps are unset in a packet for stream 0.

and within 2-3 seconds exoplayer will freeze on the Firestick 4K…every single time. This behaviour is identical on both DVB-T(aerial) and DVB-S(Satellite dish), both of which have very strong signals. Certain channels (BBC1 for example) you’re lucky to play for more than 10 seconds before this error occurs, other channels run for longer, but they occur eventually and a crash is inevitable.

Without transcoding there is no way round this, almost all other players can handle this without crashing, as these channels (with the missing timestamps) can be successfully played on every other player available.

Exoplayer cannot, that is the root of this problem now, no hardware fix is needed.

Hi everyone,

I am testing a firmware change that is targeting the reported issues on AFTMM platform since the last firmware update.

We have already tested the above linked files. In most cases (as already shown in this thread) there are clear issues with the content files - sometimes ffprobe shows that the encoder is incorrectly configured or the ts file is referencing a header or I-frame that is not present in the file. The proposed firmware change tries to make the decoder more robust, but there can be many additional ways to go out of spec.

As firmware updates take multiple months to deliver, we should cover as many content, encoder setting etc. issues in a single update as possible. I would appreciate if you could provide any additional files I should test the proposed firmware change with. If you have issues with any video streams on the AFTMM platform, while it plays fine on other platforms (still using the HW decoder), please provide a link to those files. Any content that shows no issues if you run a simple analyser on the stream (like ffprobe) is preferred.

Note: as these changes are targeting the video decoder, files without audio streams are also preferred. We should not mix the audio issues into this problem (there are multiple files linked above that have issues with the audio stream, too.)

The issue is being followed up internally, and is being worked on by the respective device team. As updates become available I will share them.

For the record, we had earlier tracked a fix for this issue that did go out in Q2. However it did not fix all use cases.

In hindsight we might have set the wrong expectation on this forum being the primary contact for fixing device issues such as this. It is not, Amazon Customer Service (see link below) is the primary forum for such issues.

The standard of language used in the posts is declining. If this continues, posting on this issue will be restricted.

Amazon Customer Contact https://www.amazon.com/hz/contact-us/csp?from=gp&source=contact-us&initialIssue=asin-order&_encoding=UTF8& ?

Hi all, We are working on this issue.

@gb160 , You mentioned in your comment (Link) that “almost all other players can handle this without crashing”. Could you please list some of those players? Are they using hardware/platform decoders or software decoders (custom decoder implementation)?

Good luck, @gb160.

@everyone: Please don’t flood this thread the same way as the original ticket. That one was locked after getting like 100 replies in 1 day. xD Please be careful and only add meaningful notes to the discussion! We already know that this issue is huge and affects everyone, so we don’t need 100x “me too” posts again. We already have that in the original thread. Please also remember that this is a vendor firmware (BIOS) issue and that Amazon can’t fix it themselves… it must be fixed by the decoder-chip vendor, who are the only ones with the BIOS source code! Any timeframe for a fix depends completely on the chip vendor… The vendor’s “fix” for the original issue did make some channels work, but still crashes badly on other channels, so they will need to do another BIOS code update…! Please be patient and let’s do our best to help Amazon and the chip vendor figure out what’s wrong!

@leone007 Thanks a lot for starting the ticket. I was just going to do it! Here’s the sample I was playing in my crash example video (the one you linked to):

Here’s more information about my crash video: https://github.com/amzn/exoplayer-amazon-port/issues/81#issuecomment-504814551

I bought my stick in late May or early June of this year.

And here’s my OS version (it installed the OS update on June 22nd, and then two “System components” updates):

Fire OS 6.2.6.4 (NS6264/1995)
Fire TV Home Version 6.1.6.0-727

I can confirm that your new samples crash on my FireTV Stick 4K too!

I just saw something interesting when I ran ffprobe -- 1080i_testclip.ts. It is saying that this video is corrupt and is referencing some non-existent “PPS” (?) data. It also shows a very interesting error saying number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one

[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] decode_slice_header error
[h264 @ 0x7fcb89002800] no frame!
[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] decode_slice_header error
[h264 @ 0x7fcb89002800] no frame!
[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] decode_slice_header error
[h264 @ 0x7fcb89002800] no frame!
[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] decode_slice_header error
[h264 @ 0x7fcb89002800] no frame!
[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] decode_slice_header error
[h264 @ 0x7fcb89002800] no frame!
[h264 @ 0x7fcb89002800] mmco: unref short failure
    Last message repeated 1 times
[h264 @ 0x7fcb89002800] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one
[h264 @ 0x7fcb89002800] mmco: unref short failure
    Last message repeated 1 times
[h264 @ 0x7fcb89002800] Increasing reorder buffer to 2
Input #0, mpegts, from '1080i_testclip.ts':
  Duration: 00:00:37.83, start: 2908.645344, bitrate: 7943 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 126 kb/s

And to get the interlacing info with ffprobe, I must run this command: ffprobe -select_streams v -show_frames -- 1080i_testclip.ts

Then simply looking at one of the frames, to see what the video data is:

[FRAME]
media_type=video
stream_index=0
key_frame=0
pkt_pts=262051200
pkt_pts_time=2911.680000
pkt_dts=262053000
pkt_dts_time=2911.700000
best_effort_timestamp=262051200
best_effort_timestamp_time=2911.680000
pkt_duration=1800
pkt_duration_time=0.020000
pkt_pos=2023632
pkt_size=12904
width=1920
height=1080
pix_fmt=yuv420p
sample_aspect_ratio=1:1
pict_type=P
coded_picture_number=74
display_picture_number=0
interlaced_frame=1
top_field_first=1
repeat_pict=0
color_range=tv
color_space=bt709
color_primaries=bt709
color_transfer=bt709
chroma_location=left
[/FRAME]

I then ffprobed the 3 samples you provided as well:

  • All 3 show the exact same error in ffprobe (which most likely means nothing at all, but MAY still be related):
[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] SPS unavailable in decode_picture_timing
[h264 @ 0x7fcb89002800] non-existing PPS 0 referenced
[h264 @ 0x7fcb89002800] decode_slice_header error
[h264 @ 0x7fcb89002800] no frame!
  • Only my original file above and your -Eurosport-HD2019-06-2410-37.ts contains the “too many reference frames, more than the h264 spec allows” error. The other 2 samples you gave me didn’t have this error:
[h264 @ 0x7f98bc809800] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one
Input #0, mpegts, from 'Eurosport 1-.ts':
  Duration: 00:01:14.40, start: 5177.459467, bitrate: 6782 kb/s
  Program 1 
    Metadata:
      service_name    : ?Service01
      service_provider: ?FFmpeg
    Stream #0:0[0xd3]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn, 50 tbc
    Stream #0:1[0xdd](deu): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 384 kb/s

[FRAME]
media_type=video
stream_index=0
key_frame=0
pkt_pts=466266552
pkt_pts_time=5180.739467
pkt_dts=466268352
pkt_dts_time=5180.759467
best_effort_timestamp=466266552
best_effort_timestamp_time=5180.739467
pkt_duration=1800
pkt_duration_time=0.020000
pkt_pos=2461860
pkt_size=7487
width=1920
height=1080
pix_fmt=yuv420p
sample_aspect_ratio=1:1
pict_type=B
coded_picture_number=83
display_picture_number=0
interlaced_frame=1
top_field_first=1
repeat_pict=0
color_range=tv
color_space=bt709
color_primaries=bt709
color_transfer=bt709
chroma_location=left
[/FRAME]

---------------------------

Input #0, mpegts, from '-Eurosport-HD2019-06-2410-37.ts':
  Duration: 00:03:00.82, start: 3907.001156, bitrate: 8645 kb/s
  Program 206 
    Metadata:
      service_name    : Eurosport HD
      service_provider: DIGI Debrecen
    Stream #0:0[0x21](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s
    Stream #0:1[0xbb8]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:2[0xc81](hun): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s

[FRAME]
media_type=video
stream_index=1
key_frame=0
pkt_pts=351970568
pkt_pts_time=3910.784089
pkt_dts=N/A
pkt_dts_time=N/A
best_effort_timestamp=351970568
best_effort_timestamp_time=3910.784089
pkt_duration=1800
pkt_duration_time=0.020000
pkt_pos=3182652
pkt_size=7433
width=1920
height=1080
pix_fmt=yuv420p
sample_aspect_ratio=1:1
pict_type=B
coded_picture_number=78
display_picture_number=0
interlaced_frame=1
top_field_first=1
repeat_pict=0
color_range=tv
color_space=bt709
color_primaries=bt709
color_transfer=bt709
chroma_location=left
[/FRAME]

---------------------------

Input #0, mpegts, from '-Eurosport-2-HD2019-06-2410-23.ts':
  Duration: 00:03:01.10, start: 77289.788911, bitrate: 9666 kb/s
  Program 211 
    Metadata:
      service_name    : Eurosport 2 HD
      service_provider: DIGI Debrecen
    Stream #0:0[0xfa0]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x106b](hun): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s
    Stream #0:2[0x106c](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s

[FRAME]
media_type=video
stream_index=0
key_frame=0
pkt_pts=6956453470
pkt_pts_time=77293.927444
pkt_dts=6956453470
pkt_dts_time=77293.927444
best_effort_timestamp=6956453470
best_effort_timestamp_time=77293.927444
pkt_duration=3600
pkt_duration_time=0.040000
pkt_pos=4308584
pkt_size=35211
width=1920
height=1080
pix_fmt=yuv420p
sample_aspect_ratio=1:1
pict_type=B
coded_picture_number=86
display_picture_number=0
interlaced_frame=1
top_field_first=1
repeat_pict=0
color_range=tv
color_space=bt709
color_primaries=bt709
color_transfer=bt709
chroma_location=left
[/FRAME]

---------------------------

@rinoshs Why is it taking so long to comment on the issue? Your last comment was 3 months ago when you told us to create this ticket. This ticket has been open for 3 months with zero comments from Amazon developers. Not even a basic courtesy ”we are investigating”!

We know that a 3rd party is responsible for the decoder hardware. That 3rd party was able to fix 50% of the deinterlacing bug (half the crashing videos now work; but the other half still fail)… so I have faith that the remaining bug can be fixed via software too.

But the way you are being completely silent for 3 months makes me think the remaining bug is actually unfixable and you have been told to stay quiet…

What else are we supposed to think?! Speak to us! This is pathetic. We have been extremely patient, and provided tons of files to reproduce the bug, and you reward us with silence…

I am lucky that our family doesn’t watch sports, since most sports is broadcast interlaced and can trigger the crash… But we still see the bug pretty often on regular channels, such as when an Ad break plays a sudden interlaced ad… and crashes the hardware. It is the highest priority bug for anyone who bought a FireTV 4K. Wake up!

And if you are actually in contact with the 3rd party and working on a fix then tell us… we are waiting in the blind here for 3 freaking months… Just letting customers know if it’s being investigated would have avoided so much hate that Amazon is rightfully getting now…

These are samples who working for me.

1 2 3 4 5 6

color_range=unknown
color_space=unknown
color_primaries=unknown
color_transfer=unknown

So far this is what we got: all working samples have unknown color space (and color range), all FTVS4K breaking samples have BT.709 color space (and color range = tv).

color_range=tv
color_space=bt709
color_primaries=bt709
color_transfer=bt709

Has anyone checked on @humiboy ? Has he arranged a parade?

Update?

Jesus stop bumping the thread. Every time you do so, loads of people are getting email notifications of your childish, impatient remarks. Its annoying.

Thank you guys for the links and for your patience!

The latest firmware we received from the vendor had issue playing only one of the files listed above. We are discussing the leftover issue with them to get to a point that all files listed play to the end. There still will be garbled frames at the beginning of some files as not all of them start with a full I-frame and necessary headers. The current focus is on stability of the decoder.

Sorry for being vague, I am legally required to not state anything that is outside the direct influence of my team.

Hi @gb160 , If you’re unsure about the type of decoder used while playback, you can enable System X-ray. More details at: https://developer.amazon.com/docs/fire-tv/system-xray-developer-tools.html

We are looking into this issue. Thank you all for answering the question. 😃

No worries, hope we finally see a solution. Just to clarify, using VLC as the player, with hardware acceleration, these channels play fine, this one has been running for a couple of hours without so much as a glitch:

screen

@everyone

I still think that this is 100% fixable with a software update. Because the original firmware fix solved 100% of our submitted crashing video files/formats. But unfortunately, nobody had submitted any videos in this new/other format which still crashes the player. So hopefully (and most likely) it is fixable too. I really hope so, because I love everything about the FireTVStick4K except for this crash! 😉

This problem is frustrating as a user, since interlaced video (basically every sport channel, and sometimes during ad breaks on regular channels) go into the “bad” mode and crash the device, so I am as frustrated as anyone else (well, the sports fans would be the most frustrated people of all)… but since the first equally-severe crash was 100% fixed, I assume this will be fixed as soon as the hardware decoder vendor has analyzed our newly submitted files and fixed those video formats too.

The fascinating thing is that the video usually plays properly for 5-40 seconds before it crashes, which suggests possible memory corruption, buffer overflow/underflow or similar… and if so, then it’s probably an easy code fix…

@rinoshs

Just to clarify, this issue is being tracked internally within Amazon by the respective device team. There are no updates to share as of now.

On another note, this issue is strictly not with Amazon’s port of the ExoPlayer per se, and depends on fixes to a specific device’s firmware. This forum should primarily be used for ExoPlayer specific issues. Device issues such as this are better followed up with Amazon Customer Service, who will route it directly to the device teams.

Hi rinoshs! First of all, thanks a lot for acknowledging that the issue is listed on Amazon’s internal issue tracker list. That’s already a big relief. I was worried the issue was forgotten here on GitHub and completely missed/ignored. So thank you for letting us know!

I realize now that the “video decoder/driver team” is a separate team and isn’t related to this ExoPlayer player-port, and I am sorry for any abuse and anger (frustration) directed at you by me and others, since it isn’t your job to deal with the hardware decoder. You probably didn’t even feel like you were supposed to talk about it, since it’s not part of your team… So again, I apologize on behalf of myself and everyone else. When customers search for this problem, this GitHub repository comes up in various forums and websites, so even though it wasn’t the right contact point, this place still ended up being “the meeting point” for customer discussions about the deinterlacing bug…

Anyway, you brought us good news and I am very grateful for that… and since it’s on the internal TODO list, we can probably assume that the hardware decoder vendor has been contacted to get the ball rolling on a fix (since Amazon themselves cannot change the firmware or do anything about that ticket, and have to contact the vendor)…

But is it possible for you to check the status with that team? Customers don’t really have any direct line to that department, and the general customer support options are very unreliable (usually they know nothing and won’t collect the info from the inner teams either). I assume that you, as a ExoPlayer player-port developer can easily talk to the hardware decoder team and get some more insight into the internal issue, right? I know it’s not your job to ask that team, but if you can do it, it would be greatly appreciated by everyone.

We would just really love to know if the 3rd party hardware decoder vendor has been contacted, and hopefully begun working on a fix.

On another note, this issue is strictly not with Amazon’s port of the ExoPlayer per se, and depends on fixes to a specific device’s firmware. This forum should primarily be used for ExoPlayer specific issues.

Never heard this argument in the previous threads about FTVS4K de-interlacing issues, so coming up with it right now feels a bit awkward.

this issue is being tracked internally within Amazon by the respective device team. There are no updates to share as of now.

This sounds like corporate BS

Device issues such as this are better followed up with Amazon Customer Service, who will route it directly to the device teams.

Even more corporate BS

But hey, thanks for your effort and letting us know about the big nothing “the device team” has done over the last 3 months. BTW in the previous thread - the one that you closed - somehow someone managed to mention that the problem was on the vendor side, and BIOS update was necessary, and it fixed half of the problems with THIS hardware. Isn’t it weird, that after half solving an issue that was clearly an issue with the DEVICE, suddenly this forum isn’t the right place to deal with this. Especially in the light of this comment:

This issue is specific to the 4k pendant. Regarding 4k stick, I would suggest that you create a new issue for your specific issue.

We understand that, but you never get any feedback from the customer care team. At least keeping this issue open we can see others who are affected and any progress being made.

But thank you for the update all the same

On Fri, 13 Sep 2019, 12:44 rinoshs, notifications@github.com wrote:

Just to clarify, this issue is being tracked internally within Amazon by the respective device team. There are no updates to share as of now.

On another note, this issue is strictly not with Amazon’s port of the ExoPlayer per se, and depends on fixes to a specific device’s firmware. This forum should primarily be used for ExoPlayer specific issues. Device issues such as this are better followed up with Amazon Customer Service, who will route it directly to the device teams.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amzn/exoplayer-amazon-port/issues/94?email_source=notifications&email_token=ACP36G4MPLIBAUYAVXTUFNLQJN4KNA5CNFSM4H26KMS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6UY3VI#issuecomment-531205589, or mute the thread https://github.com/notifications/unsubscribe-auth/ACP36G7XX7OR4DTQVCMWHADQJN4KNANCNFSM4H26KMSQ .

But please, break that tradition this time. As soon as you receive the firmware fix, please do testing on the current public OS version and then release the fix for all of us! I can see that people are going to be very angry and it will cause a lot of ill-will towards Amazon if people have to wait 6 months yet again for the final fix… it will damage the reputation of the Amazon FireTV and it will be known as a device where fixes “take forever, if ever” to arrive…

This is the crux of it, another six month wait for a fix is unacceptable imo.

These are samples who working for me.

1 2 3 4 5 6

@leone007 I see. Some feedback from Amazon would still be appreciated though…seems odd that you guys are doing all the heavy lifting in here.

Update?

@gb160 As far as I know the Q2 updates are not getting to customer devices yet. As it is only 3rd of April, I think you are probably receiving the Q1 update belated - not all devices are updated at the same time, they are ramped up slowly by Fire OS version, device type, etc. to let us identify regressions or other problems. The Q2 update should be arriving in a few weeks. (I am ambiguous again on purpose here)

Thank you guys for the samples, they helped a lot!

Just to be clear Q2 is Apr-June ?

Yes, that is the currently planned release window. Sorry for lacking exact dates or details, that is again something I am not suppose to discuss.

Thank you for the samples!

@gb160 Your file seems to play fine till the 5:00 mark.

@Uukrull, 2 of you files still have issues, I have forwarded the details to the vendor.

Please note: any current changes by the vendor will take several months to get to the customers. Please be patient with related changes.

Hi @gb160 , If you’re unsure about the type of decoder used while playback, you can enable System X-ray. More details at: https://developer.amazon.com/docs/fire-tv/system-xray-developer-tools.html

We are looking into this issue. Thank you all for answering the question. 😃

Hi all, We are working on this issue. @gb160 , You mentioned in your comment (Link) that “almost all other players can handle this without crashing”. Could you please list some of those players? Are they using hardware/platform decoders or software decoders (custom decoder implementation)?

Hello aditya-gu

are you from Amazon Developer Team? Can you help to fix this high problem after 1 1/4 years?

Many iptv appz crashes with Hardware Decoder after a while.

No disrespect meant here, but please dont pester the guy with demands about shady IPTV apps. This issue is related to crashes whilst viewing completely legal free to air TV channels…something that a Fire TV stick should be able to.

@rinoshs @peddisri @aditya-gu :Could you please give us a feedback or close this ticket with a “WON’T FIX” statement?. Thank you.

Especially complaining that a product doesn’t work for a feature it wasn’t marketed for or even designed for.

Let me put it this way: the device cannot play 1080 interlaced content. If it’s a video file or live TV stream, it doesn’t matter.

And BTW it was marketed with 1080i HW support.

For a reason they did find it important to talk about MPEG2 1080i HW deinterlacing right? So was this device intended to play back 1080i content? Clearly, it was.

Not yet you won’t, theres no OSMC for Pi4 yet, but its coming soon apparently.

Didn’t knew that. But I guess there are alternatives like CoreELEC already…

but again, not an intended use case.

Again, streaming Live TV is a clear use case for any streaming device. Moreover, from the stick description: “…Stream live news, sports, and must-see shows…” Well…

It probably can’t be fixed which is why it hasn’t been, when the previous issue was in a couple of months.

I would be really surprised if this is a Hardware issue. Even more, since the soc on the 4k stick is just more recent and powerful than the ones on the previous editions… Of course, amazon cannot fix the issue themselves since it is probably a bug in the Amlogic driver. However, they could push for a fix…

Yes because it used a different chip to do the decoding. Embarrassing for Amazon yes, but again, not an intended use case.

It probably can’t be fixed which is why it hasn’t been, when the previous issue was in a couple of months.

On Wed, 4 Dec 2019, 16:14 gb160, notifications@github.com wrote:

Where does it say that it’s for live TV? It’s a Fire TV stick because it works on a TV and brings Amazon fire to your TV. … <#m_-7525967621375513815_>

Yet the non 4k stick works fine with live TV? You’re just embarrassing yourself now.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amzn/exoplayer-amazon-port/issues/94?email_source=notifications&email_token=ACP36G27UPCNJBMH6HEU3MLQW7JMXA5CNFSM4H26KMS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5RV6A#issuecomment-561715960, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACP36GZVMWSTZBXH25JKNHDQW7JMXANCNFSM4H26KMSQ .

It streams 4k and HD content from the advertised services just fine.

Isn’t it just live broadcasted interlaced hd TV that doesn’t work either DVB from something like a HDHomeRun and some IPTV services using a specific codec

On Wed, 4 Dec 2019, 16:05 Nuno Sá, notifications@github.com wrote:

the issue we are all facing is just a tiny subset of the intended use cases.

This is just something that should just work for a 4k streaming device… What’s the point of adverting it as “the most powerful 4k streaming device” if it just crashes with a lot of Live TV content which is a huge use case for people looking for this kind of devices…

Where does it say that it’s for live TV?

Where it says it’s a streaming device…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amzn/exoplayer-amazon-port/issues/94?email_source=notifications&email_token=ACP36G4U2ENEV24VSMOKSADQW7INVA5CNFSM4H26KMS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5Q2BI#issuecomment-561712389, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACP36GYIR72SSEKI3J3DVKDQW7INVANCNFSM4H26KMSQ .

@dopsy @gb160 Upon finding out that this page (hello, you are reading this page right now) is not controlled by the video-decoder team within Amazon, and that @rinoshs has absolutely nothing to do with the video-decoder team, and that we are writing our complaints on a completely unrelated webpage (wrong place)… your reaction is to… continue blaming someone who isn’t responsible for the issue, even though he’s not responsible for the issue, and is now a really good chance for us to forward some information from the actual internal team.

I would maybe agree that he could have been faster in forwarding information to/from the team, closing and locking this ticket if necessary. But then I looked at his activity:

https://github.com/amzn/exoplayer-amazon-port/commits?author=rinoshs

It’s clear that rino works for amazon but he isn’t a super active GitHub member, isn’t active on this page (exoplayer-amazon-port), and he isn’t on the relevant team. WE are on the wrong webpage. Stop blaming an innocent unrelated worker. And yes, rino suggested that we make this new ticket, but he probably thought some other team member would pick it up since he isn’t active on this site. Blame them if you want, but not him. That’s all I am saying. Have some respect.

Furthermore, I checked all other tickets on this page (open tickets and closed tickets), as well as the commit history (no activity since end of May 2019), and yeah… it turns out that we (who are on the wrong webpage, remember?) are posting on a very inactive, unrelated project, and blaming unrelated workers who are barely on this page…

This is the basically-inactive webpage for Amazon’s version of a video player called “ExoPlayer” (by Google). It has nothing to do with video decoding hardware at all and clearly isn’t monitored for activity very often… I am not even sure why customers decided to start making these hardware bug tickets here… (I just came here from Google and other forums… like all of you…)

Anyway, dopsy and gb160, since you have so much energy, which one of you is going to contact Amazon customer support and try to get a support agent to fetch the information from the internal team? I mean… you may as well put your energy and passion to good use by following rino’s suggestion for how we can get more information from the right team. Do either of you want to do that? If not, why not? Why should someone else (like rino) have to do it for you?

Personally I don’t care much anymore, after finding out that the appropriate team is working on the issue internally (thanks to rino popping back in). Sure I’d love to know more details about the status (mostly whether the hardware decoder 3rd party has begun programming the new firmware yet), but I also know that me knowing about their internal work won’t speed up a potential fix in any way. It’ll come when it’s ready either way…

If one of you contacts customer support, please share the information.

Why does he now tell us to contact Customer support after 8-10 months of this known issue?

You might feel the need to brown-nose an Amazon employee who has failed to address the problem, and failed to keep frustrated users up to date (regardless of whether he’s part of this much fabled ‘video decoder team’ (lol), but I don’t. If its not his problem then he should’ve informed the correct people, and more importantly, kept us informed…not sit on his ass for 8 months.

And also, why do you keep rating your own posts? It’s weird.

I won’t be contacting Amazon support, I just won’t ever buy one of their products again. You’re living in a dream world if you think this is getting fixed, wake up and stop being a cuck.

Really?? Who do you think you are here to apologize for everyone complaining here? We have nothing to apologize for. These are straight facts where amazon dont give a f*ck. If it’s not this teams issue, their job is to escalate to who is and get them here to explain what is happening and not hide.

He goes further than apologising…ass kissing and grovelling to a guy who tells us after all this time not to post here and to contact Amazon Customer support. You couldn’t make this nonsense up.

Im not apologising, I’m angry and extremely disappointed.

Really?? Who do you think you are here to apologize for everyone complaining here? We have nothing to apologize for. These are straight facts where amazon dont give a f*ck. If it’s not this teams issue, their job is to escalate to who is and get them here to explain what is happening and not hide.

haha brilliant.

Not a happy chappy as the wife is not amused! Completely broken and needing an urgent fix …

Yeah good luck with that.

TBH the only people with issues seem to be using the channels app, maybe thats where the problem is considering its fixed for everyone else?

Yes, build version 6.2.7.3 is the first one that has the fix. It will take a few weeks till all devices receive the update - the slow ramp-up is required to identify regressions (independently of this issue, but in the whole system update) before updating all devices. Thank you for your patience.

Can anyone confirm 1080i content (ideally from Freeview/freesat) is working now?

My fire tv stick has gone to 5.2.7.3 and ive now got hd satellite streams playing that previously crashed the player.


From: gb160 notifications@github.com Sent: Tuesday, August 18, 2020 10:45:30 AM To: amzn/exoplayer-amazon-port exoplayer-amazon-port@noreply.github.com Cc: Steve Whitaker stephen@rndthoughts.co.uk; Manual manual@noreply.github.com Subject: Re: [amzn/exoplayer-amazon-port] FTV Stick 4K interlaced video playback leads to media player crash (#94)

@Virgil1987https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FVirgil1987&data=02|01||4bdd120414ec4c356a6f08d8435b7275|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637333407319679688&sdata=CwgBBFgR%2FU%2Bru4gkboig1L57h8IkioBib0ZnjkO0ifg%3D&reserved=0 what region are u in buddy?

Uk mate, i received it yesterday.

Im in UK also, still on 6.2.7.1 here…hopefully wont be long.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Famzn%2Fexoplayer-amazon-port%2Fissues%2F94%23issuecomment-675378432&data=02|01||4bdd120414ec4c356a6f08d8435b7275|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637333407319689683&sdata=gHU5LqFbJb0Ey5lveAoReUZEgA0gEqB80J0xyBACgyM%3D&reserved=0, or unsubscribehttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAA77EZZY77EE7P3QZ4RQ3PDSBJETVANCNFSM4H26KMSQ&data=02|01||4bdd120414ec4c356a6f08d8435b7275|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637333407319699676&sdata=lMzcph9gfTFu7y%2Bc86e5shzDKTScbsHGFxBEJ4X8G5E%3D&reserved=0.

@farbenh Thank you, all 6 videos seem to play fine on the proposed firmware.

I would currently expect the fixes getting into the Q2 update of the AFTMM platforms.

Thank you for the samples!

@gb160 Your file seems to play fine till the 5:00 mark.

Thats fine buddy, it’s only a five minute sample, as long as you got to 5 minutes then its looking good! It crashes the player on my firestick at around 4:10 every single time. I’ll upload one more for you to test in a short while.

Im sure I speak for a lot of people when I say how relieving it is to see some progress on this after such a long time!

Four samples from four different channels: https://drive.google.com/open?id=1p2VvtG1QtWSAkJYYcR5b_PNn1G-y5ip1

I’ll try to upload more tomorrow.

Hi all, We are working on this issue.

@gb160 , You mentioned in your comment (Link) that “almost all other players can handle this without crashing”. Could you please list some of those players? Are they using hardware/platform decoders or software decoders (custom decoder implementation)?

Hi, Im using the Dream Player TV app, as a client for a TV Headend server (playing DVB-T free to air channels in the UK) In Dream Player TV I have the player set to VLC, and hardware acceleration is set to ‘full’, so I presume this is using hardware decoder, and playback is perfect, with deinterlacing working perfectly as well.

This issue with exoplayer imo is definitely related to the ‘Timestamps are unset in a packet for stream 0’ which gets logged from TV headend, as the exoplayer crash will come a second or 2 later, every single time. As I mentioned in the post you linked to, other players seem to shrug this off and continue playing fine, exoplayer doesn’t and locks up.

Fantastic work, this would explain how app developers such as Channels like I said previously have found a way around the issue!

the issue we are all facing is just a tiny subset of the intended use cases.

This is just something that should just work for a 4k streaming device… What’s the point of adverting it as “the most powerful 4k streaming device” if it just crashes with a lot of Live TV content which is a huge use case for people looking for this kind of devices…

Where does it say that it’s for live TV?

Where it says it’s a streaming device…

Where does it say that it’s for live TV? It’s a Fire TV stick because it works on a TV and brings Amazon fire to your TV.

Don’t get me wrong, I’d much rather they’d fix it as I’m in the same boat as the rest of you, but this isn’t the place to keep complaining. Especially complaining that a product doesn’t work for a feature it wasn’t marketed for or even designed for.

Out of curiosity, what’s wrong with the 4k cube? I picked one up on the black Friday deals and I’m quite happy with it, and have moved the stick to the bedroom tv

On Wed, 4 Dec 2019, 15:52 gb160, notifications@github.com wrote:

I think you’re all missing the point here, Amazon produces these sticks and sells them at next to zero profit as a platform for connecting you to their video services and delivering adverts, which it does flawlessly. The issue we are all facing is just a tiny subset of the intended use cases. Yes it’s annoying but that’s how it is. Unless it’s specifically marketed that it does what we now know it doesn’t, you can’t really complain. If you don’t like it, there are plenty of work around, or send it back and get a HD stick or the 4k cube which don’t have this problem

Right, so its a Fire TV stick, that cant play live TV. We obviously expected too much guys.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amzn/exoplayer-amazon-port/issues/94?email_source=notifications&email_token=ACP36GZLMK2B4POYM6SCXK3QW7G35A5CNFSM4H26KMS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5PKTI#issuecomment-561706317, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACP36G3WWANG4Q25A4EDKLLQW7G35ANCNFSM4H26KMSQ .

I think you’re all missing the point here, Amazon produces these sticks and sells them at next to zero profit as a platform for connecting you to their video services and delivering adverts, which it does flawlessly. The issue we are all facing is just a tiny subset of the intended use cases. Yes it’s annoying but that’s how it is. Unless it’s specifically marketed that it does what we now know it doesn’t, you can’t really complain. If you don’t like it, there are plenty of work around, or send it back and get a HD stick or the 4k cube which don’t have this problem

Right, so its a Fire TV stick, that cant play live TV. We obviously expected too much guys.

I think you’re all missing the point here, Amazon produces these sticks and sells them at next to zero profit as a platform for connecting you to their video services and delivering adverts, which it does flawlessly. The issue we are all facing is just a tiny subset of the intended use cases. Yes it’s annoying but that’s how it is. Unless it’s specifically marketed that it does what we now know it doesn’t, you can’t really complain. If you don’t like it, there are plenty of work around, or send it back and get a HD stick or the 4k cube which don’t have this problem

I just got my stick yesterday and I’m also experiencing this on some IPTV streams. Honestly, I think this bug is a embarrassing for a company like amazon… Fortunately, I can use smart IPTV directly on my smart tv. For movies and tv shows I need to further experiment to see if I get this issue to often. And since, the stick is to be used in my bedroom tv (which I use like 10% of the time in comparison with my living room) I won’t be returning the stick for now… However If I had read this thread before I would not be buying it for sure (even with the 50% off I got on black friday…).

Nevertheless, @rinoshs is there any hope for a proper fix here? Is amazon and amlogic doing something on this?

Just to clarify, this issue is being tracked internally within Amazon by the respective device team. There are no updates to share as of now.

On another note, this issue is strictly not with Amazon’s port of the ExoPlayer per se, and depends on fixes to a specific device’s firmware. This forum should primarily be used for ExoPlayer specific issues. Device issues such as this are better followed up with Amazon Customer Service, who will route it directly to the device teams.

I can’t imagine I am the only 1 who feel’s like this but if this issue is not going to be fixed I would really appreciate Amazon being honest. As it starts I feel like there is some sort of false hope that the 4K stick will 1 day do everything I want it too. If that’s not the case I would just prefer to know now and find an alternative solution going forward. Keeping people in the dark is less likely to hold onto future sales than being honest about a failure!

But the way you are being completely silent for 3 months makes me think the remaining bug is actually unfixable and you have been told to stay quiet…

Bingo.

I get that we are a tiny fraction of the userbase of what is an extremely popular device, what I don’t get is why they dont just put their hands up, and issue a few hundred refunds…they’re the biggest and most valuable tech company in the world. Maybe Jeff’s divorce settlement is having a bearing on this.

Okay I have received the 1996 update too. As others have mentioned, the crash is the same. The only difference is that after a crash (which will freeze and then close your media player), you can open the media player again. And trying to play something will lead to a black screen with audio and then a green flash and finally the image reappears.

So, 1996 adds ”live re-initialization/reset” of crashed hardware decoder. A good change. We no longer have to manually reboot the whole system!

I hope the cause of the crashes will be found. It’s interesting that leone sees the same colorspace in all crashing files and others in non-crashing files.

@y2000j: Well it’s only been 3 days. And amazon @rinoshs acknowledged the situation in the previous thread and asked us to make a new ticket. So we need to be respectful and patient. Although I do hope that Amazon pressures the hardware chip maker for a faster fix this time. 😕

also here is some mediainfo w/ advanced debug

working samples:

Video
Count                                    : 377
Count of stream of this kind             : 1
Kind of stream                           : Video
Kind of stream                           : Video
Stream identifier                        : 0
StreamOrder                              : 0-0
Inform                                   : 9 802 kb/s, 1920*1080 (16:9), at 25.000 FPS, AVC (High@L4) (CABAC / 4 Ref Frames)
ID                                       : 200
ID                                       : 200 (0xC8)
Menu ID                                  : 314
Menu ID                                  : 314 (0x13A)
Format                                   : AVC
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format/Url                               : http://developers.videolan.org/x264.html
Commercial name                          : AVC
Format profile                           : High@L4
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 4
Format settings, Reference frames        : 4 frames
Internet media type                      : video/H264
Codec ID                                 : 27
Duration                                 : 178960
Duration                                 : 2 min 58 s
Duration                                 : 2 min 58 s 960 ms
Duration                                 : 2 min 58 s
Duration                                 : 00:02:58.960
Duration                                 : 00:02:58:24
Duration                                 : 00:02:58.960 (00:02:58:24)
Bit rate                                 : 9802184
Bit rate                                 : 9 802 kb/s
Width                                    : 1920
Width                                    : 1 920 pixels
Height                                   : 1080
Height                                   : 1 080 pixels
Stored_Height                            : 1088
Sampled_Width                            : 1920
Sampled_Height                           : 1080
Pixel aspect ratio                       : 1.000
Display aspect ratio                     : 1.778
Display aspect ratio                     : 16:9
Frame rate                               : 25.000
Frame rate                               : 25.000 FPS
Frame count                              : 4474
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Chroma subsampling                       : 4:2:0
Bit depth                                : 8
Bit depth                                : 8 bits
Scan type                                : MBAFF
Scan type                                : MBAFF
Scan type, store method                  : InterleavedFields
Scan type, store method                  : Interleaved fields
Scan order                               : TFF
Scan order                               : Top Field First
Bits/(Pixel*Frame)                       : 0.189
Delay                                    : 49433632.000
Delay                                    : 13 h 43 min
Delay                                    : 13 h 43 min 53 s 632 ms
Delay                                    : 13 h 43 min
Delay                                    : 13:43:53.632
Delay, origin                            : Container
Delay, origin                            : Container
Stream size                              : 219274856
Stream size                              : 209 MiB (86%)
Stream size                              : 209 MiB
Stream size                              : 209 MiB
Stream size                              : 209 MiB
Stream size                              : 209.1 MiB
Stream size                              : 209 MiB (86%)
Proportion of this stream                : 0.86007

and

Video
Count                                    : 377
Count of stream of this kind             : 1
Kind of stream                           : Video
Kind of stream                           : Video
Stream identifier                        : 0
StreamOrder                              : 0-0
Inform                                   : 9 931 kb/s, 1920*1080 (16:9), at 25.000 FPS, AVC (High@L4) (CABAC / 4 Ref Frames)
ID                                       : 1001
ID                                       : 1001 (0x3E9)
Menu ID                                  : 310
Menu ID                                  : 310 (0x136)
Format                                   : AVC
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format/Url                               : http://developers.videolan.org/x264.html
Commercial name                          : AVC
Format profile                           : High@L4
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 4
Format settings, Reference frames        : 4 frames
Internet media type                      : video/H264
Codec ID                                 : 27
Duration                                 : 179120
Duration                                 : 2 min 59 s
Duration                                 : 2 min 59 s 120 ms
Duration                                 : 2 min 59 s
Duration                                 : 00:02:59.120
Duration                                 : 00:02:59:03
Duration                                 : 00:02:59.120 (00:02:59:03)
Bit rate                                 : 9930950
Bit rate                                 : 9 931 kb/s
Width                                    : 1920
Width                                    : 1 920 pixels
Height                                   : 1080
Height                                   : 1 080 pixels
Stored_Height                            : 1088
Sampled_Width                            : 1920
Sampled_Height                           : 1080
Pixel aspect ratio                       : 1.000
Display aspect ratio                     : 1.778
Display aspect ratio                     : 16:9
Frame rate                               : 25.000
Frame rate                               : 25.000 FPS
Frame count                              : 4478
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Chroma subsampling                       : 4:2:0
Bit depth                                : 8
Bit depth                                : 8 bits
Scan type                                : MBAFF
Scan type                                : MBAFF
Scan type, store method                  : InterleavedFields
Scan type, store method                  : Interleaved fields
Scan order                               : TFF
Scan order                               : Top Field First
Bits/(Pixel*Frame)                       : 0.192
Delay                                    : 49643848.000
Delay                                    : 13 h 47 min
Delay                                    : 13 h 47 min 23 s 848 ms
Delay                                    : 13 h 47 min
Delay                                    : 13:47:23.848
Delay, origin                            : Container
Delay, origin                            : Container
Stream size                              : 222353970
Stream size                              : 212 MiB (86%)
Stream size                              : 212 MiB
Stream size                              : 212 MiB
Stream size                              : 212 MiB
Stream size                              : 212.1 MiB
Stream size                              : 212 MiB (86%)
Proportion of this stream                : 0.86441

these are the bad ones

Video
Count                                    : 377
Count of stream of this kind             : 1
Kind of stream                           : Video
Kind of stream                           : Video
Stream identifier                        : 0
StreamOrder                              : 0-0
Inform                                   : 8 856 kb/s, 1920*1080 (16:9), at 25.000 FPS, AVC (Component) (High@L4) (CABAC / 4 Ref Frames)
ID                                       : 4000
ID                                       : 4000 (0xFA0)
Menu ID                                  : 211
Menu ID                                  : 211 (0xD3)
Format                                   : AVC
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format/Url                               : http://developers.videolan.org/x264.html
Commercial name                          : AVC
Format profile                           : High@L4
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 4
Format settings, Reference frames        : 4 frames
Format settings, GOP                     : M=8, N=24
Internet media type                      : video/H264
Codec ID                                 : 27
Duration                                 : 179560
Duration                                 : 2 min 59 s
Duration                                 : 2 min 59 s 560 ms
Duration                                 : 2 min 59 s
Duration                                 : 00:02:59.560
Duration                                 : 00:02:59:14
Duration                                 : 00:02:59.560 (00:02:59:14)
Bit rate                                 : 8855893
Bit rate                                 : 8 856 kb/s
Width                                    : 1920
Width                                    : 1 920 pixels
Height                                   : 1080
Height                                   : 1 080 pixels
Stored_Height                            : 1088
Sampled_Width                            : 1920
Sampled_Height                           : 1080
Pixel aspect ratio                       : 1.000
Display aspect ratio                     : 1.778
Display aspect ratio                     : 16:9
Frame rate                               : 25.000
Frame rate                               : 25.000 FPS
Frame count                              : 4489
Standard                                 : Component
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Chroma subsampling                       : 4:2:0
Bit depth                                : 8
Bit depth                                : 8 bits
**Scan type                                : MBAFF
Scan type                                : MBAFF
Scan type, store method                  : InterleavedFields
Scan type, store method                  : Interleaved fields
Scan order                               : TFF
Scan order                               : Top Field First**
Bits/(Pixel*Frame)                       : 0.171
Delay                                    : 77290888.000
Delay                                    : 21 h 28 min
Delay                                    : 21 h 28 min 10 s 888 ms
Delay                                    : 21 h 28 min
Delay                                    : 21:28:10.888
Delay, origin                            : Container
Delay, origin                            : Container
Stream size                              : 198770518
Stream size                              : 190 MiB (91%)
Stream size                              : 190 MiB
Stream size                              : 190 MiB
Stream size                              : 190 MiB
Stream size                              : 189.6 MiB
Stream size                              : 190 MiB (91%)
Proportion of this stream                : 0.90839
colour_description_present               : Yes
colour_description_present_Source        : Stream
Color range                              : Limited
colour_range_Source                      : Stream
Color primaries                          : BT.709
colour_primaries_Source                  : Stream
Transfer characteristics                 : BT.709
transfer_characteristics_Source          : Stream
Matrix coefficients                      : BT.709
matrix_coefficients_Source               : Stream

and

Video
Count                                    : 377
Count of stream of this kind             : 1
Kind of stream                           : Video
Kind of stream                           : Video
Stream identifier                        : 0
StreamOrder                              : 0-1
Inform                                   : 7 868 kb/s, 1920*1080 (16:9), at 25.000 FPS, AVC (Component) (High@L4) (CABAC / 4 Ref Frames)
ID                                       : 3000
ID                                       : 3000 (0xBB8)
Menu ID                                  : 206
Menu ID                                  : 206 (0xCE)
Format                                   : AVC
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format/Url                               : http://developers.videolan.org/x264.html
Commercial name                          : AVC
Format profile                           : High@L4
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 4
Format settings, Reference frames        : 4 frames
Internet media type                      : video/H264
Codec ID                                 : 27
Duration                                 : 178840
Duration                                 : 2 min 58 s
Duration                                 : 2 min 58 s 840 ms
Duration                                 : 2 min 58 s
Duration                                 : 00:02:58.840
Duration                                 : 00:02:58:21
Duration                                 : 00:02:58.840 (00:02:58:21)
Bit rate                                 : 7868158
Bit rate                                 : 7 868 kb/s
Width                                    : 1920
Width                                    : 1 920 pixels
Height                                   : 1080
Height                                   : 1 080 pixels
Stored_Height                            : 1088
Sampled_Width                            : 1920
Sampled_Height                           : 1080
Pixel aspect ratio                       : 1.000
Display aspect ratio                     : 1.778
Display aspect ratio                     : 16:9
Frame rate                               : 25.000
Frame rate                               : 25.000 FPS
Frame count                              : 4471
Standard                                 : Component
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Chroma subsampling                       : 4:2:0
Bit depth                                : 8
Bit depth                                : 8 bits
Scan type                                : Interlaced
Scan type                                : Interlaced
Scan type, store method                  : SeparatedFields
Scan type, store method                  : Separated fields
Scan order                               : TFF
Scan order                               : Top Field First
Bits/(Pixel*Frame)                       : 0.152
Delay                                    : 3908264.000
Delay                                    : 1 h 5 min
Delay                                    : 1 h 5 min 8 s 264 ms
Delay                                    : 1 h 5 min
Delay                                    : 01:05:08.264
Delay, origin                            : Container
Delay, origin                            : Container
Stream size                              : 175892667
Stream size                              : 168 MiB (90%)
Stream size                              : 168 MiB
Stream size                              : 168 MiB
Stream size                              : 168 MiB
Stream size                              : 167.7 MiB
Stream size                              : 168 MiB (90%)
Proportion of this stream                : 0.90008
colour_description_present               : Yes
colour_description_present_Source        : Stream
Color range                              : Limited
colour_range_Source                      : Stream
Color primaries                          : BT.709
colour_primaries_Source                  : Stream
Transfer characteristics                 : BT.709
transfer_characteristics_Source          : Stream
Matrix coefficients                      : BT.709
matrix_coefficients_Source               : Stream

It appears that the good ones have unknown color space (and won’t even show up in Mediainfo)

color_range=unknown
color_space=unknown
color_primaries=unknown
color_transfer=unknown

Whereas the bad ones have BT.709

color_range=tv
color_space=bt709
color_primaries=bt709
color_transfer=bt709

Dunno if it makes a difference though. 😦

EDIT: @y2000j’s (bad) sample’s frame analysis also contains this:

color_range=tv
color_space=bt709
color_primaries=bt709
color_transfer=bt709

So does the 2 bad samples provided by me (Eurosport and Eurosport 2)

I think we need more WORKING samples to see what is going on with BT.709 color space and interlaced video.

Like this one, with unknown color space. I’ve yet to see a sample with BT.709 color space that is actually working.

Another bad one with BT.709.

We need someone with tvheadend 4.3+ (I’m on 4.2.8) to see if a native BT.709 stream works transcoded to different color space (I believe color space option exist in 4.3+ versions w/ transcoding, but correct me if I’m wrong)

OR since I’m not an ffmpeg magician could someone, like @VideoPlayerCode 😃 transcode our BT.709 samples to a different color space, and upload them for testing?

UPDATE: So all I have found is how to make a video BT.709 color space, but so far handbrake only produced progressive videos, so that isn’t good for testing.

-vf scale=out_color_matrix=bt709 -color_primaries bt709 -color_trc bt709 -colorspace bt709

This ffmpeg parameter needed to add as extra options during encoding, all I have to figure out is to leave the interlaced format untouched.

@leone007 Thanks, since they work, that seems to confirm that we can safely ignore the SPS and non-existing PPS 0 referenced errors.

I have updated my post to add info about another error I discovered: Two of our four test original test files contained illegal data. They were marked as H264 Level 4.1, which only allows up to 4 reference frames at 1080p. But they instead contained 5 frames. That breaks the spec. I still think the hardware is powerful enough that it should be able to decode that violation. The spec is just meant to guide hardware decoder makers to how much data they should expect to need to decode at once. But since this hardware is capable of 4K decoding, I doubt that an extra H264 reference frame will be too much for its memory to handle. 😉 And, only 2 of the 4 bad files had that violation so it’s probably not related. Still, I updated my post with those details…

@rinoshs I am very interested in knowing what these all of these test files do to your internal testing units. 😃

I suspect whatever workaround they were using to do hardware decoding with the old firmware has been modified and nolonger works. Needs an update to the channels app rather than a problem with ftvos

On Thu, 17 Sep 2020, 15:02 gb160, notifications@github.com wrote:

Not a happy chappy as the wife is not amused! Completely broken and needing an urgent fix …

Yeah good luck with that.

TBH the only people with issues seem to be using the channels app, maybe thats where the problem is considering its fixed for everyone else?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amzn/exoplayer-amazon-port/issues/94#issuecomment-694257042, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACP36G3UNCB2M3HA5ONATX3SGIJHNANCNFSM4H26KMSQ .

Since I had no issue since this update, I’ll close this issue within a week. It was fun with you guys, thanks to @zsmatyas and this community for solving this pain-in-the-back deinterlacing problem.

I have received Fire OS 6.2.7.3 in Germany too and can confirm no more crashing. IPTV Appz works very good too without crash.

Thx for this Update

So I can confirm my 4K firestick got the “intermediate” update that continued to display version 6.2.7.1 then the following day it’s upgraded to 6.2.7.3.

I can confirm the issue is resolved, I can now watch 1080i Freeview / DVB-T2 channels from my TVHeadend setup without crashing.

Yeah mine did this, it said ‘downloading 6.2.7.3’…but it seemed to download suspiciously quickly, when it rebooted it still said 6.2.7.1…I clicked ‘check for updates’ again and again it downloaded 6.2.7.3, but this time much slower…upon reboot this time it confirmed I was on 6.2.7.3.

@Virgil1987 what region are u in buddy?

Uk mate, i received it yesterday.

Im in UK also, still on 6.2.7.1 here…hopefully wont be long. What source are your streams coming from mate?

Hls 1080p 60fps original quality from lithuania, always had a problem with those streams, tryed everything, different kind of players and etc, nothing helped always use to be crashes, now works. Watching those channels around 2 hours everything is fine

Got 2 firesticks 4k both updated yesterday

@Virgil1987 what region are u in buddy?

Uk mate, i received it yesterday.

Im in UK also, still on 6.2.7.1 here…hopefully wont be long. What source are your streams coming from mate?

Hls 1080p 60fps original quality from lithuania, always had a problem with those streams, tryed everything, different kind of players and etc, nothing helped always use to be crashes, now works. Watching those channels around 2 hours everything is fine

I found this page lists the latest software version for each Amazon device: https://www.amazon.com/gp/help/customer/display.html?nodeId=201497590

You would be correct.

It’s only a couple of days late, and there is a global pandemic on, just be patient!

On Fri, 3 Jul 2020, 10:21 gb160, notifications@github.com wrote:

You mean you haven’t got it yet? Have you @geekypenguin https://github.com/geekypenguin ?

I think he’s joking around.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amzn/exoplayer-amazon-port/issues/94#issuecomment-653446305, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACP36G7F6BX76Q6RQLGFU5LRZWPIZANCNFSM4H26KMSQ .

You mean you haven’t got it yet? Have you @geekypenguin ?

I think he’s joking around.

That and it’s not uncommon for “Qn” updates to be released a week or two beyond the end of that quarter

On Mon, 15 Jun 2020, 16:51 gb160, notifications@github.com wrote:

15 days still in this Q2 to release new software update

You do appreciate it is very likely to be delayed, because of that worldwide pandemic thing going on?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amzn/exoplayer-amazon-port/issues/94#issuecomment-644217587, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACP36G6ZI7ZCUM5YINSSEQ3RWY7PRANCNFSM4H26KMSQ .

@gb160 As far as I know the Q2 updates are not getting to customer devices yet. As it is only 3rd of April, I think you are probably receiving the Q1 update belated - not all devices are updated at the same time, they are ramped up slowly by Fire OS version, device type, etc. to let us identify regressions or other problems. The Q2 update should be arriving in a few weeks. (I am ambiguous again on purpose here)

@zsmatyas could you maybe tell us the firmware version of the new update? So we could identify when it was already installed on our devices?

I know but the problem is, when update is available and we test it and still problems exist we must wait again 1 year more.

Well it’s not a problem until it happens. Wait till then before you start moaning.

Hi all, I see that this issue is quite advanted. I experienced also problems with this class of video format from Spain TV by Movistar I would like to help providing you all the videos you need as examples. I could get in SD, HD and UHD under extension TS mpeg2 h264. I would like to send by private message the links because videos could have copyright Regards

Hi macamba. I am having also problems with movistar. Do you have pixel salad? What happens to me is that randomly i get the image with tons of pixels, and if I go back and play again all go fine again for some time.

This thread is about problems with Fire Stick 4k for determinate format video not for issue conectivity with Movistar TV

@macamba Could you send me links Thank you!

Thank you guys for the links and for your patience!

The latest firmware we received from the vendor had issue playing only one of the files listed above. We are discussing the leftover issue with them to get to a point that all files listed play to the end. There still will be garbled frames at the beginning of some files as not all of them start with a full I-frame and necessary headers. The current focus is on stability of the decoder.

Sorry for being vague, I am legally required to not state anything that is outside the direct influence of my team.

This is very promising news, thanks for the feedback.

@aditya-gu When I was investigating this issue last year, I discovered that OMX.MTK.VIDEO.DECODER.AVC can stall unless h264 NALUs for slices have zero padding at the end.

This means nothing to myself but I can confirm the changes he made has resulted in hardware decoding working faultless for about 4 months without a single freeze on UK TV using hardware decoding. This is based on 7 x Fire TV 4K sticks. All HD and SD channels across the board hardware decode perfectly now using the channels app

What changes? and by who? There haven’t been any changes.

Tmm1 is a developer / owner of the channels app. Whatever charges he made to that app have allowed it to work faultless for months. It just hardware decodes beautifully. Previous to that I had top use software decoding and it was an awful viewing experience

Yeah thats fair enough, your post could’ve been interpreted as meaning the underlying issue had been resolved, when It hasn’t…just wanted to clarify that. Quite a few apps/players seem to have found a way around this issue.

Sorry didn’t mean to cause confusion I thought quoting tmm1’s reply implied I was speaking about his changes to the channels app

Dont apologise mate, in hindsight I was being a bit thick…its been a long day.

@aditya-gu When I was investigating this issue last year, I discovered that OMX.MTK.VIDEO.DECODER.AVC can stall unless h264 NALUs for slices have zero padding at the end.

This means nothing to myself but I can confirm the changes he made has resulted in hardware decoding working faultless for about 4 months without a single freeze on UK TV using hardware decoding. This is based on 7 x Fire TV 4K sticks. All HD and SD channels across the board hardware decode perfectly now using the channels app

What changes? and by who? There haven’t been any changes.

Tmm1 is a developer / owner of the channels app. Whatever charges he made to that app have allowed it to work faultless for months. It just hardware decodes beautifully. Previous to that I had top use software decoding and it was an awful viewing experience

@aditya-gu When I was investigating this issue last year, I discovered that OMX.MTK.VIDEO.DECODER.AVC can stall unless h264 NALUs for slices have zero padding at the end.

This means nothing to myself but I can confirm the changes he made has resulted in hardware decoding working faultless for about 4 months without a single freeze on UK TV using hardware decoding. This is based on 7 x Fire TV 4K sticks. All HD and SD channels across the board hardware decode perfectly now using the channels app

Vlc with software decoding works perfectly. Mx player with Hardware decoding refuses to play the problematic streams so it does not crash. Most other players crashes when using hardware decoder on the problematic streams.

Hi all, We are working on this issue.

@gb160 , You mentioned in your comment (Link) that “almost all other players can handle this without crashing”. Could you please list some of those players? Are they using hardware/platform decoders or software decoders (custom decoder implementation)?

Hello aditya-gu

are you from Amazon Developer Team? Can you help to fix this high problem after 1 1/4 years?

Many iptv appz crashes with Hardware Decoder after a while.

I am so dissapointed with Amazon.

What could have been the perfect budget streaming devise is only trash without this being fixed…

Can someone auggest another device that can work with usb power from tv, 4k netflix support, 4k stream support, dolby surround sound, just as small so it is easy to take it with you. Was looking at Nvidia shield "tube’ but it needs power from mains and does not have any usb port so; impossible to connect anything to it. Atleast with firestick 4k you can connect with special cable.

I am so dissapointed, shame on you Amazon.

After more than one month still no news?

Now you mention it, my ffmpeg log is full of missing timestamp errors from transcoding HD TV…

Thats how they’re broadcast in the UK buddy…and the root of this issue.

@gb160 Great job man! And it is an exoplayer issue after all, so I believe we actually are in the right thread, right @rinoshs ?

Test it out for yourself buddy, it’s easy to reproduce…not sure what country you’re in but I guarantee you’ll see that error seconds before the player crashes.

I think originally there was a hardware issue, remember one of the ‘fixes’ made it so that it didn’t crash the whole stick anymore, that was the hardware issue being solved…what’s left now is this problem with exoplayer not being able to handle occasional missing timestamps from packets, whilst every other player can shrug them off.

@gb160 Great job man! And it is an exoplayer issue after all, so I believe we actually are in the right thread, right @rinoshs ?

And don’t get me wrong. I also just workarounded the issue and since I just got the stick for half the price, I will, most likely, keep it. But if I had paid the full price, no way I would stick with a streaming device with this failure. For the same price, I would just get a rpi4 running OSMC that just works (of course I would not have any Amazon content but I’m also not using it)…

But that’s just me…

I don’t think you’ll struggle too much with movies/tv series…the bug only affects interlaced content, and hardly any movies/series use that…it’s mainly live tv broadcasts.

In this case I think I’m good with it. I agree it’s a basic/ugly/frustrating bug but, as I said, the stick is to be used at my bedroom tv where I don’t spend that much time. Since I can use my TV itself to watch my IPTV streams, I will be using the stick mainly to access my media center for tv shows/movies. And for the price I paid for it (black friday discount), Im ok with this setup (even though I agree a device like this should just work).

I just got my stick yesterday and I’m also experiencing this on some IPTV streams. Honestly, I think this bug is a embarrassing for a company like amazon… Fortunately, I can use smart IPTV directly on my smart tv. For movies and tv shows I need to further experiment to see if I get this issue to often. And since, the stick is to be used in my bedroom tv (which I use like 10% of the time in comparison with my living room) I won’t be returning the stick for now… However If I had read this thread before I would not be buying it for sure (even with the 50% off I got on black friday…).

Nevertheless, @rinoshs is there any hope for a proper fix here? Is amazon and amlogic doing something on this?

Id send it back if I was you, it might cost you a few quid/bucks/euros more but you can get something that’s fit for purpose.

I don’t think you’ll struggle too much with movies/tv series…the bug only affects interlaced content, and hardly any movies/series use that…it’s mainly live tv broadcasts.

I think @gb160 is right. I send two Fire TV Stick 4k back to Amazon with the error description and link to this thread some weeks ago. Nothing happens 😭 I switched to another Android TV box which works perfectly. Good bye amazon!

For what is worth, my testings show that working channels have this mediainfo:

Video ID : 163 (0xA3) Menu ID : 1 (0x1) Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference fra : 4 frames Format settings, GOP : M=4, N=24 Codec ID : 27 Duration : 1 min 0 s Bit rate : 7 802 kb/s Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan type, store method : Separated fields Scan order : Top Field First Bits/(Pixel*Frame) : 0.151 Stream size : 56.1 MiB (87%) Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709

and those that don’t this:

Video ID : 161 (0xA1) Menu ID : 1 (0x1) Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference fra : 4 frames Codec ID : 27 Duration : 1 min 2 s Bit rate : 6 272 kb/s Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : MBAFF Scan type, store method : Separated fields Scan order : Top Field First Bits/(Pixel*Frame) : 0.121 Stream size : 46.4 MiB (89%) Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709

being the only difference

[Working] Format settings, GOP : M=4, N=24 Scan type : Interlaced

vs

[Not working] Scan type : MBAFF

I can supply samples if needed.

Recieved an software update to my firestick 4k today.

Fire OS 6.2.6.6 (NS6266/2292)

Fire Home Version 6.1.8.0-810

Unfortunally some streams still crashes the Fire stick 4k. No improvement at all 😦

Although not a fix I can confirm the New Cube does NOT have this issue and plays interlaced h264 perfectly

@dougie175 For sure. High framerate or high resolution videos will stutter more in software decoding. There’s also an issue with washed-out color quality when software decoding is used (at least in MX Player). The hardware produces deeper contrast. So the software decoding is just a temporary workaround, and a hardware firmware fix is definitely needed.

I can’t honestly sat I have noticed the washed out issue, but then I never have any of my Sticks set to Hardware due to the issue so have to always watch with software decoding, in the few times I have tried hardware I don’t think it has been a huge difference in colour depth with Channels though that may just be an MX Player thing.

Like everyone I cannot express just how desperate I am for this to be fixed, the 4K Stick is very close to the ideal device for my situation but this issue is critical

The issue is being followed up internally, and is being worked on by the respective device team. As updates become available I will share them.

Hi! Thanks a lot for helping out now and offering to notify us about the other team’s progress. The thing I am most curious about is whether the hardware chip vendor has begun working on a fix (or at least been notified), since Amazon can’t do anything about it without their help.

I’m not going to ask for a timeframe guess, but if one is known, that would be appreciated too. Last time, it took the third party 3-4 months to code and test a fix, and Amazon 1-2 months to test and deploy that fix. So I know that I can reasonably expect to wait several months either way.

For the record, we had earlier tracked a fix for this issue that did go out in Q2. However it did not fix all use cases.

That’s the thing we’ve been saying to people: The earlier bugfix did fix 100% of the submitted test-files. Sadly, a new video format was discovered (this ticket) which still crashes. If we had been lucky enough to supply files with the new video format the first time, they would have fixed that format too, I am sure.

I am almost 100% sure that the new crash is fixable via software too. After all, the decoder firmware is just some code which tells the chip what hardware pathways to activate to decode various video features (since most video formats are variations of the same encoding concepts, and decoding a format is just a matter of passing the video data through each specific, generic processing pathway). And since other formats are deinterlaced fine, I don’t think there’s an unfixable hardware bug in the deinterlacer.

There may even be a simple buffer overflow/underflow in the firmware, since the new video format can be decoded (and deinterlaced) for around 20-50 seconds before it crashes, suggesting a cumulative buffer bug (or the firmware getting into the wrong state) rather than a hardware problem.

In hindsight we might have set the wrong expectation on this forum being the primary contact for fixing device issues such as this. It is not, Amazon Customer Service (see link below) is the primary forum for such issues.

Exactly. I’ve tried to tell people that we’re on the wrong page. It’s unfortunate that customers (including me) landed on this page through Google and other forums and were expecting this unrelated repo to be “the support meeting point” for the hardware issue. It’s kinda like we busted into McDonalds to ask for tech support for our mobile phones. We’re in the completely wrong place (this page is for a video player port, as I mentioned in a post above). Thanks a lot for offering to help us with status updates from the other team from now on.

The slow handling of replies on this page is absolutely nothing out of the ordinary. We’re on the completely wrong page. And we had the wrong expectation from someone unrelated to the team that’s actually working on the hardware issue. Furthermore, I don’t fault Amazon for this issue either, since it is a bug in the hardware decoder that Amazon bought from a 3rd party, which in turn is at fault for being so slow to code fixes. I am not angry at you at all (rinoshs), and I am not angry at Amazon. I am a bit annoyed at the lack of quality control at the 3rd party chip vendor, but I can’t exactly boycott them since their decoder chips are in tons of Android devices. So meh… I’ll just patiently wait for the 3rd party to fix their bug… But I do hope that Amazon is putting pressure on them to work faster at fixing the bug this time.

The standard of language used in the posts is declining. If this continues, posting on this issue will be restricted.

Please don’t punish everyone just because of a few bad eggs. Simply block any individuals who cannot behave after this warning: https://help.github.com/en/articles/blocking-a-user-from-your-organization

Amazon Customer Contact https://www.amazon.com/hz/contact-us/csp?from=gp&source=contact-us&initialIssue=asin-order&_encoding=UTF8&

Thanks.

I have the last update…sorry i don t have the number with me. The fire stick 4k is at my office. I will check tomorrow.

Oh dear… so many misunderstandings here. Let me summarize what has happened:

  • Interlaced MPEG2 videos only displayed a green picture (#58). Status: FIXED
  • Interlaced H264 videos crashed the player and required a reboot (#81). Status: FIXED (the exact video samples provided by the original author are playing perfectly now)
  • Interlaced H264 videos in unusual color formats (best theory so far thanks to the research by @leone007) still crash the player. Status: YOU ARE READING THIS THREAD RIGHT NOW

Nobody had discovered the final problem in the previous thread, because there were sadly no sample files provided with that newly discovered crashing format… so they’ve only fixed the general deinterlacing issue, but had missed the fact that there was another way to crash the player too… and literally nobody knew about it until now… 😦

Software or Hardware problem?

Answer: Software problem. The hardware decoder chip has a firmware (kind of like a BIOS) which decides what parts of the hardware to use for decoding various features of various video formats, and in what way…

To fix this final issue, Amazon has to tell the decoder chip manufacturer to fix their firmware again, for this newly discovered separate problem. Amazon does not have the source code for the hardware manufacturer’s chip (that’s their proprietary trade secret).

How long will it take to fix?

It depends on the hardware chip manufacturer. The only thing Amazon can do for us is to ask them to hurry up this time.

Releasing a fix took the the hardware chip maker around 4 months last time, because their process is as follows (it was described by Amazon in the previous H264 ticket):

  • Identify the problem.
  • Code a fix, which takes time.
  • Test all other formats again over a period of time, to ensure the fix didn’t break anything else instead.
  • Release the new firmware.

After receiving the fixed firmware, Amazon has to do their own internal testing and OS development too, which took 2 months last time.

  • Test the new fix.
  • Ensure that everything in the system is still stable.
  • Release the fix together with the next OS update.

Hopefully this time they’ll skip step 3 and do a quick “out-of-order” update of the decoder firmware. But unfortunately they may not be able to do that due to company routines. Sigh… From what we learned in the last thread, Amazon does all testing on their latest in-development (non-public) OS version and releases everything new “all at once” in a single finished OS update package, rather than risking bugs from sending out separate bugfixes to people running older software than what they themselves use in their development area…

But please, break that tradition this time. As soon as you receive the firmware fix, please do testing on the current public OS version and then release the fix for all of us! I can see that people are going to be very angry and it will cause a lot of ill-will towards Amazon if people have to wait 6 months yet again for the final fix… it will damage the reputation of the Amazon FireTV and it will be known as a device where fixes “take forever, if ever” to arrive…

My hope and advice is that you therefore strongly pressure the hardware chip vendor for a quicker fix for the final problem, and that you release it to us as soon as possible on the current OS version.

However…

The last we heard from Amazon was in the previous thread, where @rinoshs acknowledged this final problem and asked us to make a ticket. We haven’t heard anything since then. It’s still only been 7 days, but we would really appreciate hearing from someone at Amazon to know what work is being done.

We’re all ready to help you do the research but we’re at a point where we need your input as well… To test the various samples in this thread and trying to figure out if it’s indeed a colorspace issue (BT.709 colors might be the cause of the crashes).

The bright side!

It’s a software issue. It only affects a few TV channels. It’ll be fixed. And I’m very happy with my FireTV 4K. It’s cheap. It’s small. It has a great remote control (lots of tactile buttons; far better than NVidia Shield TV or Apple TV). It’s super powerful at running any software. It’s 4K. It’s HDR/Dolby Vision/Dolby Atmos. It’s great!

We get a good explanation why it takes so long! So I would accepts the long timeframe. But what is not acceptable is that no Comment comes from Amazon. Its your product, so please give a statement that we know you care about the issue!

I don’t know how difficult it is, but letting the FTVS4K to operate in 1080i resolution would solve this whole issue.

But I agree that the silence is the worst possible reaction, it keeps up - probably false - hope in ppl. If you know it isn’t going to be fixed, at least you know, and can move on.

Amazon support is not existent very bad from Amazon not fixed after 11 month

No Statement nothing zero

Id have serious reservations in buying another Amazon stick/box, considering the way they’ve dealt with this issue, or not dealt with it in this case.

The lack of feedback has been absolutely pathetic. And before people start on that its not their fault, and a third party vendor has two deal with it…that’s not my problem, Amazon has chosen to use these third parties, not me.

This shouldn’t be in this thread, but since @amazon doesn’t give a shit about this, I’ll comment here anyways.

  • tvheadend transcode ALWAYS will de-interlace.
  • the output will be 25 fps progressive (if the source was 50 fps interlaced) not really good for sports
  • you can build your own tvheadend, so it can actually do HW accelerated motion adaptive full framerate de-intelacing & H.265 transcoding (the new touring NVENC chip would be perfect for this)

Fire TV Home version just got an update to 6.1.6.1-006

It makes zero difference to the problems documented here.

Well the fact that some interlaced H264 works (FTA satellite itv and chan 4) is a good sign that it’s likely a software issue. No one but amazon can give you an assurance as regards it’s something they’ll fix though.

Im confident its something they can fix, however not at all confident they’ll fix it any time soon. As I said earlier, we are a very small part of their user base, this won’t be seen as a priority unfortunately.

It’s such a shame, I unfortunately agree with what you are saying. I think if it was going to get fixed anytime soon it would have been done by now. Sorry I’ll let the topic get back on track now wasn’t trying to derail anything just trying to make an educated decision on hardware going forward

@gb160

Problem with this approach guys is that re-encoding may well fix whatever the underlying problem is, regardless of whether its related to the colourspace…so im not sure its going to prove much.

Well this is the exact reason why I don’t want to fix BT.709 videos, but want to “ruin” already working videos. IF I can produce a freezing interlaced BT.709 video from a currently working one, that can prove that my theory is working.

Using this as extra parameter (don’t laugh!)

:tff -vf scale=out_color_matrix=bt709 -color_primaries bt709 -color_trc bt709 -colorspace bt709

or

-vf scale=out_color_matrix=bt709 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -flags +ilme+ildct -alternate_scan 1

this is what I get, progressive, but BT.709

Scan type                                : Progressive
Writing library                          : x264 core 157 r2935 545de2f
Encoding settings                        : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=30 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=31250 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

Problem with this approach guys is that re-encoding may well fix whatever the underlying problem is, regardless of whether its related to the colourspace…so im not sure its going to prove much.

Im interested to hear any feedback from the Amazon/Chipset devs and to hear their findings. The fact that there’s so many people still reporting issues with it makes you think they’ve overlooked something pretty big with their latest fix.