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

[David DeHaven]

Having heard no objections and gaining internal approval, we'll move forward 
with this plan.

-DrD-

> On Aug 26, 2015, at 11:53 AM, David DeHaven  wrote:
> 
> 
> I am proposing we deprecate support for the VP6 video encoding format and the 
> FXM/FLV file format in JFXMedia for Java 9. The current intention is to 
> completely remove support for these components in the Java 10 timeframe. Note 
> that this is only deprecation, Java 9 will still support playback of VP6 
> video in FXM or FLV containers.
> 
> The reasons in favor of deprecation:
> - Use of VP6 on the web has lost favor, it was superseded fairly quickly by 
> H.264/AVC in Flash 9 and Adobe generally recommends using H.264/AVC over it. 
> It's not even recommended for compatibility as as their "Sorenson Spark" 
> H.263 variant has a much longer history in Flash.
> - Tools for generating VP6 are non-trivial, even Adobe products no longer 
> support generating VP6 content out of the box, you have to install add-ons. 
> While there are free tools, none are particularly elegant or easy to use, or 
> produce sub-optimal results. We've heard no end of complaints from the 
> community about the lack of tools for VP6, so it seems a logical decision to 
> migrate away from it.
> - We have had (many) requests to add external codec support, if (that's a big 
> IF, please do NOT take this as any sort of promise or even the hope of a 
> promise!) we were to implement such a feature and if you absolutely had to 
> rely on VP6 then you would be able to provide one yourself.
> - The vp6 codec is the LAST closed source component in media, once removed 
> JFXMedia will be 100% open source. I think we can all agree this is a good 
> thing and something I personally look forward to achieving.
> 
> 
> The one and only reason I can think of for NOT deprecating VP6:
> - It is currently the only format (supported by JFXMedia) which supports an 
> alpha channel, though I have had thoughts on how to address that in a way 
> that would allow the use of practically any media format.
> 
> 
> While compelling for some use cases, it is a very niche use case and thus 
> cannot outweigh the benefits. So, this is a call out to any who may be using 
> VP6, please speak up now so we can discuss it or forever hold your peace.
> 
> 
> For reference, the list of supported formats in JFXMedia are in the JavaDoc 
> for javafx.scene.Media:
> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/media/package-summary.html#SupportedMediaTypes
> 
> -DrD-
> 

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

[Kevin Rushforth]

It's not directly related to JEP 257, no. Just some outstanding cleanup.

Btw, speaking of JEP 257, we plan to integrate that to 9-dev today.

-- Kevin


Michael Berry 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.

Michael

On 27 August 2015 at 12:39, Scott Palmer swpal...@gmail.com wrote:

  

On Aug 27, 2015, at 2:29 AM, Dr. Michael Paus m...@jugs.org wrote:

Am 26.08.15 um 22:25 schrieb Scott Palmer:
  

Then legacy formats could be provided in optional downloads and new


formats can be supported without the need to integrate them within the JRE
code.



To me this sounds again like a Java/JavaFX specific solution which, to
  

my opinion, is a dead-end road. I think it would be much more important
that JavaFX can directly use all system installed codecs. I simply don't
understand why it is possible to install a codec pack on a machine and
almost all software, with the exception of JavaFX, is able to immediately
use that and only JavaFX based applications are not.


Michael
  

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.)


  

There still needs to be a guarantee that certain specific codecs will work
wherever JFXMEdia is supported.  Otherwise you lose a significant bit of
cross-platform compatibility. Media assets that you ship with your
application need to be able to play, regardless of how the end user has
configured their specific codec environment.

Scott






  

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

[David DeHaven]

 +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 :)


 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.


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.

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.

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-

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

[Michael Berry]

On 27 August 2015 at 19:53, David DeHaven david.deha...@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
all?


 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?

Michael


 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-




-- 
Thanks,

Michael

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

[Kirill Kirichenko]

On 27.08.2015 9:29, Dr. Michael Paus wrote:

To me this sounds again like a Java/JavaFX specific solution which, to
my opinion, is a dead-end road. I think it would be much more important
that JavaFX can directly use all system installed codecs. I simply don't
understand why it is possible to install a codec pack on a machine and
almost all software, with the exception of JavaFX, is able to
immediately use that and only JavaFX based applications are not.


Although this is an off-topic I'll answer to your question.

Security and testing are the reasons.
It's virtually impossible to test every possible codec on every possible 
platform. Many of them are proprietary so we don't control their 
code/can't fix their bugs. And all blame that JavaFX can't play 
this/can't play that will fall on our heads.

And it can open many potential security vulnerabilities.

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

[David DeHaven]

 +1 for deprecation of VP6 and clearing the way to open sourcing of JFXMedia.
 
 On a related note, you will soon need to support H.265/HEVC.  HEVC apparently 
 also supports an alpha channel, so it may also address that concern. (See 
 http://www.itu.int/rec/T-REC-H.265-201504-I/en)

3D support too! Not sure how we'd handle that though...


 All of this might be much easier to handle if JDK-8091063 is addressed (the 
 open sourcing of JFXMedia may assist with this).
 https://bugs.openjdk.java.net/browse/JDK-8091063
 
 The brilliant guy that filed that issue nearly seven years ago was on to 
 something :-)
 
 Then legacy formats could be provided in optional downloads and new formats 
 can be supported without the need to integrate them within the JRE code.

Yes, that would be wonderful!

-DrD-

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

[Scott Palmer]

+1 for deprecation of VP6 and clearing the way to open sourcing of JFXMedia.

On a related note, you will soon need to support H.265/HEVC.  HEVC apparently 
also supports an alpha channel, so it may also address that concern. (See 
http://www.itu.int/rec/T-REC-H.265-201504-I/en)

All of this might be much easier to handle if JDK-8091063 is addressed (the 
open sourcing of JFXMedia may assist with this).
https://bugs.openjdk.java.net/browse/JDK-8091063

The brilliant guy that filed that issue nearly seven years ago was on to 
something :-)

Then legacy formats could be provided in optional downloads and new formats can 
be supported without the need to integrate them within the JRE code.

Regards,

Scott

 On Aug 26, 2015, at 2:53 PM, David DeHaven david.deha...@oracle.com wrote:
 
 
 I am proposing we deprecate support for the VP6 video encoding format and the 
 FXM/FLV file format in JFXMedia for Java 9. The current intention is to 
 completely remove support for these components in the Java 10 timeframe. Note 
 that this is only deprecation, Java 9 will still support playback of VP6 
 video in FXM or FLV containers.
 
 The reasons in favor of deprecation:
 - Use of VP6 on the web has lost favor, it was superseded fairly quickly by 
 H.264/AVC in Flash 9 and Adobe generally recommends using H.264/AVC over it. 
 It's not even recommended for compatibility as as their Sorenson Spark 
 H.263 variant has a much longer history in Flash.
 - Tools for generating VP6 are non-trivial, even Adobe products no longer 
 support generating VP6 content out of the box, you have to install add-ons. 
 While there are free tools, none are particularly elegant or easy to use, or 
 produce sub-optimal results. We've heard no end of complaints from the 
 community about the lack of tools for VP6, so it seems a logical decision to 
 migrate away from it.
 - We have had (many) requests to add external codec support, if (that's a big 
 IF, please do NOT take this as any sort of promise or even the hope of a 
 promise!) we were to implement such a feature and if you absolutely had to 
 rely on VP6 then you would be able to provide one yourself.
 - The vp6 codec is the LAST closed source component in media, once removed 
 JFXMedia will be 100% open source. I think we can all agree this is a good 
 thing and something I personally look forward to achieving.
 
 
 The one and only reason I can think of for NOT deprecating VP6:
 - It is currently the only format (supported by JFXMedia) which supports an 
 alpha channel, though I have had thoughts on how to address that in a way 
 that would allow the use of practically any media format.
 
 
 While compelling for some use cases, it is a very niche use case and thus 
 cannot outweigh the benefits. So, this is a call out to any who may be using 
 VP6, please speak up now so we can discuss it or forever hold your peace.
 
 
 For reference, the list of supported formats in JFXMedia are in the JavaDoc 
 for javafx.scene.Media:
 https://docs.oracle.com/javase/8/javafx/api/javafx/scene/media/package-summary.html#SupportedMediaTypes
 
 -DrD-