I don't want to be obstinate, but I'm curious as to why you would need precise
seeking beyond that provided by key frames? Are key frames intolerably far
apart for scrolling to the nearest key frame in MPlayer?
If you're using seeking to position the player properly during streaming
playback, I believe you can keep track of your position with something like the
following. It says not to do a seek if you're already close enough in the
stream. It would be nice if av_seek_frame kept track of that for you, but with
optimizations for various different stream formats it's easy to understand why
it doesn't, or why it's difficult to do.
int Reader::moveToFrame(int millis)
{
int m1 = (double) (millis+1)/_millisPerFileFrame;
int m2 = AV_TIME_BASE/1000*m1*_millisPerFileFrame;
if (abs(_nextFrame - m1) > 2)
av_seek_frame(_formatCtx, -1, m2, 0);
}
________________________________
From: Sumudu F <[email protected]>
To: [email protected]
Sent: Friday, January 27, 2012 2:52 AM
Subject: [libav-api] Need support to solve the problem in libavformat, which
led to a seeking problem in MPlayer2.exe
I’m working with the new MPlayer2.exe under windows in slave
mode. I really need a solution for this seeking problem in MPlayer2, when
seeking in MPEG1 program stream files.
I want to do
a precise seek in a MPEG1 program stream files(m2v video with mp2 audio), using
the new MPlayer2.exe precise seek command, seek <value> [type] [hr-seek].
The way I
used the command is,
seek
<value> [type] [hr-seek]
type = 2 is a seek to an absolute
position of <value> seconds.
hr-seek = 1 means force precise seek if
possible.
In my C code
I gave the command with the <value> for the time position as a double,
calculated for the required
frame. ("seek %f 2 1", fTime).
Eg- ‘seek 4.28 2 1’
This works
for MPEG2 program stream files(m2v video with mp2 audio), and other types like
.AVI.
But for MPEG1
program stream files it jumps only to
the key frames and not to the exact frame as expected.
I have
uploaded MPEG1 program stream sample files at,
http://uploading.com/files/46f51fcc/Mpeg1_mid.mpg/
http://uploading.com/files/aeda943b/Mpeg1_small.mpg/
When I asked about this from Mplayer2 support team, they
told me that , “When explicitly
specifying --demuxer=lavf the
libavformat demuxer is successfully
opened, but it then fails to do
time-based seeking properly with this
file (the only position it
successfully seeks to is the beginning).”
http://lists.mplayer2.org/pipermail/mplayer2-users/2011-December/000039.html
When I asked further, Uoti Urpala <[email protected]>
from Mplayer2 replied me as,
It's a problem in libavformat,
not directly in mplayer2 code.
So, could you please help me with this? Can I get a solution to
my problem through libavformat ?
Will you be able to correct libavformat
library to support time-based seeking properly with MPEG1 program stream files?
_______________________________________________
libav-api mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-api_______________________________________________
libav-api mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-api
