Details
-
Bug
-
Resolution: Fixed
-
P3
-
7u10, 8
Description
Long mp4 files (duration > 12hrs) are rejected by the media player.
Found the following check in the gstreamer (qtdemux.c:5382):
if (stream->n_samples >=
QTDEMUX_MAX_SAMPLE_INDEX_SIZE / sizeof (QtDemuxSample)) {
GST_WARNING_OBJECT (qtdemux, "not allocating index of %d samples, would "
"be larger than %uMB (broken file?)", stream->n_samples,
QTDEMUX_MAX_SAMPLE_INDEX_SIZE >> 20);
That means the gstreamer rejects streams which have more than QTDEMUX_MAX_SAMPLE_INDEX_SIZE / sizeof (QtDemuxSample) = 50 * 1024 * 1024 / 32 = 1638400 samples.
The file supplied 1861369 samples, that's why it couldn't be loaded.
Thus we have unreasonable file length limitation: even if there is enough memory to allocate for a sample table gstreamer rejects such media assuming that the 'file is broken'.
Found the following check in the gstreamer (qtdemux.c:5382):
if (stream->n_samples >=
QTDEMUX_MAX_SAMPLE_INDEX_SIZE / sizeof (QtDemuxSample)) {
GST_WARNING_OBJECT (qtdemux, "not allocating index of %d samples, would "
"be larger than %uMB (broken file?)", stream->n_samples,
QTDEMUX_MAX_SAMPLE_INDEX_SIZE >> 20);
That means the gstreamer rejects streams which have more than QTDEMUX_MAX_SAMPLE_INDEX_SIZE / sizeof (QtDemuxSample) = 50 * 1024 * 1024 / 32 = 1638400 samples.
The file supplied 1861369 samples, that's why it couldn't be loaded.
Thus we have unreasonable file length limitation: even if there is enough memory to allocate for a sample table gstreamer rejects such media assuming that the 'file is broken'.
Attachments
Issue Links
- blocks
-
JDK-8094930 Memory-Leak in Media Components
-
- Closed
-
- relates to
-
JDK-8115891 JavaFx MediaView hangs when I used large video files
-
- Resolved
-
1.
|
Backport to 2.2 |
|
Resolved | Anton Nashatyrev (Inactive) |