Re: Lots of stuff for NUT

On Sat, Dec 31, 2005 at 11:35:56PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sat, Dec 31, 2005 at 05:12:40PM -0500, Rich Felker wrote:
> > On Sat, Dec 31, 2005 at 10:54:16PM +0100, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Sat, Dec 31, 2005 at 04:30:20PM -0500, Rich Felker wrote:
> > > > On Sat, Dec 31, 2005 at 09:34:03PM +0100, Michael Niedermayer wrote:
> > > > > > > hmm, why not simply make larger decode_delay illegal?
> > > > 
> > > > Impossible; it's not known. What if I set B frame strategy to 1, and
> > > > the encoder decides never to use a B frame? Then my file is illegal!
> > > > Or, even if it does eventually use a B frame, the partly written file
> > > > is illegal until it gets to the B frame. Any law that can only be
> > > > evaluated by looking globally at the file rather than locally at all
> > > > parts is inherently broken.
> > > 
> > > no, thats wrong, in mpeg1/2/4 theres a flag (low_delay) in the header 
> > > which specifies the delay, if low_delay=0 b frames are allowed but even if
> > > there are none the delay is still 1 not 0, having the demuxer produce 
> > > dts=pts frames in this case is _wrong_
> > > 
> > > furthermore using mts ordering does not remove the need to know decode
> > > delay exactly as decode_delay is needed for calculating DTS
> > 
> > OK, I think we're thinking about things from different perspectives.
> > Your perspective is that dts corresponds to something outside of NUT,
> > and that NUT demuxer needs to provide correct dts to the codec/player.
> > I think this is reasonable for mpeg1/2/4, but maybe not for all codecs

Re: Lots of stuff for NUT

On Sat, Dec 31, 2005 at 11:22:33PM -0500, Rich Felker wrote:
> [...]

We have decided that MN rule is sufficient for "strict interleaving" with 
strict "minimum" decode_delay. There is no "correct behavior", choosing 
between dts and mts is practically arbitrary, so MN rule is the way to go.

Now, I have some other bad news.
Rich and I were discussing syncpoint timestamps a lot, and were unable to 
choose between doing "max(past dts)" or "min(future pts)" (dts or mts).
After much research: BOTH are wrong!

"|"  are syncpoints
"A" is method "max(dts)" for syncpoints
"B" is method "min(pts)" for syncpoints

              V
  A:  0 1 2 3 4 5 6 7
dts:-1|0|1|2|3|4|5|6|7
pts: 0|1|2|3|6|4|5|7|8
     I|P|P|P|I|B|B|P|P
mts: 0|1|2|3|4|4|5|7|8
  B:  1 2 3 4 4 5 7 8
              ^

I Want pts "4.5". Both methods point me to syncpoint pointed by "V". This 
syncpoint's back_ptr is pointing to the second "I". But look at what pts 
that "I" has! "6"!! seek completely failed to give me requested position.

I have a brand new suggestion:

Please add fourcc "DAVC" to codecs.conf

Hi,

the attached patch should add the capability to play AVI files with the
fourcc "DAVC" or "davc" if applied to codecs.conf.

If I play the files with mplayer, I can not watch the movie with a real
full screen view - is there a way to do this, too?

Best regards,

Johannes Ranke

--- codecs.conf?rev=1.443	2005-12-31 19:24:00.000000000 +0100
+++ codecs.conf	2006-01-01 13:12:31.000000000 +0100
 <at>  <at>  -501,6 +501,7  <at>  <at> 
   fourcc H264,h264
   fourcc X264,x264
   fourcc avc1
+  fourcc davc,DAVC
   format 0x10000005
   driver ffmpeg
   dll h264

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: Lots of stuff for NUT

On Sun, Jan 01, 2006 at 01:35:40PM +0200, Oded Shimon wrote:
> 2. the ts of syncpoint is: pts of last keyframe written to file, including 
> one right after the syncpoint. Actually, it can be just about anything and 
> it'll still be correct, but this is best IMO.

Dammit, wrong again. The PTS of keyframes is not monotone across the file. 
Even in the example I gave above, the PTS's were " 1 2 6 3 4 5 6". You 
can't have syncpoint's ts not be monotone. I think the new back_ptr method 
should still be done, however the pts of syncpoints still needs more 
thought.

- ods15

Hi, a newbie on the list

Hi,

I've downloaded mplayer source code, and got it
working. 

My intention is to develop a custom and simple ogg
music player which responses to some keys from the
keyboard, as well as an avi or mpeg video player, so I
thought on mplayer for doing this.

I'd like to know if there's any resource where I can
get info on mplayer's api, in order to achieve my
goal.

I suposse I'm in the right place, I mean, mplayer is a
good solution for this that I want to do. Whether not,
would really appreciate as well any coments on this.

Kind Regards, and happy new year.

		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Re: Hi, a newbie on the list

chinlu chinawa wrote:

>Hi,
>
>I've downloaded mplayer source code, and got it
>working. 
>
>My intention is to develop a custom and simple ogg
>music player which responses to some keys from the
>keyboard, as well as an avi or mpeg video player, so I
>thought on mplayer for doing this.
>  
>
yes, but there's nothing simple in what you want to do or in
media players in general

>I'd like to know if there's any resource where I can
>get info on mplayer's api, in order to achieve my
>goal.
>
>  
>

read slave.txt

[PATCH] better management of mpg subs

Hi,
this patch permits to _really_ show subs embedded in vob files using 
-sid (that generally doesn't work);
naturally mplayer, after this patch, maintains its current behavior when 
playing dvds.
If no one objects I'll commit it tomorrow.

    Nico

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: Hi, a newbie on the list

Hi,

Thanks Nico. Well this could definetely work for me.
My app could wait for keyboard events, and then send
desired commands to a running mplayer in slave mode,
thanks very much.

Just checking that I explained myself properly (sorry
my english I'm actually spanish). I didn't meant to
actually "develop" a custom player but  using
mplayer's api to do this. Exaclty as you point with
the -slave option, but a bit more low level.

Kind Regards, 

--- Nico Sabbi <nicola_sabbi <at> fastwebnet.it> wrote:

> chinlu chinawa wrote:
> 
> >Hi,
> >
> >I've downloaded mplayer source code, and got it
> >working. 
> >
> >My intention is to develop a custom and simple ogg
> >music player which responses to some keys from the
> >keyboard, as well as an avi or mpeg video player,
> so I
> >thought on mplayer for doing this.
> >  

Re: [PATCH] support vme=8 (iterative overlapped block)

2005/12/30, Corey Hickey <bugfood-ml <at> fatooh.org>:
> Thanks, everyone. I appreciate the votes of confidence. :)
>
> > Send Attila a mail with your username and first password and go read
> > DOCS/tech/cvs-howto.txt.
>
> Done.

One more (optinal thing).
If you come with registed nick in irc.freenode.org #mplayerdev channel
you will get op status there. Even if you don't want it you can find
mplayer developer slacking there. ;)
It won't be bad if your nick is same as your commit nick.

Re: Lots of stuff for NUT

On Sun, Jan 01, 2006 at 01:35:40PM +0200, Oded Shimon wrote:
> On Sat, Dec 31, 2005 at 11:22:33PM -0500, Rich Felker wrote:
> > [...]
> 
> We have decided that MN rule is sufficient for "strict interleaving" with 
> strict "minimum" decode_delay. There is no "correct behavior", choosing 
> between dts and mts is practically arbitrary, so MN rule is the way to go.
> 
> 
> Now, I have some other bad news.
> Rich and I were discussing syncpoint timestamps a lot, and were unable to 
> choose between doing "max(past dts)" or "min(future pts)" (dts or mts).
> After much research: BOTH are wrong!
> 
> "|"  are syncpoints
> "A" is method "max(dts)" for syncpoints
> "B" is method "min(pts)" for syncpoints
> 
>               V
>   A:  0 1 2 3 4 5 6 7
> dts:-1|0|1|2|3|4|5|6|7
> pts: 0|1|2|3|6|4|5|7|8
>      I|P|P|P|I|B|B|P|P
> mts: 0|1|2|3|4|4|5|7|8
>   B:  1 2 3 4 4 5 7 8
>               ^
> 
> I Want pts "4.5". Both methods point me to syncpoint pointed by "V". This 
> syncpoint's back_ptr is pointing to the second "I". But look at what pts 
> that "I" has! "6"!! seek completely failed to give me requested position.