[Ffmpeg-devel] truncated audio output
Justin Ruggles
jruggle
Mon Jun 19 19:00:59 CEST 2006
Michael Niedermayer wrote:
> Hi
>
> On Mon, Jun 19, 2006 at 12:11:26AM -0400, Justin Ruggles wrote:
>
>>After re-reading my post, I figured that my idea might be better
>>explained by a patch. Here is what it would look like if I modified the
>>pcm encoder to use my suggestion instead of frame_size=1, which is what
>>is used currently.
>
>
> i agree that a CODEC_CAP_VAR_FRAME_SIZE needs to be added ...
>
>
> [...]
>
>>Index: ffmpeg/ffmpeg.c
>>===================================================================
>>--- ffmpeg/ffmpeg.c (.../svn://svn.mplayerhq.hu/ffmpeg/trunk) (revision 5497)
>>+++ ffmpeg/ffmpeg.c (.../ffmpeg) (working copy)
>>@@ -526,7 +526,7 @@
>> }
>>
>> /* now encode as many frames as possible */
>>- if (enc->frame_size > 1) {
>>+
>> /* output resampled raw samples */
>> fifo_write(&ost->fifo, buftmp, size_out,
>> &ost->fifo.wptr);
>>@@ -551,48 +551,6 @@
>>
>> ost->sync_opts += enc->frame_size;
>> }
>>- } else {
>>- AVPacket pkt;
>
>
> i think we shouldnt drop support for leaving the packet size equal to
> the input where its supported, that said i dont mind changing the default
> to a fixed size if theres some advantage
I guess keeping equal-size-to-input support wouldn't be bad, but I don't
think a frame_size of 1 should be used to signal it. An encoder might
need to really write a frame with size 1. frame_size=0 might work, but
seems like an ugly way to do it.
I like the idea making a distinction between a codec supporting a
smaller last frame or supporting any frame size you throw at it (e.g.
PCM). I don't like the idea of using frame_size=0 though, unless there
is some other way of indicating how many samples are being passed to the
encoder. Another avctx field could work, but seems unnecessary. I am
in favor of adding 2 capabilities, CODEC_CAP_VAR_FRAME_SIZE, and
CODEC_CAP_SMALL_LAST_FRAME. A codec which supports the former could
choose to encode any number of samples thrown at it or else keep an
internal sample buffer & write encoded frames as necessary. The latter
would just need a check for smaller frame size & it would know it's the
last frame.
>
> [...]
>
>>@@ -1357,12 +1315,32 @@
>> if (ost->encoding_needed) {
>> for(;;) {
>> AVPacket pkt;
>>+ int fifo_bytes;
>> av_init_packet(&pkt);
>> pkt.stream_index= ost->index;
>>
>> switch(ost->st->codec->codec_type) {
>> case CODEC_TYPE_AUDIO:
>>- ret = avcodec_encode_audio(enc, bit_buffer, bit_buffer_size, NULL);
>>+ fifo_bytes = fifo_size(&ost->fifo, NULL);
>>+ ret = 0;
>>+ /* encode any samples remaining in fifo */
>>+ if(fifo_bytes > 0 && enc->codec->capabilities & CODEC_CAP_VAR_FRAME_SIZE) {
>>+ int fs_tmp = enc->frame_size;
>>+ enc->frame_size = fifo_bytes / (2 * enc->channels);
>>+ if(enc->frame_size > fs_tmp) {
>>+ enc->frame_size = fs_tmp;
>>+ }
>
>
> why is that check needed? if we had more data then frame_size shouldnt that
> have been encoded already? and what about non 16bit PCM?
>
> [...]
>
You're right. It's not needed. I didn't have that check there at
first, but was trying to debug a problem I encountered and forgot to
remove it.
Non-16bit PCM is converted to 16-bit before it gets here. Right now
16-bit samples coming from the decoder is assumed all throughout the
code. I guess it could be good to add a check for input sample type for
future use when other bit-depths are supported internally, but changing
it everywhere would be a daunting task. Needed...but daunting.
-Justin
More information about the ffmpeg-devel
mailing list