Keyframe "compression flickering" when used with ffmpeg

[Maxerist]

Hi,
I noticed a strange effect when compressing video with ffmpeg (probably a couple of weeks old) and latest vpx.

It can be explained like "compression flickering" since periodically a single frame looks like the compression of it dropped significantly (so on pause one can see dct squares while on other, normal frames it's hard to recognize them). Especially this is noticeable when there are no much moving in the video like a staying photo with little activity nearby. I looked at the structure of this frames, looks like they're all keyframes. I didn't force keyframe ratio  so probably keyframe every 10 frames was the default and exactly every 10th frame drops appearance in compression.

I didn't notice similar issue when working with other flavors of vpx compression (DS filter, VFW wrapper) so this might be related to how ffmpeg treats vpx. But I'm not sure. If I knew what setting can affect such difference, I would change my settings or experiment with ffmpeg settings to solve my problem and maybe suggest some change to default behavior of ffmpeg-vpx link.

Any thoughts would be helpful

Thanks

Max 

[James Zern]

Hi,

You can extract the libvpx settings by adding -vframes 1 -loglevel
debug to your command line. Do you have some sample source that you
can share (along with your command line)? The default bitrate is
200kbps, raising it may help, but it may be hiding a problem with the
encoder that should be investigated first.

[Maxerist]

On Friday, October 10, 2014 4:41:17 PM UTC+4, James Zern wrote:

Hi,

On Fri, Oct 10, 2014 at 10:31 AM, Maxerist <maxe...@gmail.com> wrote:
> Hi,
> I noticed a strange effect when compressing video with ffmpeg (probably a
> couple of weeks old) and latest vpx.
>

You can extract the libvpx settings by adding -vframes 1 -loglevel
debug to your command line. Do you have some sample source that you
can share (along with your command line)? The default bitrate is
200kbps, raising it may help, but it may be hiding a problem with the
encoder that should be investigated first.

Sorry, I misled you a little, I'm talking about libav library (avcodec-55.dll) used in my program with my own compression image source.

So I talked not about command line settings, rather settings I pass to avcodec_open2. They're identical for other codecs when I test: mpeg2, avi (mpeg4v2) and so on. I looked at the lines where I initialize the structure, the settings I set that might be related to compression are

   vstream.codec.bit_rate := ...;
   vstream.codec.gop_size := 10;
   vstream.codec.max_b_frames := 0;

So the keyframe rate is set by my routine (not as I wrote earlier), and I force no b frames in order to be compatible with other codecs not supporting it.

Probably ffmpeg as a program set everything right and I just lack some important setting that might be sensitive for vpx and not so for other codecs.

Max

[James Zern]

Possibly. If you could capture the source or add a logger to your
program you'd be able to compare the compression or settings with the
command line. 1-pass may still have issues as it isn't tested that
much outside of realtime. Are you using vp8 or vp9?

[Maxerist]

On Friday, October 10, 2014 7:55:34 PM UTC+4, James Zern wrote:

On Fri, Oct 10, 2014 at 3:43 PM, Maxerist <maxe...@gmail.com> wrote:
>
>
> On Friday, October 10, 2014 4:41:17 PM UTC+4, James Zern wrote:
>>
>> Hi,
>>
>> On Fri, Oct 10, 2014 at 10:31 AM, Maxerist <maxe...@gmail.com> wrote:
>> > Hi,
>> > I noticed a strange effect when compressing video with ffmpeg (probably
>> > a
>> > couple of weeks old) and latest vpx.
>> >
>>
>> You can extract the libvpx settings by adding -vframes 1 -loglevel
>
>

> Probably ffmpeg as a program set everything right and I just lack some
> important setting that might be sensitive for vpx and not so for other
> codecs.
>

Possibly. If you could capture the source or add a logger to your
program you'd be able to compare the compression or settings with the
command line. 1-pass may still have issues as it isn't tested that
much outside of realtime. Are you using vp8 or vp9?

James,

It's vp8, AV_CODEC_ID_VP8 constant in libav,
thanks for the suggestions, I can at least take identical source videos, compress it with ffmpeg program and libav with my settings. If they're different (ffmpeg good, mine bad) I can further locate the difference incrementally.
I also suspect that ffmpeg might not disable b-frames unless the user wants it.

Max

[Basil Mohamed Gohar]

For what it's worth, single-pass vbr and/or cbr VP8 encoding through
libvpx does generally suffer from something like what you described due
to some rate control issues that may still linger. At least, I never
found a fix for this.

Setting min-q and max-q to the same value to force a constant quantizer
has always been my solution to this issue, or I just do two-pass
encoding to get the maximum quality for the given bits. The min-q=max-q
option is also not terribly efficient as I've been told multiple times
that that bypasses a good bit of code that can result in more efficient
encodes, but this was generally not for distribution, but just for
uploading to YouTube (in my personal case).


--
Libre Video
http://librevideo.org

[Maxerist]

Thanks for mentioning, probably making such adjustments (equaling quantizing coefficients)  when suffering from losing bit efficiency would be ok for me. I will try and report here about my results.

Max

[Maxerist]

As I promised, some data from my tests inspired by James and Basil.
Simple equivalent of what I do with libav, but now using ffmpeg command-line
  ffmpeg.exe -i "video.mpg" -g 10 -vcodec vp8 -b:v 1200k "video.avi"
produces the same results with the same "compression flickering" artifacts.

I tried the option -crf  (constant quality mode), mentioned at https://trac.ffmpeg.org/wiki/Encode/VP8. No improvements, I tried several sets of crf/bitrate values, with the same effect.

Forcing quantizer to fixed value with qmin/qmax as suggested Basil actually helped.
-qmin 20 -qmax 20
-qmin 10 -qmax 10
both produced good results for general viewing, although looking closely at the frames step by step reveals small artifacts the keyframe positions

I also noticed that increasing the space between keyframes (up to 10 seconds, 250 frames) doesn't help, I still see this "blinks".

So currently seems like fixing quantizer is the only viable option
 
Max

[Basil Mohamed Gohar]

On 10/13/2014 04:50 AM, Maxerist wrote:
> As I promised, some data from my tests inspired by James and Basil.
> Simple equivalent of what I do with libav, but now using ffmpeg command-line
> ffmpeg.exe -i "video.mpg" -g 10 -vcodec vp8 -b:v 1200k "video.avi"
> produces the same results with the same "compression flickering" artifacts.
>
> I tried the option -crf (constant quality mode), mentioned at
> https://trac.ffmpeg.org/wiki/Encode/VP8. No improvements, I tried
> several sets of crf/bitrate values, with the same effect.
>
> Forcing quantizer to fixed value with qmin/qmax as suggested Basil
> actually helped.
> -qmin 20 -qmax 20
> -qmin 10 -qmax 10
> both produced good results for general viewing, although looking closely
> at the frames step by step reveals small artifacts the keyframe positions
>
> I also noticed that increasing the space between keyframes (up to 10
> seconds, 250 frames) doesn't help, I still see this "blinks".
>
> So currently seems like fixing quantizer is the only viable option
>
> Max

Since you're looking so closely, I would recommend the 2-pass option for
VP8 as well. I find that VP8 quality can be really good if done in
2-pass mode, but of course, that's not good for live, on-demand, or
realtime media.

If you give the quantizer a good range, like -qmin 4 and -qmax 60,
you'll find a good result, I think. I get the best results when I use
vpxenc directly, as opposed to use ffmpeg. That means I have to have my
input in Y4M format. Here's an example of doing it in two pass mode (as
a Bash script):

> inputfile=20140916_tn-200_startup-problem_288p30.y4m; codec=vp8; passes=2; pass=1; deadline=best; kbps=192; time vpxenc --output=${inputfile}_${codec}_${passes}-pass_${deadline}_${kbps}kbps_lag25_aar1.webm --codec=${codec} --passes=${passes} --pass=${pass} --fpf=${inputfile}_${codec}_lag25_aar1.fpf --${deadline} --verbose --q-hist=16 --rate-hist=16 --threads=4 --lag-in-frames=25 --end-usage=vbr --target-bitrate=${kbps} --min-q=4 --max-q=60 --kf-max-dist=300 --auto-alt-ref=1 ${inputfile}

> inputfile=20140916_tn-200_startup-problem_288p30.y4m; codec=vp8; passes=2; pass=2; deadline=best; kbps=192; time vpxenc --output=${inputfile}_${codec}_${passes}-pass_${deadline}_${kbps}kbps_lag25_aar1.webm --codec=${codec} --passes=${passes} --pass=${pass} --fpf=${inputfile}_${codec}_lag25_aar1.fpf --${deadline} --verbose --q-hist=16 --rate-hist=16 --threads=4 --lag-in-frames=25 --end-usage=vbr --target-bitrate=${kbps} --min-q=4 --max-q=60 --kf-max-dist=300 --auto-alt-ref=1 ${inputfile}

The only difference between the two lines is that the value for $pass is
1 or 2 depending on the pass I want to run. As for getting the same
results with ffmpeg, I think you can probably get close, if not
identical, by translating the commands appropriately, I think everything
is supported by ffmpeg.

[Maxerist]

On Tuesday, October 14, 2014 7:00:03 AM UTC+4, Basil Mohamed Gohar wrote:

Since you're looking so closely, I would recommend the 2-pass option for
VP8 as well.  I find that VP8 quality can be really good if done in
2-pass mode, but of course, that's not good for live, on-demand, or
realtime media.

Looks promising, thanks. Is all those options available with a dll? I remember that I tried to find "official" library encoder/decoder and looked like there should be one especially since chrome itself was supposed to handle webm with an external library.

Max

[Harald Alvestrand]

Chrome compiles libvpx from source, as it does with most external libraries. The setup is public.

--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webm-discuss...@webmproject.org.
To post to this group, send email to webm-d...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/webm-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Maxerist]

Harald,

ok, but seems like vpx code is just a part of some dll, so there's no dedicated vpx library in Chrome, at least when guessing from dll names. If there's a dynamic library everyone recognizes, then one may rely on api and calling conventions. If the library serves only chrome and browser needs, then one better chose some other solution

Max

On Tuesday, October 14, 2014 11:09:10 AM UTC+4, Harald Alvestrand wrote:

Chrome compiles libvpx from source, as it does with most external libraries. The setup is public.

14. okt. 2014 09:00 skrev "Maxerist" <maxe...@gmail.com> følgende:

On Tuesday, October 14, 2014 7:00:03 AM UTC+4, Basil Mohamed Gohar wrote:

Since you're looking so closely, I would recommend the 2-pass option for
VP8 as well.  I find that VP8 quality can be really good if done in
2-pass mode, but of course, that's not good for live, on-demand, or
realtime media.

Looks promising, thanks. Is all those options available with a dll? ....

[Harald Alvestrand]

I think you're too opitimistic regarding the plasticity of DLLs :-)

The point is - Chrome compiles its own libvpx from sources. So, most likely, should your project - that's why it's open source. That way, you have an absultely stable API - because you know which source you're compiling from.

The idea of sharing a physical DLL between multiple, independently updated programs on a computer is usually something that makes sense only in very special situations (like system libraries).

And to answer the original question - vpxenc (the one that does the 2-pass thing) is part of libvpx. Anything vpxenc can do, your code can do too.

[Maxerist]

Forgot to mention, I develop with Delphi so I have either dll option or static linking. The latter is tricky though manageable. Delphi accepts only OMF object format so the output of MinGW, VC++ is not an option (COFF format). The example of excellent policy with both options is SQLite. Although Richard Hipp (the principal author) always recommends static linking, but his choice is based on the possibility of version incompatibility rather than on non-plasticity of the dlls.

[Sylvain Fabre]

I am suffering also the same issue, but i must use real-time streaming, see my message here : https://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/SzP1ElO_rIY