[Ffmpeg-devel] truncated audio output

Justin Ruggles jruggle
Mon Jun 19 22:12:00 CEST 2006

M?ns Rullg?rd wrote:
> Michael Niedermayer said:
>>On Mon, Jun 19, 2006 at 10:01:36AM +0100, M?ns Rullg?rd wrote:
>>>Michael Niedermayer said:
>>>>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 ...
>>>Couldn't a frame_size of 0 be used to signal this?  Permitting a partial
>>>last frame is also useful with some codecs.
>>but what frame size would then be used for the previous frames?
>>a codec might not support arbitrary large ones or might not allow non fixed
>>except for the last
> That would require a new flag.
>>if all codecs which support arbitrary small last frames also support
>>arbitrary large frames anywhere then of coarse frame_size=0 would be
>>enough and iam fine with that too ...
> That's the case I meant frame_size=0 would be used for.
> Whatever solution we pick, it has to be able to handle both partial final
> frame and true variable frame size.

How does this patch look?

I have added capability flags for handling either true variable frame
size or small final frame.  frame_size=0 is used to indicate that the
codec has no particular preference as to frame size.  A codec could
conceivably set CODEC_CAP_VAR_FRAME_SIZE and still set a specific
frame_size to indicate that it prefers that particular size (for speed
reasons maybe) but has the capability to handle any size.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: var_frame_size.diff
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060619/acfae051/attachment.asc>

More information about the ffmpeg-devel mailing list