How to speed up positioning in a remote flv file when accessing via http?

For those who want to miss the tedious introduction - the solution is at the very end.

Each format has its own options that can be played. What you want is called seek, not all formats and not in all cases it is supported: for example, if your source is a simple HTTP server, such as Apache or nginx, and a video file is a simple file on disk, then the possibility of non-sequential rewinding is determined file format, as well as server settings: can it send a file from an arbitrary location (check it is simple: with wget -c, start downloading the file, interrupt and try again - if the download continues, it means supported, if it starts again, it means no), plus does the server return file size in headers (returns - you are lucky, no returns - no).

If at least one of the above conditions is not fulfilled, then the rewind will be consistent - i.e. the file will be read to the desired timestamp.

In addition, if the server is streaming, and the file is not really a file, but the canonical name of stream and stream is Live, then there will be no rewinding. If the stream is VOD - the presence of rewind depends on whether the server can for this transport (http) or not (the calculations for a regular server are correct here).

At this introductory finish. Let's get down to business.

At the entrance you have a stack of formats (in FFmpeg terminology): tcp -> http -> flv.

The flv format does not know how to rewind in time - it redirects it to the layer below (to the protocol part: for example, rtmp can handle such requests). However, the Http protocol cannot be rewound due to the fact that it is not designed for this, exactly like a regular file "protocol" (when accessing a local file). But (subject to the conditions above), the implementation can rewind byte-by-byte. Actually, the rewind itself is carried out inside, with the help of a higher-level function, which first tries to make time rewind (in the case of flv format and http protocol, this attempt is filed), if it failed, then rewind using an index (in fact, the index stores certain temporary labels and the corresponding offset). If there is no index (or for some other reason that does not allow using it), then sequential reading of frames is used, comparing their PTS with the specified one.

So, in the case of flv, the index table is not supported. More precisely, at the FFmpeg level, it is implemented and created dynamically for already read content, i.e. Rewind to still unread data can be done, in this bundle (http + flv, file + flv), only by sequential reading. Direct rewinding is feasible only in the rtmp + flv bundle, provided the media server supports it (in this case it will be VOD streaming, you can take nginx-rtmp as a tape drive for this).

Summarizing: you have chosen the wrong bunch of format and protocol. At a minimum, try changing the format to mkv (matroska).

UPD : answering-learn. Meta information can be attached to the flv file with the help of flvtool2, this meta information can be understood by ffmpeg:

 flvtool2 -UP media-file.flv 

For details: http://www.brooksandrus.com/blog/2007/03/18/flvtool2-flash-video-flv-metadata-cue-point-injector-and-cutting-tool/

And a few more utilities for adding meta-information of this kind: https://superuser.com/questions/286074/avoid-ffmpeg-to-lose-the-flv-files-keyframes/287441 # 287441

Ffmpeg itself does not need to pass any additional options.

There is a small chance that the server from which you are going to download supports HTTP pseudo streaming , and then you can simply add the parameter ?start=60 to the link. In your version like this:

 ffmpeg -i http://example.com/videofile.flv?start=60 -t 00:01:00 -vcodec copy -acodec copy file.flv 

But first check with the VLC player or in the browser that at the other end you are correctly understood with this parameter and give up 60 minutes immediately.