[Buildroot] [PATCH] new package: libav

[Buildroot] [PATCH] new package: libav

[Wolfram Gloger]

Hi,

This is a copy of the ffmpeg package with the names and download
changed for libav-0.7.

Why choose this fork when there is "original" ffmpeg?

- It may be the future?  I don't know, but for sure it was dreadfully
  hard to get patches into ffmpeg.

- I found that ffmpeg (at least 0.6.3) does _not_ work with minidlna
  (buildroot patch forthcoming), there are strange hangups just
  calling av_stream_info() on many ts files.
  libav worked out of the box in this context.

Signed-off-by: Wolfram Gloger <wg@malloc.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildroot-2011.05-libav.diff
Type: application/octet-stream
Size: 10730 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110701/37dc5e8a/attachment-0001.obj>

[Buildroot] [PATCH] new package: libav

[Thomas Petazzoni]

Hello Wolfram,

Thanks for your patches!

Le Fri, 01 Jul 2011 18:27:13 +0200,
Wolfram Gloger <wg@malloc.de> a ?crit :

> This is a copy of the ffmpeg package with the names and download
> changed for libav-0.7.
> 
> Why choose this fork when there is "original" ffmpeg?
> 
> - It may be the future?  I don't know, but for sure it was dreadfully
>   hard to get patches into ffmpeg.
> 
> - I found that ffmpeg (at least 0.6.3) does _not_ work with minidlna
>   (buildroot patch forthcoming), there are strange hangups just
>   calling av_stream_info() on many ts files.
>   libav worked out of the box in this context.
> 
> Signed-off-by: Wolfram Gloger <wg@malloc.de>

Could you turn this into a proper commit log message ? Could you also
send your patch inline and not as an attached file ? This make it
easier to review and comment.

If the libav package is a copy of the ffmpeg one, isn't it possible to
share the same .mk file ? We could then make them separate when/if
libav diverges from ffmpeg in a significant way.

What do you think ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] new package: libav

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> - I found that ffmpeg (at least 0.6.3) does _not_ work with minidlna
 >> (buildroot patch forthcoming), there are strange hangups just
 >> calling av_stream_info() on many ts files.
 >> libav worked out of the box in this context.
 >> 
 >> Signed-off-by: Wolfram Gloger <wg@malloc.de>

 Thomas> Could you turn this into a proper commit log message ? Could you also
 Thomas> send your patch inline and not as an attached file ? This make it
 Thomas> easier to review and comment.

Yes please - Please use git format-patch -s / git send-email

 Thomas> If the libav package is a copy of the ffmpeg one, isn't it
 Thomas> possible to share the same .mk file ? We could then make them
 Thomas> separate when/if libav diverges from ffmpeg in a significant
 Thomas> way.

I haven't followed the libav discussions in detail - Is it (currently) a
100% drop in replacement for ffmpeg? If so, perhaps we should handle it
like the modular/tinyx selection for the X server. If not, I think it
should be two completely independent packages.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] new package: libav

[Thomas Petazzoni]

Le Wed, 06 Jul 2011 07:14:18 +0200,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

> I haven't followed the libav discussions in detail - Is it (currently) a
> 100% drop in replacement for ffmpeg? If so, perhaps we should handle it
> like the modular/tinyx selection for the X server. If not, I think it
> should be two completely independent packages.

My understanding is that libav is a fork of ffmpeg. So, it will
probably become more and more different than ffmpeg, in which case
separate packages are obviously the right way of handling this.

In the mean time, as they are exactly similar (at least in terms of
build mechanism and options), I wanted to suggest doing a modular/tinyx
style of selection. We might switch to a separate package when needed.
But on the other hand, having a separate package is probably more clear.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] new package: libav

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> My understanding is that libav is a fork of ffmpeg. So, it will
 Thomas> probably become more and more different than ffmpeg, in which case
 Thomas> separate packages are obviously the right way of handling this.

 Thomas> In the mean time, as they are exactly similar (at least in terms of
 Thomas> build mechanism and options), I wanted to suggest doing a modular/tinyx
 Thomas> style of selection. We might switch to a separate package when needed.
 Thomas> But on the other hand, having a separate package is probably more clear.

Yes. Also if they both use the same binary/library names, then we need
to ensure that you cannot enable both at once.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] new package: libav

[Wolfram Gloger]

Hi,

> Could you turn this into a proper commit log message ? Could you also
> send your patch inline and not as an attached file ? This make it
> easier to review and comment.

Ok, I'll try to send it more git-compatible in the next revision
(forthcoming).

> If the libav package is a copy of the ffmpeg one, isn't it possible to
> share the same .mk file ? We could then make them separate when/if
> libav diverges from ffmpeg in a significant way.
> 
> What do you think ?

Basically I copied the .mk from ffmpeg, but it isn't purely a
s/FFmpeg/Libav/g job; the ffmpeg binary for example stays the same.

I would prefer to keep the .mk's separate for this and two more
reasons: the packages might well diverge and the duplication is not
excessive IMHO.

Regards,
Wolfram.

[Buildroot] [PATCH] new package: libav

[Thomas Petazzoni]

Le Wed, 13 Jul 2011 18:10:33 +0200,
Wolfram Gloger <wg@malloc.de> a ?crit :

> Basically I copied the .mk from ffmpeg, but it isn't purely a
> s/FFmpeg/Libav/g job; the ffmpeg binary for example stays the same.
> 
> I would prefer to keep the .mk's separate for this and two more
> reasons: the packages might well diverge and the duplication is not
> excessive IMHO.

Ok, fair enough.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] new package: libav

[Wolfram Gloger]

> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> 
> Hi,
> 
>  Thomas> My understanding is that libav is a fork of ffmpeg. So, it will
>  Thomas> probably become more and more different than ffmpeg, in which case
>  Thomas> separate packages are obviously the right way of handling this.
> 
>  Thomas> In the mean time, as they are exactly similar (at least in terms of
>  Thomas> build mechanism and options), I wanted to suggest doing a modular/tinyx
>  Thomas> style of selection. We might switch to a separate package when needed.
>  Thomas> But on the other hand, having a separate package is probably more clear.
> 
> Yes. Also if they both use the same binary/library names, then we need
> to ensure that you cannot enable both at once.

This is almost 100% the case -- the ffmpeg/ffprobe binary names are
the same, and the static library names are the same.  The dynamic lib
names carry a version number and should/will change if an
incompatibility arises.

It currently doesn't make sense to enable both packages at once, so
I'll try to add that to the buildroot patch.

Regards,
Wolfram.