On Apr 24, 2013, at 5:05 AM, Pradeep Karosiya <[email protected]> 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 sourc
 e 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
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user

Reply via email to