Discussion:
FOMS 2009 FFmpeg outbrief
(too old to reply)
Peter Ross
2009-01-22 00:55:12 UTC
Permalink
Hi,

Last week the third Foundations of Open Media Software Workshop (FOMS 2009)
was held in Hobart, Australia. I attended to wave the FFmpeg & Xvid flag.
A number of concerns about FFmpeg were spoken of during the workshop, so
about half an hour was spent collating them. A dump of my notes is provided
below with a paraphrasing of the hurt statements.

Each year the FOMS workshop identifies community goals to progress the state
of open media software. It is neither practical nor my place to commit other
developers to do stuff. So, for the concerns that *I* agree with, *I* have
nominated some goals that *I* might work towards over the next 12-18 months.
Comments are most welcome.


1. CONCERN: Quality assurance
"It is difficult to determine which revision of the FFmpeg tree is
suitable for distributing and/or linking against.."

This comment was echoed in unison by the gnash, gstreamer, swfdec devs
whom rely on FFmpeg for decoding/encoding services.

Yes, the head revision isn't always suitable for use due to regressions.
Recent examples include the Aug'08 WMA regression (now fixed), and audio
resampling between different sample formats (my fault, still broken).

Mike Melanson's FATE effort was discussed, and seen as a good step forward
in improving QA.

There are many outstanding bugs in roundup.
Bugs get dealt with when *somebody* fixes them (stating the obvious).

Regression tests to stress the behaviour of the FFmpeg API, not just
bitstream regressions, are lacking.

Formal releases have been discussed at length by the FFmpeg community and
have not been pursued due to lack of time & effort. 'Somebody' needs to
do the hard work.

Other projects employ bug squashing events to improve quality.

GOAL: Improve QA processes
OBJECTIVES: Extend FFmpeg regression test scripts and test cases.
Contribute FATE test cases.
Fix more bugs.

2. CONCERN: API stability
"The FFmpeg API keeps changing..."

API is not backwards compatible between major API version bumps. Stuff
gets deprecated, API behaviour changes.

This makes upgrading the libav* packages on a distribution difficult,
because often the application also needs to be upgraded.

As long as new codecs, containers and concepts are being added to FFmpeg,
the API will continue to change.

Ensuring backwards compatibility is a lot of work. There are perhaps more
important things to be concerned about.

Do we need a mechanism to inform users of FFmpeg about API changes?

3. CONCERN: Authorship
"The practises used to develop FFmpeg are considered as questionable."

This is perception stems from the unwillingness of authors to associate
their names with particular blobs of code.

4. CONERN: --disable-patents.
"It would be nice to build FFmpeg with all patent encumbered
codecs/containers disabled."

Duh, this is can be achieved today by disabling everything except RAW.

Would require lots of work to tag pieces of the code with the corresponding
patent number(s) and expiry dates.

Such an effort would never be complete, or carry authority. It would
therefore be of academic value only.

Which country? Only U.S patents? Probably.

Somebody who cares about patents would need to do this.

5. CONCERN: Suitability of libavformat API

Libavformat API is considered inadequate for 'tight' integration with
gstreamer.

So presently there is a libavformat wrapper within gstreamer, but is not
used by default. Gstreamer provides its own demuxers. This prohibits
demuxing of all the gamer & special-interest formats that libavformat
supports.

A similar comment was recorded on the FFmpeg TODO/wiki list years ago
concerning MPlayer.

GOAL: Make the libavformat API more appropriate to users
OBJECTIVES: Review the TODO list item, is it still valid?
Survey existing libavformat users; gather API requirements.


Cheers,

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
Jason Garrett-Glaser
2009-01-22 01:23:09 UTC
Permalink
Post by Peter Ross
4. CONERN: --disable-patents.
"It would be nice to build FFmpeg with all patent encumbered
codecs/containers disabled."
Duh, this is can be achieved today by disabling everything except RAW.
Would require lots of work to tag pieces of the code with the corresponding
patent number(s) and expiry dates.
Such an effort would never be complete, or carry authority. It would
therefore be of academic value only.
Which country? Only U.S patents? Probably.
Somebody who cares about patents would need to do this.
I think such an option, even if someone was willing to do it, would be
completely antithetical and contrary to the goals of the ffmpeg
project. If Xiph or whoever want this sort of thing, they can
maintain it themselves and continue to doom themselves to utter
irrelevance while ffmpeg continues doing actual development on things
the rest of the world care about.

Dark Shikari
Justin Ruggles
2009-01-22 01:48:47 UTC
Permalink
Post by Jason Garrett-Glaser
Post by Peter Ross
4. CONERN: --disable-patents.
"It would be nice to build FFmpeg with all patent encumbered
codecs/containers disabled."
Duh, this is can be achieved today by disabling everything except RAW.
Would require lots of work to tag pieces of the code with the corresponding
patent number(s) and expiry dates.
Such an effort would never be complete, or carry authority. It would
therefore be of academic value only.
Which country? Only U.S patents? Probably.
Somebody who cares about patents would need to do this.
I think such an option, even if someone was willing to do it, would be
completely antithetical and contrary to the goals of the ffmpeg
project. If Xiph or whoever want this sort of thing, they can
maintain it themselves and continue to doom themselves to utter
irrelevance while ffmpeg continues doing actual development on things
the rest of the world care about.
how about --probably-patent-safe-but-hire-a-lawyer-if-you-really-care

;)

but really, i completely agree with Dark Shikari. the only person who
should care about the "acedemic value" would be a patent lawyer. if
someone was really concerned about patents and decided to rely on some
list we might come up with, they would be looking to the wrong place.

-Justin
François Revol
2009-01-22 01:39:35 UTC
Permalink
Hi,

Interesting,
Post by Peter Ross
1. CONCERN: Quality assurance
2. CONCERN: API stability
With svn it should be possible to maintain a stable branch...
Post by Peter Ross
4. CONERN: --disable-patents.
"It would be nice to build FFmpeg with all patent encumbered
codecs/containers disabled."
This would imply endorsement of software patents by FFmpeg developers,
which at least for me is not going to happen.
Post by Peter Ross
Duh, this is can be achieved today by disabling everything except RAW.
Exactly, so who cares ?
Post by Peter Ross
5. CONCERN: Suitability of libavformat API
Libavformat API is considered inadequate for 'tight' integration with
gstreamer.
I remember writing an lavf demuxer addon for BeOS, but never finished
it because the seeking semantics were not compatible, lavf seeked the
whole stream at once, while BeOS handles seeking on a per track basis.
It worked very well except for streaming...

I suppose it's the same for gstreamer.

François.
Dan Dennedy
2009-01-23 16:57:36 UTC
Permalink
A comment on libavformat from MLT dev (me)...
Post by François Revol
Post by Peter Ross
5. CONCERN: Suitability of libavformat API
Libavformat API is considered inadequate for 'tight' integration with
gstreamer.
I remember writing an lavf demuxer addon for BeOS, but never finished
it because the seeking semantics were not compatible, lavf seeked the
whole stream at once, while BeOS handles seeking on a per track basis.
It worked very well except for streaming...
I suppose it's the same for gstreamer.
99% of MLT users use libavformat for handling 99% of its audio/video
files where the primary applications are video editing (kdenlive) and
automated playout. Of course, it is not perfect on everything, but it
works good for a lot of files. We use separate AV contexts for audio
vs. video, which is not optimal, but works to support independent
track seeking.

Also, FWIW, I am not concerned about any of the other concerns raised.
Keep up the great work and have fun!
--
+-DRD-+
Michael Niedermayer
2009-01-23 16:59:19 UTC
Permalink
Post by Dan Dennedy
A comment on libavformat from MLT dev (me)...
Post by François Revol
Post by Peter Ross
5. CONCERN: Suitability of libavformat API
Libavformat API is considered inadequate for 'tight' integration with
gstreamer.
I remember writing an lavf demuxer addon for BeOS, but never finished
it because the seeking semantics were not compatible, lavf seeked the
whole stream at once, while BeOS handles seeking on a per track basis.
It worked very well except for streaming...
I suppose it's the same for gstreamer.
99% of MLT users use libavformat for handling 99% of its audio/video
files where the primary applications are video editing (kdenlive) and
automated playout. Of course, it is not perfect on everything, but it
works good for a lot of files. We use separate AV contexts for audio
vs. video, which is not optimal, but works to support independent
track seeking.
Could you explain me _why_ you do independent track seeking?
What would fail if you did not?

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
Mike Melanson
2009-01-22 03:13:26 UTC
Permalink
Post by Peter Ross
Hi,
Last week the third Foundations of Open Media Software Workshop (FOMS 2009)
was held in Hobart, Australia. I attended to wave the FFmpeg & Xvid flag.
A number of concerns about FFmpeg were spoken of during the workshop, so
about half an hour was spent collating them. A dump of my notes is provided
below with a paraphrasing of the hurt statements.
Thanks for taking the initiative on this. Executive summary: "Same s***,
different conference." :) (Note to the LinuxTag-FFmpeg crew: that might
actually make a good banner for this year's booth.)
Post by Peter Ross
Mike Melanson's FATE effort was discussed, and seen as a good step forward
in improving QA.
Whooo! I matter! :)
Post by Peter Ross
There are many outstanding bugs in roundup.
Bugs get dealt with when *somebody* fixes them (stating the obvious).
Thanks for laying out the reality on this one.
Post by Peter Ross
Regression tests to stress the behaviour of the FFmpeg API, not just
bitstream regressions, are lacking.
Indeed. And I was also thinking that FFmpeg should come with a number of
smaller sample programs, rather than one mega-example demonstrating the
API. It might make the program less intimidating (assuming that devs
want that) while also facilitating automated testing.
Post by Peter Ross
Formal releases have been discussed at length by the FFmpeg community and
have not been pursued due to lack of time & effort. 'Somebody' needs to
do the hard work.
I've been undertaking a clandestine effort to push this through. But I
want something like 99% test coverage in FATE before it happens, though.
Post by Peter Ross
2. CONCERN: API stability
"The FFmpeg API keeps changing..."
API is not backwards compatible between major API version bumps. Stuff
gets deprecated, API behaviour changes.
This makes upgrading the libav* packages on a distribution difficult,
because often the application also needs to be upgraded.
As long as new codecs, containers and concepts are being added to FFmpeg,
the API will continue to change.
Ensuring backwards compatibility is a lot of work. There are perhaps more
important things to be concerned about.
Do we need a mechanism to inform users of FFmpeg about API changes?
Releases should at least partially obviate the problem.
Post by Peter Ross
3. CONCERN: Authorship
"The practises used to develop FFmpeg are considered as questionable."
This is perception stems from the unwillingness of authors to associate
their names with particular blobs of code.
I hope you pointed these people to CREDITS.
Post by Peter Ross
4. CONERN: --disable-patents.
"It would be nice to build FFmpeg with all patent encumbered
codecs/containers disabled."
Duh, this is can be achieved today by disabling everything except RAW.
Echoing what other responders have indicated: Stick to raw, uncompressed
data if you have the slightest paranoia about patents. If you think
about it hard enough, you will be able to envision a doomsday scenario
where just about any format is restricted (think about it: it's
generally accepted that WAV and AVI formats are actually "Microsoft WAV"
and "Microsoft AVI" formats; should we get MS' permission before writing
code to manipulate them?).
--
-Mike Melanson
Stefano Sabatini
2009-01-22 11:12:55 UTC
Permalink
Post by Mike Melanson
Post by Peter Ross
Hi,
Last week the third Foundations of Open Media Software Workshop (FOMS 2009)
was held in Hobart, Australia. I attended to wave the FFmpeg & Xvid flag.
A number of concerns about FFmpeg were spoken of during the workshop, so
about half an hour was spent collating them. A dump of my notes is provided
below with a paraphrasing of the hurt statements.
[...]
Post by Mike Melanson
Post by Peter Ross
2. CONCERN: API stability
"The FFmpeg API keeps changing..."
API is not backwards compatible between major API version bumps. Stuff
gets deprecated, API behaviour changes.
This makes upgrading the libav* packages on a distribution difficult,
because often the application also needs to be upgraded.
As long as new codecs, containers and concepts are being added to FFmpeg,
the API will continue to change.
Ensuring backwards compatibility is a lot of work. There are perhaps more
important things to be concerned about.
Do we need a mechanism to inform users of FFmpeg about API changes?
It's worthy to note that backward compatibility breaker API changes
only happen at major bumps, which are not so frequent (I can remember
just two (lavc and lavf) in two years of activity on this project).

We could have a changelog with all the API changes (e.g. functions
deleted, functions added) that we could compile every time we modify
it.

This way the user will be able to understand with O(n) steps which are
the changes to be performed on its own code when it has to switch from
libav* from version X -> Y.
Post by Mike Melanson
Releases should at least partially obviate the problem.
Post by Peter Ross
3. CONCERN: Authorship
"The practises used to develop FFmpeg are considered as questionable."
This is perception stems from the unwillingness of authors to associate
their names with particular blobs of code.
I hope you pointed these people to CREDITS.
This is not clear to me, which is the problem? Shouldn't svn annotate
issue exactly that?

[...]

Regards.
--
FFmpeg = Frenzy Friendly Multimedia Plastic Empowered Game
Stefano Sabatini
2009-01-22 11:19:11 UTC
Permalink
[...]
Post by Stefano Sabatini
Post by Mike Melanson
Post by Peter Ross
3. CONCERN: Authorship
"The practises used to develop FFmpeg are considered as questionable."
This is perception stems from the unwillingness of authors to associate
their names with particular blobs of code.
I hope you pointed these people to CREDITS.
This is not clear to me, which is the problem? Shouldn't svn annotate
issue exactly that?
Never mind, got it...

[...]

Regards.
--
FFmpeg = Fierce Faboulous Mere Proud Exuberant Governor
Robert Swain
2009-01-23 07:20:08 UTC
Permalink
Post by Stefano Sabatini
Post by Mike Melanson
Post by Peter Ross
Hi,
Last week the third Foundations of Open Media Software Workshop (FOMS 2009)
was held in Hobart, Australia. I attended to wave the FFmpeg & Xvid flag.
A number of concerns about FFmpeg were spoken of during the workshop, so
about half an hour was spent collating them. A dump of my notes is provided
below with a paraphrasing of the hurt statements.
[...]
Post by Mike Melanson
Post by Peter Ross
2. CONCERN: API stability
"The FFmpeg API keeps changing..."
API is not backwards compatible between major API version bumps. Stuff
gets deprecated, API behaviour changes.
This makes upgrading the libav* packages on a distribution difficult,
because often the application also needs to be upgraded.
As long as new codecs, containers and concepts are being added to FFmpeg,
the API will continue to change.
Ensuring backwards compatibility is a lot of work. There are perhaps more
important things to be concerned about.
Do we need a mechanism to inform users of FFmpeg about API changes?
It's worthy to note that backward compatibility breaker API changes
only happen at major bumps, which are not so frequent (I can remember
just two (lavc and lavf) in two years of activity on this project).
We could have a changelog with all the API changes (e.g. functions
deleted, functions added) that we could compile every time we modify
it.
This way the user will be able to understand with O(n) steps which are
the changes to be performed on its own code when it has to switch from
libav* from version X -> Y.
Post by Mike Melanson
Releases should at least partially obviate the problem.
I think this is an excellent suggestion by Stefano. I always envisaged
this happening when we made releases but if API changes only occur
when bumping the major version number, I think it would be wise to
document any API changes in some file _at commit time_ as Stefano
suggests, underneath the next major API number.

I really think this should be a rule that is enforced and kept on top
of from now on. Then when people claim that the FFmpeg library APIs
are always changing, we can point them to some evidence of how much it
changes and what they need to do.

There are other things we should probably pick up on and consider as
new mandatory practises in this thread too.

Best Regards,
Rob
Luca Abeni
2009-01-22 11:34:57 UTC
Permalink
On Wed, 2009-01-21 at 19:13 -0800, Mike Melanson wrote:
[...]
Post by Mike Melanson
Indeed. And I was also thinking that FFmpeg should come with a number of
smaller sample programs, rather than one mega-example demonstrating the
API. It might make the program less intimidating (assuming that devs
want that) while also facilitating automated testing.
I fully agree on the need for small (and maybe more focused) examples
about how to use the API. For example, I often point people to
"output_example.c", but most of them manage to read the "wrong
part" (meaning, irrelevant for their needs) of the code ;-)

I planned since some time ago to start writing short and self-contained
examples, but I never found the time... I'll be busy until mid february,
but then I think I'll start this mini-project.


Luca
Robert Swain
2009-01-23 07:15:31 UTC
Permalink
Post by Mike Melanson
Post by Peter Ross
Last week the third Foundations of Open Media Software Workshop (FOMS 2009)
was held in Hobart, Australia. I attended to wave the FFmpeg & Xvid flag.
A number of concerns about FFmpeg were spoken of during the workshop, so
about half an hour was spent collating them. A dump of my notes is provided
below with a paraphrasing of the hurt statements.
Thanks for taking the initiative on this. Executive summary: "Same s***,
different conference." :) (Note to the LinuxTag-FFmpeg crew: that might
actually make a good banner for this year's booth.)
I think they wouldn't necessarily appreciate that. :) Amusing though.
Post by Mike Melanson
Post by Peter Ross
3. CONCERN: Authorship
"The practises used to develop FFmpeg are considered as questionable."
This is perception stems from the unwillingness of authors to associate
their names with particular blobs of code.
I hope you pointed these people to CREDITS.
And copyrights within files. And MAINTAINERS. And...

Sometimes it's not a good idea to associate a person with some code
just because that person does not want to receive harassment from any
legal entities looking to cause trouble. As noted by Michael.

Regards,
Rob
Jean-Michel Pouré
2009-01-22 08:17:21 UTC
Permalink
Post by Peter Ross
"It would be nice to build FFmpeg with all patent encumbered
codecs/containers disabled."
Patents are only claims. Registering a patent is not a proof that the
patent is valid. Also, in many countries including Europe, patents
cannot apply on algorithm or when reverse engeneering is needed to read
your own files, for example camcorder files.

A lot of companies are registering would-be patents only to slow-down
innovation or acquire the work of others. Disabling patent claims would
mean accepting would-be claims.

So please don't come-up with an issue that you don't seem to understand.
Benjamin Larsson
2009-01-22 10:30:21 UTC
Permalink
Post by Peter Ross
Hi,
Last week the third Foundations of Open Media Software Workshop (FOMS 2009)
was held in Hobart, Australia. I attended to wave the FFmpeg & Xvid flag.
A number of concerns about FFmpeg were spoken of during the workshop, so
about half an hour was spent collating them. A dump of my notes is provided
below with a paraphrasing of the hurt statements.
Each year the FOMS workshop identifies community goals to progress the state
of open media software. It is neither practical nor my place to commit other
developers to do stuff. So, for the concerns that *I* agree with, *I* have
nominated some goals that *I* might work towards over the next 12-18 months.
Comments are most welcome.
1. CONCERN: Quality assurance
"It is difficult to determine which revision of the FFmpeg tree is
suitable for distributing and/or linking against.."
This comment was echoed in unison by the gnash, gstreamer, swfdec devs
whom rely on FFmpeg for decoding/encoding services.
Yes, the head revision isn't always suitable for use due to regressions.
Recent examples include the Aug'08 WMA regression (now fixed), and audio
resampling between different sample formats (my fault, still broken).
Mike Melanson's FATE effort was discussed, and seen as a good step forward
in improving QA.
There are many outstanding bugs in roundup.
Bugs get dealt with when *somebody* fixes them (stating the obvious).
Regression tests to stress the behaviour of the FFmpeg API, not just
bitstream regressions, are lacking.
Formal releases have been discussed at length by the FFmpeg community and
have not been pursued due to lack of time & effort. 'Somebody' needs to
do the hard work.
Other projects employ bug squashing events to improve quality.
GOAL: Improve QA processes
OBJECTIVES: Extend FFmpeg regression test scripts and test cases.
Contribute FATE test cases.
Fix more bugs.
A bug squash week every now and then should be doable. And regarding
releases we should atleast put together a roadmap for one. And then I
think we should adopt the wine method of releasing. But to do that we
need better testing of the code.
Post by Peter Ross
2. CONCERN: API stability
"The FFmpeg API keeps changing..."
API is not backwards compatible between major API version bumps. Stuff
gets deprecated, API behaviour changes.
This makes upgrading the libav* packages on a distribution difficult,
because often the application also needs to be upgraded.
As long as new codecs, containers and concepts are being added to FFmpeg,
the API will continue to change.
Err, no (for codec and containers).
Post by Peter Ross
Ensuring backwards compatibility is a lot of work. There are perhaps more
important things to be concerned about.
Do we need a mechanism to inform users of FFmpeg about API changes?
We have the mechanism, the version numbers.
Post by Peter Ross
3. CONCERN: Authorship
"The practises used to develop FFmpeg are considered as questionable."
This is perception stems from the unwillingness of authors to associate
their names with particular blobs of code.
Well the license is what matters in most part of the world.
Post by Peter Ross
4. CONERN: --disable-patents.
"It would be nice to build FFmpeg with all patent encumbered
codecs/containers disabled."
Duh, this is can be achieved today by disabling everything except RAW.
Would require lots of work to tag pieces of the code with the corresponding
patent number(s) and expiry dates.
Such an effort would never be complete, or carry authority. It would
therefore be of academic value only.
Which country? Only U.S patents? Probably.
Somebody who cares about patents would need to do this.
We had this before and it is not possible to maintain. With the
exception that of letting it disable everything.
Post by Peter Ross
5. CONCERN: Suitability of libavformat API
Libavformat API is considered inadequate for 'tight' integration with
gstreamer.
So presently there is a libavformat wrapper within gstreamer, but is not
used by default. Gstreamer provides its own demuxers. This prohibits
demuxing of all the gamer & special-interest formats that libavformat
supports.
A similar comment was recorded on the FFmpeg TODO/wiki list years ago
concerning MPlayer.
GOAL: Make the libavformat API more appropriate to users
OBJECTIVES: Review the TODO list item, is it still valid?
Survey existing libavformat users; gather API requirements.
VLC also rolls their own demuxers so I guess it has some valid points.
Post by Peter Ross
Cheers,
-- Peter
MvH
Benjamin Larsson
Jean-Baptiste Kempf
2009-01-22 11:31:24 UTC
Permalink
Post by Benjamin Larsson
Post by Peter Ross
5. CONCERN: Suitability of libavformat API
Libavformat API is considered inadequate for 'tight' integration with
gstreamer.
So presently there is a libavformat wrapper within gstreamer, but is not
used by default. Gstreamer provides its own demuxers. This prohibits
demuxing of all the gamer & special-interest formats that libavformat
supports.
VLC also rolls their own demuxers so I guess it has some valid points.
VLC has his own limited subset of demuxers but has also a working demuxer module
that use libavformat. This doesn't prevent VLC from reading the
"special-interest formats that libavformat support", nor FLV, MXF, GXF
files where there isn't a VLC counterpart.

Best Regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/
Diego Biurrun
2009-01-22 14:06:51 UTC
Permalink
Post by Benjamin Larsson
Post by Peter Ross
1. CONCERN: Quality assurance
[...]
Other projects employ bug squashing events to improve quality.
GOAL: Improve QA processes
OBJECTIVES: Extend FFmpeg regression test scripts and test cases.
Contribute FATE test cases.
Fix more bugs.
A bug squash week every now and then should be doable.
It sounds like a great idea in fact. Let's schedule one right away.

How about the weekend at the end of January?
Post by Benjamin Larsson
And regarding
releases we should atleast put together a roadmap for one.
What do you want to see in such a roadmap?
Post by Benjamin Larsson
And then I think we should adopt the wine method of releasing.
What is that method? A quick search on Google revealed nothing.
Post by Benjamin Larsson
Post by Peter Ross
5. CONCERN: Suitability of libavformat API
Libavformat API is considered inadequate for 'tight' integration with
gstreamer.
A similar comment was recorded on the FFmpeg TODO/wiki list years ago
concerning MPlayer.
GOAL: Make the libavformat API more appropriate to users
OBJECTIVES: Review the TODO list item, is it still valid?
Survey existing libavformat users; gather API requirements.
VLC also rolls their own demuxers so I guess it has some valid points.
Isn't this basically historic? MPlayer also has its own set of
demuxers, which are simply older than the libavformat demuxers.
Switching demuxers now requires overcoming gravity and exchanging a
well-known set of bugs for an unknown set. This set may possibly be
smaller, but still it may entail regressions..

Diego
compn
2009-01-22 15:34:22 UTC
Permalink
Post by Diego Biurrun
Post by Benjamin Larsson
Post by Peter Ross
5. CONCERN: Suitability of libavformat API
Libavformat API is considered inadequate for 'tight' integration with
gstreamer.
A similar comment was recorded on the FFmpeg TODO/wiki list years ago
concerning MPlayer.
GOAL: Make the libavformat API more appropriate to users
OBJECTIVES: Review the TODO list item, is it still valid?
Survey existing libavformat users; gather API requirements.
VLC also rolls their own demuxers so I guess it has some valid points.
Isn't this basically historic? MPlayer also has its own set of
demuxers, which are simply older than the libavformat demuxers.
Switching demuxers now requires overcoming gravity and exchanging a
well-known set of bugs for an unknown set. This set may possibly be
smaller, but still it may entail regressions..
i think the lavf asf demuxer could be used in default by mplayer, need
more testing.

mplayer now uses lavf mp4 demuxer by default. the only big bug i can
see is that the binary svq3 and qdm2 (and probably all binary codecs)
are broken (extradata problem?).

mkv demuxer should be switched to lavf, so aurel does not have to
maintain both of them. as soon as ffmpeg gets full subtitle support.

lavf avi demuxer had trouble with non-interleaved files? or was that
fixed?

-compn
Carl Eugen Hoyos
2009-01-22 15:53:23 UTC
Permalink
Post by compn
mplayer now uses lavf mp4 demuxer by default. the only big bug i can
see is that the binary svq3 and qdm2 (and probably all binary codecs)
are broken (extradata problem?).
Seeking before beginning (which is not unusual using MPlayer and well supported
by the mov native demuxer) does not work:
http://roundup.mplayerhq.hu/roundup/ffmpeg/issue613

Carl Eugen
Måns Rullgård
2009-01-22 15:57:01 UTC
Permalink
Post by Carl Eugen Hoyos
Post by compn
mplayer now uses lavf mp4 demuxer by default. the only big bug i can
see is that the binary svq3 and qdm2 (and probably all binary codecs)
are broken (extradata problem?).
Seeking before beginning (which is not unusual using MPlayer and
I don't see how such an operation could possibly work. It could
fail in a number of different ways, but never actually do what was
asked, which is a typical definition of "work".
--
Måns Rullgård
***@mansr.com
Carl Eugen Hoyos
2009-01-22 16:17:17 UTC
Permalink
Post by Måns Rullgård
Post by Carl Eugen Hoyos
Post by compn
mplayer now uses lavf mp4 demuxer by default. the only big bug i can
see is that the binary svq3 and qdm2 (and probably all binary codecs)
are broken (extradata problem?).
Seeking before beginning (which is not unusual using MPlayer and
I don't see how such an operation could possibly work. It could
fail in a number of different ways, but never actually do what was
asked, which is a typical definition of "work".
Then please test mplayer with -demuxer mov. It (reliably) shows the first frame
of the movie and does not report problems.
-demxuer lavf often reads the whole file, decides that no recovery is possible,
prints a few errors and exits.

(If you just wanted to point out bad usage of the English language by saying
"seeking before beginning", just ignore this message.)

Carl Eugen
Baptiste Coudurier
2009-01-22 20:40:31 UTC
Permalink
Hi Carl Eugen,
Post by Carl Eugen Hoyos
Post by Måns Rullgård
Post by Carl Eugen Hoyos
Post by compn
mplayer now uses lavf mp4 demuxer by default. the only big bug i can
see is that the binary svq3 and qdm2 (and probably all binary codecs)
are broken (extradata problem?).
Seeking before beginning (which is not unusual using MPlayer and
I don't see how such an operation could possibly work. It could
fail in a number of different ways, but never actually do what was
asked, which is a typical definition of "work".
Then please test mplayer with -demuxer mov. It (reliably) shows the first frame
of the movie and does not report problems.
-demxuer lavf often reads the whole file, decides that no recovery is possible,
prints a few errors and exits.
Yes this is true, however "mplayer" is asking for a "negative"
timestamp. Demuxer returns an _error_, why isn't this correclty handled ?

Also, yes, retrying with generic seeking is odd, and I proposed a patch
a long time ago (21/04/2007), it was discussed in:
[Ffmpeg-devel] [RFC] av_seek_frame behaviour

I still maintain that each demuxer having a seek function should handle
fallback to generic internally if wanted/needed, not av_seek_frame, this
means that if demuxer seek function returned error, av_seek_frame _must_
return this error IMHO, not trying to fall back on generic.

I don't think I have objection with negative timestamp being reset to 0
however.

[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer http://www.ffmpeg.org
Ronald S. Bultje
2009-01-22 20:43:07 UTC
Permalink
Hi,

On Thu, Jan 22, 2009 at 3:40 PM, Baptiste Coudurier
Post by Baptiste Coudurier
I still maintain that each demuxer having a seek function should handle
fallback to generic internally if wanted/needed, not av_seek_frame, this
means that if demuxer seek function returned error, av_seek_frame _must_
return this error IMHO, not trying to fall back on generic.
I 100% support this.

Ronald
Baptiste Coudurier
2009-01-27 06:17:11 UTC
Permalink
Hi Carl Eugen,
Post by Baptiste Coudurier
Hi Carl Eugen,
Post by Carl Eugen Hoyos
Post by Måns Rullgård
Post by Carl Eugen Hoyos
Post by compn
mplayer now uses lavf mp4 demuxer by default. the only big
bug i can see is that the binary svq3 and qdm2 (and probably
all binary codecs) are broken (extradata problem?).
Seeking before beginning (which is not unusual using MPlayer
I don't see how such an operation could possibly work. It could
fail in a number of different ways, but never actually do what
was asked, which is a typical definition of "work".
Then please test mplayer with -demuxer mov. It (reliably) shows the
first frame of the movie and does not report problems. -demxuer
lavf often reads the whole file, decides that no recovery is
possible, prints a few errors and exits.
Yes this is true, however "mplayer" is asking for a "negative"
timestamp. Demuxer returns an _error_, why isn't this correclty handled ?
Also, yes, retrying with generic seeking is odd, and I proposed a
[Ffmpeg-devel] [RFC] av_seek_frame behaviour
I still maintain that each demuxer having a seek function should
handle fallback to generic internally if wanted/needed, not
av_seek_frame, this means that if demuxer seek function returned
error, av_seek_frame _must_ return this error IMHO, not trying to
fall back on generic.
I don't think I have objection with negative timestamp being reset to
0 however.
Demuxer now seek at 0 when negative timestamp is requested. Could you
please check that everything is fine ? Thanks.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer http://www.ffmpeg.org
Uoti Urpala
2009-01-22 16:59:12 UTC
Permalink
Post by Måns Rullgård
Post by Carl Eugen Hoyos
Post by compn
mplayer now uses lavf mp4 demuxer by default. the only big bug i can
see is that the binary svq3 and qdm2 (and probably all binary codecs)
are broken (extradata problem?).
Seeking before beginning (which is not unusual using MPlayer and
I don't see how such an operation could possibly work. It could
fail in a number of different ways, but never actually do what was
asked, which is a typical definition of "work".
Any video player will want about the same semantics: if the seek
position goes before the start of the file then seek to the start. That
is well defined and lavf could implement it.

What's considered the correct way to get those semantics with the
current API? Retry all failed seeks without AVSEEK_FLAG_BACKWARD?
Michael Niedermayer
2009-01-22 15:56:28 UTC
Permalink
On Thu, Jan 22, 2009 at 10:34:22AM -0500, compn wrote:
[...]
Post by compn
lavf avi demuxer had trouble with non-interleaved files? or was that
fixed?
iam not aware of a problem with ni avis

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator
Baptiste Coudurier
2009-01-22 20:33:15 UTC
Permalink
Post by compn
Post by Diego Biurrun
Post by Benjamin Larsson
Post by Peter Ross
5. CONCERN: Suitability of libavformat API
Libavformat API is considered inadequate for 'tight' integration with
gstreamer.
A similar comment was recorded on the FFmpeg TODO/wiki list years ago
concerning MPlayer.
GOAL: Make the libavformat API more appropriate to users
OBJECTIVES: Review the TODO list item, is it still valid?
Survey existing libavformat users; gather API requirements.
VLC also rolls their own demuxers so I guess it has some valid points.
Isn't this basically historic? MPlayer also has its own set of
demuxers, which are simply older than the libavformat demuxers.
Switching demuxers now requires overcoming gravity and exchanging a
well-known set of bugs for an unknown set. This set may possibly be
smaller, but still it may entail regressions..
i think the lavf asf demuxer could be used in default by mplayer, need
more testing.
mplayer now uses lavf mp4 demuxer by default. the only big bug i can
see is that the binary svq3 and qdm2 (and probably all binary codecs)
are broken (extradata problem?).
Yes, it was since the beginning.
Either mplayer reconstructs full stsd to be passed to the codec, or
libavformat export full stsd in extradata, the latter has also the
advantage of exporting all informations so the user can parse them if
wanted.

Im not against the latter at all, but this requires some changes in
ffmpeg decoders to handle both formats of extradata (svq3 decoder
already expects full stsd).

[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer http://www.ffmpeg.org
Diego Biurrun
2009-01-26 15:31:40 UTC
Permalink
Post by Diego Biurrun
Post by Benjamin Larsson
Post by Peter Ross
1. CONCERN: Quality assurance
[...]
Other projects employ bug squashing events to improve quality.
GOAL: Improve QA processes
OBJECTIVES: Extend FFmpeg regression test scripts and test cases.
Contribute FATE test cases.
Fix more bugs.
A bug squash week every now and then should be doable.
It sounds like a great idea in fact. Let's schedule one right away.
How about the weekend at the end of January?
Any takers for a bug squashing weeken scheduled for this weekend or
the next, later?
Post by Diego Biurrun
Post by Benjamin Larsson
And regarding releases we should atleast put together a roadmap for one.
What do you want to see in such a roadmap?
Post by Benjamin Larsson
And then I think we should adopt the wine method of releasing.
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?

Diego
Ronald S. Bultje
2009-01-26 15:42:07 UTC
Permalink
Hi Diego,
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
And then I think we should adopt the wine method of releasing.
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?
It is a blind way of releasing weekly or monthly snapshots of the
current trunk with essentially no guaranteed QA&co. The idea is to get
it out so people use it.

Since projects like mplayer, xine and gst already use svn snapshots, I
think there is no point in doing this.

Ronald
Måns Rullgård
2009-01-26 15:52:23 UTC
Permalink
Post by Ronald S. Bultje
Hi Diego,
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
And then I think we should adopt the wine method of releasing.
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?
It is a blind way of releasing weekly or monthly snapshots of the
current trunk with essentially no guaranteed QA&co. The idea is to get
it out so people use it.
We have a public svn repository, and we put daily snapshots on the web
server. Isn't that enough?
--
Måns Rullgård
***@mansr.com
Ronald S. Bultje
2009-01-26 16:01:27 UTC
Permalink
Hi Mans,
Post by Måns Rullgård
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Diego Biurrun
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?
It is a blind way of releasing weekly or monthly snapshots of the
current trunk with essentially no guaranteed QA&co. The idea is to get
it out so people use it.
We have a public svn repository, and we put daily snapshots on the web
server. Isn't that enough?
It addresses the complaint that there's no releases.

However, I honestly don't think making releases will change the
complaining about ffmpeg at all. It would be so good if they would
interact in and contribute to this discussion.

Ronald
Måns Rullgård
2009-01-26 16:14:38 UTC
Permalink
Post by Ronald S. Bultje
Hi Mans,
Post by Måns Rullgård
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Diego Biurrun
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?
It is a blind way of releasing weekly or monthly snapshots of the
current trunk with essentially no guaranteed QA&co. The idea is to get
it out so people use it.
We have a public svn repository, and we put daily snapshots on the web
server. Isn't that enough?
It addresses the complaint that there's no releases.
So going from daily snapshots to weekly would make these people shut
up?
Post by Ronald S. Bultje
However, I honestly don't think making releases will change the
complaining about ffmpeg at all. It would be so good if they would
interact in and contribute to this discussion.
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
--
Måns Rullgård
***@mansr.com
Robert Swain
2009-01-26 16:26:37 UTC
Permalink
Post by Måns Rullgård
Post by Ronald S. Bultje
Post by Måns Rullgård
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Diego Biurrun
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?
It is a blind way of releasing weekly or monthly snapshots of the
current trunk with essentially no guaranteed QA&co. The idea is to get
it out so people use it.
We have a public svn repository, and we put daily snapshots on the web
server. Isn't that enough?
It addresses the complaint that there's no releases.
So going from daily snapshots to weekly would make these people shut
up?
This is silly and not productive.
Post by Måns Rullgård
Post by Ronald S. Bultje
However, I honestly don't think making releases will change the
complaining about ffmpeg at all. It would be so good if they would
interact in and contribute to this discussion.
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
The apathetic approach won't encourage progress. I strongly recommend
documenting the API changes and how to transition between them,
coupled with svn revisions of the version bumps as suggested by
Stefano earlier in the thread. This gives some evidence to argue
against the claims rather than us saying that it's invalid and them
complaining that it's unstable. Eventually this knowledgebase will be
popularised if we keep pushing it and the fud will stop.

Regards,
Rob
Dominik 'Rathann' Mierzejewski
2009-01-26 16:51:24 UTC
Permalink
Post by Robert Swain
Post by Måns Rullgård
Post by Ronald S. Bultje
Post by Måns Rullgård
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Diego Biurrun
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?
It is a blind way of releasing weekly or monthly snapshots of the
current trunk with essentially no guaranteed QA&co. The idea is to get
it out so people use it.
We have a public svn repository, and we put daily snapshots on the web
server. Isn't that enough?
It addresses the complaint that there's no releases.
So going from daily snapshots to weekly would make these people shut
up?
This is silly and not productive.
Post by Måns Rullgård
Post by Ronald S. Bultje
However, I honestly don't think making releases will change the
complaining about ffmpeg at all. It would be so good if they would
interact in and contribute to this discussion.
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
The apathetic approach won't encourage progress. I strongly recommend
documenting the API changes and how to transition between them,
coupled with svn revisions of the version bumps as suggested by
Stefano earlier in the thread. This gives some evidence to argue
against the claims rather than us saying that it's invalid and them
complaining that it's unstable. Eventually this knowledgebase will be
popularised if we keep pushing it and the fud will stop.
I strongly agree. There's still a lot of misconception originating from
over three years ago being repeated around. I try to correct it whenever
I come across it being mentioned, but I've been told that it'd be better
if "the developers" cleared it up prominently on the homepage.

Regular releases, even if they don't get more testing than SVN HEAD,
along with clearly documented API changes will surely calm many
confused minds.

Regards,
R.
--
MPlayer http://mplayerhq.hu | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
Michael Niedermayer
2009-01-26 20:06:03 UTC
Permalink
Post by Dominik 'Rathann' Mierzejewski
Post by Robert Swain
Post by Måns Rullgård
Post by Ronald S. Bultje
Post by Måns Rullgård
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Diego Biurrun
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?
It is a blind way of releasing weekly or monthly snapshots of the
current trunk with essentially no guaranteed QA&co. The idea is to get
it out so people use it.
We have a public svn repository, and we put daily snapshots on the web
server. Isn't that enough?
It addresses the complaint that there's no releases.
So going from daily snapshots to weekly would make these people shut
up?
This is silly and not productive.
Post by Måns Rullgård
Post by Ronald S. Bultje
However, I honestly don't think making releases will change the
complaining about ffmpeg at all. It would be so good if they would
interact in and contribute to this discussion.
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
The apathetic approach won't encourage progress. I strongly recommend
documenting the API changes and how to transition between them,
coupled with svn revisions of the version bumps as suggested by
Stefano earlier in the thread. This gives some evidence to argue
against the claims rather than us saying that it's invalid and them
complaining that it's unstable. Eventually this knowledgebase will be
popularised if we keep pushing it and the fud will stop.
I strongly agree. There's still a lot of misconception originating from
over three years ago being repeated around. I try to correct it whenever
I come across it being mentioned, but I've been told that it'd be better
if "the developers" cleared it up prominently on the homepage.
Regular releases, even if they don't get more testing than SVN HEAD,
along with clearly documented API changes will surely calm many
confused minds.
well just make a cronjob of

cp current-snapshot ffmpeg-1.$version-`pwgen -0 | tr '[A-Z]' '[a-z]'`
version=$[version+1]

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
Robert Swain
2009-01-26 21:23:45 UTC
Permalink
Post by Dominik 'Rathann' Mierzejewski
Post by Robert Swain
Post by Måns Rullgård
Post by Ronald S. Bultje
However, I honestly don't think making releases will change the
complaining about ffmpeg at all. It would be so good if they would
interact in and contribute to this discussion.
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
The apathetic approach won't encourage progress. I strongly recommend
documenting the API changes and how to transition between them,
coupled with svn revisions of the version bumps as suggested by
Stefano earlier in the thread. This gives some evidence to argue
against the claims rather than us saying that it's invalid and them
complaining that it's unstable. Eventually this knowledgebase will be
popularised if we keep pushing it and the fud will stop.
I strongly agree. There's still a lot of misconception originating from
over three years ago being repeated around. I try to correct it whenever
I come across it being mentioned, but I've been told that it'd be better
if "the developers" cleared it up prominently on the homepage.
Regular releases, even if they don't get more testing than SVN HEAD,
along with clearly documented API changes will surely calm many
confused minds.
I just had a chat with some of the videolan developers to see if I
could get them involved in this discussion. We ended up having a
discussion off list, but these were their points:

- stop renaming/moving public API files/their contents for 'internal'
consistency
e.g. http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/avcodec.c;h=2d67ef75703068983a65447b186c9448f9e640b6;hb=HEAD#l38
- keep the API/ABI as consistent as possible
e.g. http://git.videolan.org/?p=vlc.git;a=commitdiff;h=0a778174db0192075a3194fb05b06a034ad940d2
- fix .pc (package config files)
- less dependency of libavformat on libavcodec would be welcome
- detail API/ABI changes would be very very welcome
- bump a version number every time needed, even for small API/ABI changes
e.g. AVMetadata changes didn't bump version
http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=66c05cd02ee454bba603feccf69f5dcc7239021a
- feature probing API (to find out supported formats/other
functionality from the libraries rather than guessing from version
number and
other information)
e.g. get_fourcc() would simplify this:
http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/fourcc.c;
- releases will not improve version consistency from distros as
distros control the versions of software they package and they all use
different versions of the same software

And maybe some more. There were a few rather specific issues raised
but I have left these out because

I'm now having the idea that maybe it would be a good idea to audit
how FFmpeg's APIs are used in major programs/libraries (VLC,
GStreamer, xine, etc.). I think this would provide insight as to where
examples and documentation are lacking. If something is being done
wrong, we should document why doing it their way is wrong and how it
should be done.

Regards,
Rob
Måns Rullgård
2009-01-26 22:05:05 UTC
Permalink
Post by Robert Swain
Post by Dominik 'Rathann' Mierzejewski
Post by Robert Swain
Post by Måns Rullgård
Post by Ronald S. Bultje
However, I honestly don't think making releases will change the
complaining about ffmpeg at all. It would be so good if they would
interact in and contribute to this discussion.
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
The apathetic approach won't encourage progress. I strongly recommend
documenting the API changes and how to transition between them,
coupled with svn revisions of the version bumps as suggested by
Stefano earlier in the thread. This gives some evidence to argue
against the claims rather than us saying that it's invalid and them
complaining that it's unstable. Eventually this knowledgebase will be
popularised if we keep pushing it and the fud will stop.
I strongly agree. There's still a lot of misconception originating from
over three years ago being repeated around. I try to correct it whenever
I come across it being mentioned, but I've been told that it'd be better
if "the developers" cleared it up prominently on the homepage.
Regular releases, even if they don't get more testing than SVN HEAD,
along with clearly documented API changes will surely calm many
confused minds.
I just had a chat with some of the videolan developers to see if I
could get them involved in this discussion. We ended up having a
- stop renaming/moving public API files/their contents for 'internal'
consistency
e.g. http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/avcodec.c;h=2d67ef75703068983a65447b186c9448f9e640b6;hb=HEAD#l38
We've done that ONCE. It's unlikely to happen again. The old layout
was causing problems of its own too.
Post by Robert Swain
- keep the API/ABI as consistent as possible
e.g. http://git.videolan.org/?p=vlc.git;a=commitdiff;h=0a778174db0192075a3194fb05b06a034ad940d2
- fix .pc (package config files)
That's impossible until all those who demands this agree on what the
correct files should look like.
Post by Robert Swain
- less dependency of libavformat on libavcodec would be welcome
That's an orthogonal issue. Besides, changing it would mean *massive*
API/ABI breakage.
Post by Robert Swain
- detail API/ABI changes would be very very welcome
svn log avcodec.h etc...
Post by Robert Swain
- bump a version number every time needed, even for small API/ABI changes
e.g. AVMetadata changes didn't bump version
http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=66c05cd02ee454bba603feccf69f5dcc7239021a
Backward compatible changes don't need a major version bump. Updating
the minor number when things are added is of course nice since it lets
apps check for a specific number before using some feature. We try to
do this, but sometimes people forget.
Post by Robert Swain
- feature probing API (to find out supported formats/other
functionality from the libraries rather than guessing from version
number and
other information)
http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/fourcc.c;
That table maps lavc codec IDs to VLCs internal ID system. Are they
really suggesting that *we* supply ID tags internal to *every* app
that uses lav*? Or just to them, selfishly?
Post by Robert Swain
- releases will not improve version consistency from distros as
distros control the versions of software they package and they all use
different versions of the same software
Quite.
--
Måns Rullgård
***@mansr.com
Diego Biurrun
2009-01-26 22:08:24 UTC
Permalink
Post by Måns Rullgård
Post by Robert Swain
I just had a chat with some of the videolan developers to see if I
could get them involved in this discussion. We ended up having a
- fix .pc (package config files)
That's impossible until all those who demands this agree on what the
correct files should look like.
I thought all pkgconfig patches were applied and people were happy...

Diego
Dominik 'Rathann' Mierzejewski
2009-01-26 23:02:13 UTC
Permalink
Post by Diego Biurrun
Post by Måns Rullgård
Post by Robert Swain
I just had a chat with some of the videolan developers to see if I
could get them involved in this discussion. We ended up having a
- fix .pc (package config files)
That's impossible until all those who demands this agree on what the
correct files should look like.
I thought all pkgconfig patches were applied and people were happy...
From Fedora camp, I'm quite happy. The pkg-config tool is broken in RedHat
Enterprise 5 currently, but it's not FFmpeg's problem and I'm going
to work around it until it's fixed.

I suspect Debian maintainer is happy too, as it was his patch that I applied.

Regards,
R.
--
MPlayer http://mplayerhq.hu | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
Jean-Baptiste Kempf
2009-01-27 08:38:21 UTC
Permalink
Post by Måns Rullgård
Post by Robert Swain
I just had a chat with some of the videolan developers to see if I
could get them involved in this discussion. We ended up having a
Let me answer quite straight, we were asked: "what could be improved in
FFmpeg from your point of view?"

We have not many problems with FFmpeg, and we are able to mix FFmpeg
codecs and formats with others, and we have no issue with it (contrarly
what $vendor says that this is impossible to have game formats and own
demuxers).
Therefore we DON'T complain, we just gave a few random thoughts.

VLC uses FFmpeg HEAD for stupid OSes (Win32 and Mac) without
forking it in our tree. For those, we see few regressions and issues
since the Fate came up and we moved to gcc4. Therefore, releases is HEAD
for us.

For OSes with library dependencies, having or not releases will not
change anything, since we will have to deal with debian/stable and
ubuntu/next_version at the same time...
Post by Måns Rullgård
We've done that ONCE. It's unlikely to happen again. The old layout
was causing problems of its own too.
Great. That was just a random remark, don't take it as a reproach,
please.
Post by Måns Rullgård
Post by Robert Swain
- fix .pc (package config files)
That's impossible until all those who demands this agree on what the
correct files should look like.
We'll try to be more concrete on that.
Post by Måns Rullgård
Post by Robert Swain
- less dependency of libavformat on libavcodec would be welcome
That's an orthogonal issue. Besides, changing it would mean *massive*
API/ABI breakage.
We are just reporting that, because that would be nice, but we know that
this is very difficult.
The thing is when you have a module using libavformat and you link
statically, you need to have both libavcodec and libavformat in it, so
the size is big.
Once again, this is NOT a reproach nor a rant, this is just a "That
would be cool".
Post by Måns Rullgård
Post by Robert Swain
- detail API/ABI changes would be very very welcome
svn log avcodec.h etc...
Sorry, svn log is not documentation, but OK.
Post by Måns Rullgård
Backward compatible changes don't need a major version bump. Updating
the minor number when things are added is of course nice since it lets
apps check for a specific number before using some feature. We try to
do this, but sometimes people forget.
Ok.
Post by Måns Rullgård
That table maps lavc codec IDs to VLCs internal ID system. Are they
really suggesting that *we* supply ID tags internal to *every* app
that uses lav*? Or just to them, selfishly?
Sorry, this was not clear. Let me rephrase:
With more and more distributions removing or adding features, a way to
request dynamically what feature is in or is not would be nice.

Moreover, once again, this was not a rant and your answer is a bit
aggressive.

Sorry if the message wasn't clearly formulated, but we don't have many
issues and we don't really share the global rant againt FFmpeg.

About libavformat API, I'll let fenrir discuss that, because I am
clearly NOT up to date with the (non-)issue.

Btw, is there a discussion room for FFmpeg at Fosdem?

Best Regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/
Reimar Döffinger
2009-01-26 22:10:12 UTC
Permalink
Post by Robert Swain
I just had a chat with some of the videolan developers to see if I
could get them involved in this discussion. We ended up having a
Well, this is how I see things, I do not claim to represent the "truth"
just my view.
Post by Robert Swain
- stop renaming/moving public API files/their contents for 'internal'
consistency
e.g. http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/avcodec.c;h=2d67ef75703068983a65447b186c9448f9e640b6;hb=HEAD#l38
Well, it is a bit more that consistency, the problem was possible name
collissions, too. I would hope that such changes don't happen anymore.
There may be better examples for "renaming for consistency" though.
Post by Robert Swain
- keep the API/ABI as consistent as possible
e.g. http://git.videolan.org/?p=vlc.git;a=commitdiff;h=0a778174db0192075a3194fb05b06a034ad940d2
Hm, maybe there are instances but this is a really bad example.
At least IMO this did not change API, it was wrong all the time since it
would create broken/invalid files and thus this was a bug fix.
Bug fixes sometimes will break applications, but I can't see how this
could be avoided...
Post by Robert Swain
- fix .pc (package config files)
To me it seems like nobody knows what a correct .pc file looks like,
this is definitely a case of us not knowing any better.
Do they really still have issues?!?
IMHO the solution here is to kick the package-config people to create
proper documentation (or tell us where it can be found)...
Post by Robert Swain
- less dependency of libavformat on libavcodec would be welcome
I agree fully, but what exactly are you thinking of?
There are only two dependencies I know of: AVParser (which I think is
unavoidable) and that extradata formats may be incompatible (theora, and
IMHO it is justified to blame that on Ogg-braindeadness).
Post by Robert Swain
- feature probing API (to find out supported formats/other
functionality from the libraries rather than guessing from version
number and
other information)
http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/fourcc.c;
You are aware of avcodec_find_decoder and av_codec_next ?
Of course that will not solve the issue of the codec ids not being
defined, but that seems unavoidable...
About probing other functionality: more specific examples would be good.

Greetings,
Reimar Döffinger
Måns Rullgård
2009-01-26 22:23:02 UTC
Permalink
Post by Reimar Döffinger
Post by Robert Swain
- less dependency of libavformat on libavcodec would be welcome
I agree fully, but what exactly are you thinking of?
There are only two dependencies I know of: AVParser (which I think is
unavoidable) and that extradata formats may be incompatible (theora, and
IMHO it is justified to blame that on Ogg-braindeadness).
Libavformat cannot export a stream for which there is no codec in
lavc. This is annoying if you want to use a different, e.g. hardware,
decoder.
--
Måns Rullgård
***@mansr.com
Michael Niedermayer
2009-01-26 22:43:00 UTC
Permalink
Post by Måns Rullgård
Post by Reimar Döffinger
Post by Robert Swain
- less dependency of libavformat on libavcodec would be welcome
I agree fully, but what exactly are you thinking of?
There are only two dependencies I know of: AVParser (which I think is
unavoidable) and that extradata formats may be incompatible (theora, and
IMHO it is justified to blame that on Ogg-braindeadness).
Libavformat cannot export a stream for which there is no codec in
lavc.
this is only partly true
the user app has to figure the codec out based on the container specific
codec_tag but thats not the same as impossible ...

besides i see no disadvabtages in just adding a codec_id for every codec if
someone did the work ...

and for new codecs that are entirely unknown to us the codec_tag is
everything we can give the user app anyway.
Post by Måns Rullgård
This is annoying if you want to use a different, e.g. hardware,
decoder.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
Reimar Döffinger
2009-01-26 23:10:33 UTC
Permalink
Post by Michael Niedermayer
Post by Måns Rullgård
Libavformat cannot export a stream for which there is no codec in
lavc.
this is only partly true
the user app has to figure the codec out based on the container specific
codec_tag but thats not the same as impossible ...
Which MPlayer actually does (in addition) and it seems to work well enough (I think
Måns hates that design so much he immediately forgot it again after this
came up the last time :-P).

Greetings,
Reimar Döffinger
Måns Rullgård
2009-01-26 23:22:37 UTC
Permalink
Post by Reimar Döffinger
Post by Michael Niedermayer
Post by Måns Rullgård
Libavformat cannot export a stream for which there is no codec in
lavc.
this is only partly true
the user app has to figure the codec out based on the container specific
codec_tag but thats not the same as impossible ...
Which MPlayer actually does (in addition) and it seems to work well
enough (I think Måns hates that design so much he immediately forgot
it again after this came up the last time :-P).
It could be done cleaner if lavf filled in the codec_id even though
the decoder is disabled in lavc.
--
Måns Rullgård
***@mansr.com
Måns Rullgård
2009-01-26 23:21:32 UTC
Permalink
Post by Michael Niedermayer
Post by Måns Rullgård
Post by Reimar Döffinger
Post by Robert Swain
- less dependency of libavformat on libavcodec would be welcome
I agree fully, but what exactly are you thinking of?
There are only two dependencies I know of: AVParser (which I think is
unavoidable) and that extradata formats may be incompatible (theora, and
IMHO it is justified to blame that on Ogg-braindeadness).
Libavformat cannot export a stream for which there is no codec in
lavc.
this is only partly true
the user app has to figure the codec out based on the container specific
codec_tag but thats not the same as impossible ...
Libavformat could set an lavc codec ID even if that codec is
disabled. Then apps wouldn't need to know the internal tags of each
format, if they even have one.
Post by Michael Niedermayer
besides i see no disadvabtages in just adding a codec_id for every
codec if someone did the work ...
That's a secondary issue.
--
Måns Rullgård
***@mansr.com
Aurelien Jacobs
2009-01-26 23:35:23 UTC
Permalink
Post by Michael Niedermayer
Post by Måns Rullgård
Post by Reimar Döffinger
Post by Robert Swain
- less dependency of libavformat on libavcodec would be welcome
I agree fully, but what exactly are you thinking of?
There are only two dependencies I know of: AVParser (which I think is
unavoidable) and that extradata formats may be incompatible (theora, and
IMHO it is justified to blame that on Ogg-braindeadness).
Libavformat cannot export a stream for which there is no codec in
lavc.
this is only partly true
the user app has to figure the codec out based on the container specific
codec_tag but thats not the same as impossible ...
Libavformat could set an lavc codec ID even if that codec is disabled.
IIRC it actually does, don't it ?
Or maybe only some demuxers does it ?
Anyway, if it don't actually work, I agree that it's something which
should be fixed.

Aurel
Justin Ruggles
2009-01-26 22:26:43 UTC
Permalink
Post by Reimar Döffinger
Post by Robert Swain
- less dependency of libavformat on libavcodec would be welcome
I agree fully, but what exactly are you thinking of?
There are only two dependencies I know of: AVParser (which I think is
unavoidable) and that extradata formats may be incompatible (theora, and
IMHO it is justified to blame that on Ogg-braindeadness).
grep "bitstream.h" libavformat/*.c
Reimar Döffinger
2009-01-26 23:06:57 UTC
Permalink
Post by Justin Ruggles
Post by Reimar Döffinger
Post by Robert Swain
- less dependency of libavformat on libavcodec would be welcome
I agree fully, but what exactly are you thinking of?
There are only two dependencies I know of: AVParser (which I think is
unavoidable) and that extradata formats may be incompatible (theora, and
IMHO it is justified to blame that on Ogg-braindeadness).
grep "bitstream.h" libavformat/*.c
Hm, these don't even cause a dependency in-between the compiled libs.
I was actually only thinking of the dependecies that are visible to the
programs that use libavformat, being able to install libavformat without
libavcodec is not really something I'd consider useful...

Greetings,
Reimar Döffinger
Jean-Baptiste Kempf
2009-01-27 08:45:25 UTC
Permalink
Post by Reimar Döffinger
Well, this is how I see things, I do not claim to represent the "truth"
just my view.
Once again, this was more 'random thoughts about FFmpeg' not 'rant
against FFmpeg', because we don't share the general rant.
Post by Reimar Döffinger
Well, it is a bit more that consistency, the problem was possible name
collissions, too. I would hope that such changes don't happen anymore.
There may be better examples for "renaming for consistency" though.
Ok. Yes, maybe example was not the best.
Post by Reimar Döffinger
Post by Robert Swain
- keep the API/ABI as consistent as possible
Hm, maybe there are instances but this is a really bad example.
Ok. Maybe wrong example, but the "keep the API/ABI as consistent as
possible" would help us when you have to support debian/stable and
fedora/bleeding-edge versions. We don't say that FFmpeg doesn't do it
now, but this is important for us.
Post by Reimar Döffinger
Post by Robert Swain
- less dependency of libavformat on libavcodec would be welcome
I agree fully, but what exactly are you thinking of?
This is just an improvement that might be nice because we would need to
link our avformat module to both libavcodec and libavformat and decrease
the size.
Post by Reimar Döffinger
There are only two dependencies I know of: AVParser (which I think is
unavoidable) and that extradata formats may be incompatible (theora, and
IMHO it is justified to blame that on Ogg-braindeadness).
We never said that this would be easy, we just said that this would be
cool.
Post by Reimar Döffinger
Post by Robert Swain
- feature probing API (to find out supported formats/other
functionality from the libraries rather than guessing from version
number and
other information)
http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/fourcc.c;
You are aware of avcodec_find_decoder and av_codec_next ?
Of course that will not solve the issue of the codec ids not being
defined, but that seems unavoidable...
About probing other functionality: more specific examples would be good.
Well, this is more about the issue of some distributions removing
decoders/encoders or adding some and this is quite difficult to manage.
A way of detecting that would be nice.

Best Regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/
Aurelien Jacobs
2009-01-26 23:01:37 UTC
Permalink
Post by Robert Swain
Post by Dominik 'Rathann' Mierzejewski
Post by Robert Swain
Post by Måns Rullgård
Post by Ronald S. Bultje
However, I honestly don't think making releases will change the
complaining about ffmpeg at all. It would be so good if they would
interact in and contribute to this discussion.
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
The apathetic approach won't encourage progress. I strongly recommend
documenting the API changes and how to transition between them,
coupled with svn revisions of the version bumps as suggested by
Stefano earlier in the thread. This gives some evidence to argue
against the claims rather than us saying that it's invalid and them
complaining that it's unstable. Eventually this knowledgebase will be
popularised if we keep pushing it and the fud will stop.
I strongly agree. There's still a lot of misconception originating from
over three years ago being repeated around. I try to correct it whenever
I come across it being mentioned, but I've been told that it'd be better
if "the developers" cleared it up prominently on the homepage.
Regular releases, even if they don't get more testing than SVN HEAD,
along with clearly documented API changes will surely calm many
confused minds.
I just had a chat with some of the videolan developers to see if I
could get them involved in this discussion. We ended up having a
- stop renaming/moving public API files/their contents for 'internal'
consistency
e.g. http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/avcodec.c;h=2d67ef75703068983a65447b186c9448f9e640b6;hb=HEAD#l38
Here they have a variant to #include <ffmpeg/avcodec.h>.
This is wrong and never was meant to be used this way.
They should instead use #include <avcodec.h> with -I/usr/include/ffmpeg
(or similar).
Post by Robert Swain
[...]
- detail API/ABI changes would be very very welcome
I agree we could improve on this.
Post by Robert Swain
- bump a version number every time needed, even for small API/ABI changes
e.g. AVMetadata changes didn't bump version
http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=66c05cd02ee454bba603feccf69f5dcc7239021a
This is on purpose.
The new AVMetadata API is not finished and will change.
I plan to bump version number when the API will be "finalized".
Until then, people must not use this new API, and if they use
it anyway, they shouldn't complain about API/ABI changes.
This was clearly explained in initial commit message:
http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=0cf9fbf0d9ff9c3ba714678903a995fc00e5712b
Post by Robert Swain
I'm now having the idea that maybe it would be a good idea to audit
how FFmpeg's APIs are used in major programs/libraries (VLC,
GStreamer, xine, etc.). I think this would provide insight as to where
examples and documentation are lacking. If something is being done
wrong, we should document why doing it their way is wrong and how it
should be done.
I agree, but this is time consuming, and it may not be that easy to
find a volunteer for this.

Aurel
Diego Biurrun
2009-01-26 23:05:27 UTC
Permalink
Post by Aurelien Jacobs
Post by Robert Swain
- bump a version number every time needed, even for small API/ABI changes
e.g. AVMetadata changes didn't bump version
http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=66c05cd02ee454bba603feccf69f5dcc7239021a
This is on purpose.
The new AVMetadata API is not finished and will change.
I plan to bump version number when the API will be "finalized".
Until then, people must not use this new API, and if they use
it anyway, they shouldn't complain about API/ABI changes.
http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=0cf9fbf0d9ff9c3ba714678903a995fc00e5712b
Maybe you could explain this in a Doxygen comment for the API.

Diego
Aurelien Jacobs
2009-01-26 23:40:06 UTC
Permalink
Post by Diego Biurrun
Post by Aurelien Jacobs
Post by Robert Swain
- bump a version number every time needed, even for small API/ABI changes
e.g. AVMetadata changes didn't bump version
http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=66c05cd02ee454bba603feccf69f5dcc7239021a
This is on purpose.
The new AVMetadata API is not finished and will change.
I plan to bump version number when the API will be "finalized".
Until then, people must not use this new API, and if they use
it anyway, they shouldn't complain about API/ABI changes.
http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=0cf9fbf0d9ff9c3ba714678903a995fc00e5712b
Maybe you could explain this in a Doxygen comment for the API.
Done.

Aurel
Jean-Baptiste Kempf
2009-01-27 08:48:14 UTC
Permalink
Post by Aurelien Jacobs
Here they have a variant to #include <ffmpeg/avcodec.h>.
This is wrong and never was meant to be used this way.
They should instead use #include <avcodec.h> with -I/usr/include/ffmpeg
(or similar).
We add to that in oder to simplify AC_CHECK_HEADERS when running
autotools.

Best Regards,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/
Benjamin Larsson
2009-01-26 16:27:47 UTC
Permalink
Post by Måns Rullgård
Post by Ronald S. Bultje
Hi Mans,
Post by Måns Rullgård
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Diego Biurrun
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?
It is a blind way of releasing weekly or monthly snapshots of the
current trunk with essentially no guaranteed QA&co. The idea is to get
it out so people use it.
We have a public svn repository, and we put daily snapshots on the web
server. Isn't that enough?
It addresses the complaint that there's no releases.
So going from daily snapshots to weekly would make these people shut
up?
What I thought of for releases is to release 4 times a year. And around
the time for release we just ensure that all the regressions tests pass
on all supported platforms. And the releases wouldn't get any more Q/A
then what is provided by all testcases from FATE and from make test.
That shouldn't take to much developer time, when it is almost about time
for a release just pick a svn version that is ok and make a package of it.

And regarding the roadmap, it would be nice to have something describing
what features that are in progress or planned. But maybe not something
that says exactly what is going to be included in the next release.

MvH
Benjamin Larsson
Robert Swain
2009-01-26 16:35:15 UTC
Permalink
Post by Benjamin Larsson
Post by Måns Rullgård
Post by Ronald S. Bultje
Post by Måns Rullgård
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Diego Biurrun
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?
It is a blind way of releasing weekly or monthly snapshots of the
current trunk with essentially no guaranteed QA&co. The idea is to get
it out so people use it.
We have a public svn repository, and we put daily snapshots on the web
server. Isn't that enough?
It addresses the complaint that there's no releases.
So going from daily snapshots to weekly would make these people shut
up?
What I thought of for releases is to release 4 times a year. And around
the time for release we just ensure that all the regressions tests pass
on all supported platforms. And the releases wouldn't get any more Q/A
then what is provided by all testcases from FATE and from make test.
That shouldn't take to much developer time, when it is almost about time
for a release just pick a svn version that is ok and make a package of it.
This would at least provide an equal footing for external software
developers to develop against and they wouldn't use ancient snapshots
that we don't support. I'm not saying we need to provide masses of
support (backporting all bug fixes to some branch might not be
necessary for example) for the releases, but at least people could
report bugs against a non-ancient version of FFmpeg.
Post by Benjamin Larsson
And regarding the roadmap, it would be nice to have something describing
what features that are in progress or planned. But maybe not something
that says exactly what is going to be included in the next release.
A roadmap could rather be linked to version bumps.

Regards,
Rob
Reimar Döffinger
2009-01-26 17:23:01 UTC
Permalink
Post by Robert Swain
but at least people could
report bugs against a non-ancient version of FFmpeg.
How is that supposed to work? _I_ won't have that old (as in previously
released) version installed either way, so _I_ will not be able to handle
bug reports against it.
I simply can't understand how a resonable discussion should be possible
when everyone uses the word "releases" to mean "magic pixie dust that
fixes my favourite issue". That means that when we do releases, about
90% might have just as many complaints if we don't do it exactly the way
they want it.
So I propose this: any discussion about "releases" is from now on
forbidden. Issues must be stated clearly and specificially with a
specific solution (e.g.
Problem: I want every distribution to ship the same version.
Solution: send one person with a shotgun to the FFmpeg package
maintainer of each distribution.
or:
Problem: I want to develop my own private hacks to FFmpeg but don't want
to maintain them.
Solution: Stop FFmpeg development completely).
No I am not entirely serious, but just releases is obviously not what people
want, because we do have releases: each SVN revision is one.
So everyone asking for "releases" is asking for something that in their
imagination is implied by a "release", but given the lack of working
crystal balls it is also a pointless request.
Post by Robert Swain
Post by Benjamin Larsson
And regarding the roadmap, it would be nice to have something describing
what features that are in progress or planned. But maybe not something
that says exactly what is going to be included in the next release.
"roadmap" is evidently another buzzword the meaning of which we are
trying to reverse-engineer here. Am I really the only one who has no
idea what they wanted when they asked for a "roadmap"?
Why do you think that the kind of roadmap you suggest will be considered
helpful by even a single one of them?
(but yes, I personally would consider it useful to have a list of what
everyone is working on and if there is progress if they don't mind the
effort, though I doubt it will be really useful in reality).

Greetings,
Reimar Döffinger
Robert Swain
2009-01-26 17:35:45 UTC
Permalink
Post by Reimar Döffinger
Post by Robert Swain
but at least people could
report bugs against a non-ancient version of FFmpeg.
How is that supposed to work? _I_ won't have that old (as in previously
released) version installed either way, so _I_ will not be able to handle
bug reports against it.
The 'at least' was referring to the proximity. I expect number of bugs
being reported against revision N that have already been squashed in
HEAD reduces as the revision difference between N and HEAD reduces.
People reporting bugs using snapshots from 2007 would likely be much
less useful than people reporting bugs against a revision from 3
months ago.

But releases seem to be moot. I had a bit of a discussion with some
videolan devs and they aren't bothered about releases because they
don't increase the consistency of libav* on systems on which VLC is to
be installed. I will comment more on this shortly.
Post by Reimar Döffinger
Post by Robert Swain
Post by Benjamin Larsson
And regarding the roadmap, it would be nice to have something describing
what features that are in progress or planned. But maybe not something
that says exactly what is going to be included in the next release.
"roadmap" is evidently another buzzword the meaning of which we are
trying to reverse-engineer here. Am I really the only one who has no
idea what they wanted when they asked for a "roadmap"?
It probably is a buzz word but it's simply a plan of the progress to
be achieved by noted milestones.

Rob
Reinhard Tartler
2009-01-26 20:52:19 UTC
Permalink
Post by Måns Rullgård
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
I have been bitten by this this week. Several bugs have been reported
because of the recent ffmpeg update.

The root cause was the ff_gcd -> av_gcd rename in libavutil. On irc we
already could clear up this issue. The rename was done to make the gcd
function part of the public API; it was private before. However the
*perception* of users is that ffmpeg has changed ABI/API. Why? Let me
explain it:

In debian lenny, ffmpeg is split in different binary packages, among
others libavcodec51 and libavutil49 using a snapshot from february 2008
[1]. In experimental, I've now updated the an snapshot from last week
end. Because of the version bump in libavcodec, I needed to rename the
binary package libavcodec51 -> libavcodec52, which is standard practice
in debian with SONAME bumps. The rename is done to assist transitioning
programs linking against libavcodec51: Packages not yet recompiled
against the newer ffmpeg are not instantly broken, because libavcodec51
left on the hard disk. It is only removed if nothing else depends on it.

Now something interesting happens: with the new ffmpeg snapshot
libavutil is updated as well. It features a function rename
(ff_gcd->av_gcd), which is according to the ffmpeg development policy
OK, since it is a pure private function. However this rename breaks the
libavcodec51 package horribly. [3]

In the end this means that libavutil49 must not be renamed until *all*
applications linking against any library of ffmpeg has been recompiled.
We now are aware of the issue and in future, we will express this
through package dependencies propoery, however the core issue stands:
Transitions to a newer snapshot of ffmpeg are made terribly painful this
way. Please note that the requirement to rebuild *all* reverse depends
of a library like ffmpeg is really a problem [2] for distributions like
debian or ubuntu.

I just tell you this story because I think it greatly contributes to the
*perception* that ffmpeg changes its API/ABI too often. From a
distribution POV, stories like these have the *same* *impact* as an
API/ABI change.


[1] ancient, I know, but the situation would not change if I used a
snapshot from september or later.

[2] mostly time consuming, and in the case of debian makes the "testing"
process (i.e. copying/moving an updated ffmpeg package to "testing")
incredibly painful.

[3] Reported only last week:

http://bugs.debian.org/510841
http://bugs.debian.org/512466
http://bugs.debian.org/512946
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Måns Rullgård
2009-01-26 21:19:29 UTC
Permalink
Post by Reinhard Tartler
Post by Måns Rullgård
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
I have been bitten by this this week. Several bugs have been reported
because of the recent ffmpeg update.
The root cause was the ff_gcd -> av_gcd rename in libavutil. On irc we
already could clear up this issue. The rename was done to make the gcd
function part of the public API; it was private before. However the
*perception* of users is that ffmpeg has changed ABI/API. Why? Let me
In debian lenny, ffmpeg is split in different binary packages, among
others libavcodec51 and libavutil49 using a snapshot from february 2008
[1]. In experimental, I've now updated the an snapshot from last week
end. Because of the version bump in libavcodec, I needed to rename the
binary package libavcodec51 -> libavcodec52, which is standard practice
in debian with SONAME bumps. The rename is done to assist transitioning
programs linking against libavcodec51: Packages not yet recompiled
against the newer ffmpeg are not instantly broken, because libavcodec51
left on the hard disk. It is only removed if nothing else depends on it.
Now something interesting happens: with the new ffmpeg snapshot
libavutil is updated as well. It features a function rename
(ff_gcd->av_gcd), which is according to the ffmpeg development policy
OK, since it is a pure private function. However this rename breaks the
libavcodec51 package horribly. [3]
In summary, you are blaming FFmpeg for difficulties caused by broken
packaging and silly policies in Debian. That's not really fair.
--
Måns Rullgård
***@mansr.com
Reinhard Tartler
2009-01-26 21:31:17 UTC
Permalink
Post by Måns Rullgård
Post by Reinhard Tartler
Now something interesting happens: with the new ffmpeg snapshot
libavutil is updated as well. It features a function rename
(ff_gcd->av_gcd), which is according to the ffmpeg development policy
OK, since it is a pure private function. However this rename breaks the
libavcodec51 package horribly. [3]
In summary, you are blaming FFmpeg for difficulties caused by broken
packaging and silly policies in Debian. That's not really fair.
I'm sorry to disagree, but your summary is not accurate at all.

I'm not blaming ffmpeg at all! (Ok, granted, I didn't make any
suggestions how to improve the situation either. I rather pointed out
the *perception* of ffmpeg development policies for distros)

I tried to explain in detail what and why we (the distro people) are
doing. The way ffmpeg is developed makes it hard not only for debian,
but for any serious distribution. In fact, from what I read on IRC,
other distros seem to have the very same problems and therefore use
overly strict dependencies.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Reimar Döffinger
2009-01-26 22:55:15 UTC
Permalink
Post by Reinhard Tartler
Now something interesting happens: with the new ffmpeg snapshot
libavutil is updated as well. It features a function rename
(ff_gcd->av_gcd), which is according to the ffmpeg development policy
OK, since it is a pure private function. However this rename breaks the
libavcodec51 package horribly. [3]
Hm, can't libavcodec be linked to always use/prefer the libavutil version it
was linked to originally? Then bumping the minor version on such renames
would reduce the issue...
Post by Reinhard Tartler
In the end this means that libavutil49 must not be renamed until *all*
applications linking against any library of ffmpeg has been recompiled.
I don't understand what you mean by "libavutil49 must not be renamed"...
Overall I wonder if it wasn't a really bad idea to give each libav*
library a different version number, or at least not bumping major
versions together, because it seems to me that is what
causes the issue in the end...
Aurelien Jacobs
2009-01-26 23:20:03 UTC
Permalink
Post by Reimar Döffinger
Post by Reinhard Tartler
Now something interesting happens: with the new ffmpeg snapshot
libavutil is updated as well. It features a function rename
(ff_gcd->av_gcd), which is according to the ffmpeg development policy
OK, since it is a pure private function. However this rename breaks the
libavcodec51 package horribly. [3]
Hm, can't libavcodec be linked to always use/prefer the libavutil version it
was linked to originally? Then bumping the minor version on such renames
would reduce the issue...
Post by Reinhard Tartler
In the end this means that libavutil49 must not be renamed until *all*
applications linking against any library of ffmpeg has been recompiled.
I don't understand what you mean by "libavutil49 must not be renamed"...
Overall I wonder if it wasn't a really bad idea to give each libav*
library a different version number, or at least not bumping major
versions together, because it seems to me that is what
causes the issue in the end...
This is indeed the root of the problem.
We have separate version numbers for each libav*, which makes people think
that the libs are more or less independent from each other, while on the
same time we never supported linking libav* to another libav coming from
a different svn revision.

It is not that uncommon for a distro to support several major version of
the same lib at the same time. And distro generally don't support several
version of the same lib with the same major version.
So to make it clear, distro want to support simultaneously lavc51 and
lavc52, but they can't handle 2 version of lavu49 at the same time.
Right now, this is impossible.

I can imagine several solution to this.
One clean solution would be to never use any internal API of libav_x
from libav_y. Linking between the various libav* would strictly stick
to public API.
This would certainly imply exposing more things to public API of
libavutil. But that way, any change in lavu which would break
compatibility with old lavc, would also be a public API change, and
thus, would require major version bump.
I'm pretty sure this would solve the kind of problem reported here.

Aurel
Reinhard Tartler
2009-01-27 08:49:23 UTC
Permalink
Post by Aurelien Jacobs
Post by Reimar Döffinger
Post by Reinhard Tartler
Now something interesting happens: with the new ffmpeg snapshot
libavutil is updated as well. It features a function rename
(ff_gcd->av_gcd), which is according to the ffmpeg development policy
OK, since it is a pure private function. However this rename breaks the
libavcodec51 package horribly. [3]
Hm, can't libavcodec be linked to always use/prefer the libavutil version it
was linked to originally?
This is indeed an idea I had yesterday and tried to discuss it on
IRC. In order to implement that idea libavutil could be linked
statically to libavcodec.so.52/libavformat.so.52.

In the short term, we now have to introduce overly strict dependencies
that prevent libavcodec51 to be installed with the new version of
libavutil. This prevents the bugs I quoted yesterday, but makes updating
ffmpeg very painful!
Post by Aurelien Jacobs
Post by Reimar Döffinger
Then bumping the minor version on such renames would reduce the
issue...
Both major and minor version bumps wouldn't be an issue then at all.

However Måns was strictly against this idea. I can only suspect why...

Diego, how do you think about the idea of linking libavutil statically
into libavformat.so/libavcodec.so?
Post by Aurelien Jacobs
Post by Reimar Döffinger
Post by Reinhard Tartler
In the end this means that libavutil49 must not be renamed until *all*
applications linking against any library of ffmpeg has been recompiled.
I don't understand what you mean by "libavutil49 must not be renamed"...
I'm sorry, I wasn't clear on this point. I should have written "updated"
instead of "renamed", but that wouldn't be too accurate as well.

on updates to a library libfoo, a maintainer has to decide the following
cases:

a) the library has only internal change, nothing changes externally
b) the library has additions only, a minor bump is made
c) the library features changed symbols and/or types, a major bump
needs to be made

For b), this is noted in the package, so that programs get a correct
versioned dependency generated.

only c) requires a SONAME bump. In that case we introduce a new binary
package so that both the older and the new version of the library can be
installed.

Being able to install both versions of libfoo is critical for having a
smooth transition not requiring all maintainers of all all affected
packages synchronising uploads with each others. This is a real problem!
Post by Aurelien Jacobs
Post by Reimar Döffinger
Overall I wonder if it wasn't a really bad idea to give each libav*
library a different version number, or at least not bumping major
versions together, because it seems to me that is what
causes the issue in the end...
This is indeed the root of the problem.
We have separate version numbers for each libav*, which makes people think
that the libs are more or less independent from each other, while on the
same time we never supported linking libav* to another libav coming from
a different svn revision.
That's what I figured out the hard way. BTW, Michael, this is why I
didn't propose a "compatibility" patch Aurelien posted last night. Måns
explained me on IRC that ffmpeg distinguishes between internal and
external API and later then that he considers packaging libavutil
separately from libavformat and libavcodec was a bad idea in the first
place.

However if this is the case, why not combining then all of libav* into a
aggregate library libffmpeg.so?
Post by Aurelien Jacobs
It is not that uncommon for a distro to support several major version of
the same lib at the same time. And distro generally don't support several
version of the same lib with the same major version.
So to make it clear, distro want to support simultaneously lavc51 and
lavc52, but they can't handle 2 version of lavu49 at the same time.
Right now, this is impossible.
That is accurate. Thanks for phrasing it like this!
Post by Aurelien Jacobs
I can imagine several solution to this.
One clean solution would be to never use any internal API of libav_x
from libav_y. Linking between the various libav* would strictly stick
to public API.
Yes, that would be ideal for packagers. All libav* could then be
versioned properly. If this was a general policy, a linker script could
be developed which hides all internal API. This way
libavcodec/libavformat and all external applications would be *forced*
to use the public API.
Post by Aurelien Jacobs
This would certainly imply exposing more things to public API of
libavutil. But that way, any change in lavu which would break
compatibility with old lavc, would also be a public API change, and
thus, would require major version bump.
I'm pretty sure this would solve the kind of problem reported here.
In the end I think this would make libavutil much more useful for
external projects!

Another solution/workaround is outlined further above in this email.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Michael Niedermayer
2009-01-26 22:54:12 UTC
Permalink
Post by Reinhard Tartler
Post by Måns Rullgård
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
I have been bitten by this this week. Several bugs have been reported
because of the recent ffmpeg update.
The root cause was the ff_gcd -> av_gcd rename in libavutil. On irc we
already could clear up this issue. The rename was done to make the gcd
function part of the public API; it was private before. However the
*perception* of users is that ffmpeg has changed ABI/API. Why? Let me
In debian lenny, ffmpeg is split in different binary packages, among
others libavcodec51 and libavutil49 using a snapshot from february 2008
[1]. In experimental, I've now updated the an snapshot from last week
end. Because of the version bump in libavcodec, I needed to rename the
binary package libavcodec51 -> libavcodec52, which is standard practice
in debian with SONAME bumps. The rename is done to assist transitioning
programs linking against libavcodec51: Packages not yet recompiled
against the newer ffmpeg are not instantly broken, because libavcodec51
left on the hard disk. It is only removed if nothing else depends on it.
Now something interesting happens: with the new ffmpeg snapshot
libavutil is updated as well. It features a function rename
(ff_gcd->av_gcd), which is according to the ffmpeg development policy
OK, since it is a pure private function. However this rename breaks the
libavcodec51 package horribly. [3]
In the end this means that libavutil49 must not be renamed until *all*
applications linking against any library of ffmpeg has been recompiled.
We now are aware of the issue and in future, we will express this
Transitions to a newer snapshot of ffmpeg are made terribly painful this
way. Please note that the requirement to rebuild *all* reverse depends
of a library like ffmpeg is really a problem [2] for distributions like
debian or ubuntu.
I just tell you this story because I think it greatly contributes to the
*perception* that ffmpeg changes its API/ABI too often. From a
distribution POV, stories like these have the *same* *impact* as an
API/ABI change.
1. why did you not tell this to us earlier
2. why did you not just add ff_gcd(){return av_gcd()} !?

in that sense, a patch doing 2. under #if ...VERSION < next major
is welcome!

IMHO the gcd issue is a bug on our side not the way we/i want to do things
when its avoidable

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
Robert Swain
2009-01-26 22:59:19 UTC
Permalink
Post by Michael Niedermayer
Post by Reinhard Tartler
Post by Måns Rullgård
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
I have been bitten by this this week. Several bugs have been reported
because of the recent ffmpeg update.
The root cause was the ff_gcd -> av_gcd rename in libavutil. On irc we
already could clear up this issue. The rename was done to make the gcd
function part of the public API; it was private before. However the
*perception* of users is that ffmpeg has changed ABI/API. Why? Let me
In debian lenny, ffmpeg is split in different binary packages, among
others libavcodec51 and libavutil49 using a snapshot from february 2008
[1]. In experimental, I've now updated the an snapshot from last week
end. Because of the version bump in libavcodec, I needed to rename the
binary package libavcodec51 -> libavcodec52, which is standard practice
in debian with SONAME bumps. The rename is done to assist transitioning
programs linking against libavcodec51: Packages not yet recompiled
against the newer ffmpeg are not instantly broken, because libavcodec51
left on the hard disk. It is only removed if nothing else depends on it.
Now something interesting happens: with the new ffmpeg snapshot
libavutil is updated as well. It features a function rename
(ff_gcd->av_gcd), which is according to the ffmpeg development policy
OK, since it is a pure private function. However this rename breaks the
libavcodec51 package horribly. [3]
In the end this means that libavutil49 must not be renamed until *all*
applications linking against any library of ffmpeg has been recompiled.
We now are aware of the issue and in future, we will express this
Transitions to a newer snapshot of ffmpeg are made terribly painful this
way. Please note that the requirement to rebuild *all* reverse depends
of a library like ffmpeg is really a problem [2] for distributions like
debian or ubuntu.
I just tell you this story because I think it greatly contributes to the
*perception* that ffmpeg changes its API/ABI too often. From a
distribution POV, stories like these have the *same* *impact* as an
API/ABI change.
1. why did you not tell this to us earlier
2. why did you not just add ff_gcd(){return av_gcd()} !?
in that sense, a patch doing 2. under #if ...VERSION < next major
is welcome!
IMHO the gcd issue is a bug on our side not the way we/i want to do things
when its avoidable
Thank you for being humble and making this statement. (This is a
sincere statement.)

Regards,
Rob
Aurelien Jacobs
2009-01-26 23:57:42 UTC
Permalink
Post by Michael Niedermayer
Post by Reinhard Tartler
Post by Måns Rullgård
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
I have been bitten by this this week. Several bugs have been reported
because of the recent ffmpeg update.
The root cause was the ff_gcd -> av_gcd rename in libavutil. On irc we
already could clear up this issue. The rename was done to make the gcd
function part of the public API; it was private before. However the
*perception* of users is that ffmpeg has changed ABI/API. Why? Let me
In debian lenny, ffmpeg is split in different binary packages, among
others libavcodec51 and libavutil49 using a snapshot from february 2008
[1]. In experimental, I've now updated the an snapshot from last week
end. Because of the version bump in libavcodec, I needed to rename the
binary package libavcodec51 -> libavcodec52, which is standard practice
in debian with SONAME bumps. The rename is done to assist transitioning
programs linking against libavcodec51: Packages not yet recompiled
against the newer ffmpeg are not instantly broken, because libavcodec51
left on the hard disk. It is only removed if nothing else depends on it.
Now something interesting happens: with the new ffmpeg snapshot
libavutil is updated as well. It features a function rename
(ff_gcd->av_gcd), which is according to the ffmpeg development policy
OK, since it is a pure private function. However this rename breaks the
libavcodec51 package horribly. [3]
In the end this means that libavutil49 must not be renamed until *all*
applications linking against any library of ffmpeg has been recompiled.
We now are aware of the issue and in future, we will express this
Transitions to a newer snapshot of ffmpeg are made terribly painful this
way. Please note that the requirement to rebuild *all* reverse depends
of a library like ffmpeg is really a problem [2] for distributions like
debian or ubuntu.
I just tell you this story because I think it greatly contributes to the
*perception* that ffmpeg changes its API/ABI too often. From a
distribution POV, stories like these have the *same* *impact* as an
API/ABI change.
1. why did you not tell this to us earlier
2. why did you not just add ff_gcd(){return av_gcd()} !?
in that sense, a patch doing 2. under #if ...VERSION < next major
is welcome!
Trivial patch attached.

Aurel
Michael Niedermayer
2009-01-27 00:36:33 UTC
Permalink
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Reinhard Tartler
Post by Måns Rullgård
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
I have been bitten by this this week. Several bugs have been reported
because of the recent ffmpeg update.
The root cause was the ff_gcd -> av_gcd rename in libavutil. On irc we
already could clear up this issue. The rename was done to make the gcd
function part of the public API; it was private before. However the
*perception* of users is that ffmpeg has changed ABI/API. Why? Let me
In debian lenny, ffmpeg is split in different binary packages, among
others libavcodec51 and libavutil49 using a snapshot from february 2008
[1]. In experimental, I've now updated the an snapshot from last week
end. Because of the version bump in libavcodec, I needed to rename the
binary package libavcodec51 -> libavcodec52, which is standard practice
in debian with SONAME bumps. The rename is done to assist transitioning
programs linking against libavcodec51: Packages not yet recompiled
against the newer ffmpeg are not instantly broken, because libavcodec51
left on the hard disk. It is only removed if nothing else depends on it.
Now something interesting happens: with the new ffmpeg snapshot
libavutil is updated as well. It features a function rename
(ff_gcd->av_gcd), which is according to the ffmpeg development policy
OK, since it is a pure private function. However this rename breaks the
libavcodec51 package horribly. [3]
In the end this means that libavutil49 must not be renamed until *all*
applications linking against any library of ffmpeg has been recompiled.
We now are aware of the issue and in future, we will express this
Transitions to a newer snapshot of ffmpeg are made terribly painful this
way. Please note that the requirement to rebuild *all* reverse depends
of a library like ffmpeg is really a problem [2] for distributions like
debian or ubuntu.
I just tell you this story because I think it greatly contributes to the
*perception* that ffmpeg changes its API/ABI too often. From a
distribution POV, stories like these have the *same* *impact* as an
API/ABI change.
1. why did you not tell this to us earlier
2. why did you not just add ff_gcd(){return av_gcd()} !?
in that sense, a patch doing 2. under #if ...VERSION < next major
is welcome!
Trivial patch attached.
looks good

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
Aurelien Jacobs
2009-01-27 00:47:57 UTC
Permalink
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Reinhard Tartler
Post by Måns Rullgård
Given that most of the complaints are invalid, e.g. the API hasn't
changed nearly as often as they say, there really isn't much we can
do. If people want to make up false claims about FFmpeg, and then
complain about them, they'll keep doing that no matter what we do.
I have been bitten by this this week. Several bugs have been reported
because of the recent ffmpeg update.
The root cause was the ff_gcd -> av_gcd rename in libavutil. On irc we
already could clear up this issue. The rename was done to make the gcd
function part of the public API; it was private before. However the
*perception* of users is that ffmpeg has changed ABI/API. Why? Let me
In debian lenny, ffmpeg is split in different binary packages, among
others libavcodec51 and libavutil49 using a snapshot from february 2008
[1]. In experimental, I've now updated the an snapshot from last week
end. Because of the version bump in libavcodec, I needed to rename the
binary package libavcodec51 -> libavcodec52, which is standard practice
in debian with SONAME bumps. The rename is done to assist transitioning
programs linking against libavcodec51: Packages not yet recompiled
against the newer ffmpeg are not instantly broken, because libavcodec51
left on the hard disk. It is only removed if nothing else depends on it.
Now something interesting happens: with the new ffmpeg snapshot
libavutil is updated as well. It features a function rename
(ff_gcd->av_gcd), which is according to the ffmpeg development policy
OK, since it is a pure private function. However this rename breaks the
libavcodec51 package horribly. [3]
In the end this means that libavutil49 must not be renamed until *all*
applications linking against any library of ffmpeg has been recompiled.
We now are aware of the issue and in future, we will express this
Transitions to a newer snapshot of ffmpeg are made terribly painful this
way. Please note that the requirement to rebuild *all* reverse depends
of a library like ffmpeg is really a problem [2] for distributions like
debian or ubuntu.
I just tell you this story because I think it greatly contributes to the
*perception* that ffmpeg changes its API/ABI too often. From a
distribution POV, stories like these have the *same* *impact* as an
API/ABI change.
1. why did you not tell this to us earlier
2. why did you not just add ff_gcd(){return av_gcd()} !?
in that sense, a patch doing 2. under #if ...VERSION < next major
is welcome!
Trivial patch attached.
looks good
Applied.

Reinhard, you could try to upgrade the libavutil package again. It should
work with both libavcodec51 and 52. If you encounter other such problems,
please tell us !

Aurel
Uoti Urpala
2009-01-26 18:41:32 UTC
Permalink
Post by Måns Rullgård
We have a public svn repository, and we put daily snapshots on the web
server. Isn't that enough?
You could make much more useful snapshots with relatively little work. I
wouldn't recommend anyone to just pick "latest svn version" for their
project; there are too frequently obvious bugs where the code doesn't
even build with some common settings. Picking some version from the last
week which didn't immediately need fixes in the next day or two when
people tried to use it would give a much better result. Developers could
regularly select such a version without much work and it would be a lot
better choice than latest svn for users who do not constantly follow the
development of FFmpeg internals.
Robert Swain
2009-01-26 15:45:35 UTC
Permalink
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
Post by Peter Ross
1. CONCERN: Quality assurance
[...]
Other projects employ bug squashing events to improve quality.
GOAL: Improve QA processes
OBJECTIVES: Extend FFmpeg regression test scripts and test cases.
Contribute FATE test cases.
Fix more bugs.
A bug squash week every now and then should be doable.
It sounds like a great idea in fact. Let's schedule one right away.
How about the weekend at the end of January?
Any takers for a bug squashing weeken scheduled for this weekend or
the next, later?
Sure. Not this weekend for me, but I should be OK for the one after.
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
And regarding releases we should atleast put together a roadmap for one.
What do you want to see in such a roadmap?
I'm sure we can come up with millions of ideas for features, but I
think our aims for release roadmaps should be centered around
improving the quality of FFmpeg by spending time on core functionality
(i.e. feature holes or weakly implemented features - libavfilter? port
major filters from mplayer? channel mixing and >2 channel resampling?
easy stream concatenation? etc. things that any multimedia
one-stop-shop should have) and documentation (developer, api user and
cli user).

Simply put, releases and their road maps should focus on reliability
and usability. The community already has enough enthusiasm for format
support in my opinion.
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
And then I think we should adopt the wine method of releasing.
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?
I think they have weekly releases for the development branch or
something like that. I'm not sure how regularly stable releases are
updated.

Regards,
Rob
Diego Biurrun
2009-01-26 21:30:52 UTC
Permalink
Post by Robert Swain
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
A bug squash week every now and then should be doable.
It sounds like a great idea in fact. Let's schedule one right away.
How about the weekend at the end of January?
Any takers for a bug squashing weeken scheduled for this weekend or
the next, later?
Sure. Not this weekend for me, but I should be OK for the one after.
What about the weekend 14/15 of February then? Any takers?

Diego
Robert Swain
2009-01-26 21:59:37 UTC
Permalink
Post by Diego Biurrun
Post by Robert Swain
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
A bug squash week every now and then should be doable.
It sounds like a great idea in fact. Let's schedule one right away.
How about the weekend at the end of January?
Any takers for a bug squashing weeken scheduled for this weekend or
the next, later?
Sure. Not this weekend for me, but I should be OK for the one after.
What about the weekend 14/15 of February then? Any takers?
Valentine's Day weekend? You expect lots of us to be available for
that? :) Unfortunately I currently have no plans.

Rob
Måns Rullgård
2009-01-26 22:34:13 UTC
Permalink
Post by Robert Swain
Post by Diego Biurrun
Post by Robert Swain
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
A bug squash week every now and then should be doable.
It sounds like a great idea in fact. Let's schedule one right away.
How about the weekend at the end of January?
Any takers for a bug squashing weeken scheduled for this weekend or
the next, later?
Sure. Not this weekend for me, but I should be OK for the one after.
What about the weekend 14/15 of February then? Any takers?
Valentine's Day weekend?
That didn't even occur to me :-(
--
Måns Rullgård
***@mansr.com
Måns Rullgård
2009-01-26 15:47:21 UTC
Permalink
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
Post by Peter Ross
1. CONCERN: Quality assurance
[...]
Other projects employ bug squashing events to improve quality.
GOAL: Improve QA processes
OBJECTIVES: Extend FFmpeg regression test scripts and test cases.
Contribute FATE test cases.
Fix more bugs.
A bug squash week every now and then should be doable.
It sounds like a great idea in fact. Let's schedule one right away.
How about the weekend at the end of January?
Any takers for a bug squashing weeken scheduled for this weekend or
the next, later?
What exactly does a bug squashing weekend entail? I'll be at FOSDEM
in Brussels the 7-8 February, so don't expect any development work
from then. Anyone else going there? You'll probably find me with the
OpenEmbedded crowd.
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
And regarding releases we should atleast put together a roadmap for one.
What do you want to see in such a roadmap?
"Roadmaps" are silly. They belong in the rubbish bin next to the
"whitepapers".
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
And then I think we should adopt the wine method of releasing.
What is that method? A quick search on Google revealed nothing.
Can anybody shine a light on this?
I have a bottle of wine. If I drink it and then do some coding, will
that help?
--
Måns Rullgård
***@mansr.com
Robert Swain
2009-01-26 16:22:02 UTC
Permalink
Post by Måns Rullgård
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
Post by Peter Ross
1. CONCERN: Quality assurance
[...]
Other projects employ bug squashing events to improve quality.
GOAL: Improve QA processes
OBJECTIVES: Extend FFmpeg regression test scripts and test cases.
Contribute FATE test cases.
Fix more bugs.
A bug squash week every now and then should be doable.
It sounds like a great idea in fact. Let's schedule one right away.
How about the weekend at the end of January?
Any takers for a bug squashing weeken scheduled for this weekend or
the next, later?
What exactly does a bug squashing weekend entail? I'll be at FOSDEM
in Brussels the 7-8 February, so don't expect any development work
from then. Anyone else going there? You'll probably find me with the
OpenEmbedded crowd.
Looking at the bug tracker or wherever else known bugs are documented
and working to resolve as many bugs as possible. It's mainly a
motivational community event that encourages developers and
contributors to squash as many bugs as they can while they're all
motivated to do so.
Post by Måns Rullgård
Post by Diego Biurrun
Post by Diego Biurrun
Post by Benjamin Larsson
And regarding releases we should atleast put together a roadmap for one.
What do you want to see in such a roadmap?
"Roadmaps" are silly. They belong in the rubbish bin next to the
"whitepapers".
Disagree. They at least show that we have some idea of the major
things that need to be improved and allow for prioritisation of issues
to be addressed. And things (CLI/API documentation, API examples) most
certainly do need to be improved and have been mostly neglected for as
long as I've had an interest in the project. Writing a roadmap itself
doesn't get these issues addressed, but it should at least increase
awareness of them.

Even if the time frame for the next release remains as "When it's
done.", if we make bite sized road map items that genuinely do improve
the usability and reliability (which are the main concerns for
releases I think...) we at least have a hope of making releases. I
would be happy to do a bit of documentation but my usual feeling is
"Where do I start?" and then nothing gets done because I can't just
look at a list of things to do and think "OK, I'll do that bit because
it'll take about half an hour to do."

FFmpeg need some organisation and improved presentation. The current
state is (and has been for some time) a rabble of interested/funded
parties working on whatever interests them/they are being paid to work
on. This is fine in many respects and the freedom is appreciated but
it isn't leading to a well-rounded, polished, professional product.

FFmpeg is obviously technically strong and is the core of open source
multimedia because of the wide format support and fairly
well-optimised implementations of said formats. It is _not_ the core
of open source multimedia because many of its community are (or are
perceived to be) unwelcoming, unhelpful and unfriendly, because its
documentation is severely lacking (I never look at the documentation
because I know it's weak whereas when using MPlayer I know the man
page is very good), because its API examples are unclear and
monolithic rather than modular (I have had to implement swscale in a
separate program and it took a lot of prodding and guess work to make
it not crash and function properly as I had to use ffplay.c and
ffmpeg.c as reference points at the time) and so on, and it has no
plans to combat these issues which are significant to many quiet
observers and outside users.

I think you underestimate the power of a little organisation.

Regards,
Rob
compn
2009-01-26 17:23:14 UTC
Permalink
Post by Robert Swain
page is very good), because its API examples are unclear and
monolithic rather than modular (I have had to implement swscale in a
separate program and it took a lot of prodding and guess work to make
it not crash and function properly as I had to use ffplay.c and
ffmpeg.c as reference points at the time) and so on, and it has no
plans to combat these issues which are significant to many quiet
observers and outside users.
an swscale howto page would fit in the wiki:
i wonder how many projects use the swscale code now.

http://wiki.multimedia.cx/index.php?title=FFmpeg_demuxer_howto
http://wiki.multimedia.cx/index.php?title=FFmpeg_codec_howto
http://wiki.multimedia.cx/index.php?title=FFmpeg_filter_howto

-compn
Måns Rullgård
2009-01-26 17:24:38 UTC
Permalink
Post by compn
Post by Robert Swain
page is very good), because its API examples are unclear and
monolithic rather than modular (I have had to implement swscale in a
separate program and it took a lot of prodding and guess work to make
it not crash and function properly as I had to use ffplay.c and
ffmpeg.c as reference points at the time) and so on, and it has no
plans to combat these issues which are significant to many quiet
observers and outside users.
i wonder how many projects use the swscale code now.
I've used it, and it wasn't difficult at all.
--
Måns Rullgård
***@mansr.com
Robert Swain
2009-01-26 17:29:56 UTC
Permalink
Post by Måns Rullgård
Post by compn
Post by Robert Swain
page is very good), because its API examples are unclear and
monolithic rather than modular (I have had to implement swscale in a
separate program and it took a lot of prodding and guess work to make
it not crash and function properly as I had to use ffplay.c and
ffmpeg.c as reference points at the time) and so on, and it has no
plans to combat these issues which are significant to many quiet
observers and outside users.
i wonder how many projects use the swscale code now.
I've used it, and it wasn't difficult at all.
I expect you're more capable than the average developer and more in
touch with the development and API style of swscale than the vast
majority of other developers who implement swscale in their
programs/libraries.

Rob
Kolb, Jeremy
2009-01-26 17:43:09 UTC
Permalink
Post by Måns Rullgård
Post by compn
i wonder how many projects use the swscale code now.
I've used it, and it wasn't difficult at all.
--
Måns Rullgård
Isn't swscale GPL only though?
Robert Swain
2009-01-26 17:44:51 UTC
Permalink
Post by Kolb, Jeremy
Post by Måns Rullgård
Post by compn
i wonder how many projects use the swscale code now.
I've used it, and it wasn't difficult at all.
Isn't swscale GPL only though?
Yes, at the moment. Work was being conducted to make swscale LGPL, at
least aside from ASM optimisations.

Regards,
Rob
Robert Swain
2009-01-26 17:37:17 UTC
Permalink
Post by compn
Post by Robert Swain
page is very good), because its API examples are unclear and
monolithic rather than modular (I have had to implement swscale in a
separate program and it took a lot of prodding and guess work to make
it not crash and function properly as I had to use ffplay.c and
ffmpeg.c as reference points at the time) and so on, and it has no
plans to combat these issues which are significant to many quiet
observers and outside users.
i wonder how many projects use the swscale code now.
http://wiki.multimedia.cx/index.php?title=FFmpeg_demuxer_howto
http://wiki.multimedia.cx/index.php?title=FFmpeg_codec_howto
http://wiki.multimedia.cx/index.php?title=FFmpeg_filter_howto
These are good points, though the first two are internal API, not
external. I was referring to external API documentation, I should have
been more clear.

Regards,
Rob
Michael Niedermayer
2009-01-26 20:15:56 UTC
Permalink
On Mon, Jan 26, 2009 at 04:22:02PM +0000, Robert Swain wrote:
[...]
Post by Robert Swain
because its API examples are unclear and
monolithic rather than modular (I have had to implement swscale in a
separate program and it took a lot of prodding and guess work to make
it not crash and function properly as I had to use ffplay.c and
ffmpeg.c as reference points at the time) and so on, and it has no
what was wrong with libswscale/swscale-example.c ?

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
Robert Swain
2009-01-26 21:52:20 UTC
Permalink
Post by Michael Niedermayer
[...]
Post by Robert Swain
because its API examples are unclear and
monolithic rather than modular (I have had to implement swscale in a
separate program and it took a lot of prodding and guess work to make
it not crash and function properly as I had to use ffplay.c and
ffmpeg.c as reference points at the time) and so on, and it has no
what was wrong with libswscale/swscale-example.c ?
Note that I was working on it back in July of 2007, so I was looking at:
http://svn.ffmpeg.org/mplayer/trunk/libswscale/swscale-example.c?revision=23722&view=markup
*Looks at the file.*

As a code example, it lacks detailed comments of what each line does.
In my opinion, code examples should be like tutorials in that they
explain what the goal of the code is, what each bit does, the
functions used, maybe which headers they're from, the arguments of the
functions etc etc. It should be very explicit and informative about
how all the code works so that a reader can very easily understand the
meaning of all the significant bits of the API and how they can be
applied to achieve something useful.

A coder will come in with a problem they want to solve. They want to
convert an image buffer from one colour space to another, or they want
to scale it, or both. They've found out that libswscale does this. How
do they use the API to do it? What format do their buffers have to be?
What initialisation needs to be done? What actually conducts the
scaling/conversion? What needs clearing up afterwards? What
performance/quality related flags can be passed through the API that
may be of interest? What other concerns might I have when using the
API?

For someone coming from the API user side with no knowledge of FFmpeg
or MPlayer but just having found libswscale, swscale-example.c did not
at that time really answer too many of those questions. One has to
(know to!) dig around in the header files for more API information and
then play around to figure out what is needed for a simple application
like those proposed above or what to change from pre-existing code to
make it work for their application.

*Looks at the file that currently exists to see if any of his
complaints have been addressed.*
Doesn't look like it. This isn't meant to be a dig at anyone for not
doing it. I'm just pointing out what I perceive to be a good quality,
easy to use code example and for what we should aim.

Michael: what do you think of what I've said?

Best regards,
Rob
Michael Niedermayer
2009-01-26 22:08:09 UTC
Permalink
Post by Robert Swain
Post by Michael Niedermayer
[...]
Post by Robert Swain
because its API examples are unclear and
monolithic rather than modular (I have had to implement swscale in a
separate program and it took a lot of prodding and guess work to make
it not crash and function properly as I had to use ffplay.c and
ffmpeg.c as reference points at the time) and so on, and it has no
what was wrong with libswscale/swscale-example.c ?
http://svn.ffmpeg.org/mplayer/trunk/libswscale/swscale-example.c?revision=23722&view=markup
*Looks at the file.*
As a code example, it lacks detailed comments of what each line does.
In my opinion, code examples should be like tutorials in that they
explain what the goal of the code is, what each bit does, the
functions used, maybe which headers they're from, the arguments of the
functions etc etc. It should be very explicit and informative about
how all the code works so that a reader can very easily understand the
meaning of all the significant bits of the API and how they can be
applied to achieve something useful.
A coder will come in with a problem they want to solve. They want to
convert an image buffer from one colour space to another, or they want
to scale it, or both. They've found out that libswscale does this. How
do they use the API to do it? What format do their buffers have to be?
What initialisation needs to be done? What actually conducts the
scaling/conversion? What needs clearing up afterwards? What
performance/quality related flags can be passed through the API that
may be of interest? What other concerns might I have when using the
API?
For someone coming from the API user side with no knowledge of FFmpeg
or MPlayer but just having found libswscale, swscale-example.c did not
at that time really answer too many of those questions. One has to
(know to!) dig around in the header files for more API information and
then play around to figure out what is needed for a simple application
like those proposed above or what to change from pre-existing code to
make it work for their application.
*Looks at the file that currently exists to see if any of his
complaints have been addressed.*
Doesn't look like it. This isn't meant to be a dig at anyone for not
doing it. I'm just pointing out what I perceive to be a good quality,
easy to use code example and for what we should aim.
Michael: what do you think of what I've said?
i fully agree
but i am too lazy to write anything ATM, a commit (no patch needed)
to swscale-example / doxy in *.h and README in libswscale is welcome

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
Diego Biurrun
2009-01-26 22:00:40 UTC
Permalink
I would be happy to do a bit of documentation but my usual feeling is
"Where do I start?" and then nothing gets done because I can't just
look at a list of things to do and think "OK, I'll do that bit because
it'll take about half an hour to do."
Is that really so hard?

Here are some ideas:

- The list of supported formats in general.texi is incomplete.
- Many files are lacking Doxygen comments.
- Much of the Doxygen comments are full of errors and harder
to understand than necessary.

That should keep you busy for some time and you can do it in small,
file-sized chunks.

I guess we should start a wiki page for this. Rob, go right ahead :)

Oh, and don't review the Doxygen in libavutil, I have that in my local
tree, will commit some time this week.

Diego
Michael Niedermayer
2009-01-26 22:13:13 UTC
Permalink
Post by Diego Biurrun
I would be happy to do a bit of documentation but my usual feeling is
"Where do I start?" and then nothing gets done because I can't just
look at a list of things to do and think "OK, I'll do that bit because
it'll take about half an hour to do."
Is that really so hard?
- The list of supported formats in general.texi is incomplete.
- Many files are lacking Doxygen comments.
- Much of the Doxygen comments are full of errors and harder
to understand than necessary.
why is fate not running doxgen and counting the warnings & errors it prints?

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
Diego Biurrun
2009-01-26 22:52:58 UTC
Permalink
Post by Michael Niedermayer
why is fate not running doxgen and counting the warnings & errors it prints?
Interesting question. It's a dozen warnings less now.

Indeed, this looks like the perfect place to find bite-sized documentation
tasks. Just fix Doxygen warnings...

Diego
Reimar Döffinger
2009-01-26 23:02:41 UTC
Permalink
Post by Michael Niedermayer
why is fate not running doxgen and counting the warnings & errors it prints?
Well, most people do not use nuclear weapons to solve a rodent problem
:-P
Or to put it more clearly: There is not really much sense in running
doxygen on loads of different architectures and operating systems,
so it does not really fit FATE...
Diego Biurrun
2009-01-26 23:07:11 UTC
Permalink
Post by Reimar Döffinger
Post by Michael Niedermayer
why is fate not running doxgen and counting the warnings & errors it prints?
Well, most people do not use nuclear weapons to solve a rodent problem
:-P
Or to put it more clearly: There is not really much sense in running
doxygen on loads of different architectures and operating systems,
so it does not really fit FATE...
This only means that Doxygen should be run on one system, whichever
one it is :)

Diego
Michael Niedermayer
2009-01-26 23:41:02 UTC
Permalink
Post by Reimar Döffinger
Post by Michael Niedermayer
why is fate not running doxgen and counting the warnings & errors it prints?
Well, most people do not use nuclear weapons to solve a rodent problem
:-P
the LD50 for mice is twice than that for humans, also mice tend to hide out of
direct sight thus would also have some stuff between them and the radiation
source significantly attenuating it.
And mice can increase their number 5 fold every 2-3 month IIRC
so even if you get 99% with no human casualties it would not be a long
lasting effect.

besides they are cute and nice animals
Post by Reimar Döffinger
Or to put it more clearly: There is not really much sense in running
doxygen on loads of different architectures and operating systems,
so it does not really fit FATE...
well i agree but also its better to run redundantly than run not at all
if it can be done just on one fate machine that of course would be fine
as well ...

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
Daniel Verkamp
2009-01-27 00:25:58 UTC
Permalink
Post by Michael Niedermayer
Post by Reimar Döffinger
Post by Michael Niedermayer
why is fate not running doxgen and counting the warnings & errors it prints?
[...]
Post by Michael Niedermayer
Post by Reimar Döffinger
Or to put it more clearly: There is not really much sense in running
doxygen on loads of different architectures and operating systems,
so it does not really fit FATE...
well i agree but also its better to run redundantly than run not at all
if it can be done just on one fate machine that of course would be fine
as well ...
I slapped together a cron job to update and run doxygen at 15-minute
intervals, counting lines of stderr output; it doesn't do anything too
fancy yet, but I would be happy to extend it if it's useful...

http://drv.nu/ffmpeg/doxygen/logs/

Thanks,
-- Daniel Verkamp
Mike Melanson
2009-01-27 04:56:52 UTC
Permalink
Post by Michael Niedermayer
Post by Reimar Döffinger
Or to put it more clearly: There is not really much sense in running
doxygen on loads of different architectures and operating systems,
so it does not really fit FATE...
well i agree but also its better to run redundantly than run not at all
if it can be done just on one fate machine that of course would be fine
as well ...
This sounds like a good idea. I'll think of a good way to implement it
for a single machine.

Actually, I thought you already had this auto-generated and posted on
the web somewhere.
--
-Mike Melanson
Diego Biurrun
2009-01-26 21:27:25 UTC
Permalink
I'll be at FOSDEM in Brussels the 7-8 February, so don't expect any
development work from then. Anyone else going there? You'll probably
find me with the OpenEmbedded crowd.
I was thinking about going and was just going to ask who will attend..

Diego
François Revol
2009-01-26 22:24:21 UTC
Permalink
Post by Diego Biurrun
I'll be at FOSDEM in Brussels the 7-8 February, so don't expect any
development work from then. Anyone else going there? You'll
probably
find me with the OpenEmbedded crowd.
I was thinking about going and was just going to ask who will
attend..
/me will be there, I have a booth for Haiku.

François.
Måns Rullgård
2009-01-26 23:07:04 UTC
Permalink
Post by François Revol
Post by Diego Biurrun
I'll be at FOSDEM in Brussels the 7-8 February, so don't expect any
development work from then. Anyone else going there? You'll
probably
find me with the OpenEmbedded crowd.
I was thinking about going and was just going to ask who will
attend..
/me will be there, I have a booth for Haiku.
Finally I'll get to meet you. Are you there for the beer party on
Friday?

BTW, I'm staying in Hotel Astrid.
--
Måns Rullgård
***@mansr.com
Aurelien Jacobs
2009-01-26 23:29:34 UTC
Permalink
Post by François Revol
Post by Diego Biurrun
I'll be at FOSDEM in Brussels the 7-8 February, so don't expect any
development work from then. Anyone else going there? You'll
probably
find me with the OpenEmbedded crowd.
I was thinking about going and was just going to ask who will
attend..
/me will be there, I have a booth for Haiku.
I should be there too.
Are you there for the beer party on Friday?
Will try to be there, but not sure at which time I will be able to arrive.
BTW, I'm staying in Hotel Astrid.
Staying at 'Hotel du Congres'.

Aurel
François Revol
2009-01-26 23:47:05 UTC
Permalink
Post by Måns Rullgård
Post by François Revol
Post by Diego Biurrun
I'll be at FOSDEM in Brussels the 7-8 February, so don't expect any
development work from then. Anyone else going there? You'll
probably
find me with the OpenEmbedded crowd.
I was thinking about going and was just going to ask who will
attend..
/me will be there, I have a booth for Haiku.
Finally I'll get to meet you.
Just don't bring nukes :P
Post by Måns Rullgård
Are you there for the beer party on
Friday?
BTW, I'm staying in Hotel Astrid.
Hmm no I'll be staying in Lille at a friend's place, so likely won't be
going to brussels just for the evening.

François.
Baptiste Coudurier
2009-01-22 20:17:06 UTC
Permalink
Hi guys,
Post by Benjamin Larsson
[...]
Post by Peter Ross
5. CONCERN: Suitability of libavformat API
Libavformat API is considered inadequate for 'tight' integration with
gstreamer.
So presently there is a libavformat wrapper within gstreamer, but is not
used by default. Gstreamer provides its own demuxers. This prohibits
demuxing of all the gamer & special-interest formats that libavformat
supports.
A similar comment was recorded on the FFmpeg TODO/wiki list years ago
concerning MPlayer.
GOAL: Make the libavformat API more appropriate to users
OBJECTIVES: Review the TODO list item, is it still valid?
Survey existing libavformat users; gather API requirements.
VLC also rolls their own demuxers so I guess it has some valid points.
Yes, definitely, I think everybody is inclined to hear problems about
its usability and API, and I, the first, will try to accomodate the
requirements.

However, it seems, unfortunately and sadly, that the will of its (past?)
users is to reinvent the wheel and recode their own, since some people
have the skills for it, while some don't for codecs (they cannot),
instead of participating, reporting problems and helping in the efforts
of improving it, so all users libavformat could benefit.

That said, I'd like to say for sure reporting from VLC people have been
really appreciated.

I find rather odd that other people comes complaining now.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer http://www.ffmpeg.org
Peter Ross
2009-01-24 02:13:52 UTC
Permalink
Post by Baptiste Coudurier
Hi guys,
Post by Benjamin Larsson
[...]
Post by Peter Ross
5. CONCERN: Suitability of libavformat API
VLC also rolls their own demuxers so I guess it has some valid points.
However, it seems, unfortunately and sadly, that the will of its (past?)
users is to reinvent the wheel and recode their own, since some people
have the skills for it, while some don't for codecs (they cannot),
instead of participating, reporting problems and helping in the efforts
of improving it, so all users libavformat could benefit.
Agree. The challenge is that projects that have written and validated their
own muxers/demuxers aren't going to switch to libavformat unless it provides
equivalent functionality.
Post by Baptiste Coudurier
That said, I'd like to say for sure reporting from VLC people have been
really appreciated.
I find rather odd that other people comes complaining now.
IIRC, the dialog on libavformat kicked off when I 'complained' that
folks were rolling their own muxer/demuxers and not using libavformat...

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
Michael Niedermayer
2009-01-22 11:03:06 UTC
Permalink
On Thu, Jan 22, 2009 at 11:55:12AM +1100, Peter Ross wrote:
[...]
Post by Peter Ross
3. CONCERN: Authorship
"The practises used to develop FFmpeg are considered as questionable."
A lot of things are considered questionable by various people these days
like, "may i use this hammer i bought to open a nut, or did i give up the
right to use the hammer as i need when i signed the EULA"
Ownership of a piece of hw or sw should end the moment it is bought/sold.
EULAs as such should be illegal they are clearly not in the interrest of the
people. We have copyright to protect the authors ...
This mess has happened because people just dont give a damn and click
the "i agree" button without ever even considering the implications or
reading the text. If companies where loosing money because people would buy
other products that have no EULAs the problem would disappear ...
Someone should write a EULA that says that the user will pay 10$ per hour
of use of some program and then see how this is digested by the courts,
either it would weaken/invalidate EULAs as such or it would open peoples
eyes about why one shouldnt agree to these things so easily.
</rant>
Anyway, reverse engeneering is legally protected thus there is nothing
questionable on it, any kind of "you may not reverse engeneer" clause is
invalid by law in europe.
Post by Peter Ross
This is perception stems from the unwillingness of authors to associate
their names with particular blobs of code.
a minority of authors are, and its understandable, not because their actions
would be questionable on legal or moral grounds but rather because if one is
a normal person and writes an independant implementation that competes with
some multi million revenue generating commercial product, one is taking some
risk. Theres no need for the big company to be legally right to be able to
cause quite some annoyance to one ...


[...]
Post by Peter Ross
5. CONCERN: Suitability of libavformat API
Libavformat API is considered inadequate for 'tight' integration with
gstreamer.
So presently there is a libavformat wrapper within gstreamer, but is not
used by default. Gstreamer provides its own demuxers. This prohibits
demuxing of all the gamer & special-interest formats that libavformat
supports.
A similar comment was recorded on the FFmpeg TODO/wiki list years ago
concerning MPlayer.
GOAL: Make the libavformat API more appropriate to users
OBJECTIVES: Review the TODO list item, is it still valid?
Survey existing libavformat users; gather API requirements.
above all we need a list of what exactly is causing problems, what exactly
can how exactly be improved, ...


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
Loading...