[FFmpeg-devel] [PATCH v2] avformat/ifv: added support for ifv cctv files

Reimar Döffinger Reimar.Doeffinger at gmx.de
Wed May 8 22:28:33 EEST 2019


On Wed, May 08, 2019 at 03:06:37PM +0530, Swaraj Hota wrote:
> On Wed, May 08, 2019 at 12:52:01AM +0200, Reimar Döffinger wrote:
> > First, seeking should be handled specially, by resetting the state.
> > You should not make the get_packet less efficient because of that.
> > That should enable the "remember last position and start from there".
> >
> > As to the corruption case, well the question is what to do about that, and I don't have the answer.
> > But if the solution were to e.g. ensure the frame offset is monotonous then binary search could be used.
> > However there is also the possibility that the format does in fact allow a completely arbitrary order of frames in the file, maybe even re-using an earlier frame_offset if the same frame appears multiple times.
> > In that case this whole offset-based positioning code would simply be wrong, and you'd have to store the current index position in your demuxer instead of relying on avio_tell.
> > Maybe you chose this solution because you did not know that seeking should be implemented via special functions?
>
> By "special functions" do you mean those "read_seek" functions that
> are present in many demuxers(Cuz I have not implemented that)?

Yes.

> If yes then am I mistaken that FFmpeg can also handle seeking
> automatically? (Carl suggesting something like that, iirc)

It has some functionality, but I think in practice I don't think
you can get a proper fully working solution with it.

> Keeping the corruption case aside, how do you suggest I implement this?
> Is it not required to skip bytes till the next frame boundary in the
> read_packet function (as done in the current patch) ?
> If not then I guess I can go with a binary search, or better yet
> remember the last position.

It's a bit more complex (in some aspect, simpler in others), but
gxf.c might be an example.

I will describe what I think would be a correct full implementation,
but I will also note that maybe this is asking a bit much.
You would start with changing your index reading function to
use av_add_index_entry instead of storing your own index.
In read_packet you simply remember your position in that index and
use that information to know where to read from the next time.
This should work for linear playback.

Once that is done, read_seek would need implementing
(it seems read_seek2 is currently only implemented by subtitle
formats?).
There you would seek the index for the right position
(av_index_search_timestamp), and set the variables you
use in read_packet accordingly so you will read the proper
frames next.
If the desired position is not in the index, you
will also need to read the next index entries from
the file (to start with you could do that by calling
read_packet, even though it is a bit overkill).

Unfortunately this is all a bit complicated and a
lot of things that need to be implemented right.
The "quick fix" would be to implement a read_seek
function that only returns -1, with that you
continue to use the current seeking code, but
it would allow you to tell the read_packet
function to use the "search index position based
on file position" code, whereas for normal
playback you just continue reading whatever
you stored as "next index position to read".

I'm sure far from everything I wrote is clear,
but hopefully it gives you some starting points.

Best regards,
Reimar Döffinger


More information about the ffmpeg-devel mailing list