On 5/30/2019 11:16 PM, Sun, Jing A wrote: > -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > James Almer > Sent: Thursday, May 30, 2019 11:35 PM > To: ffmpeg-devel@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
