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 > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th December 2013, 20:56   #241  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by Sagittaire View Post
x265 is actualy not able to produce the same quality output for psnr than x264 10 bit in placeb mode.
Can you please re-say that?
Do you mean x264 is still better than x265, at higher qualities?
James Freeman is offline   Reply With Quote
Old 4th December 2013, 20:57   #242  |  Link
easyfab
Registered User
 
Join Date: Jan 2002
Posts: 332
Quote:
Originally Posted by Sagittaire View Post
x265 is actualy not able to produce the same quality output for psnr than x264 10 bit in placeb mode.
At the same bitrate or half bitrate ?
easyfab is offline   Reply With Quote
Old 4th December 2013, 21:01   #243  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,484
Quote:
Originally Posted by easyfab View Post
At the same bitrate or half bitrate ?
half bitrate ... I make correction ...
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9
Sagittaire is offline   Reply With Quote
Old 4th December 2013, 21:01   #244  |  Link
fumoffu
Registered User
 
Join Date: May 2013
Posts: 90
@Kurosu - thanks for explanations!

Quote:
Originally Posted by sneaker_ger View Post
I will test but it sounds reasonable. Totally blind to not notice 24000 != 24.000. Now when using "--fps 23.976" the log says "23Hz". Wondering if it just clips the log or if the output might be wrong (if there a timings in the raw stream at all).
AFAIK there are no timings in raw stream, and the fps count is only used to tweak compression. With this in mind those decimal places aren't even important as there isn't that much of a difference. Few days ago I accidentally used 29.97fps to encode 23.976 clip and after muxing to mkv (with correct fps value) I couldn't even tell that it was encoded with faster fps.
fumoffu is offline   Reply With Quote
Old 4th December 2013, 21:15   #245  |  Link
easyfab
Registered User
 
Join Date: Jan 2002
Posts: 332
I also notice that even if a frame looks worse encoded by x265 than x264 (when comparing frame by frame ), when playing the video is much more pleasant for x265 encoded videos.
There must be some temporal filter or some noise processing in HEVC and not for AVC ?
easyfab is offline   Reply With Quote
Old 4th December 2013, 21:19   #246  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,484
Quote:
Originally Posted by James Freeman View Post
Can you please re-say that?
Do you mean x264 is still better than x265, at higher qualities?
No. x265 produce in my test quality between H264 Mainconcept (slowest mode) and x264 10 bits (placebo mode) at half bitrate. I have simply never see this difference bettwen previous and next generation codec ...
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9
Sagittaire is offline   Reply With Quote
Old 4th December 2013, 21:31   #247  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by Sagittaire View Post
No. x265 produce in my test quality between H264 Mainconcept (slowest mode) and x264 10 bits (placebo mode) at half bitrate. I have simply never see this difference bettwen previous and next generation codec ...
That's great.

Can't wait till this implemented commercially world wide, especially for the new Blu-Ray standard.
James Freeman is offline   Reply With Quote
Old 4th December 2013, 21:36   #248  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Quote:
Originally Posted by fumoffu View Post
AFAIK there are no timings in raw stream, and the fps count is only used to tweak compression. With this in mind those decimal places aren't even important as there isn't that much of a difference. Few days ago I accidentally used 29.97fps to encode 23.976 clip and after muxing to mkv (with correct fps value) I couldn't even tell that it was encoded with faster fps.
H.264 had timings and frame rate mode in the stream which could break some players or specs if not set exactly correct, that's why I'm asking.

I did test with --fps 23.976 now and bitrate was raised by ~60% at the same crf though it looked worse than the crf 18 I was used to from x264. For fun I made an x264 10 Bit encode with 2pass and preset veryslow at the same bitrate and the x265 one looked more pleasing. Artifacts were a lot less pronounced/visible, though it may have come out blurrier overall so the result might be different for decent bitrates or pre-filtering. Looking forward to the further development.

Last edited by sneaker_ger; 4th December 2013 at 21:40.
sneaker_ger is offline   Reply With Quote
Old 4th December 2013, 22:01   #249  |  Link
Beelzebubu
Registered User
 
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 109
Quote:
Originally Posted by easyfab View Post
I also notice that even if a frame looks worse encoded by x265 than x264 (when comparing frame by frame ), when playing the video is much more pleasant for x265 encoded videos.
There must be some temporal filter or some noise processing in HEVC and not for AVC ?
This is likely because of the bigger block sizes. What sometimes happens with older codecs (e.g. h264) is that neighbouring blocks with virtually identical motion will get slightly different motion vectors (1 qpel value different, for example), because the RD doesn't take block edge artifacts into account. In new codecs (e.g. hevc), it will choose a bigger block size, which therefore gets a uniform motion vector, and thus the artifacts at block edges disappear.
Beelzebubu is offline   Reply With Quote
Old 5th December 2013, 06:29   #250  |  Link
Procrastinating
Registered User
 
Procrastinating's Avatar
 
Join Date: Aug 2013
Posts: 71
Because of the more accurate motion prediction of h265, I wonder if pseudo-slowmo won't look as awful now.
Procrastinating is offline   Reply With Quote
Old 5th December 2013, 08:07   #251  |  Link
xooyoozoo
Registered User
 
Join Date: Dec 2012
Posts: 197
Quote:
Originally Posted by x265_Project View Post
Adaptive Quantization is still considered experimental. We are not always seeing the expected improvements to SSIM when it is enabled, and thus it is still not enabled by default.
I've been testing AQ on still images because it's quick and *SSIM is still a spatial metric, and I also assumed it was reasonable that changes in Intra results would represent changes in the rest of a clip. Here, 5-20% bdrate improvements versus HM12 on MS-SSIM seems normal.

Just did an actual short clip, and x265+AQ scored worse than HM12, in contrast to what both a set of single-frame encodes and visual inspection of mid-clip snaps demonstrate. ¯\_(ツ)_/¯
xooyoozoo is offline   Reply With Quote
Old 5th December 2013, 08:17   #252  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by xooyoozoo View Post
I've been testing AQ on still images because it's quick and *SSIM is still a spatial metric, and I also assumed it was reasonable that changes in Intra results would represent changes in the rest of a clip. Here, 5-20% bdrate improvements versus HM12 on MS-SSIM seems normal.

Just did an actual short clip, and x265+AQ scored worse than HM12, in contrast to what both a set of single-frame encodes and visual inspection of mid-clip snaps demonstrate. ¯\_(ツ)_/¯
Interesting! Thanks for sharing.
  Reply With Quote
Old 5th December 2013, 08:27   #253  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Quote:
Originally Posted by sneaker_ger View Post
Now when using "--fps 23.976" the log says "23Hz".
It still does? I don't even remember when I reported this missing precision... during v0.3?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 5th December 2013, 10:25   #254  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
I revisited the --crf encodes today and compared 10 Bit to 8 Bit encoding and the 10 Bit crf feature really looks to be far off/have a different scale.

Last edited by sneaker_ger; 5th December 2013 at 10:34.
sneaker_ger is offline   Reply With Quote
Old 5th December 2013, 10:34   #255  |  Link
Kurosu
Registered User
 
Join Date: Sep 2002
Location: France
Posts: 432
Quote:
Originally Posted by xooyoozoo View Post
visual inspection of mid-clip snaps demonstrate. ¯\_(ツ)_/¯
Visual inspection of that snap shows me a vast superiority of x265+AQ over HM12 to my eyes: the HM12 is a blurry mess (tree, grass, sky). And the parts where it is a lot more blurry have less motion, so one may notice that more easily.
Kurosu is offline   Reply With Quote
Old 5th December 2013, 12:02   #256  |  Link
Procrastinating
Registered User
 
Procrastinating's Avatar
 
Join Date: Aug 2013
Posts: 71
Quote:
Originally Posted by xooyoozoo View Post
Just did an actual short clip, and x265+AQ scored worse than HM12
As kurosu said, did you look at those pictures? HM12 looks awful in comparison on just about every noticeable front.
Procrastinating is offline   Reply With Quote
Old 5th December 2013, 16:44   #257  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Quote:
Originally Posted by LigH View Post
It still does? I don't even remember when I reported this missing precision... during v0.3?
Fractional rates seem to be on the to-do list at least.

https://bitbucket.org/multicoreware/x265/wiki/TODO
sneaker_ger is offline   Reply With Quote
Old 6th December 2013, 01:02   #258  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by sneaker_ger View Post
I revisited the --crf encodes today and compared 10 Bit to 8 Bit encoding and the 10 Bit crf feature really looks to be far off/have a different scale.
In AVC & HEVC, every extra bit of depth bumps the quant scale up by 6, so 10-bit is +12. If you'd normally use crf 24, you'd have to use crf 12 in 10-bit or you'll get files about four times as large. If you normally use 10, you have to use -2. (Yup, negative crf is allowed.)

I have no idea why they chose that method.
foxyshadis is offline   Reply With Quote
Old 6th December 2013, 09:14   #259  |  Link
Procrastinating
Registered User
 
Procrastinating's Avatar
 
Join Date: Aug 2013
Posts: 71
I may be missing something here, but can x265 input yuv420p10le color space? Otherwise in what format should the 10-bit YUV/Y4M be? Or am I really missing something here and x265 cannot yet input 10-bit video?

x265 crashes with the error "header missing" on a yuv420p10le .y4m when using --input-depth 10 (displays no error and just crashes on --input-depth 8)
and displays the processing of the first frame before crashing when providing the parameters and using a raw .yuv
The YUV's and Y4M's were processed with FFMPEG using the rawvideo yuv420p10le and yuv4mpegpipe formats respectively.
For the record, x264 processes these raw inputs fine.

Similarly, what is the best way for outputting x265 compatible 10-bit y4m through ffmpeg?

Last edited by Procrastinating; 6th December 2013 at 09:17.
Procrastinating is offline   Reply With Quote
Old 6th December 2013, 09:30   #260  |  Link
easyfab
Registered User
 
Join Date: Jan 2002
Posts: 332
for raw 10-bit .yuv it's ok for me with --input-depth 10 --input-csp i420 --input-res ***x*** --fps ***
But from ffmpeg with : -pix_fmt yuv420p10le -f yuv4mpegpipe it doesn't work
easyfab 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 00:58.


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