Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 24th February 2005, 02:08   #1  |  Link
bond
Registered User
 
Join Date: Nov 2001
Posts: 9,779
ffmpeg avc bug: displaced strange blocks/artefacts

after encoding with r137 i noticed the following:

the used settings where: 2pass, cabac, loop-5,-5, mref5, 3 b-frames (temporal), all partitions enabled, subq5

pretty often i saw strange single blocks/artefacts popping up on single frames (the frame before and after doesnt have those) where they definitely dont belong
this happens very often and it seems only on b-frames!

a best of can be seen here (look at the middle, near the heads):





this is one somewhat different, checkout the multiple (!) strange blocks in the middle by zooming into the picture:


i have stored the frames as .jpg to save space, i think the artefacts are also clearly seeable without having to use .png

i am not 100% (hard to proove something that doesnt exist) but i think these artefacts are not there in streams encoded with pre-r136 (latest encoder version before r136 i tested was compiled from svn on 14th february) at least they are not that easily spotable as the ones above were
__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau)
I know, that I know nothing (Socrates)

MPEG-4 ASP FAQ | AVC/H.264 FAQ | AAC FAQ | MP4 FAQ | MP4Menu stores DVD Menus in MP4 (guide)
Ogg Theora | Ogg Vorbis
use WM9 today and get Micro$oft controlling the A/V market tomorrow for free

Last edited by bond; 24th February 2005 at 11:22.
bond is offline   Reply With Quote
Old 24th February 2005, 05:37   #2  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,393
I think it's more likely that the artifacts are caused by weighted prediction. The symptoms of that would be: artifacts only in B-frames, occur in rev135 but not rev134. (134 and 135 should make identical encoding decisions aside from wpred, so spotting differences should be easy. Wpred was implemented in 134 but enabled in vfw in 135. Currently it is on when B-frames > 1, with no way to disable it.)
And while I made pretty sure that x264's internal state with wpred is consistent with JM's, I'm not so sure of lavc's decoding.
akupenguin is offline   Reply With Quote
Old 24th February 2005, 06:09   #3  |  Link
AlexW
x264 contributor
 
Join Date: Feb 2005
Posts: 22
I can confirm that this appears to be an decoding problem with ffdshow, Nero's decoder doesn't seem to display these strange blocks/artefacts.
AlexW is offline   Reply With Quote
Old 24th February 2005, 06:11   #4  |  Link
sysKin
Registered User
 
sysKin's Avatar
 
Join Date: Jun 2002
Location: Adelaide, Australia
Posts: 1,167
I discovered a problem with weightned prediction. Patch at http://syskin.is.dreaming.org/x264/

..however, this patch will make MORE artifacts appear. Why? Because with the bug fixed, weightned prediction is used *much more* and ffdshow fails decoding it more often (I hope Alex's info about ffdshow failing will appear before this post. Wasn't here when I started typing )

Radek
__________________
Visit #xvid or #x264 at irc.freenode.net
sysKin is offline   Reply With Quote
Old 24th February 2005, 06:28   #5  |  Link
virus
Senior n00b
 
Join Date: Jan 2004
Location: Italy
Posts: 446
since a fixed version of ffdshow won't be out before a bit of time, I just wanted to notify everyone that builds/distributes VfW that by editing /vfw/codec.c, line 226 in the SVN code, you can easily disable bvops' weighted prediction just by setting param.analyse.b_weighted_bipred to 0 (unless akupenguin decides to disable it in VfW directly, he's the one with SVN access ).
That should allow you to test adaptive bvops without waiting for a new ffdshow build.
virus is offline   Reply With Quote
Old 24th February 2005, 10:54   #6  |  Link
bond
Registered User
 
Join Date: Nov 2001
Posts: 9,779
Quote:
Originally posted by akupenguin
And while I made pretty sure that x264's internal state with wpred is consistent with JM's, I'm not so sure of lavc's decoding
it seems to be indeed a problem of libav's decoding, as it doesnt seem to happen here with the moonlight decoder (cant test nero here)

edit: btw videosofts decoder shows single wierd green blocks on many parts of the picture on all frames

Quote:
Currently it is on when B-frames > 1, with no way to disable it.)
didnt realise that x264 now does weigthed prediction too
would be nice if there would be an option to en/disable it (just so that people see how powerful x264 is )

btw, why is it currently only done on only more than 1 b-frames?

Quote:
I think it's more likely that the artifacts are caused by weighted prediction. The symptoms of that would be: artifacts only in B-frames, occur in rev135 but not rev134. (134 and 135 should make identical encoding decisions aside from wpred, so spotting differences should be easy. Wpred was implemented in 134 but enabled in vfw in 135.
the 14th february version i used was inside mencoder, dunno what revision

edit2: changed thread title
__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau)
I know, that I know nothing (Socrates)

MPEG-4 ASP FAQ | AVC/H.264 FAQ | AAC FAQ | MP4 FAQ | MP4Menu stores DVD Menus in MP4 (guide)
Ogg Theora | Ogg Vorbis
use WM9 today and get Micro$oft controlling the A/V market tomorrow for free

Last edited by bond; 24th February 2005 at 11:41.
bond is offline   Reply With Quote
Old 24th February 2005, 12:13   #7  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,393
Quote:
Originally posted by bond
it seems to be indeed a problem of libav's decoding, as it doesnt seem to happen here with the moonlight decoder (cant test nero here)
I just found and fixed a wpred bug in lavc. I hope it was the only one.

Quote:
btw, why is it currently only done on b-frames?
Because B-frames use implicit weights, which are easy: I just modified the averaging function, no additional analysis needed.
In P-frames you need to first decide whether wpred is useful on a given frame and what weights to use, then preprocess the whole frame(s) and make motion estimation use the transformed refrence frames, while keeping the final macroblock encoding based on the original version because the preprocessing introduces rounding errors...
akupenguin is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:54.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.