search

FFMS / ffms2

An FFmpeg based source library and Avisynth/VapourSynth plugin for easy frame accurate access
Other
582 stars 105 forks source link

Add a faster indexing / virtual Index #240

Closed slajar closed 6 years ago

slajar commented 8 years ago

I Imagine a second type of indexing, that returns very fast. The idea is that vbr files are estimated in length and the length is corrected afterwards when a full index is done. Sample accurateness should be achieved through the already existing cache window for audio data. Frame accurateness in video data must be done by a look ahead and Look behind algorithm. This will cause of course more CPU load.

I'd like to provide an implementation, but a first it would be great to read some thoughts about this idea.

dwbuiten commented 8 years ago

I can't imagine how this would work at all on formats that must be read linearly to get the correct info to seek accurately, or e.g. timestamps. If you open a file, and seek late in the file, lookahead/behind is not going to work here.

slajar commented 8 years ago

Hey Derek, well mostly it is not needed to have sample accurate search but sample acurate decoding. I am not sure if this is easily understandable :) Let me eplain it in more detail.

The current state is that we have sample exact search for every single sample. This is great for every case. The drawback is that we have to index the whole file and that needs one pass of entire decoding of the file in most cases.

My application doesn't need to have full precise sample exact search, but after search I need the correct following and previous samples. The same is valid for video frames. It is not necessary to have a 100% correct possition but the consecutive samples and frames must be preserved as well the audio sample to video frame alligment. I am sure this is much more complicated.

From my perspective this might be very useful for others as well. The advantage of this would be a performance boost espacially for very long files. E.g. indexing of an 1,5h divx file takes around 30 seconds on my PC. That would be completely eliminated.

slajar commented 8 years ago

What I also could imagine that full indexing might be done internally by a thread. Until it returns it works like I described above and when it is finished and the thread is synced we have the full index to work with.

dwbuiten commented 8 years ago

My application doesn't need to have full precise sample exact search, but after search I need the correct following and previous samples. The same is valid for video frames. It is not necessary to have a 100% correct possition but the consecutive samples and frames must be preserved as well the audio sample to video frame alligment. I am sure this is much more complicated.

I don't think this is within the FFMS2 use-case. I think you may be better off with using the libav* APIs directly if you need that kind of control. @tgoyne can chime in here with an opinion, probably.

From my perspective this might be very useful for others as well. The advantage of this would be a performance boost espacially for very long files. E.g. indexing of an 1,5h divx file takes around 30 seconds on my PC. That would be completely eliminated.

The libav* APIs can more or less accomplish this, though, already, no?

slajar commented 8 years ago

Well, you are right. I could use libav or ffmpeg directly. FFMS2 has a much higher level API, so it's my favourite choice. When this is so out of scope, then I might fork FFMS2 to some kind of "FFMS2-fast".

myrsloik commented 8 years ago

I've thought about adding something like this. Basically have an indexer and and a source and if a frame is requested beyond the end of what's indexed the source calls the indexer instance to proceed a bit.

The "problem" is that it'd have very few users but a slightly higher complexity. Just about everything that uses FFMS2 right now wouldn't benefit from it at all. On the other hand it'd be much easier to add now that there's only one indexer left.

dwbuiten commented 8 years ago

Basically have an indexer and and a source and if a frame is requested beyond the end of what's indexed the source calls the indexer instance to proceed a bit.

Won't this cause all sorts of seeking / trashing? Or do you intend to only demux once and keep it around in memory for use in decoding? That would require a bit of a refactor.

myrsloik commented 8 years ago

It wouldn't be that bad with two instances of ffmpeg. And if you're lucky the OS disk cache will save you from the worst evils. Also, SSD.

dwbuiten commented 8 years ago

That doesn't necessarily apply when using FFMS2 over a network (drive, or protocol), mind you.

myrsloik commented 8 years ago

That would obviously be something the end user/developer has to worry about. Implementing a cache big enough for this to work well is insane.

myrsloik commented 7 years ago

I guess another file open mode that assumes recoverable frame count and correct seeking could be added. Unfortunately I think AVI is the only notable container where this would work. Mp4, mkv and basically everything else doesn't store exact framecount or have a direct time to number of frames relation. And by then you're basically back to using the FFmpeg api like normal but with a long list of limitations.