> On 28 Jan 2015, at 15:15, wm4 <[email protected]> wrote: > > On Wed, 28 Jan 2015 15:51:53 +0200 > Anton Shekhovtsov <[email protected]> wrote: > >> 2015-01-28 15:34 GMT+02:00 Nicolas George <[email protected]>: >> >>> Le nonidi 9 pluviôse, an CCXXIII, Max Vlasov a écrit : >>>> The idea was to read all packets saving pts and keyframe flag (without >>>> decoding) and make a list of them in order of ptses. After this we have a >>>> ready FrameCount and when one needs to jump to an exact frame number >>> >>> Why do people here always want to work with frame numbers? Frame numbers >>> are >>> unreliable, they are a remnant of the time where containers could only do >>> constant FPS. >>> >>> The correct way of identifying a frame is not its number, it is its >>> timestamp. >>> >>> Regards, >>> >>> -- >>> Nicolas George >>> >>> _______________________________________________ >>> Libav-user mailing list >>> [email protected] >>> http://ffmpeg.org/mailman/listinfo/libav-user >>> >>> >> Frames are important entities if the application is video editor. >> It wants to treat video as a sequence of images. It wants discrete timeline >> where each frame is a unit. >> How about buffering 40ms of video in memory? Vague. 40 frames? Required >> memory=frame_size*40. Simple. etc > > Things like FFMS2 use a complete index and a cache for this. > L-SMASH-Works (which is a different project from L-SMASH) > does something similar and is more modern, AFAIK.
The last time I tried FFMS it took 20 seconds or more to index a larger file. I don’t think that any user would be OK with that. So indexing the whole file does not sound like a good idea to me. This may however depend on the video files you’re trying to use. My application also has to deal with files a couple of gigs in size. _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
