[FFmpeg-devel] [PATCH] FFV1 rectangular slice multithreading

[Jason Garrett-Glaser]

On Thu, Oct 14, 2010 at 1:16 PM, Jason Garrett-Glaser
<darkshikari at gmail.com> wrote:
> On Thu, Oct 14, 2010 at 8:09 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> On Thu, Oct 14, 2010 at 06:33:08AM -0700, Jason Garrett-Glaser wrote:
>>> On Thu, Oct 14, 2010 at 5:59 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>> > Hi
>>> >
>>> > Following patchset makes ffv1.2 much faster on multiprocessor systems
>>> > (requires version to be set to 2, which needs you to edit the source if you
>>> > ?want to try as 1.2 bitstream is not finalized yet)
>>> >
>>> > Compression wise 4 slices with foreman and large gops (300 frames) perform
>>> > slightly better (0.05% IIRC) than 1 slice.
>>> > With small gops (50 frames) compression is worse with the rangecoder and the
>>> > large context model by 0.8% otherwise better too.
>>> > (its quite obvious why its worse in that case and ill be working on that ...)
>>> >
>>> > Comments welcome, bikesheds not, and ill apply this soon
>>>
>>> >+ ? ?if(f->num_h_slices > 256U || f->num_v_slices > 256U){
>>>
>>> The max slices is 256, but this allows for up to 65,536, which doesn't
>>> seem right.
>>
>> oops, fixed locally with
>> + ? ?if(f->num_h_slices > 256U || f->num_v_slices > 256U || f->num_h_slices*f->num_v_slices > MAX_SLICES){
>> - ? ?if(f->num_h_slices > 256U || f->num_v_slices > 256U){
>
> Isn't the former check unnecessary? ?If either num_h_slices or
> num_v_slices exceeds 256, the latter check will also be triggered,
> unless one of the slice counts is 0 (which is equally invalid).
>
> Also while you're playing with FFV1, I mucked with the contexts a
> while back. ?I was never able to get a very large improvement, but
> here's some of the ideas I tried:
>
> 1. ?Base some (or all) of the contexts on previous residual values
> instead of neighboring pixels (it was almost equivalent in
> compression, but I'm curious how much a combination of that and the
> current approach could help). ?The bonus of this method is you can
> combine it with FFV2's pixel ordering to allow decode/encode SIMD of
> the median prediction.
>
> 2. ?Base some of the contexts on the actual pixel values, e.g. an [8]
> based on a quantized luma range of the average neighbor range.
>
> 3. ?"Blended" contexts -- in addition to reading the relevant context,
> read all the "neighboring" contexts too, and do a weighted average of
> some sort. ?This is equivalent to blending on context update, IIRC.
>
> Obviously no issue if you don't have time to try any of this, but I'm
> just throwing it out there for people to play with.
>
> Dark Shikari
>

Oh, also, LPC predictors, I almost forgot.  This was on the agenda to
try in FFV2, but Loren, being lazy, never seemed to get around to
it...

Dark Shikari