[MPlayer-dev-eng] NUT (informal) proposal, based on discussions
Oded Shimon
ods15 at ods15.dyndns.org
Wed Jan 18 12:36:07 CET 2006
On Wed, Jan 18, 2006 at 03:54:34AM +0100, Michael Niedermayer wrote:
> On Tue, Jan 17, 2006 at 09:20:02PM -0500, Rich Felker wrote:
> > yes, there are problems we've been discussing on irc too. some of the
> > problems have a fix by changing the definition of the back_ptr
> > appropriately, but i don't know if they all do. i'm still
> > investigating. will let you know when there's an update, unless you
> > come up with a brilliant idea first. :)
>
> some rule like:
> there must be no interval of max_distance in which any stream has a keyframe
> but no back ptr anywhere including outside this intervall pointing to any
> keyframe of that stream in the interval
>
> in our case above both K2 and K15 would need some syncpoints pointing to
> them to fullfill this ...
I'm not sure I understand this rule, but I think it comes at relatively
high implementation cost in muxer...
I think we are back to complexity, and I want that gone... I have 2 votes:
1. Per stream pts and back_ptr in syncpoints, with this syncpoint placement
rule:
When putting a keyframe for a certain stream, if it makes back_ptr change
by more than T, queue a syncpoint to be written before the next keyfame for
this stream. If by then a syncpoint has already been written, don't bother.
Pro: simplest, most elegant, easiest to implement.
Con: obviously overhead, and theoretically it does contain redundant
data...
2. Go back to single back_ptr and pts. Michael said it best:
also consider that 1ptr+1pts and per stream ptr+pts differ only if all of
the following are true:
1. no index
2. there is at least one stream with a large keyframe intervall which the
user doesnt want to seek to / decode
3. the user wants to seek more exactly then the largest keyframe interval
of any stream
4. the media is slow so that the time to read the largest keyframe interval
is significant, also keep in mind here that due to 1. we will have O(log n)
physical seeks anyway no matter what we do
- in conclusion, there is no problem of speed of linear search, it's
really not bad at all...
The two cons IMO:
1. Seeking with index and without is very different. It might be possible
to collapse the syncpoints into a dynamic index, I'm not sure.
2. Behavior with large interval keyframe streams is slightly undefined
(info streams, userdata streams, subtitles...)
I think I'm done looking into increasingly complicated solutions and focus
on these 2. :/
- ods15
More information about the MPlayer-dev-eng
mailing list