On 31/07/15 5:40 PM, Michael Niedermayer wrote:
> On Fri, Jul 31, 2015 at 02:18:07PM -0300, James Almer wrote:
>> Signed-off-by: James Almer <jamr...@gmail.com>
>> ---
>> doc/APIchanges | 3 +++
>> libavutil/blowfish.c | 15 +++++++++++++++
>> libavutil/blowfish.h | 10 ++++++++++
>> libavutil/version.h | 5 ++++-
>> 4 files changed, 32 insertions(+), 1 deletion(-)
> [...]
>> @@ -30,12 +31,21 @@
>> * @{
>> */
>>
>> +#if FF_API_CRYPTO_CONTEXT
>> #define AV_BF_ROUNDS 16
>>
>> typedef struct AVBlowfish {
>> uint32_t p[AV_BF_ROUNDS + 2];
>> uint32_t s[4][256];
>> } AVBlowfish;
>> +#else
>> +typedef struct AVBlowfish AVBlowfish;
>> +#endif
>
> Is it intended to remove all means to allocate the context on the
> stack ?
>
> this would avoid dealing with malloc/free and malloc failure handling
> and could be a signifiant advantage also if any usecase is in a API
> that lacks the possibility to fail, like maybe some crypto callbacks
> with "void return"
I have no preferences regarding the context, really, I'm just trying to get the
API for all the modules consistent. Not sure what would be the use of an alloc
function if the context is not opaque, though.
And you're right, rtmp for example needs some considerable changes to actually
use the alloc functions.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
