Re: finding keyframes

Hello,

>> Is there call that would give the next(previous) keyframe for an
>> arbitrary position in the stream?

> The sad answer is: not right now :-(

> Currently, xine_play tries to seek to keyframes with the help of the
> demuxer. Otherwise, it just jumps in and plays what the decoders can
> deliver.

>> What can be added without too much effort and performance loss is:
>>  - query a container supplied keyframe index (mov, mp4)
>>  - build an index while playing to get previous ones at least
>>  - add "pause at next keyframe" flag

>> Not really what you want I guess?

Yes its what I want. The problem is that we have:

 xine_play (xine_stream_t *stream, int start_pos, int start_time)

seeking to a different position than the value contained in some
system of index's that the application maintains which wreakes havoc
with synchonizing different streams and events, and to build up a
table of keyframes would solve this and probably many other problems
since typically seeks are to keyframes. Consider the case of trying to
seek by 2 seconds back from the current position and the nearest
keyframe is 1.7 seconds away. You can see that repeated seeks will
always seek to the same position, whereas if you seek by keyframe as
the basic unit the problem is solved. ( If I got my example right )
Another case of seeking to a specific frame. You seek to the nearest
previous keyframe, build up the subsequent frames without displaying
them and finally arrive at your frame, display it and continue.

The scenario you describe above would be fairly easy to implement
at the application level, but at the the xine library level
it would be lightning fast to create an index for the entire
container. ( And it would actually be very big )

Bruce


On 5/18/17, Torsten Jager <[email protected]> wrote:
> Hello,
>
>> Is there call that would give the next(previous) keyframe for an
>> arbitrary
>> position in the stream?
>
> "Dropping message with timestamp 20170504172059 because it is too old
> (diff 13012544)."
>
> OK, sorry for that delay.
>
> The sad answer is: not right now :-(
>
> Currently, xine_play tries to seek to keyframes with the help of the
> demuxer. Otherwise, it just jumps in and plays what the decoders can
> deliver.
>
> What can be added without too much effort and performance loss is:
>   - query a container supplied keyframe index (mov, mp4)
>   - build an index while playing to get previous ones at least
>   - add "pause at next keyframe" flag
>
> Not really what you want I guess?
>
> Torsten
>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot