[FFmpeg-devel] [PATCH] encoder for adobe's flash ScreenVideo2 codec

Daniel Verkamp daniel at drv.nu
Sat May 7 04:33:04 CEST 2011


On Wed, May 4, 2011 at 6:22 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Apr 29, 2011 at 08:03:01PM -0700, Daniel Verkamp wrote:
>> On Thu, Apr 28, 2011 at 5:30 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Wed, Jul 22, 2009 at 11:10:45AM -0600, Joshua Warner wrote:
>> >> Him
>> >>
>> >> I fixed the issues you guys have commented on (tell me if I
>> >> accidentally missed one), and the revised patch is attached.
>> >
>> > Applied locally will push to main ffmpeg git
>> > it makes no sense to let this rot in the ML archives just because its
>> > not perfect
>> >
>>
>> Thanks for merging this!
>>
>> However, a quick test encoding this sample shows a problem:
>>   http://drv.nu/temp/flashsv2/screen.flv
>
> iam not sure how to test the resulting file ...
> what do you use to play it ?
>

The standard Adobe Flash player browser plugin plays it fine.

>
>>
>> Around 2-4 seconds into the video, some blocks are corrupted.
>>
>> Reverting 4517ba092e0606e9473c8e148c9895b01f975e18 ("flashsv2enc:fix
>> segfault") fixes the problem for this sample.  I could not reproduce
>> the mentioned segfault.  I don't understand how that code is supposed
>> to work, but it looks like moving the FFSWAP past the use of
>> s->keybuffer - s->encbuffer will definitely change the results.
>
>
> without 4517ba092e0606e9473c8e148c9895b01f975e18
>
> s->key_blocks[i].enc += (s->keybuffer - s->encbuffer);
> will add the pointer difference the wrong way and instead of
> switching buffers point to random memory.
> Id guess the most likely way this can work better is by never using
> the previous data and encoding as keyframe.
>
> you can try running the code under valgrind if it doesnt segfault
> for you.
>

Indeed, though it doesn't crash here, Valgrind complains loudly... I
am at a loss to explain why it works here or what that buffer is
really pointing at, but it does produce correct and consistent output
for me.

> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thanks,
-- Daniel


More information about the ffmpeg-devel mailing list