[MPlayer-dev-eng] Ugly H.263 display bug

Michael Niedermayer michaelni at gmx.at
Tue Jul 20 13:55:34 CEST 2004


Hi

On Sunday 18 July 2004 03:53, attila wrote:
> On Tue, Jan 27, 2004 at 10:22:54PM +0000, Shan wrote:
> > I just noticed a really ugly bug which affects VLC as well as mplayer
> > when an AVI or MOV containing a H.263 stream with no aspect set is
> > displayed on screen and I'm at a loss over how best to fix it without
> > possibly screwing the RTP demuxer display size up!
> >
> > What happens is both parse the correct display size from the file
> > header, but during the video setup both VLC and mplayer set the display
> > size that is passed from ffmpeg's H.263 codec.  Which ends up being a
> > default size of 352x288 so you can imagine that a video that's really
> > 160x120 or 320x240 would end up having black borders added to the right
> > and bottom.
> >
> > Of course ffplay, JMF, quicktime and other players don't have a problem
> > as they take the header value as the only indication of the display
> > size.
>
> Is this problem resolved or still outstanding ?
first small explanation what "this" problem is, its simply that mov files 
store a (width,height) which may be different from the one of the video, in 
which case the player should crop, AFAIK its not fixed

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en




More information about the MPlayer-dev-eng mailing list