androidx
All (28!) image based subtitle tracks are parsed to Bitmap objects, even when none are selected for playback, resulting in stuttery video playback
Is there a limitation on the number of tracks in a video, or a way to deal with a video with excessive tracks?
Playing an mkv video file which has 7 audio tracks and 28 subtitle tracks over http , Exoplayer pauses for 5 seconds, plays for 10 seconds, pauses for 5 seconds, etc. This happens with a ONN google TV device and an Amazon Fire stick 4K. It does not happen with the Android Studio emulator or a NVidia Shield. It seems there is not enough CPU power in some devices to bypass all the extra tracks. If I use mkvmerge on the video file to remove extra tracks and leave only 1 audio and 1 subtitle track, it plays perfectly on those devices.
This also happens with the Demo player from github.
Sample file is here https://drive.google.com/file/d/19dgchCfQUuOOVJgR4-9Le2YG0sc5mgvf/view?usp=sharing
Exoplayer pauses for 5 seconds, plays for 10 seconds, pauses for 5 seconds, etc. This happens with a ONN google TV device and an Amazon Fire stick 4K.
I can reproduce this on a CCwGTV (Sabrina) device.
The issue can be resolved by reverting to legacy subtitle handling (see instructions in the 1.4.0 release notes).
In the case of the file you provided, ExoPlayer's new subtitle handling parses all the subtitle tracks (including decoding the 28 image-based PGS tracks to Bitmap) - because this process happens as part of extraction/loading, before track selection can indicate which track(s) will actually be played.
I think this is what is causing the device to run out of resources and fail to keep up with the video decoding.
This is a similar root cause to https://github.com/androidx/media/issues/1621 (though the symptoms are different enough that I'm going to keep them as separate issues for now). I think the fix for both of them probably avoids parsing subtitle bytes to Bitmap in the loading/extraction phase, and pushes this to the Renderer side - but unfortunately this is quite fiddly for a few reasons.
Aside: There is something strange about the file you shared.
mediainfo reports the overall file size as 110MB (which agrees with ls -lh), but it also states the video track alone is 16.3GB:
$ mediainfo many_tracks.mkv
...
File size : 110 MiB
...
Video
ID : 1
ID in the original source medium : 4113 (0x1011)
Format : AVC
Format/Info : Advanced Video Codec
...
Stream size : 16.3 GiB
5 of the audio tracks are reported to be about 314MB and the other 2 are 135MB. The subtitle tracks range from 4MB to 1GB (!).
Aside: There is something strange about the file you shared.
Yes I saw that. The original file was very large ( maybe 16 GB) and she used ffmpeg to extract a part of it. Evidently ffmpeg is not the best for extracting a part of an mkv file. I prefer mkvmerge.
see https://github.com/bennettpeter/android-MythTV-Leanfront/issues/117
I posted the original leanfront issue and provided the clip made with ffmpeg. If it helps, I can probably provide a clip made with mkvtoolnix or similar, that has more realistic metadata. The clip's metadata probably reflects the original source's contents. I'm attaching the mediainfo output from the original source.
Following issue #2850, please note that it causes crashes on devices with low memory when having ttml file like this one:
