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

[Michael Niedermayer]

On Wed, Mar 23, 2011 at 02:37:19AM -0400, Alexander Strange wrote:
> 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?

yes, it was the only thing needed to make fate pass with default
parameters. Which i felt was sufficient to merge it.


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

The problem is ff_draw_horiz_band() isnt used in encoding at all but
the edges need to be drawn on encoding too.
the MPV_frame_end() draw_edges case could be skiped for decoding but
done for encoding.
should be a trivial + && s->encoding in there
that would avoud the 2x drawing


--
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110323/d9fac764/attachment.asc>