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

James Almer jamrial at gmail.com
Fri May 31 05:38:17 EEST 2019


On 5/30/2019 11:16 PM, Sun, Jing A wrote:
> -----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.

Yes, i can reproduce what you describe with the ffmpeg.c CLI, where
avcodec_receive_frame is called in a while(1) loop until it returns
EAGAIN after each avcodec_send_frame call.
In the end it depends on how an API user implements
avcodec_send_frame/avcodec_receive_frame, but using the encode2 API for
this purpose is ok.

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

No, with the encode2 API you should be using ff_alloc_packet2() instead.
As i said, the API user may provide it's own buffer in the avpacket
passed to avcodec_encode_video2(), which av_new_packet() would ignore
and unconditionally allocate a new one.

> 
> Regards,
> Sun, Jing
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> 



More information about the ffmpeg-devel mailing list