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

[Joshua Warner]

On Wed, Jul 22, 2009 at 9:08 PM, Mike Melanson<mike at multimedia.cx> wrote:
> ?smail D?nmez wrote:
>>
>> On Tue, Jul 21, 2009 at 6:01 PM, Mike Melanson<mike at multimedia.cx> wrote:
>>>
>>> Joshua Warner wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I've developed an encoder for Adobe's Flash ScreenVideo2 format, which
>>>> is
>>>> stored in flv files. ?My encoder currently only supports a large subset
>>>> of
>>>> the format. ?The only player that supports this codec (so far) is Adobe
>>>> Flash Player itself, but ScreenVideo2 makes dramatic improvement in file
>>>> size over ScreenVideo (currently in ffmpeg as flashsv) - and should be
>>>> very
>>>> useful for uploading screencasts, etc. ?Most options (block size, etc)
>>>> now
>>>> just fall back on defaults because I couldn't find a general algorithm
>>>> that
>>>> produced consistantly better results than these. ?All the code is in
>>>> place
>>>> to be able to change these parameters dynamically, so future
>>>> improvements
>>>> there should be easy. ?The patch is attached.
>>>>
>>>> The codec is listed as flashsv2 in ffmpeg.
>>>
>>> How did you figure out the format? I only ask because I don't know anyone
>>> who has been able to figure it out based on the official Adobe
>>> documentation
>>> (that I helped write). :)
>>
>> Is this a tricky question? ;) To make it harder to reverse engineer :-P
>
> Not exactly. I worked hard during the last revision to clean up the existing
> SV2 description because we had a number of requests. Combined with the fact
> that it's very difficult to obtain test media (only generated by another bit
> of Adobe software), the format was impenetrable. I tried to create a naive
> encoder (that I wouldn't be able to release) to generate some contrived
> samples (that I would be able to release) but didn't get too far before I
> got busy with other things.
>
> I'll try to review this patch and see if it exercises all of the codec's
> features. The codec does feature something I haven't seen elsewhere-- the
> 15/7-bit hybrid pixel encoding (top bit of a byte indicates whether it's the
> pixel is RGB555 or a 7-bit palette index).

There are a few features that it doesn't exercise - first of all, it
doesn't support dynamically changing the palette, so only the default
palette is supported.  Second (and more importantly), it doesn't use
the ZLIB_PRIME_COMPRESS_CURRENT flag at all.  I couldn't find any
examples of this in the wireshark data, and I wasn't able to figure it
out just by trial and error.  Maybe you could explain this  - what
block does it initialize the dictionary with? I assume that the
dictionary initialization itself is the same as in the
ZLIB_PRIME_COMPRESS_PREVIOUS flag.

-Joshua Warner

>
> --
> ? ?-Mike Melanson
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel