[FFmpeg-devel] release status
Sun Mar 1 22:31:56 CET 2009
On Sun, Mar 01, 2009 at 08:58:23PM +0000, Robert Swain wrote:
> 2009/3/1 Michael Niedermayer <michaelni at gmx.at>:
> > On Sun, Mar 01, 2009 at 07:48:04PM +0000, Robert Swain wrote:
> >> 2009/3/1 Michael Niedermayer <michaelni at gmx.at>:
> >> > On Sun, Mar 01, 2009 at 07:10:59PM +0100, Diego Biurrun wrote:
> >> >> There has been a flurry of activity during the past days. ?I must admit
> >> >> I have lost track of current issues. ?So, are there any regression fixes
> >> >> pending or any regressions or nasty new bugs that need to be addressed?
> >> >>
> >> >> Does HEAD compile and pass regression tests on all OSes and CPU
> >> >> architectures? ?FATE looks reasonably green right now but I would
> >> >> like to hear more explicit OKs from you as well.
> >> >
> >> > The sooner we release the sooner we are back to normal development
> >> >
> >> > if you ask about outstanding issues, well
> >> > * h264 timestamps still have a heap of issues but less than 2 weeks ago, i
> >> > ?suspect they could be fixed in 1-2 weeks if ivan works hard on them but it
> >> > ?could take longer
> >> But are there any regressions versus before all this timestamp stuff kicked off?
> > It wasnt working before
> > If you ask me if the random timestamps where by luck sometimes correct and
> > that by more luck they are wrong in that case now, well iam not aware of a
> > specific case but i did not search for one either (it was said, you dont have
> > to work for the release just dont be in its way ...)
> OK, so these changes have been improvements, good. I wasn't aware
> things were significantly broken before and just had the impression
> that you were trying to clean things up/generalise the implementation.
hehe, no h264 timestamps where random, they still are in many cases,
theres a reason why vsync is disabled on many conformance tests on fate ...
> Admittedly I didn't follow the threads about timestamp issues too
> > [...]
> >> > * ive found some bugs in the parser but my fix does not yet pass regresions
> >> > ?ivans work depends on this fix i suspect as it will make handling pos
> >> > ?easier
> >> See my first comment.
> > i can commit my fixes if you want but i make no promise about the regressions
> > that might cause (make test, the h264 conformance & some random files pass)
> > also these are all old bugs no regressions as far as i can see
> Hmm, I suspect if you had enough confidence in it to make the change
> before the release, you would have committed it already.
they are very minor issues ...
one issue is that fetch_timestamp() was using a wrong variable, but it happned
to be equal to the correct one from where its called
Then fetch_timestamp() was called at the end of the frame and this could with
invalid streams have caused the timestamps to be flushed out of the buffer
when i now changed the buffers to include all packets (one thing needed to
track of pos as ivan needs) fetch_timestamp no longer had timestamps as they
where flushed out from the timestamp less packets ...
> Anyway, on to productive discussion. I started to look at what needed
> to be done to make sure swscale is available in LGPL earlier this week
> but I have been side-tracked since. I will return to it ASAP.
> > when it comes to imgconvert we have people who "have to" fix things if
> > imgconvert is droped we should use them. And keep in mind its to some
> > part at least people who use ffmpeg for their commercial LGPL requireing
> > code, i have little interrest to work for free to make non(/half free use of
> > ffmpeg easier.
> See above comments about commercial entities and their relationship
> with FFmpeg. I do think we should be receiving more sponsorship from
> various commercial users of FFmpeg though, only as long as these users
> do not try to steer the course of our development in a negative way.
> It is clear that FFmpeg's good parts are such high quality because of
> the pedantism and attention to every last detail of the code. That
> must persist.
steering imgconvert/swscale is already happening as you can see ...
theres no real technical reason to delay imgconvert droping
> > [...]
> >> > ? ?And i like to see the next done without a freeze of HEAD.
> >> Hmm, so what do you propose? A tag and branch, backporting fixes to
> >> the branch up until we make the release?
> > just throw a dice each week and when you get a 2 do a svn up and
> > make a tarball [except of course if something is known to be broken]
> > it worked fine for our users since ages to use 'svn up' from random
> > times ...
> I think the tag and branch approach may be better. ;p
i dont mind at all but we have no manpower to backport anything so its
as good as releasing straight ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel