You should take a look at the fifo functions that would cache the audio for you and you would feed the encoder the number of samples you see fit.
2015-01-21 8:31 GMT-03:00 Max Vlasov <[email protected]>: > Hi, > > When sample rate conversion is needed, one can face another problem. Some > codecs reports they don't have CODEC_CAP_VARIABLE_FRAME_SIZE capability so > accept only some fixed frame size buffers with an exception for the last > block. I tried to find a working example, but it seems they often lack full > support for such cases. Obviously one may cache converter results and > output by necessary blocks, but this involves supporting several buffers > for planar data and knowing exact format. > > With own experiment I tried to do the following: > 1) For the required dest_frames use infamous formula > av_rescale_rnd(swr_get_delay(...) + inp_frames,... > trying to detect the number of input frames (inp_frames here) necessary > for at least dest_frames (src_frames). Either with binary search or just by > using an incrementer > 2) call swr_convert with src_frames as the number of input frames, but > pass exactly dest_frames as output. So the converter have to cache some > input frames since I limited the output buffer. > > The approach worked at least for some cases, but there are problems I > faced: > - I have to use much larger dest_frames (currently it is twice as large). > Otherwise sometimes swr_convert reports making several bytes less than I > requested (1535 instead of 1536). I suspect this is because swr_get_delay > is approximate in most cases. The question is whether should I fix this > multiplier (x2) or use some other approach for this detection. > - I can not figure out how correctly get the last cached frames from the > converter and not violate the rule for frame_size (it should have the same > size with every step except the last one). When I fed the last input bytes, > I probably already get non-standard output so another call with Null and 0 > as input will produce extra non-standard block. > > Any help will be appreciated > > Thanks, > > Max > > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user > > -- Gonzalo Garramuño [email protected]
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
