JDK-8096534 : [media] Long mp4 files (duration > 12hrs) are rejected by the media player.
  • Type: Bug
  • Component: javafx
  • Sub-Component: media
  • Affected Version: 7u10,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-05-07
  • Updated: 2015-06-12
  • Resolved: 2014-05-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8u20Fixed
Related Reports
Blocks :  
Relates :  
Sub Tasks
JDK-8097526 :  
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'. 
Comments
SQE OK to take low risk fix in PSU14_04
14-07-2014

Fix Summary Template - Fix for Release : 7 (2.2.x) - Risk Analysis : Low - Testing : For testing the mp4 with the duration > 12hr needed. Without the fix the file is not accepted: the fx-media report that the file is corrupted. (I have a file locally and can share it via ftp) - JavaFX Impact : YES
08-07-2014

Code has been pushes so I closed this bug.
08-05-2014

Pushed: http://jfxsrc.us.oracle.com/javafx/8u/dev/rt/rev/8c38297db42b
08-05-2014

Thanks for review! I'll add #ifdef GSTREAMER_LITE before commit without additional review if you don't mind
08-05-2014

Approved, but use #ifdef GSTREAMER_LITE for changes in GStreamer or GLib. #ifdef GSTREAMER_LITE #define QTDEMUX_MAX_SAMPLE_INDEX_SIZE (500*1024*1024) #else #define QTDEMUX_MAX_SAMPLE_INDEX_SIZE (50*1024*1024) #endif // GSTREAMER_LITE
07-05-2014

Thanks for confirming. +1 for pushing to 8u-dev (for 8u20).
07-05-2014

The original restriction was 1638400 samples. I've tried the file with 1861369 samples - all went fine. The constant I'm changing is used only in this qtdemux.c file so this gives us some confidence that other code doesn't rely on the same '50Mb of samples'
07-05-2014

Note that we are under additional push restrictions for this week (leading up to our M4 milestone). See https://wiki.openjdk.java.net/display/OpenJFX/8u20 My only question with this fix is: Have you made sure that a media file with the new maximum number of samples cannot overflow any array?
07-05-2014

Approved
07-05-2014

No, there is no problems with the memory allocation. Just an unnecessary check which prevents us from trying to allocate the memory. If the requested amount could not be allocated the result is pretty the same as we didn't pass the check: we return an error.
07-05-2014

Do you mean that this fix goes with the fix for memory allocation ?
07-05-2014

Webrev: http://cr.openjdk.java.net/~anashaty/RT-37010/8/webrev.00/
07-05-2014

The size checking code described above is immediately followed by the allocation code stream->samples = g_try_new0 (QtDemuxSample, stream->n_samples); if (!stream->samples) { GST_WARNING_OBJECT (qtdemux, "failed to allocate %d samples", stream->n_samples); return FALSE; } The method gives up if it couldn't allocate enough memory for the samples table.
07-05-2014