On 10/3/2013 7:51 AM, Anton Khirnov wrote:
>> + avctx->coded_frame = avcodec_alloc_frame();
>
> av_frame_alloc()
No mortal can keep up with the about of API code churn.
Also, encoders in libavcodec seem to still avcodec_alloc_frame()
and av_freep().
>> + if (!avctx->coded_frame) {
>> + av_log(avctx, AV_LOG_ERROR, "Could not allocate frame.\n");
>> + return AVERROR(ENOMEM);
>> + }
>> +
>> + x265_param_default(&ctx->params);
>> +
>> + ctx->params.frameNumThreads = avctx->thread_count;
>> + ctx->params.maxCUSize = 16; /* Only require mod16 width. */
>> + ctx->params.frameRate = (int) (avctx->time_base.den /
>> avctx->time_base.num); /* No way this is right... */
>> + ctx->params.sourceWidth = avctx->width; /* TODO: Fix mid-stream res
>> changes? */
>
> We don't support those currently.
Neither does their API, I
>> + ctx->params.sourceHeight = avctx->height;
>> +
>> + if (avctx->width % ctx->params.maxCUSize) {
>> + av_log(avctx, AV_LOG_ERROR,
>> + "libx265 requires a width that is a multiple of %d.\n",
>
> It doesn't autopad like x264 does?
I don't think so -- I admit I looked at VLC's code here.
>> + for (i = 0; i < nnal; i++) {
>> + memcpy(dst, nal[i].p_payload, nal[i].i_payload);
>> + dst += nal[i].i_payload;
>> + }
>
> No timestamps?
Nope. I could generate some maybe by using the POC, but that's a pretty
horrible idea IMHO.
>> +AVCodec ff_libx265_encoder = {
>> + .name = "libx265",
>> + .type = AVMEDIA_TYPE_VIDEO,
>> + .id = AV_CODEC_ID_HEVC,
>> + .init = libx265_encode_init,
>> + .encode2 = libx265_encode_frame,
>> + .close = libx265_encode_close,
>> + .pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
>> AV_PIX_FMT_NONE },
>> + .priv_data_size = sizeof(libx265Context),
>> + .long_name = NULL_IF_CONFIG_SMALL("libx265 H.265 / HEVC"),
>
> Needs CODEC_CAP_DELAY. And possible AUTO_THREADS if applicable.
Right.
- Derek
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
