[MPlayer-users] Solved! (was Re: Problem: some videos freeze, other very similar videos do not--difference might be just in resolution (pixels)--how to convert?)

[Reimar Döffinger]

On Sat, Oct 22, 2011 at 06:28:00AM -0400, Randy Kramer wrote:
> Reimar,
> 
> Thanks for that!  Some followups below:
> 
> On Saturday 22 October 2011 06:06:05 am Reimar Döffinger wrote:
> > On Fri, Oct 21, 2011 at 04:39:46PM -0400, Randy Kramer wrote:
> > > I got the problem solved.
> > >
> > > It turns out it was related to the 1000 fps for the container. ("Seems
> > > stream 0 codec frame rate differs from container frame rate: 1000.00...")
> >
> > 1000 fps really means variable frame-rate in MPlayer.
> 
> Thanks--it's good to learn something.  Does it matter whether that 1000 fps is 
> from the container or for (from?) the codec?  

I suspect that MPlayer overrides the container value, causing some
strange messages or something.

> > Most likely there's something wrong with the first frame's time stamp.
> 
> Do you know of any sort of more "surgical" tool that might let me examine and 
> edit the first frame's time stamp (and/or the container frame rate) without 
> doing a conversion on the entire file?

I doubt that would help, there's some very specific bug that breaks it.

> > I think your MPlayer version might be old enough that -demuxer lavf
> > helps.
> 
> Looks like it, as there is a -demuxer option in man mplayer.  But, I normally 
> (other than when testing) use gmplayer with a playlist.  I'm sure I could 
> answer this question for myself with a little digging, but since I'm asking 
> questions anyway, I'll ask: is there a way to apply the -demuxer option to 
> only certain files (not all are the same format) in a (plain text) playlist?

Read up on per-file config files.
Note for upgrade: Your MPlayer version probably will read them still
when they are in the same directory as the video.
That is probably a massive security issue and by default MPlayer now
only takes them from ~/.mplayer

> > But as said, I am quite confident that this is just a result of using
> > too old code.
> 
> Ok, that's interesting also--so you think that if I upgraded mplayer, it could 
> handle the 1000 fps framerate (for the container) and the different 29.nn 
> frame rate for the codec without choking, as my current mplayer does?

As Carl pointed out, yes.