[FFmpeg-devel] [PATCH v13 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper
Sun, Jing A
jing.a.sun at intel.com
Fri May 31 05:16:20 EEST 2019
-----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
More information about the ffmpeg-devel
mailing list