Re: [FFmpeg-devel] [GSOC][PATCH 3/4] median compare function for ffv1 me
Info added to codecs.texi 2016-08-22 15:43 GMT+01:00 Michael Niedermayer <mich...@niedermayer.cc>: > On Thu, Aug 18, 2016 at 02:53:29PM +0300, Станислав Долганов wrote: > > Trailing whitespaces were removed. > > > > 2016-08-17 14:07 GMT+03:00 Станислав Долганов < > stanislav.dolga...@gmail.com> > > : > > > > > Hello, > > > > > > I'm sending the patch set with implementation of GSoC project -- FFV1 P > > > frame support. The current FFV1 uses the same OBMC code as the Snow > > > codec. Also new median_me_mp function has appeared. > > > > > > I'm attaching speed report to every patch to proof > effectivity > > > of each implemented part. > > > > > > I'll appreciate feedback > > > > > > Best regards, > > > Stanislav > > > > > > > > > > > -- > > Станислав Долганов > > > avcodec.h | 33 > > ffv1enc.c |2 + > > me_cmp.c| 76 ++ > ++ > > me_cmp.h|1 > > motion_est.c|1 > > mpegvideo.h |3 +- > > obme.c |1 > > options_table.h |1 > > 8 files changed, 101 insertions(+), 17 deletions(-) > > patch applied > (without changes in obme and ffv1enc) > > Please update the docs in doc/*.texi > > Thanks > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Old school: Use the lowest level language in which you can solve the > problem > conveniently. > New school: Use the highest level language in which the latest > supercomputer > can solve the problem without the user falling asleep waiting. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > -- Станислав Долганов 0003-median-compare-function-for-ffv1-me.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 2/4] FFV1 p frames
More error handling based on snow decoder errors from patch 1 discussion.
2016-08-20 14:10 GMT+03:00 Michael Niedermayer <mich...@niedermayer.cc>:
> On Thu, Aug 18, 2016 at 08:50:08PM +0200, Moritz Barsnick wrote:
> > On Thu, Aug 18, 2016 at 14:49:28 +0300, Станислав Долганов wrote:
> >
> > > +static int decode_q_branch(FFV1Context *f, int level, int x, int y){
> > > +RangeCoder *const c = >slice_context[0]->c;
> > > +OBMCContext *s = >obmc;
> > > +const int w= s->b_width << s->block_max_depth;
> >
> > This whole function breaks ffmpeg style (wrt brackets and whitespace)
> > throughout. How come style is so different here from the rest of the
> > patch?
>
> 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
>
> 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 ...
>
>
> [...]
>
> > > +coder->c.bytestream_start = coder->c.bytestream = coder->buffer;
> //FIXME end/start? and at the other stoo
> >
> > Do the FIXMEs need to get fixed before the patch is ready for
> > inclusion?
>
> I think this originate from:
>
> origin/master:libavcodec/snowenc.c:pc.bytestream= p_buffer; //FIXME
> end/start? and at the other stoo
> origin/master:libavcodec/snowenc.c:ic.bytestream= i_buffer; //FIXME
> end/start? and at the other stoo
> vs.
> master:libavcodec/snowenc.c:coder->c.bytestream_start =
> coder->c.bytestream= coder->buffer; //FIXME end/start? and at the other stoo
>
> i think the FIXME should be kept, whatever it meant when code is
> factored
> either way this is not a fixme stanislav added so he cant know what
> it means ...
>
> about the rest of the review, thanks alot for the help!
>
> [...]
>
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
--
Станислав Долганов
0002-FFV1-p-frames.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 2/4] FFV1 p frames
Fix some problems.
2016-08-18 21:50 GMT+03:00 Moritz Barsnick <barsn...@gmx.net>:
> On Thu, Aug 18, 2016 at 14:49:28 +0300, Станислав Долганов wrote:
>
> > +static int decode_q_branch(FFV1Context *f, int level, int x, int y){
> > +RangeCoder *const c = >slice_context[0]->c;
> > +OBMCContext *s = >obmc;
> > +const int w= s->b_width << s->block_max_depth;
>
> This whole function breaks ffmpeg style (wrt brackets and whitespace)
> throughout. How come style is so different here from the rest of the
> patch?
>
> > @@ -409,6 +554,7 @@ static int read_extra_header(FFV1Context *f)
> > ff_build_rac_states(c, 0.05 * (1LL << 32), 256 - 8);
> >
> > f->version = get_symbol(c, state, 0);
> > +
> > if (f->version < 2) {
>
> This is still a stray change.
>
> > if ((ret = read_header(f)) < 0)
> > return ret;
> > f->key_frame_ok = 1;
> > +
> > } else {
>
> This is still a stray change.
>
> > +for(plane_index=0; plane_index < f->obmc.nb_planes;
> plane_index++){
> > +PlaneObmc *pc= >obmc.plane[plane_index];
> > +int w= pc->width;
> > +int h= pc->height;
> > +
> > +if(!p->key_frame){
>
> Whitespace style.
>
> > @@ -906,6 +1153,7 @@ static int decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame, AVPac
> > if (f->last_picture.f)
> > ff_thread_release_buffer(avctx, >last_picture);
> > f->cur = NULL;
> > +
> > if ((ret = av_frame_ref(data, f->picture.f)) < 0)
> > return ret;
>
> Yet another stray change.
>
> > @@ -917,15 +1165,24 @@ static int decode_frame(AVCodecContext *avctx,
> void *data, int *got_frame, AVPac
> > #if HAVE_THREADS
> > static int init_thread_copy(AVCodecContext *avctx)
> > {
> > +
> > FFV1Context *f = avctx->priv_data;
> > int i, ret;
>
> Ditto.
>
>
> > -ThreadFrame picture = fdst->picture, last_picture =
> fdst->last_picture;
> > +ThreadFrame picture = fdst->picture, last_picture =
> fdst->last_picture, residual = fdst->residual;
> > +uint16_t *c_image_line_buf = fdst->c_image_line_buf,
> *p_image_line_buf = fdst->p_image_line_buf;
>
> I personally find comma-separated declarations with assignments very
> hard to read, but I don't know whether there's a policy on that. (And
> you may be mixing declarations and assignments, which will give
> warnings.)
>
> > +for (i = 0; i < MAX_REF_FRAMES; i++)
> > +last_pictures[i] = fdst->obmc.last_pictures[i];
>
> memcpy()? (Not sure.)
> This occurs a few times.
>
> > @@ -1003,13 +1322,41 @@ static int update_thread_context(AVCodecContext
> *dst, const AVCodecContext *src)
> >
> > av_assert1(fdst->max_slice_count == fsrc->max_slice_count);
> >
> > -
> > ff_thread_release_buffer(dst, >picture);
>
> Another stray change.
>
> > +for(j=0; j<9; j++) {
> > +int is_chroma= !!(j%3);
> > +int h= is_chroma ? AV_CEIL_RSHIFT(fsrc->avctx->height,
> fsrc->chroma_v_shift) : fsrc->avctx->height;
> > +int ls= fdst->obmc.last_pictures[i]->linesize[j%3];
>
> Whitespace style.
>
> > +uint8_t state[128 + 32*128];
>
> I saw that same number somewhere above. Could it be defined as a
> constant?
>
> > +rc = >c; state = coder->state;
>
> Putting these on the same line is not necessary.
>
> > +coder->c.bytestream_start = coder->c.bytestream = coder->buffer;
> //FIXME end/start? and at the other stoo
>
> Do the FIXMEs need to get fixed before the patch is ready for
> inclusion?
>
> > +if (c->priv_data) {
> > +av_freep(>priv_data);
>
> I thought Michael had explained that the NULL check is not necessary?
>
> > +static void put_block_type (struct ObmcCoderContext *c, int ctx, int
> type)
>
> Stray whitespace. Are you trying to align the brackets in this group of
> functions?
>
> > +if (!f->key_frame) { //FIXME update_mc
>
> Fix this?
>
> > +for(plane_index=0; plane_index<FFMIN(f->obmc.nb_planes, 2);
> plane_index++){
> > +PlaneObmc *p= >obmc.plane[plane_index];
>
> Again, whitespace.
>
> > +const int width= f->avctx->width;
> > + const int height= f->avctx->height;
>
> Whitespace.
>
Re: [FFmpeg-devel] [GSOC][PATCH 3/4] median compare function for ffv1 me
Trailing whitespaces were removed. 2016-08-17 14:07 GMT+03:00 Станислав Долганов <stanislav.dolga...@gmail.com> : > Hello, > > I'm sending the patch set with implementation of GSoC project -- FFV1 P > frame support. The current FFV1 uses the same OBMC code as the Snow > codec. Also new median_me_mp function has appeared. > > I'm attaching speed report to every patch to proof effectivity > of each implemented part. > > I'll appreciate feedback > > Best regards, > Stanislav > -- Станислав Долганов 0003-median-compare-function-for-ffv1-me.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 2/4] FFV1 p frames
Tried to tune up to newest version + some fixes.
2016-08-18 4:47 GMT+03:00 Michael Niedermayer <mich...@niedermayer.cc>:
> On Wed, Aug 17, 2016 at 02:07:24PM +0300, Станислав Долганов wrote:
> > Hello,
> >
> > I'm sending the patch set with implementation of GSoC project -- FFV1 P
> > frame support. The current FFV1 uses the same OBMC code as the Snow
> codec.
> > Also new median_me_mp function has appeared.
> >
> > I'm attaching speed report to every patch to proof
> effectivity
> > of each implemented part.
> >
> > I'll appreciate feedback
> >
> > Best regards,
> > Stanislav
>
> > Makefile |4
> > ffv1.c| 35 -
> > ffv1.h| 15 ++
> > ffv1dec.c | 356 ++
> +
> > ffv1enc.c | 370 ++
> +++-
> > x86/me_cmp_init.c |4
> > 6 files changed, 768 insertions(+), 16 deletions(-)
> > 02753371eb59a185eeca7189eb711c3cf0cb5dab 0002-FFV1-p-frames.patch
> > From c3b0c6b53f7a558f06879938ffc22b3544a4f276 Mon Sep 17 00:00:00 2001
> > From: Stanislav Dolganov <dolga...@qst.hk>
> > Date: Tue, 16 Aug 2016 20:56:26 +0300
> > Subject: [PATCH 2/4] FFV1 p frames
>
> this still needs to be updated to git master HEAD
>
> it also contains trailing whitespace
>
> Applying: FFV1 p frames
> .git/rebase-apply/patch:74: trailing whitespace.
>
> .git/rebase-apply/patch:110: trailing whitespace.
>
> .git/rebase-apply/patch:167: trailing whitespace.
>
> .git/rebase-apply/patch:225: trailing whitespace.
>
> .git/rebase-apply/patch:370: trailing whitespace.
>
> warning: squelched 30 whitespace errors
> warning: 35 lines add whitespace errors.
> Using index info to reconstruct a base tree...
> M libavcodec/Makefile
> M libavcodec/ffv1.c
> M libavcodec/ffv1.h
> M libavcodec/ffv1dec.c
> M libavcodec/ffv1enc.c
> .git/rebase-apply/patch:74: trailing whitespace.
>
> .git/rebase-apply/patch:110: trailing whitespace.
>
> .git/rebase-apply/patch:167: trailing whitespace.
>
> .git/rebase-apply/patch:225: trailing whitespace.
>
> .git/rebase-apply/patch:370: trailing whitespace.
>
> warning: squelched 30 whitespace errors
> warning: 35 lines applied after fixing whitespace errors.
> Falling back to patching base and 3-way merge...
> Auto-merging libavcodec/ffv1enc.c
> CONFLICT (content): Merge conflict in libavcodec/ffv1enc.c
> Auto-merging libavcodec/ffv1dec.c
> CONFLICT (content): Merge conflict in libavcodec/ffv1dec.c
> Auto-merging libavcodec/ffv1.h
> Auto-merging libavcodec/ffv1.c
> Auto-merging libavcodec/Makefile
> error: Failed to merge in the changes.
> Patch failed at 0001 FFV1 p frames
> The copy of the patch that failed is found in: .git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
>
> [...]
> > @@ -226,6 +248,11 @@ av_cold int ff_ffv1_close(AVCodecContext *avctx)
> > av_freep(>sample_buffer);
> > }
> >
> > +if (s->p_image_line_buf)
> > +av_freep(>p_image_line_buf);
> > +if (s->c_image_line_buf)
> > +av_freep(>c_image_line_buf);
> > +
> > av_freep(>stats_out);
> > for (j = 0; j < s->quant_table_count; j++) {
> > av_freep(>initial_states[j]);
>
> unneeded checks, fring NULL is safe
>
>
> > @@ -238,6 +265,8 @@ av_cold int ff_ffv1_close(AVCodecContext *avctx)
> >
> > for (i = 0; i < s->max_slice_count; i++)
> > av_freep(>slice_context[i]);
> > +
> > +ff_obmc_close(>obmc);
> >
> > return 0;
> > }
> > diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
> > index d9398e5..30943ee 100644
> > --- a/libavcodec/ffv1.h
> > +++ b/libavcodec/ffv1.h
> > @@ -42,6 +42,11 @@
> > #include "rangecoder.h"
> > #include "thread.h"
> >
> > +#define FF_MPV_OFFSET(x) (offsetof(MpegEncContext, x) +
> offsetof(FFV1Context, obmc.m))
> > +#include "obmemc.h"
> > +
> > +#define MID_STATE 128
> > +
> > #ifdef __INTEL_COMPILER
> > #undef av_flatten
> > #define av_flatten
> > @@ -49,6 +54,7 @@
> >
> > #define MAX_PLANES 4
> > #define CONTEXT_SIZE 32
> > +#define FRAC_BITS 4
> >
> > #define MAX_QUANT_TABLES 8
&
Re: [FFmpeg-devel] [GSOC][PATCH 1/4] factoring obmc out of snow
> Thanks for the report! Typically, people will measure a few coding points > per file (instead of one) so you can plot filesize vs. quality (in whatever > metric) and see relative improvement between clips (old vs. new) over > interpolated points. See e.g. a graph like this: > > https://blogs.gnome.org/rbultje/files/2015/09/vp9- x264-x265-encoding-quality.png But FFV1 is lossless, so there is no quality range. 2016-08-17 14:59 GMT+03:00 Ronald S. Bultje <rsbul...@gmail.com>: > Hi Stanislav, > > On Wed, Aug 17, 2016 at 7:07 AM, Станислав Долганов < > stanislav.dolga...@gmail.com> wrote: > > > Hello, > > > > I'm sending the patch set with implementation of GSoC project -- FFV1 P > > frame support. The current FFV1 uses the same OBMC code as the Snow > codec. > > Also new median_me_mp function has appeared. > > > > I'm attaching speed report to every patch to proof > effectivity > > of each implemented part. > > > Thanks for the report! Typically, people will measure a few coding points > per file (instead of one) so you can plot filesize vs. quality (in whatever > metric) and see relative improvement between clips (old vs. new) over > interpolated points. See e.g. a graph like this: > > https://blogs.gnome.org/rbultje/files/2015/09/vp9- > x264-x265-encoding-quality.png > > More importantly: nice work! > > Ronald > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > -- Станислав Долганов ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [GSOC 2016] Ideas on FFV1 P frame project
Hello, I'm currently working on GSOC 2016 project for upgrading FFV1 codec with an ability to use P frames. Maybe some of you have any suggestions or recommendations. While working on qualification task I implemented a simple modification of codec to encode P frames without motion compensation, so now the base for trying several MC approaches is ready. My plan of upgrade is the next: 1) I want to try current realization of OBMC algorithm from snow*.c 2) Then try to take some ideas from HEVC 2.1) In paper "Overview of the High Efficiency Video Coding (HEVC) Standard" (can be found here http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6316136) motion compensation process is described. It includes quarter pixel interpolation technic, intra- and inter-frame predicting strategies, quadtree of frame blocks, several types of predicted units, so there is a lot of stuff to try next. 2.2) In "PARALLEL AMVP CANDIDATE LIST CONSTRUCTION FOR HEVC" ( https://www.researchgate.net/profile/Liang_Zhao57/publication/261497818_Parallel_AMVP_candidate_list_construction_for_HEVC/links/54117bd10cf264cee28b3964.pdf) can be found algorithm to make MC process faster. 2.3) Authors of "HEVC Lossless Coding and Improvements" ( http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.352.3447=rep1=pdf) proposed Sample-Based Angular Intra Prediction algrorithm special for lossless compression, which can be tried too. 3) Try to use filtration just like bilateral in "SEPARABLE BILATERAL FILTERING FOR FAST VIDEO PREPROCESSING" ( http://elynxsdk.free.fr/ext-docs/Bilateral/ICME2005_TPLV.pdf) as pre-processing part, it can reduce compression size due to encoding noise values only from a current frame. 4) Maybe try some non common ideas like not use motion vectors as in "Lossless Video Sequence Compression Using Adaptive Prediction" ( https://www.researchgate.net/profile/K_Sayood/publication/51386836_Lossless_Video_Sequence_Compression_Using_Adaptive_Prediction/links/5489cf110cf225bf669c7487.pdf ). I'll be appreciate for any ideas or comments how to improve proposed project. Regards, Stanislav D. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [WIP] GSoC P frame support for FFV1 codec
New formula for residual calculation, which reduced compressed sized significantly, but it is still a bit larger then in case if all frames are I. I think it because of coder context changes to much from I frame pixel value to P ones. Also more fate test references were generated. -- Stanislav Dolganov 0001-simple-P-frame-support.patch Description: Binary data 0002-more-tests-and-residual-formula.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [WIP] GSoC P frame support for FFV1 codec
Hello, I have implemented simple p frame support for FFV1 codec as part of the GSoC qualification task, so now it for every non key frame stores a "residual" instead of a frame itself. The patch file is attached to this message. It also replaces reference files for FATE tests, cause relative checksums and filesizes were changed. -- Stanislav Dolganov 0001-simple-P-frame-support.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [WIP] GSoC P frame support for FFV1 codec
Hello, I have implemented simple p frame support for FFV1 codec as part of the GSoC qualification task, so now it for every non key frame stores a "residual" instead of a frame itself. The patch file is attached to this message. It also replaces reference files for FATE tests, cause relative checksums and filesizes were changed. -- Станислав Долганов 0001-simple-P-frame-support.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
