[Libav-user] flushing internal buffers using custom I/O
Selmeci, Tamás
tselmeci at open-st.eu
Fri Apr 10 11:42:21 CEST 2015
Hello all!
I'm writing an application which receives MPEG-TS and decodes it, both
steps are performed with ffmpeg (works great!).
MPEG-TS data is received in a non-conventional way, so I'm using a
custom I/O context; the callback function in the custom I/O makes sure
the MPEG-TS data is available and passes it to ffmpeg for processing
(demultiplexing). This is needed since the MPEG-TS data we receive needs
some preparation (decryption) before ffmpeg would be able to process it.
This also works great.
As I've observed ffmpeg works somehow like this (when it comes to
demultiplexing):
- requests raw data from I/O context (from my custom I/O);
- stores raw packets internally;
- parses raw packets and puts them into a parsed-packet buffer;
- av_read_frame(...) takes a complete frame from the parsed-packet
buffer and returns it to the caller;
It definitely happens that ffmpeg stores some incomplete frames in any
of its buffers, e.g. a video frame almost always occupies more MPEG-TS
packets and until all packets are received there are incomplete internal
frames.
In this case if I feed ffmpeg (through its custom I/O) with another
MPEG-TS stream, which has all the same parameters of the previous one,
begins with a video keyframe and is in all aspects a perfect MPEG-TS
stream, the consecutive few av_read_frame(...) calls return with some
broken frames (the size is not okay) from the old MPEG-TS data (from
internal buffers). Broken flag is not set, I have to get rid of these
frames somehow.
I mean:
- feeding old MPEG-TS;
- there are some 'incomplete' frames inside;
- flush (how)?
- feeding new MPEG-TS;
- the first av_read_frame(...) returns with the first complete frame
from the new MPEG-TS;
Is there any way to force ffmpeg flush all of its internal caches so I
can get rid of these incomplete frames? Reopening the stream is not
preferred, since quite slow. I've tried many things, all of them failed.
Thanks, regards,
--
Selmeci Tamás
http://www.open-st.eu/
More information about the Libav-user
mailing list