Libavcodec AAC - Revision history

109.252.91.225: /* Gapless decoding support */

2022-01-28T23:29:01Z

Gapless decoding support

← Older revision		Revision as of 23:29, 28 January 2022
Line 42:		Line 42:
	{{main\|Gapless playback}}		{{main\|Gapless playback}}

	AAC encoding groups samples into frames of 512/1024/2048 samples. There is padding of extra samples at the start, due to encoder delay, or at the end only if there less than the exact number or samples needed to fill a frame. These extra samples will be decoded as additional silence if they are not trimmed or in some scenarious (remainder) even as not silence but artifacts, priming is always silence. AAC in raw form (.adts or .latm) provides no way to signal how many samples need to be trimmed (only app that wrote it is written and that can be used to decide on what to remove), so this information is stored in the container, ffmpeg only supports the ISO variant (media time and media duration in editlist and roll metadata was added recently that allows to correctly decode first sample after priming), but Apple's music is using iTunSMPB metadata, which is ~~not~~ supported by FFmpeg.		AAC encoding groups samples into frames of 512/1024/2048 samples. There is padding of extra samples at the start, due to encoder delay, or at the end only if there less than the exact number or samples needed to fill a frame. These extra samples will be decoded as additional silence if they are not trimmed or in some scenarious (remainder) even as not silence but artifacts, priming is always silence. AAC in raw form (.adts or .latm) provides no way to signal how many samples need to be trimmed (only app that wrote it is written and that can be used to decide on what to remove), so this information is stored in the container, ffmpeg only supports the ISO variant (media time and media duration in editlist and roll metadata was added recently that allows to correctly decode first sample after priming), but Apple's music is using iTunSMPB metadata, which is again only supported for priming removal by FFmpeg.
	* FFmpeg's decoder will trim from the beginning, but not the end, though it writes correct metadata for both at least in native encoder. Remainder removal was fixed by chromium's fork of ffmpeg: https://bugs.chromium.org/p/chromium/issues/detail?id=668999 but still not upstreamed. Firefox is still broken in both priming and remainder.		* FFmpeg's decoder will trim from the beginning, but not the end, though it writes correct metadata for both at least in native encoder. Remainder removal was fixed by chromium's fork of ffmpeg: https://bugs.chromium.org/p/chromium/issues/detail?id=668999 but still not upstreamed. Firefox is still broken in both priming and remainder.
	* Libav's decoder will not trim at all.		* Libav's decoder will not trim at all.

109.252.91.225: /* Gapless decoding support */

2022-01-28T14:34:41Z

Gapless decoding support

← Older revision		Revision as of 14:34, 28 January 2022
Line 42:		Line 42:
	{{main\|Gapless playback}}		{{main\|Gapless playback}}

	AAC encoding groups samples into frames of 512/1024/2048 samples. There is padding of extra samples at the start, due to encoder delay, or at the end only if there less than the exact number or samples needed to fill a frame. These extra samples will be decoded as additional silence if they are not trimmed or in some scenarious (remainder) even as not silence but artifacts, priming is always silence. AAC in raw form (.adts or .latm) provides no way to signal how many samples need to be trimmed (only app ~~thag~~ wrote ot is written and that can be used to decide on what to remove), so this information is stored in the container, ffmpeg only supports the ISO variant (media time and media duration in editlist and roll metadata was added recently ~~thag~~ allows to correctly decode first sample after priming), but Apple's music is using iTunSMPB metadata, which is not supported by FFmpeg.		AAC encoding groups samples into frames of 512/1024/2048 samples. There is padding of extra samples at the start, due to encoder delay, or at the end only if there less than the exact number or samples needed to fill a frame. These extra samples will be decoded as additional silence if they are not trimmed or in some scenarious (remainder) even as not silence but artifacts, priming is always silence. AAC in raw form (.adts or .latm) provides no way to signal how many samples need to be trimmed (only app that wrote it is written and that can be used to decide on what to remove), so this information is stored in the container, ffmpeg only supports the ISO variant (media time and media duration in editlist and roll metadata was added recently that allows to correctly decode first sample after priming), but Apple's music is using iTunSMPB metadata, which is not supported by FFmpeg.
	* FFmpeg's decoder will trim from the beginning, but not the end, though it writes correct metadata for both at least in native encoder. Remainder removal was fixed by chromium's fork of ffmpeg: https://bugs.chromium.org/p/chromium/issues/detail?id=668999 but still not upstreamed. Firefox is still broken in both priming and remainder.		* FFmpeg's decoder will trim from the beginning, but not the end, though it writes correct metadata for both at least in native encoder. Remainder removal was fixed by chromium's fork of ffmpeg: https://bugs.chromium.org/p/chromium/issues/detail?id=668999 but still not upstreamed. Firefox is still broken in both priming and remainder.
	* Libav's decoder will not trim at all.		* Libav's decoder will not trim at all.

194.186.220.205: /* Gapless decoding support */

2022-01-28T13:05:38Z

Gapless decoding support

← Older revision		Revision as of 13:05, 28 January 2022
Line 42:		Line 42:
	{{main\|Gapless playback}}		{{main\|Gapless playback}}

	AAC encoding groups samples into frames of 512/1024/2048 samples. There ~~may be~~ padding of extra samples at the start, due to encoder delay, or at the end if there less than the exact number or samples needed to fill a frame. These extra samples will be decoded as additional silence if they are not trimmed. AAC provides no way to signal how many samples need to be trimmed, so this information is stored in the container, ~~likely~~ in ~~the mp4~~ iTunSMPB ~~atom~~.		AAC encoding groups samples into frames of 512/1024/2048 samples. There is padding of extra samples at the start, due to encoder delay, or at the end only if there less than the exact number or samples needed to fill a frame. These extra samples will be decoded as additional silence if they are not trimmed or in some scenarious (remainder) even as not silence but artifacts, priming is always silence. AAC in raw form (.adts or .latm) provides no way to signal how many samples need to be trimmed (only app thag wrote ot is written and that can be used to decide on what to remove), so this information is stored in the container, ffmpeg only supports the ISO variant (media time and media duration in editlist and roll metadata was added recently thag allows to correctly decode first sample after priming), but Apple's music is using iTunSMPB metadata, which is not supported by FFmpeg.
	* FFmpeg's decoder will trim from the beginning, but not the end. ~~This~~ was fixed by chromium's fork of ffmpeg: https://bugs.chromium.org/p/chromium/issues/detail?id=668999		* FFmpeg's decoder will trim from the beginning, but not the end, though it writes correct metadata for both at least in native encoder. Remainder removal was fixed by chromium's fork of ffmpeg: https://bugs.chromium.org/p/chromium/issues/detail?id=668999 but still not upstreamed. Firefox is still broken in both priming and remainder.
	* Libav's decoder will not trim at all.		* Libav's decoder will not trim at all.

109.252.91.225: /* Gapless decoding support */

2022-01-28T09:59:42Z

Gapless decoding support

← Older revision		Revision as of 09:59, 28 January 2022
Line 43:		Line 43:

	AAC encoding groups samples into frames of 512/1024/2048 samples. There may be padding of extra samples at the start, due to encoder delay, or at the end if there less than the exact number or samples needed to fill a frame. These extra samples will be decoded as additional silence if they are not trimmed. AAC provides no way to signal how many samples need to be trimmed, so this information is stored in the container, likely in the mp4 iTunSMPB atom.		AAC encoding groups samples into frames of 512/1024/2048 samples. There may be padding of extra samples at the start, due to encoder delay, or at the end if there less than the exact number or samples needed to fill a frame. These extra samples will be decoded as additional silence if they are not trimmed. AAC provides no way to signal how many samples need to be trimmed, so this information is stored in the container, likely in the mp4 iTunSMPB atom.
	* FFmpeg's decoder will trim from the beginning, but not the end.		* FFmpeg's decoder will trim from the beginning, but not the end. This was fixed by chromium's fork of ffmpeg: https://bugs.chromium.org/p/chromium/issues/detail?id=668999
	* Libav's decoder will not trim at all.		* Libav's decoder will not trim at all.

C3POwen: Minor page reformatting.

2018-10-15T18:07:59Z

Minor page reformatting.

← Older revision		Revision as of 18:07, 15 October 2018
Line 1:		Line 1:
			{{DISPLAYTITLE:libavcodec AAC}}
	{{aac-encoders}}		{{aac-encoders}}
	The multi-codec library, ''libavcodec'', includes an AAC encoder and decoder. The library was created as part of FFmpeg, and forked with Libav. Both projects maintain a separate version of libavcodec.		The multi-codec library, '''libavcodec''', includes an '''AAC''' encoder and decoder. The library was created as part of [[FFmpeg]], and forked with Libav. Both projects maintain a separate version of libavcodec.

	The original native AAC encoder was written by Konstantin Shishkov, and released under version 2.1 of the LGPL. It was considered experimental and poor quality compared to non-free/commercial encoders, but at least free. For GSoC 2015, Claudio Freire and Rostislav Pehlivanova did a significant amount of work on the AAC encoder that would be included in FFmpeg 3.0 (February 2016), and FFmpeg has declared this encoder stable (at least for CBR) and ready for common use. Libav has not merged this new work, and continues to use the original experimental encoder.		The original native AAC encoder was written by Konstantin Shishkov, and released under version 2.1 of the LGPL. It was considered experimental and poor quality compared to non-free/commercial encoders, but at least free. For GSoC 2015, Claudio Freire and Rostislav Pehlivanova did a significant amount of work on the AAC encoder that would be included in FFmpeg 3.0 (February 2016), and FFmpeg has declared this encoder stable (at least for CBR) and ready for common use. Libav has not merged this new work, and continues to use the original experimental encoder.
Line 11:		Line 12:
	* libaacplus, the very old Coding Technologies HE-AAC[v2] encoder. (support removed in FFmpeg 3.0)		* libaacplus, the very old Coding Technologies HE-AAC[v2] encoder. (support removed in FFmpeg 3.0)

	== Sample ~~Rates~~ ==		== Sample rates ==
	;FFmpeg 3.0+:Supports sample rates for input of 7350, 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000, 64000, 88200, and 96000 Hz.		===FFmpeg 3.0+===
			Supports sample rates for input of 7350, 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000, 64000, 88200, and 96000 Hz.

	== Channel ~~Layouts~~ ==		== Channel layouts ==
			===FFmpeg 3.0+===
	;FFmpeg 3.0+:
	{\| class="wikitable"		{\| class="wikitable"
	! Channels !! Layout !! Description		! Channels !! Layout !! Description
Line 39:		Line 40:
	==Issues==		==Issues==
	===Gapless decoding support===		===Gapless decoding support===
	~~:''See [[~~Gapless playback~~]] for more on the general topic.''~~		{{main\|Gapless playback}}

	AAC encoding groups samples into frames of 512/1024/2048 samples. There may be padding of extra samples at the start, due to encoder delay, or at the end if there less than the exact number or samples needed to fill a frame. These extra samples will be decoded as additional silence if they are not trimmed. AAC provides no way to signal how many samples need to be trimmed, so this information is stored in the container, likely in the mp4 iTunSMPB atom.		AAC encoding groups samples into frames of 512/1024/2048 samples. There may be padding of extra samples at the start, due to encoder delay, or at the end if there less than the exact number or samples needed to fill a frame. These extra samples will be decoded as additional silence if they are not trimmed. AAC provides no way to signal how many samples need to be trimmed, so this information is stored in the container, likely in the mp4 iTunSMPB atom.
	* FFmpeg's decoder will trim from the beginning, but not the end		* FFmpeg's decoder will trim from the beginning, but not the end.
	* Libav's decoder will not trim at all		* Libav's decoder will not trim at all.

	===Embedded album art===		===Embedded album art===
	Album art embedding is not supported the same way it is for MP3. Use -vn if the source file contains album art, or it will try to convert it to MP4 video and fail.		Album art embedding is not supported the same way it is for MP3. Use -vn if the source file contains album art, or it will try to convert it to MP4 video and fail.

	== External links ==		== External links ==
	* [https://en.wikipedia.org/wiki/Libavcodec libavcodec] at Wikipedia
	* [https://trac.ffmpeg.org/wiki/Encode/AAC#fdk_aac FFmpeg AAC encoding guide]		* [https://trac.ffmpeg.org/wiki/Encode/AAC#fdk_aac FFmpeg AAC encoding guide]
	* [https://wiki.libav.org/Encoding/aac Libav AAC encoders]		* [https://wiki.libav.org/Encoding/aac Libav AAC encoders]
			* {{wikipedia\|libavcodec}}

	[[Category:Encoder/Decoder]]		[[Category:Encoder/Decoder]]

Bp: /* Issues */ album art

2016-07-05T19:16:28Z

Issues: album art

← Older revision		Revision as of 19:16, 5 July 2016
Line 43:		Line 43:
	* FFmpeg's decoder will trim from the beginning, but not the end		* FFmpeg's decoder will trim from the beginning, but not the end
	* Libav's decoder will not trim at all		* Libav's decoder will not trim at all
			===Embedded album art===
			Album art embedding is not supported the same way it is for MP3. Use -vn if the source file contains album art, or it will try to convert it to MP4 video and fail.

	== External links ==		== External links ==

Bp: supported sample rates and channel formats

2016-07-05T19:13:24Z

supported sample rates and channel formats

@@ Line 10: / Line 10: @@
 * [[VisualOn AAC|libvo-aacennc]], the very poor VisualOn AAC encoder. (support removed in FFmpeg 3.0)
 * libaacplus, the very old Coding Technologies HE-AAC[v2] encoder. (support removed in FFmpeg 3.0)
 ==Issues==

Bp: +visualon aac link

2016-07-02T19:02:28Z

+visualon aac link

← Older revision		Revision as of 19:02, 2 July 2016
Line 8:		Line 8:
	* [[Fraunhofer FDK AAC]], via libfdk-aac. Both frameworks recommend using this encoder if it is available, but it is non-free.		* [[Fraunhofer FDK AAC]], via libfdk-aac. Both frameworks recommend using this encoder if it is available, but it is non-free.
	* [[FAAC]], via libfaac.		* [[FAAC]], via libfaac.
	* libvo-aacennc, the very poor VisualOn AAC encoder. (support removed in FFmpeg 3.0)		* [[VisualOn AAC\|libvo-aacennc]], the very poor VisualOn AAC encoder. (support removed in FFmpeg 3.0)
	* libaacplus, the very old Coding Technologies HE-AAC[v2] encoder. (support removed in FFmpeg 3.0)		* libaacplus, the very old Coding Technologies HE-AAC[v2] encoder. (support removed in FFmpeg 3.0)

Bp: gapless info

2016-06-28T09:28:15Z

gapless info

← Older revision		Revision as of 09:28, 28 June 2016
Line 10:		Line 10:
	* libvo-aacennc, the very poor VisualOn AAC encoder. (support removed in FFmpeg 3.0)		* libvo-aacennc, the very poor VisualOn AAC encoder. (support removed in FFmpeg 3.0)
	* libaacplus, the very old Coding Technologies HE-AAC[v2] encoder. (support removed in FFmpeg 3.0)		* libaacplus, the very old Coding Technologies HE-AAC[v2] encoder. (support removed in FFmpeg 3.0)

			==Issues==
			===Gapless decoding support===
			:''See [[Gapless playback]] for more on the general topic.''
			AAC encoding groups samples into frames of 512/1024/2048 samples. There may be padding of extra samples at the start, due to encoder delay, or at the end if there less than the exact number or samples needed to fill a frame. These extra samples will be decoded as additional silence if they are not trimmed. AAC provides no way to signal how many samples need to be trimmed, so this information is stored in the container, likely in the mp4 iTunSMPB atom.
			* FFmpeg's decoder will trim from the beginning, but not the end
			* Libav's decoder will not trim at all

	== External links ==		== External links ==

Bp: +faac

2016-06-28T02:44:39Z

+faac

← Older revision		Revision as of 02:44, 28 June 2016
Line 7:		Line 7:
	The FFmpeg/Libav frameworks can also use other encoding libraries, if they are available.		The FFmpeg/Libav frameworks can also use other encoding libraries, if they are available.
	* [[Fraunhofer FDK AAC]], via libfdk-aac. Both frameworks recommend using this encoder if it is available, but it is non-free.		* [[Fraunhofer FDK AAC]], via libfdk-aac. Both frameworks recommend using this encoder if it is available, but it is non-free.
			* [[FAAC]], via libfaac.
	* libvo-aacennc, the very poor VisualOn AAC encoder. (support removed in FFmpeg 3.0)		* libvo-aacennc, the very poor VisualOn AAC encoder. (support removed in FFmpeg 3.0)
	* libaacplus, the very old Coding Technologies HE-AAC[v2] encoder. (support removed in FFmpeg 3.0)		* libaacplus, the very old Coding Technologies HE-AAC[v2] encoder. (support removed in FFmpeg 3.0)