search

Chen-tao / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

Red video has blocky artifacts #391

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What is the expected behavior?
high quality

What do you see instead?
blocky artifacts

What version are you using?
duclair

On what operating system?
windows 7

Can you reproduce using the vpxdec or vpxenc tools? What command line are
you using?

d:\mediatests\red>timex vpxenc --passes=2 --profile=1 --fps=30000/1001 
--static-thresh=0 --drop-frame=0 --best --auto-alt-ref=1 --minsection-pct=0 
--maxsection-pct=1200 --lag-in-frames=16 --kf-min-dist=0 --kf-max-dist=250 
--min-q=0 --max-q=63  -t 4 -w 1920 -h 1080 --target-bitrate=3000 
red.1920x1080_30Hz_P420.yuv -o red_tmp_0.webm

Please provide any additional information below.
go/videotestmatrix and play the 'red' video
notice blocky artifacts
Try the mp4 version for comparison.
This video is not intended to be a 'difficult' compression test... seems like 
vp8 encoder should do better than it is.

Original issue reported on code.google.com by fbarch...@google.com on 9 Feb 2012 at 3:26

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by albe...@google.com on 16 Feb 2012 at 9:16

GoogleCodeExporter commented 9 years ago 
Is it because of --profile=1? this will force the use of simple loopfilter and 
bilinear filter in MC. Default profile=0 is better suited for best quality 
encoding.

Original comment by attilan...@google.com on 20 Feb 2012 at 7:44

GoogleCodeExporter commented 9 years ago 
The quality is similar with --profile 0.  Seek to 1:46 in this video

profile 0:
http://fbarchard0-w.ad.corp.google.com/testmatrix/mediaFiles/red_profile0/red2.w
ebm

profile 1:
http://fbarchard0-w.ad.corp.google.com/testmatrix/mediaFiles/red/red2.webm

settings for profile 0
vpxenc --passes=2 --profile=0 --fps=30000/1001 --static-thresh=0 --drop-frame=0 
--best --auto-alt-ref=1 --minsection-pct=0 --maxsection-pct=1200 
--lag-in-frames=16 --kf-min-dist=0 --kf-max-dist=250 --min-q=0 --max-q=63  -t 4 
-w 1920 -h 1080 --target-bitrate=3000 red.1920x1080_30Hz_P420.yuv -o 
red_tmp_0.webm

You should have source to this video and be able to reproduce the issue.
So far I've tried Cayuga vs Duclair, good vs best and profile 0 vs 1.

psnr/ssim is low for the affected frames.

Original comment by fbarch...@google.com on 21 Feb 2012 at 6:34

GoogleCodeExporter commented 9 years ago 
Using --max-q=42 avoids the issue on this video, but causes high bitrates on 
others.
--minsection-pct=20 reduces the issue, with less side effect.  See attached

Original comment by fbarch...@google.com on 5 Mar 2012 at 5:59

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by albe...@google.com on 8 Mar 2012 at 12:04

GoogleCodeExporter commented 9 years ago

Original comment by albe...@google.com on 8 Mar 2012 at 12:26

GoogleCodeExporter commented 9 years ago 
Setting --minsection-pct=20 works around the issue with existing/old vpxenc.
A prerelease candidate has a bit rate logic change that assigns more bits to 
'easy' sections and also works.  Both are satisfactory for my use case.

Original comment by fbarch...@google.com on 24 Mar 2012 at 6:32

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
This bug can be closed.  The bitrate logic was improved and quality is okay now.

Original comment by fbarch...@google.com on 4 Jun 2013 at 6:20

GoogleCodeExporter commented 9 years ago

Original comment by louquil...@google.com on 15 Aug 2013 at 10:11

GoogleCodeExporter commented 9 years ago 
FYI This issue is also fixed for vp9.

Original comment by fbarch...@google.com on 19 Aug 2013 at 5:58