[BUG] MOV demuxer vs H.261 problem (was: Re: [Ffmpeg-devel] Re: Raw h261 broken)

[Diego Biurrun]

On Mon, Aug 21, 2006 at 07:25:12AM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Mon, Aug 21, 2006 at 07:12:50AM +0100, M?ns Rullg?rd wrote:
> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> 
> >> >> I don't know if lavf demuxer reports wrong size since it reports what is
> >> >> stored in mov file, quicktime also says 320x200.
> >> >
> >> > H.261 supports 2 sizes 176x144 and 352x288 so it cant be 320x200
> >> 
> >> Can't quicktime files specify a cropping to be applied after decoding?
> >
> > sure but this doesnt belong in AVCodecContext.width/heigt
> 
> No, it doesn't.  However, it should be handled somewhere.  Rereading
> the subject line, I'm not quite sure what to make of the whole thing.
> The report isn't very clear.

The subject line was about another issue that has since been fixed, so
I'll try to make another more precise bug report about this.

We have a MOV sample with H.261 video in our samples collection that
fails in ffplay and MPlayer:

http://samples.mplayerhq.hu/V-codecs/h261/lotr.mov

It plays fine in QuickTime and MPlayer when combining the native MOV
demuxer with the qt261 binary codec.  An interesting issue is that the
MPlayer native demuxer produces 320x200 as video dimensions, which
appears to be correct, while the libavformat demuxer comes up with
352x288.

Diego