On Thu, Jul 2, 2015 at 3:13 PM, Rostislav Pehlivanov
<atomnu...@gmail.com> wrote:
> This commit implements intensity stereo coding support to the native aac 
> encoder. This is a way to increase the efficiency of the encoder by zeroing 
> the right channel's spectral coefficients (in a channel pair) and rederiving 
> them in the decoder using information from the scalefactor indices of special 
> band types. This commit confomrs to the official ISO 13818-7 specifications, 
> although due to their ambiguity certain deviations have been taken to ensure 
> maximum sound quality. This commit has been extensively tested and has shown 
> to not result in audiable audio artifacts unless in extreme cases. This 
> commit also adds an option, aac_is, which has the value of 0 by default. 
> Intensity Stereo is part of the scalable aac profile and is thus non-default.
>
> The way IS coding works is that it rederives the right channel's spectral 
> coefficients from the left channel via the scalefactor index values left in 
> the right channel. Since an entire band's spectral coefficients do not need 
> to be coded, the encoder's efficiency jumps up and it unzeroes some high 
> frequency values which it previously did not have enough bits to encode. That 
> way less information is lost than the information lost by rederiving the 
> spectral coefficients with some error. This is why the filesize of files 
> encoded with IS do not decrease significantly. Users wishing that IS coding 
> should reduce filesize are expected to reduce their encoding bitrates 
> appropriately.
>
> This is V2 of the commit. The old version did not mark ms_mask as 0 since M/S 
> and IS coding are incompactible, which resulted in distortions with M/S 
> coding enabled. This version also improves phase detection by measuring it 
> for every spectral coefficient in the band and using a simple majority rule 
> to determine whether the coefficients are in or out of phase. Also, the 
> energy values per spectral coefficient were changed as to reflect the 
> official specifications.


This one also looks identical to a WIP I thoroughly tested, so I
believe this means the whole set is good to be pushed, if a committer
agrees.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to