Keyword - VLC

Entries feed - Comments feed

Saturday, July 19 2014

VLC, Android and DVDs

DVD on Android

If you're like me, you probably have a large number of DVDs at your place.

Of course, the DVD format is outdated, but it has a few advantages:

  • Everything is available on DVDs and it's cheap to buy,
  • It's cheap to decode MPEG-2 with any CPU (even mobile),
  • It's very simple and well supported,
  • It has menus and bonuses,
  • Most patents for decoding DVDs are over (or almost),
  • It does not need an Internet connection to work.

Adding to the fact that you have probably numerous legally bought DVDs in your home, and that VLC plays DVDs since a long time, we've decided to add DVD support on VLC for Android.

It's also great when you travel, in car, trains or planes.

Continue reading...

Sunday, July 13 2014

Blu-Ray playback libraries updates (BD-J)

Triumvirat update

6 months after the first libbdplus release, and my post about the open Blu-Ray playback stack state, we've updated a bit the libraries.

We have seen, in the last weeks, the release of:

So, the three libraries of the stack have been updated with a few important features.

Continue reading...

Monday, March 31 2014

VLC for Android: take 2

Intro

VLC for Android is on the store since quite some time, and it is quite popular, notably knowing it is only a Beta release.

After more than 6 months since the last release, we've developed a new version that is changing a lot of things.

This could be mostly considered as a Second main release of VLC for Android.

The most important parts are a new UI, closer to a modern Android theme and a rewritten hardware acceleration.

Continue reading...

Thursday, November 14 2013

VLC: 2.1.1 and 2.0.9

VLC 2.1.1

So, we've released today VLC 2.1.1. It's mostly a release to fix the numerous bugs and regressions that always happen at major.0 releases.

But why are there so many regressions at every major releases of VLC?

The main two reasons are:

  • we still don't have enough people testing the prebuilt and release candidates versions...
  • our major releases cycle is too long.

While I don't know what to do for the first, we will shorten our development cycle, starting from 2.2.0.

New formats

But for once, this release introduces new features, notably a new decoder to support HEVC (H.265).

We did that because we could not ignore this major codec and introduce it only at our next major release.

We worked quite a bit on Opus and VP9, because we want to help pushing those formats.

As for HEVC, VP9 and Opus integrations are quite young, so you should expect issues or shortcomings...

Updates path

As you might have seen, we have not pushed 2.1.0 through the update system, for the reasons you've seen above.

But 2.1.1 is different and will be pushed through the update system.

Windows installer

On Windows, 2.1.1 introduces a new installer that will allow us to upgrade to future versions without asking the options at every install! 2.1.1 should be the last annoying installer that you will see on Windows.

Mac OS X 2.0.9

We did a release of source for 2.0.9, but unlike on Windows, we did binaries too for Mac OS X. Why is that?

Well, as you might have seen, we've discontinued VLC for PowerPC and Intel32 for 2.1.x. This is mostly for technical reasons, (notably to support correctly OS X.9), but also for timing reasons (there are few Intel macs that are 32bit only, and it's time consuming to support them).

So PowerPC users will upgrade to 2.0.9, where we fixed many bugs affecting them, as one would expect.

But, a contrario from what you would expect, Intel32 and Universal Binary users on 2.0.8 will be upgraded to the 2.0.9 Universal Binary.

This will allow users using the Intel32 version of VLC but running on a 64bit-capable machine to upgrade to a 64bit version of VLC. Indeed, the 64bit slice of this UB will upgrade to 2.1.1 afterwards, but not the 32bit slice which might upgrade to 2.0.10, if ever there is one :)

I hope this clears a few questions...

Wednesday, August 28 2013

VLC 2.1.0-rc1

VLC 2.1.0-rc1

I'm pleased to announce, from the VLC development team, the first release candidate of VLC media player 2.1.0, named RinceWind.

This is a major version, totally more than 7000 commits, improving a lot most parts of VLC and fixing the important issues of the 2.0.x branch.

Highlights

  • Port of the VLC engine to Mobile OS, including Android, iOS (again), WinRT. This denotes new audio and video outputs, OpenGL ES improvements, including shaders; but also work on the hardware decoding for mobile.
  • A new audio core, including rewrite of most audio output modules. This improves the stability, reactivity (no more volume change lag), volume control (logarithmic), performance, precision (up to 384kHz).
  • An important work on correct playback of new formats and old non-standard files, fixing most of the small regressions on rare formats that we've seen in the 2.0.x branch. New codecs have been added, including G2M4, MSS1/2, SCTE-27, Real Lossless or Ulead DV Audio
  • New protocols and input support have been added like Smooth Streaming, improved MPEG-DASH, improved Blu-Ray; but also a new VNC support and an AVCapture module for OSX.
  • Hardware decoders (Mac OS X, Android) and encoders (Intel QuickSync Video) were also added in this release, to focus on performance.
  • The OS X interface has seen a lot of polishing and fixes, which finishes the work started in 2.0.0 to renew the interface.
  • For developers, libVLC and most libVLC modules are now licensed under the LGPL, a copyleft license that should allow more flexibility for application developers.
  • For web developers, the webplugin has been partially rewritten and now support windowless, allowing CSS transform like 3D and overlaying objects above the video, like Flash does.
  • Many other issues fixed that I forget about.

You can get it now:

Please test it and file bugreports,

Thursday, August 1 2013

News about our WinRT port

WinRT still advances

As people who follow @videolan know, we keep working quite a bit on our port to the WinRT platforms. It is probably the port where the most effort is spent on those days, and is probably the most difficult.

The good news is that we are improving quite a bit, and we are closer to having something on the store.

Precision about VLC ports

Some people said that we stopped working on WinRT to ship VLC on iOS... This is totally wrong, because those are not the same people working on it.

VLC development is closer to a bazaar than to a cathedral building, and while the core advances altogether, people, who are volunteers, work on what they want, and on the features they want. This is very often true for VLC modules, and this is even more true for the ports to the mobile platforms.

Notably:

Therefore, doing work on one platform does not slow down the development of other platforms ports.

On the contrary, porting VLC to more platforms improves the portability of VLC, and helps finding weird bugs or misdesigns that benefit all the other ports, when they are fixed!

For example, the work on OpenGL ES for Android helped the port to iOS. Or the work on WinRT helped the normal VLC for Windows.

WinRT calls

So, last time we spoke about our advance, we had to fix 16 forbidden calls to 4 Windows dll, from 5 dlls and all the socket code. And those required WinRT direct calls from C.

We fixed most of the issues, including the WinRT static calls, meaning that we rewrote a lot of idl, idl tools and header files. We are at 5 forbidden calls (3 tonight, I hope), to 1 Windows dll, from only the VLC core. We still have the socket code to fix though.

The remaining calls are on the threading initialization, and so far, we are not able to create those WinRT objects from a C codebase. We are looking at alternatives, including using a C++ library to work-around this issue.

For the socket code, we have an idea for that too, and I hope I can share it soon to you.

As soon as we are down to 0 calls, we can upload something on the store, for the backers to test it.

Goodies

We've done another round of sending of goodies.

Therefore, if you had a certificate, a key-holder, a mug or a cone, you should have received them before the end of the week.

If you had a t-shirt or a hoodie, they might not have reached you yet. Note that, if you had one of these, the keyholder and certificate will arrive at the same time.

If you have not received your goodies, please e-mail us about it, to the email where you received your confirmation from. If you are at a total loss, please mail me or contact me :)

Sorry again for the delay, but we're doing the best we can, so far. Have fun!

- page 1 of 9