JDK-8213510 : [Windows] MediaPlayer does not play some mp3 with artwork stream in mjpeg
  • Type: Bug
  • Component: javafx
  • Sub-Component: media
  • Affected Version: 8u191,openjfx11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2018-11-07
  • Updated: 2020-01-31
  • Resolved: 2019-04-19
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 Other
8u231Fixed openjfx11.0.5Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
Windows 10, Java 11.0.1, JavaFX 11

A DESCRIPTION OF THE PROBLEM :
MediaPlayer stays in state UNKNOWN with some mp3 files if they have artwork as second mjpeg stream.
Those file are playable by iTunes and VLC without any problem, once artwork is removed using iTunes - MediaPlayer can play the file as expected.
Specific file where issue was discovered is encoded with Lame3.99. 
Other files with artwork as png stream are ok. Some other files encoded with different encoders with mjpeg stream are not affected.
Typical output from ffprobe for affected files looks as below:
Input #0, mp3, from '01-01.mp3':
  Metadata:
    track           : 1/49
    album_artist    : XXX 
    Engineer        : XXX
    title           : XXX
    album           : XXX
    genre           : XXX
    artist          : XXX
    date            : 2014-09-03
  Duration: 00:12:47.90, start: 0.000000, bitrate: 132 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s
    Stream #0:1: Video: mjpeg, yuvj444p(pc, bt470bg/unknown/unknown), 583x520 [SAR 100:100 DAR 583:520], 90k tbr, 90k tbn, 90k tbc
    Metadata:
      comment         : Cover (front)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Play mp3 with mjpeg stream for artwork with MediaPlayer.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Music is playing.
ACTUAL -
Music is not playing.

---------- BEGIN SOURCE ----------
Standard example of using MediaPlayer
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Remove artwork manually, however could be not possible by end users.

FREQUENCY : always



Comments
http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/3f29f685f4e1
19-04-2019

OK
19-04-2019

Will file a new bug and revert VS project changes before pushing.
19-04-2019

Probably separately would be best, since it is completely unrelated to this fix. Please file a new bug.
19-04-2019

Visual Studio will not open VS projects without this fix. Not sure how and when they become corrupted. I will prefer to push such change as part of this bug or file a new one.
19-04-2019

I presume that you didn't mean for the vs_project files to be a part of this webrev? I think they should be reverted. +1 pending the reversion of the vs_project files (no need for a new webrev)
19-04-2019

http://cr.openjdk.java.net/~almatvee/8213510/webrev.00/ - Fixed by disabling support for free format files in mpeg audio parser. This is how it was before we upgraded to GStreamer 1.14 and check is taken from previous version. - When we allow such streams mpeg parser will send as metadata stream as audio stream and it will break us. - Another possible solution is to ignore such streams (since decoder does not output anything) and wait for caps change event and rebuild dshow graph to re-initialize decoder, but this approach is complicated and for now lets ignore metadata build into stream.
17-04-2019

Probably duplicate of JDK-8210828.
14-11-2018

Response from Submitter: -------------------------------------------- Please find original file here (Original.mp3) . It's a part of audiobook in Russian. FFProbe output for it: Duration: 00:10:22.40, start: 0.000000, bitrate: 133 kb/s Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s Stream #0:1: Video: mjpeg, yuvj444p(pc, bt470bg/unknown/unknown), 583x520 [SAR 100:100 DAR 583:520], 90k tbr, 90k tbn, 90k tbc Metadata: comment : Cover (front) The same file (Original_no_art.mp3), but I removed artwork in iTunes. And it works as expected. FFProbe output: Duration: 00:10:22.40, start: 0.000000, bitrate: 128 kb/s Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s I have could do few other samples if needed - resolution always the same - remove the artwork. The code behaviour is the same - MediaPlayer stays in state - UNKNOWN, but once artwork is removed it plays as expected. -------------------------------------------------------------------------------- Received mp3 file (Original.mp3) from Submitter using which issue is reproducible. Provided mp3 file is playable by VLC but not by FX MediaPlayer. Its a regression in JDK 8u191-b05 and reproducible only in Windows. Windows 10, 64-bit JDK results ================ 8b132 : Pass 8u181-b13 : Pass 8u191-b04 : Pass 8u191-b05 : Fail <== regression 8u192-b12 : Fail latest openjfx : Fail =============== Same file with no art (as provided by submitter - original_no_art.mp3) is playing in MediaPlayer.
08-11-2018

This is very likely a regression introduced by the updated version of GStreamer done in JDK-8199527. It was initially done for JDK 9, and backported to JDK 8u191 in b05.
08-11-2018

I could not reproduce the issue with one sample MP3 file embedded with artwork: Input #0, mp3, from 'XXX.mp3': Metadata: title : XXX album : XXX artist : XXX comment : Downloaded from Mr-Jatt.com Duration: 00:05:19.71, start: 0.000000, bitrate: 328 kb/s Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 320 kb/s Stream #0:1: Video: mjpeg (Baseline), yuvj444p(pc, bt470bg/unknown/unknown), 480x480 [SAR 72:72 DAR 1:1], 90k tbr, 90k tbn, 90k tbc Metadata: title : cover comment : Other file icon Requested Submitter to provide affected MP3 file (mp3 with mjpeg stream for artwork) to reproduce the issue. Marking as Incomplete pending for more information.
07-11-2018