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. |
23rd May 2020, 17:15 | #121 | Link | ||||
Testeur de codecs
Join Date: May 2003
Location: France
Posts: 2,484
|
Quote:
https://norkin.org/pdf/DCC_2018_AV1_film_grain.pdf In fact I think that you must encode denoised.yuv and FGM will add grain after stream decoding. It's logical because if you use FGM at medium/high bitrate with noisy source, codec will able to retain noise and FGM will add more noise at this same encoding natively noised. The good way seem to be: Quote:
Quote:
Quote:
I will try that. Where I can find compiled noise_model.exe ?
__________________
Le Sagittaire ... ;-) 1- Ateme AVC or x264 2- VP7 or RV10 only for anime 3- XviD, DivX or WMV9 Last edited by Sagittaire; 23rd May 2020 at 18:59. |
||||
24th May 2020, 19:44 | #123 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
|
|
29th May 2020, 22:49 | #124 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
Is it reasonable to generate the grain table with a heavily denoised reference, yet do the actual encoding with a more gently denoised clip?
I've found that getting full grain elimination using tools like SMDegrain or KNLMeansCL requires some pretty heavy handed settings, which can result in the plastic face effect. The grain synthesis is really nice, but I'd like to dial back the denoising strength when actually encoding a bit. |
29th May 2020, 23:16 | #125 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
|
|
30th May 2020, 03:34 | #126 | Link | |
Registered User
Join Date: Jan 2019
Location: Canada
Posts: 574
|
Quote:
It's at least better than leaving aomenc do the denoise and the grain modeling at the same time, because it's using very basic denoise methods. Last edited by quietvoid; 30th May 2020 at 03:37. |
|
12th October 2020, 09:05 | #128 | Link |
Lost my old account :(
Join Date: Jul 2017
Posts: 326
|
|
12th October 2020, 17:01 | #130 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
IIRC, I went from those to uncompressed v210 in After Effects, and then used FFMPEG for the final conversion to yuv420p .y4m, using xdither. Last edited by benwaggoner; 12th October 2020 at 17:16. Reason: Specified color space |
|
25th April 2021, 20:01 | #132 | Link |
Registered User
Join Date: Jan 2002
Posts: 332
|
First try with VVC codec and vvencapp codec (Fraunhofer Versatile Video Encoder )
tos.266 -> https://www.sendspace.com/file/qk2ko0 vvencapp -i ToS_1920x800_xdither.yuv -s 1920x800 -r 24 --preset fast -q 29 -o tos.266 Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR YUV-PSNR 17620 a 912.8453 52.1495 59.0134 58.8494 40.7851 Total Time: 5167.89 sec. Fps(avg): 3.40952 encoded Frames 17620 I don't know a player that decode vvc, I'm using vvdecapp + mpv to play it for the moment : vvdecapp -b tos.266 -o - | mpv.com --demuxer=rawvideo --demuxer-rawvideo-w=1920 --demuxer-rawvideo-h=800 --demuxer-rawvideo-mp-format=yuv420p10le --demuxer-rawvideo-fps=24 - or to use with ffmpeg to do what you want : vvdecapp -b tos.266 -o - | ffmpeg -f rawvideo -s 1920x800 -r 24 -pix_fmt yuv420p10le -i - .... Here a build of vvcdecapp for those who don't want to build the source : https://www.sendspace.com/file/uhc8j6 |
3rd June 2021, 22:29 | #134 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
I've finally added a new source for the challenge, an interesting hybrid anime/CGI title. Links and details in the updated first post.
It's got some very different properties from Tears of Steel that should stress different encoder features. I look forward to seeing what we all can do with it! |
7th June 2021, 20:19 | #135 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Here's my first test encode, at 1 Mbps ABR.
https://1drv.ms/v/s!AlvIQZWsyeO-k9ly...a-TPQ?e=baJVUi Even though a ton of its runtime is just white text/graphics on black, it's still a MUCH harder clip to encode than Tears of Steel. Perhaps something could be done with --zones to further save bits from the credits sections to help the hard bits. I've not done any actual tuning with the parameters. I just did a 2-pass placebo with --tune animation and throwing in a bunch of other features that would hopefully help with this kind of content. So --cu-lossless and --tskip for all the very sharp lines in the text I did a simple --tune animation --preset slower without the fancy stuff and quality and bit distribution came out pretty much the same; just a hair lower . Which confirms the extra stuff didn't cause some qualitative regression. As expected, 20x faster with -1.5 dB PSNR and -0.22 dB SSIM. Looking at the .csv log file, it seems that --frame-dup didn't actually set any frames to dup. so raising the threshold there might be helpful. Maybe the dithering added just that extra bit of noise? I'm not sure if --tune animation is appropriately tuned either. I fear that preset is exactly copied from an email I sent a x265 dev extrapolating a starting point for tuning a --tune animation, and I know I didn't do adequate testing of it . I doubt this is a clip that particularly benefits from --hme either. I should also try --hevc-aq for comparison. x265.exe --input SolLevante_SDRv2_1080p24_8bit.y4m --level-idc 4.0 --preset placebo --pass 1 --ref 5 --bframes 16 -F 1 --hme --hme-search 2,3,4 --fades --frame-dup --tune animation --tskip --cu-lossless --rd-refine --multi-pass-opt-analysis --multi-pass-opt-distortion --keyint 120 --rc-lookahead 120 --bitrate 1000 --vbv-maxrate 12000 --hrd --aud --vbv-bufsize 12000 --colorprim bt709 --transfer bt709 --colormatrix bt709 -o SolLevante_SDR-1080p_1000_placebo_p1.hevc --psnr --ssim --csv-log-level 1 --analysis-reuse-file SolLevante_SDR-1080p_1000_placebo.dat --stats SolLevante_SDR-1080p_1000_placebo.stats --csv SolLevante_SDR-1080p_1000_placebo_p1.csv x265.exe --input SolLevante_SDRv2_1080p24_8bit.y4m --level-idc 4.0 --preset placebo --pass 2 --ref 5 --bframes 16 -F 1 --hme --hme-search 2,3,4 --fades --frame-dup --tune animation --tskip --cu-lossless --rd-refine --multi-pass-opt-analysis --multi-pass-opt-distortion --keyint 120 --rc-lookahead 120 --bitrate 1000 --vbv-maxrate 12000 --vbv-bufsize 12000 --hrd --aud --colorprim bt709 --transfer bt709 --colormatrix bt709 -o SolLevante_SDR-1080p_1000_placebo_p2.hevc --psnr --ssim --csv-log-level 1 --analysis-reuse-file SolLevante_SDR-1080p_1000_placebo.dat --stats SolLevante_SDR-1080p_1000_placebo.stats --csv SolLevante_SDR-1080p_1000_placebo_p2.csv |
9th June 2021, 06:32 | #139 | Link | |
Registered User
Join Date: Dec 2013
Posts: 349
|
Quote:
To advertise x265 binary builds no one runs ? A place for foreign students to get their university multimedia assignments solved without the need to do any work ? Another place for trolls to unleash their time wasting and irritating nonsense posts ? Now regarding this encoding challenge I could post some Sol Levante encode like this which is quite different from Bens: https://drive.google.com/file/d/16ya...ew?usp=sharing And then people would take a look and compare and discuss and whatnot. But no, people nowadays are more interested to post pictures on Insta and toxic one liners on Twitter. Makes no sense to do an encoding challenge with most people on this BBS anyway as everyone only has access to x265 which is a broken encoder. Encoding the sequence in high quality AV1 will take a year and other OSS encoders are still in their infancy. And I get an aneurysm every time I see someone doing encodes at a medium like preset and then still complains about encoding speed because in their opinion it runs too slow on their 15 year old 4 core SSE2 CPU. |
|
9th June 2021, 18:56 | #140 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
If y'all don't like Doom9, you're welcome to not participate, or suggest a better place for these kinds of discussions.
We've had a variety of tests in this challenge provided in a variety of codecs and encoders. |
|
|