[MPlayer-cvslog] r33795 - trunk/mencoder.c

[Ivan Kalvachev]

On 7/2/11, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> On 2 Jul 2011, at 19:13, iive <subversion at mplayerhq.hu> wrote:
>
>> Author: iive
>> Date: Sat Jul  2 19:13:26 2011
>> New Revision: 33795
>>
>> Log:
>> Increase video muxer output frame size.
>>
>> A user experienced broken encode when using ffvhuf with HD material.
>> 8MB should be enough for raw 1920x1080 32bpp frame.
>>
>> Modified:
>>   trunk/mencoder.c
>>
>> Modified: trunk/mencoder.c
>> ==============================================================================
>> --- trunk/mencoder.c    Sat Jul  2 10:17:45 2011    (r33794)
>> +++ trunk/mencoder.c    Sat Jul  2 19:13:26 2011    (r33795)
>> @@ -835,7 +835,7 @@ muxer->audio_delay_fix = audio_delay_fix
>>
>> mux_v=muxer_new_stream(muxer,MUXER_TYPE_VIDEO);
>>
>> -mux_v->buffer_size=0x200000; // 2MB
>> +mux_v->buffer_size=0x800000; // 8MB
>> mux_v->buffer=malloc(mux_v->buffer_size);
>>
>> mux_v->source=sh_video;
>
> Just curious: do we have a video size at that point? Just thinking of the
> people using mencoder on routers, 8 MB is quite a lot on a device with 32 MB
> RAM...

Thanks to optimistic memory allocation, aka how the linux kernel
works, the memory that is never accessed, would not be really
allocated.

In theory, it would be great if FFmpeg allocates and realloc()s the
output buffer on its own, so the application should never worry about
it.

In reality, if we get complains from people with routers, we'll
probably have to either allocate 110% of the raw image size or just
provide cli option for it.