[FFmpeg-devel] [PATCH 2/3] proresdec2: Replace a VLA with a heap alloc
Edward Richards
edward at edwardandalison.com
Fri Sep 7 19:35:59 CEST 2012
I would very much like it to not end up shared.
I'm looking into using proresdec2 and proresenc_kostya|anatoliy as
CODEC_CAP_FRAME_THREADS enabled. Slice threading ( CODEC_CAP_SLICE_THREADS )
isn't making large computer (eg 2x 6core Xeon) work hard enough because
there is too much singled threaded activity outside of the multi-threaded
quantization code. Multi-threading the frames (since they are I-frames) will
mask the single threaded remainder of the code.
Much thanks to you all for all your development.
While on the topic of ProRes.
The prores_kostya.c version will only set the profile by the dictionary.
This means that via library use that you can't set avctx->profile to cascade
into the prores init code.
Prores_kostya.c#908
ctx->profile_info = prores_profile_info + ctx->profile;
I currently (for legacy) am using libav, thus kostya, so I hack it (because
I'm not using the dictionary)
ctx->profile = avctx->profile;
The Anatoliy version has smarter processing of the profile. It would be
great if the anatoliy way were patched into the kostya code so that both
avctx->profile and the dictionary were supported.
if (avctx->profile == FF_PROFILE_UNKNOWN) {
avctx->profile = FF_PROFILE_PRORES_STANDARD;
av_log(avctx, AV_LOG_INFO,
"encoding with ProRes standard (apcn) profile\n");
} else if (avctx->profile < FF_PROFILE_PRORES_PROXY
|| avctx->profile > FF_PROFILE_PRORES_HQ) {
av_log(
avctx,
AV_LOG_ERROR,
"unknown profile %d, use [0 - apco, 1 - apcs, 2 -
apcn (default), 3 - apch]\n",
avctx->profile);
return -1;
}
-----Original Message-----
From: ffmpeg-devel-bounces at ffmpeg.org
[mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of Derek Buitenhuis
Sent: Friday, September 07, 2012 10:18 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 2/3] proresdec2: Replace a VLA with a
heap alloc
On 07/09/2012 12:29 PM, Derek Buitenhuis wrote:
>> the array could be moved to ProresContext avoding teh alloc/free
>> cycle per picture
>
> I didn't think once per frame was that bad.
>
> Will do, though.
Actually, it seems ProresContext is shared, so adding it might be ugly.
Opinions?
- Derek
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
More information about the ffmpeg-devel
mailing list