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 14th August 2020, 13:30   #1  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
x264 possibly not safe for 4K UHD encoding?

Last night I captured a long series of night sky photos, hoping to catch some shooting stars. This worked out pretty well, so I tried to turn this photo series into a time lapse video, using ImageSource and several nested Layers with different blend modes in AviSynth+.

When I watched the encoded material, I noticed heavy glitches for brief intervals in some areas close to the bottom. To ensure that the reason was not already in AviSynth+, I split my complex script into parts and saved intermediate results with Ut Video, reading these AVIs in following scripts. I encoded with x264 to MP4 both in VirtualDub2 and with the CLI encoder. The results differed in details, but in general, they all contained glitches now and then.

Encoding the same video with x265 appeared to be safe, I could not spot any glitches.

So I guess that the motion detection and estimation in x264 may have been fooled by the material. I noticed that it was usually provoked in one scene by a passing-by shooting star or whatever appeared in this frame. The glitches are always in the bottom part of the video.

I am not sure how to provide test material if anyone would be interested, it takes up several GB. I guess if bit accuracy is not necessary, a low CRF x265 or AV1 encode might be suitable as compromise source...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 14th August 2020, 15:15   #2  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,997
Maybe you want to try and compare with an older release of x264. Perhaps you found a bug?
Sharc is offline   Reply With Quote
Old 14th August 2020, 15:19   #3  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
I will, as time permits...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 14th August 2020, 20:55   #4  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Interesting, are you certain this is not a decoding issue, like a hardware decoder going beyond its limits?
Blue_MiSfit is offline   Reply With Quote
Old 14th August 2020, 23:29   #5  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Does it happen with low --ref values as well? I remember several years ago some people were complaining about motion estimation not working correctly on a video recorded at very high altitude containing several different clouds which was encoded with --ref 16.
That was the only time in which I ever heard of something similar, but it could be.
By the way, for general purpose files, I have encoded 4K 4:2:2 planar 10bit files in AVC Intra Class 300 (i.e 500 Mbit/s) with x264 and I never had such a problem, so it's probably not resolution-specific but rather content-specific.

As a very last question: does it happen with both x264 8bit and 10bit? And which version were you using?
FranceBB is offline   Reply With Quote
Old 16th August 2020, 18:08   #6  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Interim findings:
  • happens with a range of x264 builds
  • happens for 8 bpc encodes with slower preset (the only explicit parameters are --crf 15 --preset slower)
  • does not happen for 10 bpc encodes with slower preset
  • does not happen for x265 with fast preset

Thank you for your testing suggestions, I will add such parameters too.

Next scheduled test series: x264 8 bpc with all the presets.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 16th August 2020 at 18:10.
LigH is offline   Reply With Quote
Old 16th August 2020, 18:14   #7  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Quote:
Originally Posted by Blue_MiSfit View Post
Interesting, are you certain this is not a decoding issue, like a hardware decoder going beyond its limits?
Interesting idea. I opened the encoding result in VirtualDub2 and could not notice any decoding errors. I'll see how to configure LAV Filters in MPC-HC to check this again.

PS: You nailed it. It breaks in DXVA2 and in CUVID mode but looks fine without HW (avcodec). GPU is an Nvidia 1660 Super.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 16th August 2020 at 18:20.
LigH is offline   Reply With Quote
Old 20th August 2020, 02:27   #8  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
And also a good point about x264 by default not enforcing Profile @ Level requirements historically. It was a huge problem back in the day, because you'd get content flagged as High Level 4.1 which should only have 4 reference frames but it would have 16 because --preset placebo was used. Which is actually level 5.1 or something. Which is why Xbox 360 media apps used to be limited to 720p, because it could decode 720p with 16 reference frames.

x265 does contrain parameters to the specified profile and level by default, so it never became an issue in HEVC.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 20th August 2020, 02:54   #9  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Nice! Glad you found the issue. A good example of hardware being a PITA

You should be able to encode 4k H.264 while maintaining hardware decode compatibility if you use VBV and cap reference frames etc.

https://en.wikipedia.org/wiki/Advanc..._Coding#Levels

So, I'd look at using Level 5.1, and setting vbv-maxrate to no more than 240 Mbps. I'd set vbv-bufsize to no more than 240 Mbits, and set ref to no more than 5.
Blue_MiSfit is offline   Reply With Quote
Old 20th August 2020, 07:24   #10  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Thank you for the detailed recommendations.

I also discussed in the LAV Filters thread whether a pessimistic fallback to software decoding might be advisable when the video's P@L flags exceed HW decoder constraints.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH 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 01:41.


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