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 _______________________________________________ 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".
