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 9th July 2014, 00:58   #1  |  Link
nhakobian
Registered User
 
Join Date: Oct 2009
Location: San Francisco, CA
Posts: 101
Artifacts in interlaced h264 made by x264

I've been archiving interlaced student videos captured (by me) from our original masters. The capture machine is an old Discreet Edit 6 non-linear editor with a Targa 2000 capture board. I've been copying the raw captured files over to a modern Windows 7 machine where we have purchased a software VFW decoder for this format (TVMJ) since ffmpeg/libav does not have a decoder for this old format.

Everything has been going well, until I created my intermediary master files. These are fully interlaced files encoded with x264 r2431. On decode with any ffmpeg/libav decoder (tested with VLC, LAV Filters, FFMS2), artifacts appear. The only decoder that shows no artifacts is LAV Filters using CUVID or DXVA2 HW decoders.

To rule out anything, I've performed the encoding several times on multiple computers. Each time the artifacts appear in different places (non-deterministic). The decoding of the original source happens inside avisynth (since the software decoder format is a VFW decoder) where I convert to YV12 (the source is YUY2). The output of avisynth is perfect, so x264 is given input that looks correct.

I found an old post http://doom10.org/index.php?topic=372.0 that mentions there was an interlaced decoding bug with weightb (which was fixed). I attempted disabling weightb (with --no-weightb) and the artifacts still appear, so this does not seem to be a re-emergence of this bug.

Here is an image which demonstrates this problem. The left one is the original frame and the right one is the decoded frame with artifacts.



Here is an example of my encoding options to x264 (input piped from avisynth) :

Code:
avs2pipemod.exe -y4mb input.avs | x264-r2431-ac76440 --level 4.1 --preset veryslow --tune film --bff --crf 12 --demuxer y4m - -o output.mp4
This intermediate master is for long term storage in case encoding settings need to be changed in the future for online or disk distribution. I have a workflow setup to perform deinterlacing and some enhancement and that procedure works perfectly. I just now need to figure out how to ensure that this intermediate master is encoding properly and can be decoded properly.

Has anyone come across this before?
nhakobian is offline   Reply With Quote
Old 9th July 2014, 02:29   #2  |  Link
Sulik
Registered User
 
Join Date: Jan 2002
Location: San Jose, CA
Posts: 215
IIRC, there are some known issues in ffmpeg/libav regarding interlaced H.264 support. These artifacts are definitely decoder-side bugs.
Sulik is offline   Reply With Quote
Old 9th July 2014, 06:24   #3  |  Link
nhakobian
Registered User
 
Join Date: Oct 2009
Location: San Francisco, CA
Posts: 101
Quote:
Originally Posted by Sulik View Post
IIRC, there are some known issues in ffmpeg/libav regarding interlaced H.264 support. These artifacts are definitely decoder-side bugs.
Thanks! I suspected as much since the HW accelerated versions seemed to work normally. Do you (or anyone else) know if the issues are dependent on certain encoder options? I'm not as concerned about storage space (only quality) and more concerned with file formats that will be able to be decoded for many, many years.

Edit: I realized I didn't clarify my purpose. These videos are the collected works of a High School Video Production program (whose instructor was my father) and includes more than 100 projects, the collected effort of thousands of students over a 20+ year period, and which won 200+ international awards. The oldest storage masters (which are BetacamSP tapes) are now getting to be about 15 years old and we are afraid that they are going to start degrading. We have DVD copies of most of the projects created with a prosumer grade standalone recorder, but the quality is lacking (many macroblock artifacts). We want to create a digital archive that will contain the best possible quality even if the tapes fall apart and become unwatchable. In addition, we are going to clean them up (i.e. deinterlace, maybe some color correction and glitch removal) and create a website to showcase all the work. It is going to take a considerable amount of time to get through all the material, but I feel it is worth it to protect the projects.

Last edited by nhakobian; 9th July 2014 at 06:38.
nhakobian is offline   Reply With Quote
Old 9th July 2014, 06:58   #4  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,401
Interlaced doesn't get much love in the freeware world (other than removing it). If there errors are repeatable during decoding, though, I'd suggest cropping the stream from the most recent IDR frame up to the next and submitting it to the ffmpeg bug list; they'll fix it eventually and that'll filter out to everyone else.

You might try the CoreAVC decoder (or even the reference software) to verify that it's just an ffmpeg problem before letting x264 off the hook entirely.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis is offline   Reply With Quote
Old 9th July 2014, 20:35   #5  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 713
Quote:
Originally Posted by Sulik View Post
IIRC, there are some known issues in ffmpeg/libav regarding interlaced H.264 support. These artifacts are definitely decoder-side bugs.
Such as?
kieranrk is offline   Reply With Quote
Old 9th July 2014, 22:03   #6  |  Link
SeeMoreDigital
Life looks better in UHD
 
SeeMoreDigital's Avatar
 
Join Date: Jun 2003
Location: Notts, UK
Posts: 11,390
Quote:
Originally Posted by nhakobian View Post
I've been archiving interlaced student videos captured (by me) from our original masters.
Are you able to provide us with few seconds sample from one of your 'original masters'?
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
SeeMoreDigital is offline   Reply With Quote
Old 10th July 2014, 03:55   #7  |  Link
nhakobian
Registered User
 
Join Date: Oct 2009
Location: San Francisco, CA
Posts: 101
Quote:
Originally Posted by SeeMoreDigital View Post
Are you able to provide us with few seconds sample from one of your 'original masters'?
Sure! However, the original can only be decoded with a payware software decoder (unfortunately the TVMJ format cannot be decoded by lavfilters, hence my desire to re-encode to h264)

The sample showing corruption: corrupt-1677.mkv

The original sample from the NLE: orig-1677.avi

Just as a reminder, the various HW decoders I have do not show corruption in the sample above.
nhakobian is offline   Reply With Quote
Old 10th July 2014, 07:50   #8  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,717
DivX h264, CoreAVC decoders work without issues as well on the sample. That implies ffmpeg/libav decoding issue
poisondeathray is offline   Reply With Quote
Old 10th July 2014, 19:02   #9  |  Link
nhakobian
Registered User
 
Join Date: Oct 2009
Location: San Francisco, CA
Posts: 101
Quote:
Originally Posted by poisondeathray View Post
DivX h264, CoreAVC decoders work without issues as well on the sample. That implies ffmpeg/libav decoding issue
Thanks for checking this out. I will post the samples onto the ffmpeg bug tracker list since it seems its a ffmpeg/libav issue.

Just to rule out a recent introduction of a problem in x264 I tested it with r2345 which is > 6 months old and it still showed up. I've tried the 10-bit builds as well and even tried the more restrictive bluray-compatibility options and it still happened.
nhakobian is offline   Reply With Quote
Old 10th July 2014, 19:09   #10  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,717
Even though you say the artifacts appear in different places, since nobody is probably going to have that proprietary decoder, it might help to post a decoded sample of the source with lossless compression that can be decoder by ffmpeg/libav etc... (e.g. ffv1, ut video, etc...) . It will also help to rule out something amiss with x264 MBAFF encoding. Or perhaps some characteristic in your sources that predispose to these types of artifacts. I just find it odd that nobody has reported it before

Last edited by poisondeathray; 10th July 2014 at 19:12.
poisondeathray is offline   Reply With Quote
Old 10th July 2014, 19:37   #11  |  Link
Sulik
Registered User
 
Join Date: Jan 2002
Location: San Jose, CA
Posts: 215
Disabling weighted prediction might help as well (weighted pred + bff + interlaced is probably creating not-so-common code paths).
Sulik is offline   Reply With Quote
Old 11th July 2014, 07:38   #12  |  Link
nhakobian
Registered User
 
Join Date: Oct 2009
Location: San Francisco, CA
Posts: 101
Quote:
Originally Posted by poisondeathray View Post
...it might help to post a decoded sample of the source with lossless compression that can be decoder by ffmpeg/libav etc... (e.g. ffv1, ut video, etc...) . It will also help to rule out something amiss with x264 MBAFF encoding. Or perhaps some characteristic in your sources that predispose to these types of artifacts. I just find it odd that nobody has reported it before
Yes, I should have done that from the beginning. I'll do the conversion and post it up sometime tomorrow (I have a job interview in the morning).

I agree that if its a decoder side issue it is very odd that nobody has reported these artifacts before. Especially since there are a significant number of consumer cameras that capture in 25i/30i in h264 and/or AVCHD.

I'm very willing to entertain the thought that there is something odd with the source material (or the payware decoder) that is triggering an odd code path. (However, I have run the source through QTGMC to de-interlace and encoded the progressive frames with x264 and they are perfectly fine.)

Quote:
Originally Posted by Sulik View Post
Disabling weighted prediction might help as well (weighted pred + bff + interlaced is probably creating not-so-common code paths).
I thought of that too, but x264 seems to be smarter. It prints out a warning if interlaced and weightp are enabled at the same time and apparently disables weightp. I checked it in mediainfo and the encoding settings seem to show that:

Code:
cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 /
chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=12 / 
lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=bff / bluray_compat=0 / constrained_intra=0 / bframes=8 / 
b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / 
intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=12.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Thanks everyone for your continued help in trying to pin this bizarre issue down. I'll update this tomorrow when I've posted a usable copy of the original source material.
nhakobian is offline   Reply With Quote
Old 11th July 2014, 10:07   #13  |  Link
MasterNobody
Registered User
 
Join Date: Aug 2007
Posts: 512
I am sure it is decoder (ffmpeg/libav) side bug because JM also decodes this sample without any errors or artifacts. As for why it wasn't detected earlier than it may be because not many people use interlaced encoding in x264 and as for other encoders they may be don't use MBAFF (i.e. use PAFF) or may be use not adaptive MBAFF (i.e. all MBs are encoded as interlaced; x264 use not adaptive one only with --subme 0).
MasterNobody is offline   Reply With Quote
Old 11th July 2014, 11:23   #14  |  Link
MasterNobody
Registered User
 
Join Date: Aug 2007
Posts: 512
One more thing which may help to pinpoint and fix this bug in ffmpeg/libav. Looks like it only occure in the case of temporal direct prediction mode (i.e. --direct temporal or --direct auto) and do not happen in case of --direct spatial.
MasterNobody is offline   Reply With Quote
Old 13th July 2014, 00:41   #15  |  Link
Beelzebubu
Registered User
 
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 47
https://ffmpeg.org/pipermail/ffmpeg-...ly/159771.html fixes it.
Beelzebubu is offline   Reply With Quote
Old 14th July 2014, 07:53   #16  |  Link
nhakobian
Registered User
 
Join Date: Oct 2009
Location: San Francisco, CA
Posts: 101
I finally got my act together and posted the sample in FFV1 format for people to reproduce the problem, but since its been identified and fixed, I guess its not 100% necessary anymore.

FFV1 format: orig-1677-ffv1.mkv

Also, I think I might go and archive the original footage for storage in FFV1 format. Since storage is cheap and the compression in FFV1 is very good for lossless (and very likely to have decoders around in 10-15 years, like AVC decoders).

Thanks for the help, and hopefully getting this bug fixed will prevent some frustration by others i the future.
nhakobian 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 07:30.


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