Commit ae8d21fb authored by Baptiste Coudurier's avatar Baptiste Coudurier

clarify avcodec_decode_audio3 and avcodec_decode_video2 doxygen

Originally committed as revision 19128 to svn://svn.ffmpeg.org/ffmpeg/trunk
parent d4a92556
...@@ -3208,11 +3208,11 @@ attribute_deprecated int avcodec_decode_audio2(AVCodecContext *avctx, int16_t *s ...@@ -3208,11 +3208,11 @@ attribute_deprecated int avcodec_decode_audio2(AVCodecContext *avctx, int16_t *s
* @note You might have to align the input buffer avpkt->data and output buffer * @note You might have to align the input buffer avpkt->data and output buffer
* samples. The alignment requirements depend on the CPU: On some CPUs it isn't * samples. The alignment requirements depend on the CPU: On some CPUs it isn't
* necessary at all, on others it won't work at all if not aligned and on others * necessary at all, on others it won't work at all if not aligned and on others
* it will work but it will have an impact on performance. In practice, the * it will work but it will have an impact on performance.
* bitstream should have 4 byte alignment at minimum and all sample data should *
* be 16 byte aligned unless the CPU doesn't need it (AltiVec and SSE do). If * In practice, avpkt->data should have 4 byte alignment at minimum and
* the linesize is not a multiple of 16 then there's no sense in aligning the * samples should be 16 byte aligned unless the CPU doesn't need it
* start of the buffer to 16. * (AltiVec and SSE do).
* *
* @param avctx the codec context * @param avctx the codec context
* @param[out] samples the output buffer * @param[out] samples the output buffer
...@@ -3259,14 +3259,12 @@ attribute_deprecated int avcodec_decode_video(AVCodecContext *avctx, AVFrame *pi ...@@ -3259,14 +3259,12 @@ attribute_deprecated int avcodec_decode_video(AVCodecContext *avctx, AVFrame *pi
* @warning The end of the input buffer buf should be set to 0 to ensure that * @warning The end of the input buffer buf should be set to 0 to ensure that
* no overreading happens for damaged MPEG streams. * no overreading happens for damaged MPEG streams.
* *
* @note You might have to align the input buffer avpkt->data and output buffer * @note You might have to align the input buffer avpkt->data.
* samples. The alignment requirements depend on the CPU: on some CPUs it isn't * The alignment requirements depend on the CPU: on some CPUs it isn't
* necessary at all, on others it won't work at all if not aligned and on others * necessary at all, on others it won't work at all if not aligned and on others
* it will work but it will have an impact on performance. In practice, the * it will work but it will have an impact on performance.
* bitstream should have 4 byte alignment at minimum and all sample data should *
* be 16 byte aligned unless the CPU doesn't need it (AltiVec and SSE do). If * In practice, avpkt->data should have 4 byte alignment at minimum.
* the linesize is not a multiple of 16 then there's no sense in aligning the
* start of the buffer to 16.
* *
* @note Some codecs have a delay between input and output, these need to be * @note Some codecs have a delay between input and output, these need to be
* feeded with avpkt->data=NULL, avpkt->size=0 at the end to return the remaining frames. * feeded with avpkt->data=NULL, avpkt->size=0 at the end to return the remaining frames.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment