[FFmpeg-cvslog] r18896 - trunk/libavcodec/eatgq.c

Reimar Döffinger Reimar.Doeffinger
Sat May 23 17:42:11 CEST 2009


On Sat, May 23, 2009 at 04:25:11PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > So it seems to me that the commit message is quite accurate, even if
> > we might want to avoid aligned data on the stack completely in the
> > future.
> 
> Aligning stack variables is either possible or impossible.  Unreliable
> is equivalent to impossible.  The commit message is misleading.

No, unreliable meant "possible, but probably several compilers we might
like to support are broken, so it is better to avoid it".
Also I find your assertion that aligning for 8 bytes is always on any
architecture absolutely reliable more than questionable.
If you insist I can extend the commit message into such extended prose,
but I really think such details would be more appropriate in some
developer reference.
Particularly since it seems to me that your view of FFmpeg code is
severely out of touch with reality, in particular having a look at any
of these functions:
ff_check_alignment dct_sad8x8_c dv_decode_video_segment tqi_decode_frame
h263_skip_b_part dct_quantize_refine apply_mdct rtjpeg_decode_frame_yuv420
render_slice

I think I can quickly "fix" tqi_decode_frame and rtjpeg_decode_frame_yuv420
but I don't see the point if the others will probably stay as they are
now for years, unless someone else makes an effort.



More information about the ffmpeg-cvslog mailing list