[MPlayer-cvslog] CVS: main/libmpcodecs vd_ffmpeg.c,1.137,1.138

[Michael Niedermayer]

Hi

On Monday 06 December 2004 17:38, D Richard Felker III wrote:
> On Mon, Dec 06, 2004 at 05:11:19AM +0100, Michael Niedermayer CVS wrote:
> > CVS change done by Michael Niedermayer CVS
> >
> > Update of /cvsroot/mplayer/main/libmpcodecs
> > In directory mail:/var2/tmp/cvs-serv17497/libmpcodecs
> >
> > Modified Files:
> >  vd_ffmpeg.c
> > Log Message:
> > fix byteorder
> >
> >
> > Index: vd_ffmpeg.c
> > ===================================================================
> > RCS file: /cvsroot/mplayer/main/libmpcodecs/vd_ffmpeg.c,v
> > retrieving revision 1.137
> > retrieving revision 1.138
> > diff -u -r1.137 -r1.138
> > --- vd_ffmpeg.c 28 Nov 2004 18:37:49 -0000 1.137
> > +++ vd_ffmpeg.c 6 Dec 2004 04:11:17 -0000 1.138
> > @@ -303,9 +303,9 @@
> >          } else {
> >       /* has extra slice header (demux_rm or rm->avi streamcopy) */
> >       unsigned int* extrahdr=(unsigned int*)(sh->bih+1);
> > -     ((uint32_t*)avctx->extradata)[0] = extrahdr[0];
> > -     avctx->sub_id=
> > -     ((uint32_t*)avctx->extradata)[1] = extrahdr[1];
> > +     ((uint32_t*)avctx->extradata)[0] = be2me_32(extrahdr[0]);
> > +     avctx->sub_id= extrahdr[1];
> > +     ((uint32_t*)avctx->extradata)[1] = be2me_32(extrahdr[1]);
>
> are you sure this is the best way? 

no its certainly not


> imo extradata should be treated as 
> a block of raw binary data from the file, and libavcodec, not the
> calling program, should be responsible for knowing and interpreting
> the byte order... 

yes, exactly, but mplayers obfuscated rm demuxer byteswaps the data so this 
only swaps it back to how its stored in the file


> but maybe there's a reason this one is special..? 

[...]
-- 
Michael

"I do not agree with what you have to say, but I'll defend to the death your
right to say it." -- Voltaire