Recherche avancée

Sur d’autres sites (7406)

• FFmpeg, access violation on av_frame_free when running though Unity

  1er février 2021, par Mockarutan

  I'm working on a video recording plugin for Unity using ffmpeg. I'm new to the video encoding domain and just got my code to work today. But I think a might have a few memory leaks and trying to fix them crashes Unity.

  



  The plugin is written i c++ (as external "C" code) and imported in a c# script in unity with a simple DllImport. Again, this is not my comfort area either, but it works.

  



  When a screen buffer is rendered, I put in a RGB24 buffer and send it to my c++ function, this one :

  



  int encode_frame(uint8_t* rgb24Data)
{
    AVFrame *frame = av_frame_alloc();
    if (!frame)
        return COULD_NOT_ALLOCATE_FRAME;

    frame->format = codec_context->pix_fmt;
    frame->width = codec_context->width;
    frame->height = codec_context->height;

    int ret = av_image_alloc(frame->data, frame->linesize, codec_context->width, codec_context->height, codec_context->pix_fmt, 32);
    if (ret < 0)
        return COULD_NOT_ALLOCATE_PIC_BUF;

    SwsContext * ctx = sws_getContext(codec_context->width, codec_context->height,
        AV_PIX_FMT_RGB24, codec_context->width, codec_context->height,
        AV_PIX_FMT_YUV420P, 0, 0, 0, 0);


    uint8_t * inData[1] = { rgb24Data };
    int inLinesize[1] = { 3 * codec_context->width };

    sws_scale(ctx, inData, inLinesize, 0, codec_context->height, frame->data, frame->linesize); // From RGB to YUV

    frame->pts = frame_counter++;

    ret = avcodec_send_frame(codec_context, frame);
    if (ret < 0)
        return ERROR_ENCODING_FRAME_SEND;

    AVPacket pkt;
    av_init_packet(&pkt);
    pkt.data = NULL;
    pkt.size = 0;

    while (true)
    {
        ret = avcodec_receive_packet(codec_context, &pkt);
        if (!ret)
        {
            if (pkt.pts != AV_NOPTS_VALUE)
                pkt.pts = av_rescale_q(pkt.pts, codec_context->time_base, video_st->time_base);
            if (pkt.dts != AV_NOPTS_VALUE)
                pkt.dts = av_rescale_q(pkt.dts, codec_context->time_base, video_st->time_base);

            av_write_frame(outctx, &pkt);
            av_packet_unref(&pkt);
        }
        else if (ret == AVERROR(EAGAIN))
        {
            frame->pts = frame_counter++;
            ret = avcodec_send_frame(codec_context, frame);
            if (ret < 0)
                return ERROR_ENCODING_FRAME_SEND;
        }
        else if (ret < 0)
            return ERROR_ENCODING_FRAME_RECEIVE;
        else
            break;
    }

    // This one
    av_frame_free(&frame);
}


  



  Now, this code might have a lot of issues that I'm not aware of, and you are free to point them out if you like. But the line that gives me error is av_frame_free(&frame);.

  



  If I run this in a synthetic test app in c++ that I made, it works. I can even run it in a c# synthetic test app (exactly like the c++ one), and it works. But if I run it though Unity, it crashes on the first frame. The log says "Read from location fe7f8097 caused an access violation.".

  



  I have tried with av_freep() and av_free(). Not sure exactly what makes them different (different example codes use different ones), but none work.

  



  So, what I'm I missing ? The frame is leaking if I don't free it right ? But why does it crash in Unity ?

  



  The whole thing works great in Unity if I don't have the av_frame_free(&frame);. Resulting video looks great !

  



  PS. I'm aware (as far as I know) that the frame also leaks if something fails and returns an error code. But one thing at a time.

  


• cuda10.2 cuvidParseVideoData call back data CUVIDPICPARAMS has problem

  19 mai 2021, par goforward

  ffmpeg3.4.5 parse H265 stream, call av_read_frame(), and pass AVPacket to CUVIDSOURCEDATAPACKET,
then call cuvidParseVideoData, call is successful. but call back function pfnDecodePicture return with wrong CUVIDPICPARAMS (picwidthinmbs = 0)

  


• Roll back 4:4:4 H.264 for now

  13 juin 2011, par Jason Garrett-Glaser

  Roll back 4:4:4 H.264 for now