[Nix-dev] ffmpeg defaults

Mathijs Kwik mathijs at bluescreen303.nl
Thu Feb 9 01:00:09 CET 2012


On Thu, Feb 9, 2012 at 12:26 AM, Arie Middelkoop <amiddelk at gmail.com> wrote:
> Also, I think that mplayer uses ffmpeg. When I recently tried to watch
> some movie with it, it didn't have the codec. That was rather
> disappointing. VLC on the other hand knew the codec out of the box. So,
> in this case, I rather have more dependencies so that it works out of
> the box...

Was it complaining about audio or video codec?
Looking at vlc's nix expression, the only extra codec it contains is
vorbis (audio). All the other codecs are handled through ffmpeg.
So I would think mplayer supports the same codecs as vlc. If not,
extending ffmpeg is probably not gonna be the answer.

Back to the original issue:
I think adding vorbis is a non-issue.
kde/gnome/gstreamer/pulseaudio/vlc all depend on it, so it's installed
anyway.
Considering ffmpeg's built-in vorbis is experimental and buggy, and
other distro's (arch, ubuntu, gentoo) still use the external one, I
think it's safe to follow.

xvid is a different story though. My system doesn't seem to have it
installed at the moment.
Playing xvid works fine, through general mpeg4 codec.
Other distros:
Arch: ffmpeg depends on xvid
Gentoo: optional via xvid useflag (off by default)
Ubuntu: off by default, available via ffmpeg-extra

It seems it's only useful for encoding at the moment, which is
probably not something that average users do a lot.
On the other hand, as a small community, if adding 800k (xvidcore) to
my installation helps others so they don't have to run a custom ffmpeg
(leading to compiling vlc, chrome, kdemultimedia locally from now on),
I'm fine with that.

Goodnight all,
Mathijs


>
> On 08-02-12 21:28, Mathijs Kwik wrote:
>> On Wed, Feb 8, 2012 at 9:05 PM, Eelco Dolstra<e.dolstra at tudelft.nl>  wrote:
>>> On 08/02/12 20:50, Lluís Batlle i Rossell wrote:
>>>> On Wed, Feb 08, 2012 at 08:38:01PM +0100, Mathijs Kwik wrote:
>>>>> +1 enable
>>>>>
>>>>> Only thing to watch mind: overlapping codecs/defaults.
>>>>> xvid decoding is probably handled by some generic mpeg4 codec at the
>>>>> moment, which might be better/worse than xvid itself.
>>>>> I don't know a whole lot about ffmpeg, so maybe this isn't an issue at
>>>>> all (probably players decide this stuff, not ffmpeg itself).
>>>>
>>>> I was caring more on encoding... ffmpeg has a 'vorbis' codec, but it's
>>>> experimental and failed to work for me. Adding 'libvorbis' makes the process
>>>> smooth. Same for xvid; I have a TV player that only understands xvid, and I'd
>>>> get benefit from xvid encoding there.
>>>
>>> In order to prevent dependency bloat we really shouldn't enable every external
>>> codec supported by ffmpeg, especially when it has builtin support...  I think
>>> I've done xvid encoding with ffmpeg/mencoder (though I did add ‘ffmpeg =
>>> pkgs.ffmpeg.override { faacSupport = true; };’ to my packageOverrides to get AAC
>>> support).
>>
>> The problem with overrides on packages like ffmpeg is that you will
>> have to build a lot from source from that moment on, as quite a lot of
>> packages depend on it.
>> I agree about keeping dependency trees slim by default, but it would
>> be great if there's an easy way to have 2 versions/flavours of a
>> package like ffmpeg, both built by the buildfarm.
>> A normal slim one, and a full blown max-functionality one. But I
>> understand this would mean building 2 versions of all dependent
>> packages as well, and exponentially more if a package depends on more
>> of those "flavourable" packages.
>>
>>>
>>> --
>>> Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/
>>> _______________________________________________
>>> nix-dev mailing list
>>> nix-dev at lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev


More information about the nix-dev mailing list