[MPlayer-dev-eng] Lots of stuff for NUT

Michael Niedermayer michaelni at gmx.at
Fri Jan 13 19:46:26 CET 2006


Hi

On Fri, Jan 13, 2006 at 03:26:22PM +0200, Oded Shimon wrote:
> On Fri, Jan 13, 2006 at 11:26:13AM +0200, Oded Shimon wrote:
> > On Thu, Jan 12, 2006 at 09:01:41PM +0100, Michael Niedermayer wrote:
> > > On Thu, Jan 12, 2006 at 09:27:52PM +0200, Oded Shimon wrote:
> > > > On Thu, Jan 12, 2006 at 08:06:47PM +0100, Michael Niedermayer wrote:
> > > > > On Wed, Jan 11, 2006 at 08:59:25PM +0200, Oded Shimon wrote:
> > > > > > There's one part I still have problem with - what is "current_dts"?... 
> > > > > > unfortunately, dts is not monotone across streams... you can't just grab 
> > > > > > the dts of the last frame put in the file, because you could end up with 
> > > > > > non monotone syncpoint ts.
> > > > > 
> > > > > well choosing dts is easy, do strict dts ordering
> > > > 
> > > > I thought we discussed this... :)
> > > > Didn't we finally decide on loose MN rule, not strict dts?
> > > 
> > > iam fine with either but in that case here dts ordering is easier ...
> > 
> > You'll have to decide between the 2. Either we do strict dts and single 
> > syncpoint ts, or loose MN rule and several ts's per syncpoint. It is simply 
> > impossible to have both... (If it is possible, which I doubt, it is very 
> > very complicated - start by picking the "refernce" ts for the syncpoint)
> 
> max(dts) across all streams, not including the frame right after the syncpoint.
> 
> > I vote for MN rule and several ts... It is simpler, and in any sane 
> > situation, it will only add a SINGLE ts per syncpoint. Having more than one 
> > delayed stream in a single file is extremely rare...
> > 
> > Also loose MN rule seems to please more people than strict DTS...
> > 
> > Only reason I'm slightly leaning towards single ts is because we already 
> > made a nice compression for syncpoints and adding several (optional) pts's 
> > in a compact way would be non trivial...
> 
> I went over all the details with uau, assuming we allow multiple syncpoints 
> in a single position, it IS possible to do everything, the solution is 
> "flawless", except that it is much much more difficult to implement. At the 
> very least, you need to cache all/some syncpoints and keyframes so you 
> can choose back_ptr's correctly, also flushing dts cache for EOR situation 
> and now for this max(dts) thing is rather complicated (you have to flush 
> the cache interleaved...). What makes it particularly annoying is that all 
> this extra handling only comes up at extreme scenarios, so someone could 
> make a non compliant muxer and it would be very hard to tell (without 
> inspecting the source).
> 
> The second solution comes with NO caching cost, and very little complexity:
> 
> ...write_frame...
> if (is_key) {
>         old_back_ptr = stream->back_ptr;
>         stream->back_ptr = nut->last_syncpoint;
>         if (nut->last_syncpoint != old_back_ptr) stream->key_pts = pts;
>         if (nut->last_syncpoint - old_back_ptr > nut->max_distance) put_syncpoint();
> }
> 
> and that's IT. put_syncpoint just grabs the stream->back_ptr and 
> stream->key_pts, and it's done. Simple as that...
> 
> The overhead cost is, like I said, most likely a SINGLE ts per syncpoint, 
> which most likely takes a single byte!...
> 
> Demuxer complexity is the same for both solutions...
> 
> So, Michael, what's your vote?.. My vote is to second solution...

my vote is for a single timestamp per syncpoint

your analysis of complexity is not completely objective, multiple timestamps 
all else equal are more complicated then a single one, so demuxer complexity
is higher the index format also needs to deal with various special cases like
zero back ptrs in the mutiple ts case ...

the strict DTS rule is a subset of the MN rule, so a simple muxer can always
use the DTS rule and have no more complexity then with multiple timestamps
if for whatever reason the muxer doesnt follow the strict DTS rule then it
would have some additional complexity to deal with
keeping track of all syncpoints and keyframes is pretty much needed for the
index anyway, you could also store backptrs for every stream and syncpoint
instead of the keyframes for the index sure ...

one possible method to simplify single ts + MN rule / SP TS selection might
be the following (assuming my headache doesnt affect my abbility to think)

1. add exactly one "virtual/imaginary" syncpoint stream
2. every time the muxer is feeded with a packet, add a virtual syncpoint with
its dts=pts equal to either the pts or dts (always choose the same but either
seems ok)
3. discard these virtual syncpoints as needed
4. write them like the other packets filling in ptrs and such

[...]

-- 
Michael




More information about the MPlayer-dev-eng mailing list