[FFmpeg-devel] [ANNOUNCE] ffmpeg-mt merged

Alexander Strange astrange at ithinksw.com
Wed Mar 23 07:37:19 CET 2011

On Tue, Mar 22, 2011 at 5:28 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Mar 22, 2011 at 10:12:31PM +0100, Francesco Cosoleto wrote:
>> 2011/3/22 Michael Niedermayer <michaelni at gmx.at>:
>> > But as I said previously ffmpeg is a democratic project, ffmpeg
>> > developers who plan to contribute to ffmpeg in the future and thus
>> > are affected by how the main tree looks can vote
>> I vote for undo if this is feasible, thanks.
> Good these are enough votes
> We will undo
> please noone do pushes into it, that surely can only make it worse
> and if someone wants to help (and knows git well), iam on  IRC
> Ill reset --hard to prior of the merge and then push the same diffs
> without merge metadata. Thus not pulling the history in and git not
> knowing about it

Yes, this is how I was expecting changes to be exported out of the
repository. I think some of the changes are actually easier to
understand squashed...

Since I did a lot of work + multiple merges based on the old git
conversion, I couldn't find a way to filter it to new history
properly. I wanted 'git blame' and future merging to work, so I glued
the new history together and ended up with multiple root commits.

Did the fate-fixing just consist of drawing edges in MPV_frame_end all
the time? That actually makes it draw them twice for decoding, which
might be a small speed hit but I don't think causes race conditions,
because it's just drawing the same thing twice. The problem was that
it ended up drawing 0 times for some pictures in encoding, but I
didn't investigate enough to find the cause there (besides obviously
ff_draw_horiz_band isn't called on something).

> Better ideas welcome but be quick
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> Old school: Use the lowest level language in which you can solve the problem
>            conveniently.
> New school: Use the highest level language in which the latest supercomputer
>            can solve the problem without the user falling asleep waiting.
> Version: GnuPG v1.4.10 (GNU/Linux)
> dY0AnRkhqWEnLEq8Byi2gHRPnHQP6Yne
> =Yi9X
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list