[haiku-commits] Re: haiku: hrev52200 - src/add-ons/media/plugins/ffmpeg

  • From: Stefano Ceccherini <stefano.ceccherini@xxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 9 Aug 2018 14:49:49 +0200

Il giorno gio 9 ago 2018 alle ore 11:11 Adrien Destugues <
pulkomandy@xxxxxxxxxxxxx> ha scritto:

9 août 2018 10:47 "Stefano Ceccherini" <stefano.ceccherini@xxxxxxxxx> a
écrit:



Yes, the old API had a "1 in, 1 out" logic which did not work with modern
video encoding
(and even decoding) techniques. The new API was introduced for this
reason, but we need to adjust
our API use now.

I think that the concept of "draining" the internal buffer is not new to
the new decoupled api.
Also the old api (avcodec_decode_video2) had the concept of "draining" the
codec buffers.
Check this, for example: the api users pass a NULL AVFrame after the source
stream has finished, and keep reading the "delayed" buffers, until it's
done:

https://ffmpeg.org/doxygen/trunk/decoding__encoding_8c-source.html

(starting at line 446)

Flushing the stream on close should be possible through BMediaTrack::Flush
and BMediaFile::Close,
but may require adjustments to the API between plugins and media kit if
these events are not
forwarded to the plugin (it is ok to do, we don't have BeOS compatibility
at this level IIRC).


Other related posts: