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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
