You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a particular stream that is H.264 encapsulated in mpeg-ts that was taken off a DVB-T receiver. I saved this stream to a file using VLC without any transcoding etc, and play it in exoplayer on my target device as a file, so the problem I am seeing is clearly nothing to do with network/streaming behaviors.
This particular video does not play smoothly on RK chipset-based device; its keeps freezing every few seconds, but works fine on a Samsung Galaxy phone and on VLC desktop, so it's not an inherent fault in the video itself. Problem doesn't affect audio, so it's purely a video decoder issue. Other MP4 videos play fine though, so I'm not sure what's the exact thing in it that is triggering the poor behavior.
Anyhow, I then thought I would try it on VLC-Android for comparison, and lo and behold it does the same thing. Hence it's a hardware decoder issue of some type.
In VLC for Android there is a preference setting for Hardware Acceleration. which can can be set to "Automatic", "Disabled", "Decoding acceleration" and "Full acceleration". It turns out my problem only manifests with "Full acceleration". If I set it to "Decoding Acceleration" it works fine.
I had a trawl through the VLC-Android source, and their acceleration setting that appears to work successfully does this:
if (hardwareAcceleration == HW_ACCELERATION_DECODING) {
media.addOption(":no-mediacodec-dr")
media.addOption(":no-omxil-dr")
}
These VLC options in turn influence settings on the decoder through the OMX interface.
So my question is, it seems like I need to do something similar for my exoplayer app. How to achieve this?
Possibly pertinent to this, I noticed that in media3 there is already code that tests for particular hardware codecs and introduces workarounds, such as
This appears to be the only hw specific reference to this hw decoder in the whole library. Not sure if this relates to my problem, nor why it's apparently only an issue if SDK < 25. May have nothing to do with it).
PS: Just to rule anything to do with the container format I converted to MP4 container but the result was the same.
The text was updated successfully, but these errors were encountered:
Exoplayer 1.5.1.
I have a particular stream that is H.264 encapsulated in mpeg-ts that was taken off a DVB-T receiver. I saved this stream to a file using VLC without any transcoding etc, and play it in exoplayer on my target device as a file, so the problem I am seeing is clearly nothing to do with network/streaming behaviors.
This particular video does not play smoothly on RK chipset-based device; its keeps freezing every few seconds, but works fine on a Samsung Galaxy phone and on VLC desktop, so it's not an inherent fault in the video itself. Problem doesn't affect audio, so it's purely a video decoder issue. Other MP4 videos play fine though, so I'm not sure what's the exact thing in it that is triggering the poor behavior.
Anyhow, I then thought I would try it on VLC-Android for comparison, and lo and behold it does the same thing. Hence it's a hardware decoder issue of some type.
In VLC for Android there is a preference setting for Hardware Acceleration. which can can be set to "Automatic", "Disabled", "Decoding acceleration" and "Full acceleration". It turns out my problem only manifests with "Full acceleration". If I set it to "Decoding Acceleration" it works fine.
I had a trawl through the VLC-Android source, and their acceleration setting that appears to work successfully does this:
These VLC options in turn influence settings on the decoder through the OMX interface.
So my question is, it seems like I need to do something similar for my exoplayer app. How to achieve this?
Possibly pertinent to this, I noticed that in media3 there is already code that tests for particular hardware codecs and introduces workarounds, such as
This appears to be the only hw specific reference to this hw decoder in the whole library. Not sure if this relates to my problem, nor why it's apparently only an issue if SDK < 25. May have nothing to do with it).
PS: Just to rule anything to do with the container format I converted to MP4 container but the result was the same.
The text was updated successfully, but these errors were encountered: