[MPlayer-dev-eng] Re: [PATCH] -endpos support in mplayer::3rd try

[Paul TT]

On Thu, 1 Dec 2005 14:01:15 +0100
Alban Bedel <albeu at free.fr> wrote:

> On Thu, 1 Dec 2005 02:23:55 +0100
> Paul TT <paultt at hackerjournal.it> wrote:
> 
> > patch adding that option to mplayer and externalizing parse_end_at
> > function and field, this last passage thanx to alban bedel :-)
> > 
> > Albeu wrote:
> > 
> > >Adding up the duration of the frames that (should) have been
displayed
> > >is probably the only way to get a reliable absolute time value in
> > >mplayer. The video timestamp can (and do on many dvd) jump around
so
> > >it's not really usable imho.
> > 
> > sorry this simply doesn't work. tried it and it's less reliable. if
i
> > seek forward / backward, it count frames, but if i wanna stop after
12
> > seconds it's wrong to play a certain amount of frames, i should
indeed
> > stop after 12s, which my code does.
> 
> As said sh_video->pts is in no way an absolute time value, so you may
> very well have a 5H movie where the pts never go above 5 min. In such
> (a bit extreme but very well possible) case having -endpos 10:00 would
> do nothing and the movie would play 5H. At the very least the doc
should
> warn that, in mplayer, this option is not reliable with some
containers,
> in particular DVD.

yes, sad but true i know. hte only reliable way, for endpos and timing
osd in general would be adda nother variable which stores total time
played, not taking care of what is pts, or this is what i think, maybe i
can miss something in the way mp works, if so, sorry :(


> BTW note that i wrote "Adding up the _duration_ of the frames", this
is
> because the frame duration can vary and in such case -frames is not
> really usable. Having something equivalent to -frames but which take a
> time could be usefull imho. No need to know the fps and it would work
> reliably on VFR content and lame container.

i tried filling play_n_frames_mf with (sh_video->fps*end_at.pos), then
use it. it works, but you have the problem that going on forward, it
won't stop when reached total amount of time...

> Both approch seems usefull depending on the situation. The tricky part
> would be to find sensible and not too confusing names for the options
if
> we go for both.

can you explain better? sorry...

> > the problem is still with -ss
> > option enabled.
> > -ss option doesn't work reliably, i think i'll put my hands on this
> > after my patches'll be applied, i can't take care of too much code
> > simultaneously-or-how-ever-it's-written....
> 
> Having -ss to be exact in all case is strictly impossible. Having it
exact
> when possible is still a big task. Decoding must start on a keyframe
so the
> demuxer must seek to one. Look simple, however with some format it is
not
> possible to do efficiently, so the best you can do is seek somewhere
that
> should be near the wanted position :(

sure this is more speedy, but indeed if i (read someone) want to play
from second the 3rd, probably i mean exactly by second the 3rd...
i know the implications and the task of this, but it's a lot of time i
would put my hands in it, only now i've a little knowledge on mplayer
way-to-work to can do it

> Now even if you ignore this and assume that the demuxer of sane
formats
> will seek to the keyframe before the wanted point, you still need some
> kind of "decode to /dev/null" which is probably not trivial to
implement.
> 
> Good luck ;)

eheheheh thanx, i know i need :-))))

> > +           // FIXME: add size based support for -endpos
> > +           if ( end_at.type == END_AT_TIME && end_at.pos <
sh_video->pts )
> > +                break;
> 
> This is wrong, you must set eof instead.

ok, my fault. reformatted and reposted right now..
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mplayer_endpos9b.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20051201/bd3f6842/attachment.asc>