[MPlayer-dev-eng] mencoder start position

[The Wanderer]

D Richard Felker III wrote:

> On Sat, Dec 04, 2004 at 12:53:11PM +0100, Jérôme Petazzoni wrote:
> 
>>> When I encode normal avi file then -ss option work correct (when
>>> I choose 51,27 then encoding start from that position) but I've
>>> got a few files in matroska and I want to cut them. To check
>>> start position in frames I must extract video track (mplayer
>>> doesn't show actual frame in matroska - only decoded frames).
>>> When I've got video track extracted from mkv mplayer and mencoder
>>> as start position choose next keyframe from choosen position.
>> 
>> I seem to have the same problem with MPEG2 and MPEG4 streams. When
>> I try to extract some specific frames (with "mplayer -ss", not
>> "mencoder -ss" so I don't know if it's the same mechanism behind it
>> ...) I observe some serious discrepancies between the frames
>> extracted (I have the very same video sequence in VOB format, in
>> MPEG4 ISO (quicktime) format, and a few others ; and when trying to
>> get some specific frames, I end up with slights offsets - because
>> indeed "mplayer -ss" doesn't do accurate seeking).
>> 
>> It seems that no mplayer guru wants this feature, so we will
>> probably end up coding it ourselves :-)
> 
> For mpeg1/2 it's a totally different problem. The format sucks really
> bad, so it's impossible to do accurate seeking without being VERY
> SLOW (i.e. reading the whole file). For other file types the problem
> is mainly that you can only seek to keyframes.

Actually, unless my understanding is off, it should in principle be
possible to seek to non-keyframes in other formats if you're willing to
accept a trade-off in CPU time; the basic notion would be to seek to the
immediately preceding keyframe and then decode (but not output) frames
as needed to get to the requested point.

The advantage of this, for psople whose computers aren't fast enough to
decode all of the intervening frames in a negligible time, lies mainly
in the use of -ss and its ilk. Quite frequently, when I want to seek at
runtime to a certain point within a video file, I want to go to
*exactly* that point; I don't mind a bit of a wait while the player
starts, but I do mind not getting the time offset I requested.

(Complete tangent: it might be nice, for some of the things which I like
to do on a fairly regular basis, to be able to bind a key to "seek to
time X", X being specified at runtime. Am I correct in thinking that
this should be doable?)

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.