[FFmpeg-devel] [PATCH v13 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Sun, Jing A]

-----Original Message-----
From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of James Almer
Sent: Thursday, May 30, 2019 11:35 PM
To: ffmpeg-devel at ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v13 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

>Why the switch to encode2? All previous versions were using the send/receive API, and seeing SVT also uses a decoupled input/output API, it was certainly the most adequate option.
>Were you running into some issue? A quick look at v12 shows you were using ff_alloc_packet2(), which afaik you shouldn't have. It's meant for the encode2() API only, where user provided buffers are allowed, and it alone does not ensure the packet will be reference counted, which is required for the send/receive API.

Hi James,

Yes I indeed was running into an issue. Although SVT uses a decoupled input/output API, it calls the two by the below method:
    while(not stopped) {
    send_frame(one frame);
    if (receive_packet(one frame’s pkt) != empty)
        save_bitstream;
    }
In one round, none or only one packet is receive.

However, if using v12's send_frame/receive_packet implementation, it is possible that multiple of receive_packet are executed in one round.
    while(not stopped) {
        send_frame(one frame);
        while(1) {
            if (receive_packet(one frame’s pkt) == empty)
                break;
            else
                save_bitstream;
        }
    }

The first calling method's sequence is like:
    Send 579
    Receive 487
    Send 580
    Receive 496
    Send 581
    Receive 492
    Send 582
    Receive 490
    Send 583
    Receive 489
    Send 584
    Receive 491
    Send 585
    Receive 494
    Send 586
    Receive 493
    Send 587
    Receive 495
And the second one's is:
    Send 579
    Receive empty
    Send 580
    Receive 489
    Receive 491
    Receive 494
    Receive 493
    Receive 495
    Receive empty
    Send 581
    Receive 504
    Receive empty
    Send 582
    Receive empty
    Send 583
    Receive empty
    Send 584
    Receive 500
    Receive empty
    Send 585
    Receive empty
    Send 586
    Receive empty
    Send 587

When we input the source frame at the constant frequency 60, the first one's each second's output frames are ~60, [59, 61], while the second one's tends to be like 64(63) ->57(58) ->64(63) ->57(58)… 
Besides the average FPS, the stableness of each second's FPS is also important to us. So I changed the API to encode2, because in encode2, I can control the SVT's send_frame/receive_packet calling sequence, and let it not do receive_packet more than once in one round.

And thanks for the information on ff_alloc_packet2. I changed to use av_new_packet in v13 and hope it's OK.

Regards,
Sun, Jing