enable fdk-aac, x262, x264 10bit and x265

Bug #1362211 reported by djcj on 2014-08-27
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
vlc (Ubuntu)
Undecided
Unassigned

Bug Description

Can you enable fdk-aac, x262, x264 10bit and x265 for Ubuntu releases? At least fdk-aac, since there's no point to keep it disabled on Ubuntu. To enable the additional x26* codecs, their source code needs to be added to the source package (so better switch versioning to native) and you have to compile static libraries with -fPIC.

djcj (djcj) wrote :
Benjamin Drung (bdrung) wrote :

We can enable libraries that are DFSG-free (therefore in main or universe) and that can be linked dynamically. Adding the source code of the libraries to the vlc source package or linking the libraries statically is a no go.

* fdk-aac is DFSG-non-free
* x262 not in the archive -> please package it as library
* x264 10bit is available in x264-10bit/libx264.so.142. Should we link against that?
* x265 not in the archive (yet) -> see http://bugs.debian.org/750817

JB VideoLAN (jb-videolan) wrote :

fdk-aac is not free software, why do you want to enable it?

djcj (djcj) wrote :

Non-free software is enabled by default on Ubuntu, so IMO there's no reason to keep it disabled (and fdk-aac has a nice quality).
Linking statically against x264-10bit is not a nice solution, but I wouldn't know a good alternative. Maybe using an rpath in the library or renaming the 10bit library to something like libx264-10bit.so.142?
Instead of adding the x262 and x264 code to the VLC source you could add additional static libraries compiled with -fPIC to the -dev packages.
BTW why exactly is fdk-aac considred non-free? To me it seems like a typical FOSS.

djcj (djcj) wrote :

In VLC fdk-aac is provided through a plugin. What about making this plugin available as a separate package?

Rémi Denis-Courmont (rdenis) wrote :

The same process would have x264-10b and x264(-8b), and also x262 linked in, even if through different VLC plugins. So I am not quite sure that rpath would help: I guess the symbols would still clash.

FDK-AAC is not GPL compatible, so the VLC plugin is not legally redistributable. You thus have to compile it yourself anyway.

djcj (djcj) wrote :

Creating a libx264-10bit.so library is really simple:
./configure --system-libx264 --enable-shared --bit-depth=10
echo SONAME=libx264-10bit.so.140 >> config.mak
make && mv x264 x264-10bit

However, VLC's configure script might only look for static libraries of x264-10bit and x262, I haven't checked that out yet.

Ubuntu already does provide a 10bit libx264 library in
/usr/lib/x86_64-linux-gnu/x264-10bit/libx264.so.142

Check yourself at: http://packages.ubuntu.com/trusty/amd64/libx264-142/filelist

The problem is that you can't have both the 8bit and the 10bit
libx264.so loaded into the same process because they define the same
symbols.

On Sat, Nov 8, 2014 at 8:58 PM, djcj <email address hidden> wrote:
> Creating a libx264-10bit.so library is really simple:
> ./configure --system-libx264 --enable-shared --bit-depth=10
> echo SONAME=libx264-10bit.so.140 >> config.mak
> make && mv x264 x264-10bit
>
> However, VLC's configure script might only look for static libraries of
> x264-10bit and x262, I haven't checked that out yet.
>
> --
> You received this bug notification because you are a member of MOTU
> Media Team, which is subscribed to vlc in Ubuntu.
> https://bugs.launchpad.net/bugs/1362211
>
> Title:
> enable fdk-aac, x262, x264 10bit and x265
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1362211/+subscriptions

--
regards,
    Reinhard

djcj (djcj) wrote :

Yes, I know about the 10-bit version, which is by the way incompatible with the provided x264 binary. I just thought that creating a separate library with the SONAME libx264-10bit.so.140 might be useful to link the VLC plugin dynamically and not against a static library. Of course, if somebody tries to link his program against libx264 and libx264-10bit at the same time it won't work.

Rémi Denis-Courmont (rdenis) wrote :

You are missing the point: the problem is with the symbols, not the library name. You cannot have two libraries with the same symbols in the same process - in this case the VLC process. So either x264 should be linked statically; I believe this is what upstream recommends. Or some trick is necessary to change the names of symbols.

Benjamin Drung (bdrung) wrote :

I have to clarify comment #2: If we want to link vlc against packages from restricted or multiverse, vlc needs to be moved to multiverse.

djcj (djcj) wrote :

I figured that linking the x262 and x26410b plugins dynamically does work. x26410b requires an rpath though, otherwise it would use the regular 8bit x264 library.

Here's the override_dh_auto_configure target I had to use:
override_dh_auto_configure:
 mkdir -p x262 x264
 cp /usr/include/x262.h /usr/include/x262_config.h x262/
 cp /usr/include/x264.h /usr/include/x264-10bit/x264_config.h x264/
 ln -s /usr/lib/$(DEB_HOST_MULTIARCH)/libx262.so x262/
 ln -s /usr/lib/$(DEB_HOST_MULTIARCH)/x264-10bit/libx264.so x264/
 dh_auto_configure -- $(confflags)

The patch for configure.ac is attached.

The attachment "link_x26x_plugins_dynamically.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Reinhard Tartler (siretart) wrote :

With this patch, how does the user select whether to encode with 8bit or
10bit depth?
On Jan 10, 2015 10:20 AM, "djcj" <email address hidden> wrote:

> I figured that linking the x262 and x26410b plugins dynamically does
> work. x26410b requires an rpath though, otherwise it would use the
> regular 8bit x264 library.
>
> Here's the override_dh_auto_configure target I had to use:
> override_dh_auto_configure:
> mkdir -p x262 x264
> cp /usr/include/x262.h /usr/include/x262_config.h x262/
> cp /usr/include/x264.h /usr/include/x264-10bit/x264_config.h x264/
> ln -s /usr/lib/$(DEB_HOST_MULTIARCH)/libx262.so x262/
> ln -s /usr/lib/$(DEB_HOST_MULTIARCH)/x264-10bit/libx264.so x264/
> dh_auto_configure -- $(confflags)
>
> The patch for configure.ac is attached.
>
> ** Patch added: "link_x26x_plugins_dynamically.patch"
>
> https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1362211/+attachment/4295298/+files/link_x26x_plugins_dynamically.patch
>
> --
> You received this bug notification because you are a member of MOTU
> Media Team, which is subscribed to vlc in Ubuntu.
> https://bugs.launchpad.net/bugs/1362211
>
> Title:
> enable fdk-aac, x262, x264 10bit and x265
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1362211/+subscriptions
>

djcj (djcj) wrote :

With this patch libx26410b_plugin.so is linked against /usr/lib/${DEB_HOST_MULTIARCH}/x264-10bit/libx264.so.140 and loading it via rpath. libx264_plugin.so loads the regular x264 library.
It seems the x264 bit depth can be set in the input/codecs settings in the VLC settings via the x264 profile (baseline, main, high, high10, ...). I didn't test it though (I prefer encoding via x264 CLI).

Reinhard Tartler (siretart) wrote :

On Sat, Jan 10, 2015 at 12:53 PM, djcj <email address hidden> wrote:
> With this patch libx26410b_plugin.so is linked against /usr/lib/${DEB_HOST_MULTIARCH}/x264-10bit/libx264.so.140 and loading it via rpath. libx264_plugin.so loads the regular x264 library.
> It seems the x264 bit depth can be set in the input/codecs settings in the VLC settings via the x264 profile (baseline, main, high, high10, ...). I didn't test it though (I prefer encoding via x264 CLI).

I don't see how this could possibly work since the two flavors of
libx264 here have clashing symbols.

--
regards,
    Reinhard

djcj (djcj) wrote :

You're right, the plugin doesn't really work because of clashing symbols. The output is always h264 8bit. 10bit can be forced if the 10bit x264 library was preloaded. libx262 is using the x264 symbols too, so it won't work either.
This makes me wonder what the purpose of these plugins is anyway.

Rémi Denis-Courmont (rdenis) wrote :

The plugins are meant to be statically linked. That's how x264 upstream recommends using x264, and that's how VLC releases on Windows are made (supporting both 8 and 10 bits).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.