[FFmpeg-devel] Merge "contest"

Michael Niedermayer michaelni at gmx.at
Mon Feb 27 05:24:15 CET 2012


Hi

Iam replying here instead of todays snow docs flame as its quite a
different topic and not so much flame id say

Reimar said there that:
> If you have a specific funding proposal it would be easier for me to
> say more about this.
> But it is clear that mostly the foundation has been sponsoring big
> projects, so I have no idea what other directors think about sponsoring
> this kind of small but possibly long-term stuff.


Now this is not so much a proposal than a little bit about the "small"
above.

The daily merges are sometimes dead easy and sometimes they are not.
The hard cases can be summarized by simply being buggy to begin with
one way or another. A result that IMHO comes due to patches not being
reviewed by people who know the code 
But thats just idle talk, lets come to the point, as reimar mentioned
the work being small i skiped the hard part of todays merge. I leave
this to reimar or other interrested parties to merge. Ive added
some terse quick comments to 2 of the commits in ()
also i dont plan to merge these tomorrow or later, its really
you (plural) or they will be missing.

And about the future, I really think the community should reunite
and should work on a single open mailing list. 2 Trees or 1 or 100
is of no relevance, friendly merges are very effective (linux is the
best proof) the technical issue with the current situation are that
we are really doing enemy merges with developers not pulling on the
same string in the same direction. The social part of the hostilities
i guess i dont need to mention, everyone from both sides surely could
quote examples in large amounts. But i guess iam drifting Off topic
here so ill stop.


commit 7929e22bdea3bc40735d31ed7ddbf047732c3b9f (this looks just wrong)
Author: Anton Khirnov <anton at khirnov.net>
Date:   Mon Nov 28 21:57:06 2011 +0100

    lavf: don't guess r_frame_rate from either stream or codec timebase.

    Neither of those is guaranteed to be connected to framerate in any way
    (if it even exists).

    Fixes bug 56.

commit d3783f47eeed364aae9c916d1d659bf5f31c5ea0
Author: Anton Khirnov <anton at khirnov.net>
Date:   Mon Nov 28 09:31:48 2011 +0100

    lavf: don't set codec timebase in avformat_find_stream_info().

    It's not supposed to be set outside of lavc.

commit 832ba44d8d91d5c5ad47843085f810bde74a2e6d
Author: Anton Khirnov <anton at khirnov.net>
Date:   Tue Feb 7 11:03:33 2012 +0100

    avconv: saner output video timebase.

    r_frame_rate should in theory have something to do with input framerate,
    but in practice it is often made up from thin air by lavf. So unless we
    are targeting a constant output framerate, it's better to just use input
    stream timebase.

    Brings back dropped frames in nuv and cscd tests introduced in
    cd1ad18a6539bd7fc2dc4c1740fbcbd498c0c0a2

commit 87d7a92b62ad9b582afa0d4006c5a387e7a1bdac (this should make it impossible to represent some timestamps of some files)
Author: Anton Khirnov <anton at khirnov.net>
Date:   Tue Feb 7 08:13:05 2012 +0100

    rawdec: set timebase to 1/fps.

commit 493a86e25b9e51b45231c510cabe481ae369fb37
Author: Anton Khirnov <anton at khirnov.net>
Date:   Fri Feb 24 19:24:27 2012 +0100

    FATE: remove a bunch of useless -vsync 0

    No changes in the test results.



-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- 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/20120227/ea48ddfe/attachment.asc>


More information about the ffmpeg-devel mailing list