Il giorno gio 9 ago 2018 alle ore 10:09 Adrien Destugues <
pulkomandy@xxxxxxxxxxxxx> ha scritto:
9 août 2018 09:12 "Stefano Ceccherini" <stefano.ceccherini@xxxxxxxxx> aYou're right.
écrit:
hrev52200 adds 1 changeset to branch 'master'^53a5dca9d7f0
old head: 53a5dca9d7f01ef9d23a8f12f0d6ef57b9d56fcd
new head: f049e59f5022cf7fa0d4c091d637a529cdf4f521
overview: https://git.haiku-os.org/haiku/log/?qt=range&q=f049e59f5022+
----------------------------------------------------------------------------
buffers.
f049e59f5022: Try to use the ffmpeg api more correctly:
call avcodec_receive_packet() in a loop, drain and flush the internal
Introduced private method to improve code readability (hopefully).
[ JackBurton79 <stefano.ceccherini@xxxxxxxxx> ]
+ // Pass a NULL AVFrame and enter "draining" mode, then flush buffers
+ // before restarting encoding, again.
+ // TODO: It's probably not very efficient to do it like this. We should
+ // do this only when there is no more data (when closing the "stream")
+ _EncodeVideoFrame(NULL, pkt, info);
+ avcodec_flush_buffers(fCodecContext);
+ av_packet_free(&pkt);
+ return ret;
It is even incorrect to do this. The point of the API is that you can send
several
frames, and ffmpeg may encode them out-of-order. This is used a lot in
MPEG and
other modern codecs, where some frames are derived from data both in
previous and
next ones (https://users.cs.cf.ac.uk/Dave.Marshall/Multimedia/node258.html
).
When you enter draining mode, you prevent this from happening, as ffmpeg
will never
have the "next" frame to work with.