[MPlayer-dev-eng] [patch] DVD NAV work continues...

[Kees Cook]

On Mon, Apr 01, 2002 at 01:09:52AM +0200, Arpi wrote:
> > probably because mplayer used real stream id starting from 128 while
> > libdvdnav might map it to 0, 1 etc.
> yes

Yeah, I tried this too.  It didn't seem to help.  It might be off by one 
or something.  I'll play around once I finish my new event handler.

> > > - I have the caching subsystem check the STREAMTYPE_*, and skips if
> > >   it sees a DVDNAV stream.
> > suboptimal solution, IMHO better solution: use cache, but disable it
> > during interactive scenes. Why? because without caching dvd playback is
> > very sucking jerky...
> 
> cache cannot be enabled/disabled runtime... :(
> the whole cache code is messy (it uses fork()) and should be avoided if
> possible. it'sgood for network playback, but it still has problems with
> multiple files playback and some vo drivers.

The trouble is, I'm currently writing this to hook into libdvdnav.  As a 
result, reads from libdvdnav can't be cached because it'll be running the 
nagivational state machine the whole time.  The only way to do the cache 
"right" is to pull the dvd nav vm into mplayer which I don't want to do 
yet.

> > > - I fixed the stream seeking to not rewind a DVDNAV stream, since this
> > >   seemed to corrupt things pretty badly.  I've left the arrow keys active
> > >   for now, but they'll be disabled at some point (maybe).
> > 
> > If possible you should remap curso key for navigation during interactive
> > stuff, and use normal mapping the rest of time.
> yes

Absolutely.  That's what I meant.

> > > - Since I'm still working on getting menu navigation visible the Right 
> > >   way, I hacked in some code to draw lines around the menu box.  Since
> > >   I don't have the brain power to understand the draw_alpha routines
> > >   right now, I hacked together a "line drawing" routine using font
> > >   characters.  :)  With that routine, I draw the menu box.  Unfortunately,
> > >   you have to move the menu around at least once before it appears (this
> > >   is due to DVDNAV events...)
> > 
> > eeh, why don't you look at dvdsub/vobsub code, to findout how to draw
> > that stuff (spudec.c etc.)
> yes

Yeah, I did.  It hurt my head, and I just wanted to get something done 
quick so I could continue hooking up the rest of the stuff.  I'll come 
back to it later on.  If anyone else wants to write a quick function to 
draw a line between to coords, I'd appreciate it!  :)

> > do you have fool proof way of detecting still scenes?
> > If yes there are two solutions:
> > a) repeat still frame
> > b) disable a/vsync code during still scenes, so buffer won't overrun
> 
> i vote for a).
> b) is hard to implement, messy and needs some interface to mpeg decoders to
> force flushing last P frame (as normally they are 1 frame behind).
> a) sounds easy in viewpint of mplayer - but dunno if it's possible in stream
> layer. probably soem small hacks into libmpdemux/video.c could do
> (don't reset videobuffer pointer when still_flag is set (so next call
> will display the same frame) or such trick)

I haven't gotten too far with the still stuff.  Once I've got the events 
mapped better, I can look at this again.

I'm going to try a) as well.

How can I implement it from the mplayer.c layer?  I'm in the middle of 
adding a dvdnav_stream subsystem that mplayer.c's main loop will have 
access to, there-by removing all the dvdnav hacks from libmpdemux/* and 
putting them into the corrent layer.  That way I don't have to do the 
silly command hack to pass AID/SID changes.  And I can feed SPU palette 
changes into spudec too.

-- 
Kees Cook                                            @outflux.net