[Nix-dev] ffmpeg defaults

[Arie Middelkoop]

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

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