[Libav-user] AAC with FLV

Brad O'Hearne brado at bighillsoftware.com
Wed Apr 24 19:25:52 CEST 2013


On Apr 24, 2013, at 5:05 AM, Pradeep Karosiya <praks411 at gmail.com> wrote:

> Hi Brad,
> 
> Have you found the solution to your issueof audio distortion. I'm also
> facing a similar issue while encoding with AAC and this is happening for
> same audio parameters sample rate: 44100, sample format: AV_SAMPLE_FMT_FLTP
> and number of channels = 2. For mono it is working fine. So I guess the
> problem could be with planar data. Please let share with me.

Pradeep -- thanks so much for your reply! Given the hair-pulling (what little I have of it to pull) required thus far with this problem, it is encouraging to know there's someone else to validate the difficulties I am experiencing (so I have a fighting chance of still being semi-sane!)

To answer your question, no, I have not figured this out yet. As you may have gathered from my posts on this topic, I have taken a working codebase and simply changed the destination sample format for resampling (from AV_SAMPLE_FMT_S16 to AV_SAMPLE_FMT_FLTP) and the codec in play (ADPCM_SWF to AAC), and audio went from perfect to garbage. That garbage became understandable audio with distortion simply by changing the destination sample rate from 44100 (which is the same as the source sample rate) to 96000, which is completely confusing to me. 

Another poster astutely recommended to reexamine all assumptions and understand that the changes above constitute a "different situation", but in acknowledging that, it is important to note what is *not* different: the entire handling pipeline. There is absolutely zero data byte value manipulation taking place in my code -- I am merely feeding data I have to FFmpeg data / array filling, resampling, and encoding functions. The parts I'm changing are merely settings, which leads me to two possibilities I'm testing at this point: 

1. My code (specifically data array pointers on the captured samples) wasn't right to begin with, which would seem a little strange, given that it was producing perfect video / audio encoding with other settings / codec. If I had passed bad pointers or array structure / layout / population I would have expected any format to blow up. 

2. There is some issue in FFmpeg -- and you are right, the glaring difference in use case here was going from a non-planar destination to a planar destination. This was even more confusing for me, because my captured format was planar -- so as a test I skipped resampling entirely and passed the encoder my source data array (which should have been in the exact format as the destination array once resampled), and it blew up. I do believe there's an issue that revolves around the fact the destination format is planar. I mean, my original stab at this resampled from a source array with the same channel layout, sample format, and sample rate as the destination -- the encoder can take the destination fine, but blows up if I pass it the source (again, should be no different from the resampled destination) -- how weird is that?  This would seem to be a fair indication that, to quote the Princess Bride movie, "I do not think it means what you think it means", with respect to the source data array. But it sure seems weird that if I were handling the source data array improperly, that it wouldn't have blown up before and that I'd be able to get perfect audio from it using another sample format...so I'm still allowing for the possibility that swr_convert doesn't like source and destination with identical sample formats for some reason. 

I'll keep you posted. One other thing I've been looking into are the "align" parameters on a number of these functions. They aren't documented very well, and there appears to be more than one way to interpret alignment and the parameter values, so if someone could expound on that further, I'd appreciate it. 

Thanks, 

Brad


More information about the Libav-user mailing list