[FFmpeg-devel] [RFC] Frame accurate seeking

Artur Bodera abodera
Wed Dec 30 16:31:47 CET 2009


On Wed, Dec 30, 2009 at 3:46 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de>wrote:

> So this is about the FFmpeg program, not the libraries.
> The project you linked to only provides a library interface.
>
It's a concept, not solution.



> No idea if it is possible with FFmpeg but it should be obvious how to do
> it with any program using libavcodec by changing the source code.
>
That doesn't make any sense. It's like you implied that seeking should be
dumped altogether and handled by 3rd party app, because ffmpeg is just for
encoding or decoding start-to-finish.

It's kind of important and common use case to be able to encode/decode
chunks of videos (or join them together). And yeah yeah, ffmpeg is not an
editing tool and none expects it to be blah blah. Anyways, IMO _seeking_ is
core functionality. If -ss and -t jumps around a few seconds forth and back,
some users will call a bug, I will call a missing feature because I know how
gop can be messy - still the core is the best place for implementation.



>  Which now again has nothing at all to do with frame-accurate seeking,
> since that is only possible with decoding (which ffmpeg-fas does, too,
> and which you do not want to do).
>
Either you're trying really hard not to understand it, or not willing to
help. It's obvious that decoding is needed to know where keyframes are. The
only workaround to the jerky -ss and -t right now is to decode the file to
rawvideo or "gop 1" or "all-l-frame" video, then seek it, then encode it
again. I'm looking for a way to work around it or implement properly so it
stopped being a guessing game of +/- x frames



> Either the ffmpeg-fas project has some completely hidden features that
> are not mentioned anywhere or it has nothing to do with what you
> described that you wanted above.
> Particularly since for .mp4 file seeking is "frame accurate" as far as
> possible due to missing key frames (i.e. for an all-I-frame video it
> should be frame accurate).
> Allowing frame-accurate when decoding IIRC should be possible by putting
> the -ss behind the input file name (never tested it though, and I
> suspect it could be much improved).
>

And we're back to square one. I tested it, IT DOESN'T WORK. You can try
putting it behind or before it is still not accurate. Exact use cases and
examples have been provided in the link before (from ffmpeg-user).




> frame-accurate without decoding simply is not possible, the closest you
> could probably get is finding a tool that tells you where the keyframes
> are and then using those values with FFmpeg. I don't know of such a tool
> though and it doesn't belong on this list anyway.
>

It's not a tool, it's a feature called seeking. Because I want to seek to
frame xxxx , I call it frame-accurate seeking - if the words have not been
chosen right, please correct me.

I've noticed that -vframes is frame-accurate - it will extract and merge all
types of frames. For fps 25 the "-t 0 -vframes 25" will correctly produce
first 25 frames. 23.98 fps and -t > 0 or -ss > 0 gives strange results.

The most basic use case I can think of now is - file.mp4 --  25fps, 1min in
length, split it in half:
ffmpeg -i file.mp4 -t 30 -acodec copy -vcodec copy chunk1.mp4
ffmpeg -i file.mp4 -ss 00:00:30 -acodec copy -vcodec copy chunk2.mp4

Should work, doesn't.


-- 

     __
    /.)\   +48 695 600 936
    \(./   abodera at gmail.com



More information about the ffmpeg-devel mailing list