[FFmpeg-devel] [GSOC][PATCH 2/4] FFV1 p frames

[Michael Niedermayer]

On Sat, Aug 20, 2016 at 10:45:59PM +0200, Moritz Barsnick wrote:
> On Sat, Aug 20, 2016 at 13:10:56 +0200, Michael Niedermayer wrote:
> > On Thu, Aug 18, 2016 at 08:50:08PM +0200, Moritz Barsnick wrote:
> 
> > This code is based on libavcodec/snowdec.c:static int decode_q_branch
> > Fixing formating is very welcome but it should be in a seperate patch
> 
> I thought it was being factored out, I didn't realize code copy was
> still taking place. 
> 
> If even the formatting is copied, so is probably the majority of the
> code? Can this duplication be avoided? Just wondering. Let me check...
> See below.
>
> > Or could you tell me what has changed between a reformatted
> > decode_q_branch() and the original in libavcodec/snowdec.c
> > thats not reformatted ?
> > I cant easily, which would make review of this change much harder ...
> 
> True, though both are not identical, thanks to different choice of
> variable names. But why is the code not shared? (I'm wondering, not
> complaining - yet.)
> 
> As after applying patch 0001 and 0002, it looks like ffv1's
> decode_q_branch() could be like this:
> static int decode_q_branch(FFV1Context *f, int level, int x, int y) {
>     // pseudo code, you get my jist:
>     return snow::decode_q_branch(&f->ombc, level, x, y);
> }

its better for decode_q_branch() to be duplicated
I want to be able to develop the bitstream syntax of ffv1 and snow
idependantly.
FFV1 will likely be  heavily influenced by IETF decissions, snow
wont

also theres a seperate line of thought:

Snow must use OBMC due to its use of wavelets, FFv1 may or may not
stay on the OBMC route, we will see.

iam ATM not satisfied with the non OBMC testing done.
The OBMC tests use the most advanced code we have, the non OBMC
tests used the OBMC code with the overlapp switched off AFAIK
(cuz its easy and GSoC is just too short to do everything ...)
but non overlapped MC allows other optimizations like more complete
"rate distortion" which have not been tested but which every modern
encoder use.

A key question is IMO how OBMC (without RD) vs. BMC (with RD)
perform.
Somehow BMC with RD didnt happen within the GSoC time (which is just
too short to try everything i guess), but IMHO its the most
important post GSoC work.

On the decoder side BMC should be 2-4 times faster than OBMC.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160820/92d8123b/attachment.sig>