[FFmpeg-devel] [PATCH 2/5] ffmpeg: use the write_uncoded_frame() API.

Lukasz Marek lukasz.m.luki at gmail.com
Sat Jan 25 14:47:38 CET 2014


On 25.01.2014 04:12, Michael Niedermayer wrote:
> On Sun, Jan 19, 2014 at 03:29:15PM -0200, Ramiro Polla wrote:
>> On Sun, Jan 19, 2014 at 12:31 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>> On Sun, Jan 19, 2014 at 12:04:26PM +0100, Nicolas George wrote:
>>>> Le decadi 30 nivôse, an CCXXII, Michael Niedermayer a écrit :
>>>>> why do you need all this special casing and complexity compared to
>>>>> ramiros patch ?
>>>>
>>>> Two reasons: Ramiro's patch only handles video, while this patch handles
>>>> audio too; in Ramiro's patch, the RAW_FRAME code path skips the timestamps
>>>> rescaling and such.
>>>
>>> i was thinking of having the existing unchanged encoder generate
>>> AVPackets and all the timestamp rescaling done to them and then
>>> close to where the call to av_interleaved_write_frame() is
>>> take the timestamps from the AVPacket, put them in a AVFrame
>>> and pass that to the uncoded frame API
>>> i may very well be missing something but that would avoid having to
>>> build these fake AVPackets and would put the code in fewer seperate
>>> places
>>> There would be a useless memcpy in the encoder (but if the code is
>>> only intended for test coverage then this should not matter much
>>> and could be fixed by setting a flag telling the encoder not to do it)
>>
>> This patch started off as a way to remove an extra memcpy. In my
>> example (decklink at 1080p) it amounted to ~10% of the total time.
>
> in that case something should be done to avoid the memcpy

I haven't follow this discussion deeply, but is it blocking to merge 
first patch from the set: [PATCH 1/5] lavf: add write_uncoded_frame() API.?



More information about the ffmpeg-devel mailing list