Difference in video quality compared to mediaplayer

[loredana2314]

Issue description

Hello
We are using Exoplayer on our application. We have noticed that there is a difference on video quality between Exolplayer and Mediaplayer.
The picture quality is better on Mediaplayer and the video plays smoothly (the colors seem to be different). On the other hand, picture on Exoplayer is not so clear and video freezes time after time.
We are testing the same streams in both players

Version of ExoPlayer being used

The version of exoplayer is 2.7.1

Device(s) and version(s) of Android being used

We have tested on different devices, mainly in Android 4.4.2 STB

A full bug report captured from the device

[tonihei]

Could be related to #4559 which was fixed in version 2.9.0. Can you try updating to see if it still occurs?
Besides that we would need example media to actually debug the problem. If you don't want to post it publicly, please send it to dev.exoplayer@gmail.com with "Issue #5003" in the subject.

[loredana2314]

We tested with version 2.9.0 and the problem seems to continue.
We tested on Amlogic and Rock cheap STB were the problem seems to continue.
We also tested on Philips Android Tv and there is no problem.
An example media is also sent to you as requested.

[tonihei]

I'm unfortunately getting 404s when trying to access the media you've sent. Can you check it's still valid?

[loredana2314]

Sorry about that, we sent you another email with other media.
Thank you for the support.

[tonihei]

The media plays fine for me, although I used a new device.

Can you give some more details of what's wrong with the ExoPlayer playback?

• For example do both MediaPlayer and ExoPlayer use the same format? If not, it could be that you are just looking at different formats because both players made a different decision.
• Also, when the video "freezes", do you get droppedFrames notifications? You can add an EventLogger to SimpleExoPlayer to check. If so, it seems that the device is just not capable of processing the streams fast enough.

[ojw28]

We've had some reports about AmLogic (and possibly RockChip) STBs in the past. For example #953. They are likely device specific issues that need reporting to the manufacturer, rather than to us.

[loredana2314]

From our findings it looks like it is NOT a hardware/manufacturer issue. We also spoke to the device manufacture and they confirmed the same thing as below.

This are the results from our tests on the same device:
Default player plays the stream very well.
VLC player plays the the stream very well, same as default player.
MX Player plays the stream very well, same as default player.

Video plays smoother and has more colors on above players compared to Exoplayer. On exoplayer we also notice some sporadic freezes from time to time.

Please let me know if you need further information. The hardware is running on an amlogic s812.

[tonihei]

There is also #926 and #678 which both sounds like the same problem. The conclusion on these issues was that it may be a device specific issue or may not occur with newer versions of ExoPlayer.

It's still a device-specific issue because it only happens on this device. However, given that the default player can play it fine, it seems we should be able to provide a workaround. Need to get hold of the device first though.

One thing that stands out in the logs is the repeated "AmlogicVideoDecoderAwesome: head is 001,do not add start code" in every renderer iteration which indicates that the decoder expects us not to send a start code.

It would be helpful to know the scope the problem. Can you check on all the devices where you've seen the problem which decoder they use? Look out for the "decoderInitialized" messages of the EventLogger. Can you also let us know the Build.DEVICE and Build.MODEL values of these devices? Thanks!

[loredana2314]

From the logs "decoderInitialized" is OMX.amlogic.avc.decoder.awesome for video and OMX.google.aac.decoder for the audio. As for the Build.DEVICE: stvm8 and MODEL: Quad-Core Enjoy TV Box. Attached you will find some more logs from the device that we are interested in (the one that our customers have). You will also find system/etc/media_codecs.xml.
We will also send an email with a new valid media example.

[okycelt]

Since our issue related to this topic was closed (#5022) and we also want this resolved, I'd like to share our observations here.

We're seeing basically the same symptoms as @loredanatosku. In MediaPlayer, the image quality is better (the image is sharper) and the playback is smoother. Whereas in ExoPlayer, the image is not that sharp and the video seems like it would have slightly lower frame rate than when playing in MediaPlayer.

We're seeing these issues only on some devices and some content though. Our DASH content is playing fine everywhere, but when we play the UDP multicasts from which our DASH content is prepared, on some devices, we see the problems described above. I've made a summary of the devices we tested on including the details @tonihei requested.

Problematic devices

• Amlogic S905X, Android 6.0.1, Build.DEVICE: p212_1113, Build.MODEL: p212, Video decoder: OMX.amlogic.avc.decoder.awesome
• Amlogic S905X, Android 7.1.2, Build.DEVICE: SN6B6AC_EU132, Build.MODEL: SN6B6AC_EU132, Video decoder: OMX.amlogic.avc.decoder.awesome

Okay devices

• Amlogic S805X, Android 8.0, Build.DEVICE: SEI102, Build.MODEL: SEI102, Video decoder: OMX.amlogic.avc.decoder.awesome

If necessary, we can provide test content as well as bugreports from these devices.

Thanks for looking into this.

[tonihei]

@loredanatosku @okycelt Thanks for the input. We'll try to get hold of a device to reproduce ourselves. And then check if there is an easy workaround we could enable for those devices.

[okycelt]

@tonihei Have you made any progress regarding this? Thank you.

[tonihei]

No, sorry. Haven't got a device yet.

[okycelt]

@tonihei If you'd like, we would be willing to provide a test device for you. For free of course.

[tonihei]

Thanks for the offer, but that's probably too complicated. Would you reckon this device is one of the problematic ones?

[okycelt]

Would you reckon this device is one of the problematic ones?

Looking at the specs, I think it could be. The problematic box we use has the same specs.

[okycelt]

@tonihei Sorry to push, but do you have any estimate when approximately you're going to start working on this? Thanks again.

[tonihei]

Will investigate this week. Got one of the devices now.

[okycelt]

Great, thanks a lot.

[okycelt]

@tonihei Have you had a chance to take look at this? Thanks.

[tonihei]

I wasn't able to reproduce the problem with the streams provided by Loredana. And I couldn't test with your test stream so far as the link expired already - could you sent it again?

[okycelt]

I've just sent a link to dev.exoplayer@gmail.com

[Svechnikov]

The first bugreport unfortunately doesn't contain the start of the video where the problem happens. And the second one only has a weird size change to 160x90 pixels?

I don't know where this weird size came from, but the circle in the test video was smooth.

Did tests one more time:
testFix.log.txt - logs with MediaFormat.KEY_HEIGHT set to 1089
testInitial.log.txt - logs without any changes
testMaxHeight.log.txt - logs with MediaFormat.KEY_MAX_HEIGHT and MediaFormat.KEY_MAX_WIDTH set to 1089 and 1920.

Can you verify again that directly setting the max values doesn't help too?
mediaFormat.setInteger(MediaFormat.KEY_MAX_WIDTH, 1920); mediaFormat.setInteger(MediaFormat.KEY_MAX_HEIGHT, 1089);

Checked it another time, I confirm it doesn't help.

[tonihei]

Thanks for the reports. As you noted, it looks as if this device is ignoring the MAX_WIDTH and MAX_HEIGHT parameters completely. When changing the video size itself, the codec seems to switch to a special 4K code path which doesn't have the bug. Note how the line with "omx output size changed from 1920*1088 to ..." isn't even part of the output anymore.

Although changing the video size itself seems to work, it's may not be a good idea to change it in code because we would be giving the decoder a wrong configuration. Whereas setting a higher maximum size isn't wrong per se. As a whole bunch of other devices seem to work fine with the existing workaround (see above), I would leave it as it is in the hope that this is just an exception. Maybe also be worth reporting the issue to Amlogic again to see if they can provide a proper workaround.

[Svechnikov]

Although changing the video size itself seems to work, it's may not be a good idea to change it in code because we would be giving the decoder a wrong configuration. Whereas setting a higher maximum size isn't wrong per se. As a whole bunch of other devices seem to work fine with the existing workaround (see above), I would leave it as it is in the hope that this is just an exception. Maybe also be worth reporting the issue to Amlogic again to see if they can provide a proper workaround.

Yes, I understand that setting invalid size will necessary break playback on some other device and it would be a horrible decision to make such thing to ExoPlayer :)

ExoPlayer helps to get rid of vendor-specific bugs almost on every level, except hardware decoding.It would be great to have more deeper control over decoding process than existing MediaCodec has to offer.

[tonihei]

ExoPlayer helps to get rid of vendor-specific bugs almost on every level, except hardware decoding.It would be great to have more deeper control over decoding process than existing MediaCodec has to offer.

Well, the media codecs are part of the platform and we can't only work around issues or hope for vendor updates if possible. There are ExoPlayer extensions to use software decoders (e.g. ffmpeg for audio) if you prefer that.

[tonihei]

Closing this issue under the assumption that the workaround we committed helps.

[giridharkannan]

The given fix results in breaking the Amlogic box that I have. This results in a completely black screen which covers the whole viewing area (including any sibling views). I could hear only the audio.

If the new code is commented out, things work without any issue as expected.

It would be good if you could change the codecNeedsMaxVideoSizeResetWorkaround method from private static to protected so that I can override the behaviour.

I will also open up a new issue so that other users need not waste time on this issue.

Box Details:
Device - G9X
Manifacturer - ShiningWorth
Android SDK - 23
Hardware - Amlogic

[ojw28]

I think I'd be in favour of reverting the fix for now. It's unclear whether it's making things better, on balance (in particular if it's affecting playback of non-interlaced content).

[tonihei]

I'll close this issue again because the revert of the original fix has been pushed. If you find a way to target the max video size workaround to only the affected video streams, please let us know.

[lintax]

@tonihei
Actually reverting the fix made video much worse quality for many Amlogic devices - the fix is really good.
Maybe it would be better idea to make it configurable like some experimental flags that depends on the library user, without the need to fork repository?

[tonihei]

@lintax I can see how this helps for some devices, but on the other hand it seems to break playback on other devices (see #5003 (comment)).

How would you decide if it's fine for your app to enable such a flag or not? So far it's unclear under which exact conditions it improves playback and under which conditions the "fix" completely breaks it. From ExoPlayer side it seems safer to opt for having some devices with non-optimal playback vs some devices with no playback at all.

Regardless of this decision dilemma, you can reenable the fix by extending MediaCodecVideoRenderer like that (untested):

public final class MyVideoRenderer extends MediaCodecVideoRenderer {
  @Override
  protected CodecMaxValues getCodecMaxValues(
      MediaCodecInfo codecInfo, Format format, Format[] streamFormats) {
    CodexMaxValues maxValues = 
        super.getCodecMaxValues(codecInfo, format, streamFormats);
    if ("OMX.amlogic.avc.decoder.awesome".equals(codecInfo.name) 
        && Util.SDK_INT <= 25
        && (maxValues.width < 1920 || maxValues.height < 1089)) {
      return new CodecMaxValues(
          Math.max(maxValues.width, 1920), 
          Math.max(maxValues.height, 1089), 
          maxValues.inputSize);
    }
    return maxValues;
  }
}

[lintax]

@tonihei thanks for your solution, probably the best would be to override DefaultRendererFactory.buildVideoRenderers() since it is effective only creating a single renderer in my case

PS: I've got lots of users reports that video quality drastically improved when updated to the version with the patch, and no one reporting issue (I understand that it is a weak point, since the app also has software decoders and user is able to switch to it instead of exoplayer, since many streams are not playable via hardware decoders)

[tonihei]

@giridharkannan Would it be possible for you to provide a full bugreport for the problematic device when the problem occurs? It would be good to see if there is any indication of the underlying problem.

[giridharkannan]

@tonihei Sure, but don't expect an immediate response as 'am currently occupied with other things. I will try to give a full bug report by the end of next week.

[marabej]

HI

"mediaFormat.setInteger(MediaFormat.KEY_WIDTH, 1920); mediaFormat.setInteger(MediaFormat.KEY_HEIGHT, 1089);"
really fixed the problem with amlogic.

@tonihei I saw this problem not only with amlogic, but with smart TVs, for ex. finlux.
Another thing I discovered is that default MediaPlayer redirected to ScallableVideoView
shows the same problem, (aliased rounded objects, bad colors, pixelisation), the picture is 1:1
with ExoPlayer,
but after that I changed the output view to standard VideoView and the problem gone.
This is a software problem, not hardware
I mean that MediaPlayer output to that:
https://github.com/yqritc/Android-ScalableVideoView
shows the same bad picture like ExoPlayer, but output to VideoView - the picture is fine
I can easily put on ftp captured from multicast mpeg2 .ts file for test if necessary.
This file played in ExoPlayer looks like an old VHS tape, but differently in mediaPlayer/MX Player

best regards

[ojw28]

We are convinced that parameters I described above are suitable for all devices on a Amlogic chip.

Based on what? It seems to be the case that AmLogic have two separate video paths. Your suggestion is that the one that's not enabled by default is strictly better. However if that were the case, I think AmLogic would have made it the default. This suggests to me that there are disadvantages with the alternate video path, perhaps for use cases other than the one you've tested. I also suspect that the original workaround we had was effectively achieving the same thing (i.e. causing the non-default video path to be selected), and it did not turn out to be suitable for all cases.

This is a software problem, not hardware

Probably, but the problem is in the underlying platform, not in ExoPlayer (and not in ScalableVideoView either), which is why this issue only affects certain devices. The device manufacturers and/or the chipset providers are the people who should fix this.

From our perspective, this issue affects a small number of devices, and only when playing interlaced content. The fraction of ExoPlayer playbacks affected is tiny, and so I don't think we can really justify investing more time into this issue. It's up to AmLogic to decide whether they wish to better support your use case. Please direct your issue to them.

[mindfields5]

We are convinced that parameters I described above are suitable for all devices on a Amlogic chip.

Based on what? It seems to be the case that AmLogic have two separate video paths. Your suggestion is that the one that's not enabled by default is strictly better. However if that were the case, I think AmLogic would have made it the default. This suggests to me that there are disadvantages with the alternate video path, perhaps for use cases other than the one you've tested. I also suspect that the original workaround we had was effectively achieving the same thing (i.e. causing the non-default video path to be selected), and it did not turn out to be suitable for all cases.

Perhaps you `re right. We reported problems to Amlogic.