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

[Swaraj Hota]

On Wed, May 08, 2019 at 09:28:33PM +0200, Reimar Döffinger wrote:
> 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

That was really helpful! Thanks a lot!
It is more or less clear to me now. Okay then I will surely try the
"complicated" one first, and fallback to the "quick fix" otherwise.
Really sorry if I am asking a lot of questions here ':D

Swaraj