[9] Proposal to deprecate VP6 video and the FLV/FXM file formats

Michael Berry berry120 at gmail.com
Thu Aug 27 20:36:36 UTC 2015

On 27 August 2015 at 19:53, David DeHaven <david.dehaven at oracle.com> wrote:

> > +1 for deprecation - I haven't used VP6 in a long while, and would value
> > the whole thing being open source more than its inclusion.
> >
> > Out of interest, is this anything to do with JEP 257? I started looking
> at
> > this with Kirill's guidance a year or so ago, but sadly many other things
> > had to take precedence so I didn't really have the time.
> No, that's unrelated. I suspect we'll hear something about that soon...
> Oh, I see Kevin let the cat out of the bag. Well, there you go :)

Awesome, that's good to hear!

> >> I agree that codecs that are usable by the system’s default media
> >> framework should work.  However, I believe that is already supported in
> >> most cases, is it not?
> >>
> >
> > It's not - JavaFX can decode the audio / video / container formats that
> it
> > knows about through its GStreamer plugins, and nothing else (unless you
> > compile them in yourself, which isn't all that hard.)
> Not entirely true... on the Mac, GStreamer does not support HLS, that gets
> routed through QTKit (for <= 10.7) or AVFoundation (10.8+). With VP6 gone
> there will actually be no need for GStreamer on Mac at all.
Sorry, my mistake - I'm used to the media stack on Windows where this is (I
think) always the case.

> It *used* to be the case that we allowed anything the native platform
> provided, in the previous media stack (JMC if anyone was paying attention).
> The big issue, as Kirill pointed out, was it was very difficult to support
> due to the vast combinations of operating systems and codecs/media formats
> and (more importantly) there are security implications.
Perhaps a political issue as oppose to a technical one, but (on the support
side of things rather than the security side) would "best efforts" here
with a warning that it might not work 100% reliably be better than not at

> There are internal discussions ongoing about how we're approaching this
> problem. The security aspects only affect webstart and plugin, standalone
> applications aren't as much of a concern (except from a supportability
> standpoint) so maybe some compromise can be reached.
Without wishing to drag this further off topic (perhaps it should be split
into a separate discussion!), from memory at the moment the Java code won't
allow any format down to the native layer (gstreamer) unless it matches one
of the types it's aware of. Would it be possible to remove this hard
requirement (perhaps with a flag?) If this was done then it would probably
be a small bit of boilerplate in the native layer to pass the stream down
to the relevant plugin. If it doesn't exist then we haven't lost anything,
if it does then the stream can be played without an issue.

This wouldn't change anything by default, but it would mean that anyone
could then drag custom gstreamer plugins into the correct JRE directory and
have them work straight off. Considering that many applications bundle a
JRE anyway these days, that would make it trivial for those who wanted to
to support any other codec / container type that GStreamer offered, and
would (presumably) remove the support / legal burden on Oracle of
distributing and maintaining these plugins. Hopefully that ticks the
sustainability and security boxes?


> I would actually favor allowing formats supplied by the underlying native
> platform over trying to figure out how to provide a pluggable codec
> interface, but it needs to be done in a way that's sustainable and does not
> expose security vulnerabilities.

> Again, I'm not promising anything, just know that complaints and requests
> have been heard and are being taken into consideration.
> -DrD-



More information about the openjfx-dev mailing list