caprica
commented
5 years ago Updated project README at 9a889d956c6bfd8189ab97006ddd4b8d9a838a61.
Closed caprica closed 5 years ago
caprica
commented
5 years ago Updated project README at 9a889d956c6bfd8189ab97006ddd4b8d9a838a61.
At least some interesting headline features, apart from the refactoring, e.g. so far:
529 new API for 360 degree video, build a media player that changes pitch, roll, yaw etc
527 new API for renderer discovery, e.g. you can now play to Chromecast
686 slave API (for SPU and additional/alternate audio tracks)
412 use other AWT components for video surfaces (e.g. Window, which should work on OSX), also much easier now to extend vlcj to use video surfaces from other UI frameworks like SWT
718 heavyweight embedded media players (kind of) work on OSX again, but see 718 for important limitations
378 simplified/improved native library usage (no longer uses a single instance)
694 simplified native event handling
471 new API for native dialog callbacks, you can now e.g. get prompted by VLC for credentials, or display errors or questions (like building an index when playing a corrupted AVI or MP4) - of course you don't need to display an actual dialog if you don't want, you could do things like provide credentials programmatically from a config file
711 API support for multiple logos, each with their own optional duration/opacity and optional looping. This could actually be used in earlier versions of vlcj, but there was no specific API for it
713 it is no longer necessary to explicitly enable the logo/marq VLC modules when using logo/marquee. It is also now possible to set logo and marquee before playing any media.
697 new native discovery implementation, should be simpler and easier to extend. Previously native discovery was optional and you had to explicitly incorporate it into your own application, now native discovery is an intrinsic part of creating a media player factory and so it should work for most applications right out-of-the-box on Linux, Windows and OSX. You can still provide completely bespoke implementations instead if you want
465 significant improvements to the "direct rendering" media player. A native direct byte buffer is now used rather than a Java one for the video buffers - this should provide a nice speed boost. mlock/munlock (or equivalent on other OS) are optionally used to try and and prevent GPU/CPU page swapping of the native buffer. The examples have been updated to use one less frame copy by using the byte buffer direct from an image raster rather than an intermediate int[]. The price for these improvements is some API breakage.
758 direct-rendering video is now re-implemented as a bespoke VideoSurface for the existing EmbeddedMediaPlayer, making it much easier to use for client applications. A new CallbackMediaPlayerComponent provides an easy-to-use out-of-the-box direct-rendering solution with a reasonable default implementation and a convenient plugin-point to render lightweight overlays. All of the improvements as a result of #465 (mentioned above) are carried forward. The new component can now optionally scale the video when the window is resized.
759 direct audio player is now re-implemented as an intrinsic part of the normal media player, no specialist approach is needed. You can now very easily combined the direct audio playback with direct rendering video if needed.
744 new full-screen implementation for OSX (uses a native solution via the com.sun.apple.eawt classes).
739 improvements to full-screen support generally, it is now easier to choose a default full screen strategy automatically on all platforms via the AdaptiveFullScreenStrategy.
725, #52 improvements to native event handling should give a small performance increase
756 automatic playing of sub-items (e.g. for YouTube) is now intrinsic
Other things not covered by a specific ticket:
Apart from that, old issues were cleared that were previously stalled due to architectural or API restrictions.
Despite all of these significant changes, we are still able to support JDK 1.6 with no later language or source-level (API) changes requiring a later JDK version.