> On Wed, May 30, 2018 at 05:39:50AM +0000, Eran Kornblau wrote: > > > > > > > > > -----Original Message----- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > > Behalf Of Michael Niedermayer > > > Sent: Wednesday, May 30, 2018 12:37 AM > > > To: FFmpeg development discussions and patches > > > <ffmpeg-devel@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH 2/2] qt-faststart - optimize the > > > offset change loop > > > > > > > + *ptr++ = (current_offset >> 56) & 0xFF; > > > > + *ptr++ = (current_offset >> 48) & 0xFF; > > > > + *ptr++ = (current_offset >> 40) & 0xFF; > > > > + *ptr++ = (current_offset >> 32) & 0xFF; > > > > + *ptr++ = (current_offset >> 24) & 0xFF; > > > > + *ptr++ = (current_offset >> 16) & 0xFF; > > > > + *ptr++ = (current_offset >> 8) & 0xFF; > > > > + *ptr++ = (current_offset >> 0) & 0xFF; > > > > > > can this be simplfified with > > > libavcodec/bytestream.h, libavutil/intreadwrite.h or similar ? > > > > > > [...] > > > > > > > Yes, I can change it to AV_WB32/AV_WB64, but at the moment this > > utility is completely stand-alone - it does not depend on anything from > > ffmpeg, so maybe it's better to keep it this way. > > well, i surely wont insist but these should not add dependancies just use > inline functions and macros from headers I think it does no harm to use these > as it doesnt add a depency at link > Right, but it does add a dependency on configure, since intreadwrite.h includes libavutil/avconfig.h. I don't think it's too important, but currently I can pull only qt-faststart.c and run: gcc qt-faststart.c -o qt-faststart, which can be convenient. Anyway, let's table this patch, as I've just completed the larger patch for the issue I originally encountered (stco offset overflow). In the larger patch I locally defined AV_WB32/64, as I had to do this in multiple places.
Thanks Eran > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Awnsering whenever a program halts or runs forever is On a turing machine, in > general impossible (turings halting problem). > On any real computer, always possible as a real computer has a finite number > of states N, and will either halt in less than N cycles or never halt. > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel