On 10/20/12 6:59 PM, John Stebbins wrote:
On 10/15/2012 09:36 AM, Diego Biurrun wrote:
On Mon, Oct 15, 2012 at 06:01:17PM +0200, John Stebbins wrote:
On 10/15/2012 05:38 PM, Diego Biurrun wrote:
On Sun, Oct 14, 2012 at 05:41:03PM +0200, John Stebbins wrote:
On 10/14/2012 05:14 PM, Luca Barbato wrote:
On 10/14/2012 04:52 PM, John Stebbins wrote:
+ uint8_t forced;
why uint8_t ? I guess it would require a version bump btw.
In itself looks a good feature (and probably the players would enjoy
having this information)
Is the version number bump something I should do in the patch, or do you
prefer handling that yourselves?
It's preferable you do it lest it be forgotten.
Ok. I'm unfamiliar with how libav versioning works. Can you educate me
or point me to the write document? I.e. what file and what define gets
changed in this case?
http://www.libav.org/developer.html#Development-Policy
16. Remember to check if you need to bump versions for the specific
libav parts (libavutil, libavcodec, libavformat) you are changing. You
need to change the version integer. Incrementing the first component
means no backward compatibility to previous versions (e.g. removal of
a function from the public API). Incrementing the second component
means backward compatible change (e.g. addition of a function to the
public API or extension of an existing data structure). Incrementing
the third component means a noteworthy binary compatible change (e.g.
encoder bug fix that matters for the decoder).
In your case I think bumping the minor number should be appropriate.
Thanks. Patch updated.
Looks fine to me, I'll push during the weekend if nobody beats me at it
(sorry for the delay).
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
