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 > Capturing and Editing Video > VirtualDub, VDubMod & AviDemux

Reply
 
Thread Tools Search this Thread Display Modes
Old 23rd September 2020, 22:52   #21  |  Link
anton_foy
Registered User
 
Join Date: Dec 2005
Location: Sweden
Posts: 702
@poisondeathray
Quote:
Maybe a problem with your ffmpeg binary. What does info() report ?
Sorry but how do I use "info()"? Im not familiar with this command.

Quote:
Code:

Blankclip(pixel_type="YV12").KillAudio()
convertbits(16)
ConverttoYUV444()
Prefetch(4)
ConvertBits(bits=10, dither=1)

For this test script, info() reports YUV444P10 ; and ffmpeg -i input.avs reports yuv444p10le
This is what my ffmpeg reports:
Input #0, avisynth, from 'input.avs':
Duration: 00:00:10.00, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (Y3[0][10] / 0xA003359), yuv444p10le, 640x480, 24 fps, 24 tbr, 24 tbn, 24 tbc
At least one output file must be specified


Quote:
Why don't you have ConvertBits before prefetch ?
I was given this advice from another member in doom9 in the Avisynth section. But I tried to put prefetch(4) last and it did not make a difference.
anton_foy is offline   Reply With Quote
Old 23rd September 2020, 23:07   #22  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
The problem is your script. It's returning YUV420P16

The problem line is
Code:
return(result)
Instead, just call result

Code:
#return(result)
result
That "result" gets passed into the rest of the script neo_f3kdb, etc... as "implied last"

Last edited by poisondeathray; 23rd September 2020 at 23:10.
poisondeathray is offline   Reply With Quote
Old 23rd September 2020, 23:12   #23  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by anton_foy View Post
@poisondeathray

Sorry but how do I use "info()"? Im not familiar with this command.
When someone asks for info(), it refers to the avisynth script. You just add info() to the very end. It tells you what the script characteristics are, including colorspace(pixel format). In your case it was yuv420p16 , so that was what ffmpeg was being "fed"

Code:
Blankclip(pixel_type="YV12").KillAudio()
convertbits(16)
ConverttoYUV444()
Prefetch(4)
ConvertBits(bits=10, dither=1)
info()
On the other test script, it says YUV444P10
poisondeathray is offline   Reply With Quote
Old 23rd September 2020, 23:13   #24  |  Link
anton_foy
Registered User
 
Join Date: Dec 2005
Location: Sweden
Posts: 702
@poisondeathray
Aha many thanks!!! I will try this in the morning and let you know how it worked
Back to the job again in a few hours...
anton_foy is offline   Reply With Quote
Old 23rd September 2020, 23:19   #25  |  Link
age
Registered User
 
Join Date: Oct 2015
Posts: 54
Quote:
Originally Posted by shekh View Post
This should work, no idea the for the reason of crash. Do you run x64 version? Otherwise low memory could be the issue.

For the command line you have to also put pix_fmt of the rawvideo:

example ffv1
Code:
-f rawvideo -pix_fmt %(pix_fmt) -s %(width)x%(height) -r %(fpsnum)/%(fpsden) -i - -c:v ffv1 %(tempvideofile)
prores
Code:
-f rawvideo -pix_fmt %(pix_fmt) -s %(width)x%(height) -r %(fpsnum)/%(fpsden) -i - -c:v prores_ks -profile:v 4 -pix_fmt yuv444p10 "%(tempvideofile)"
Does newer ffmpeg versions encode prores hq with the correct matrix metadata or is it always 470bg ?
age is offline   Reply With Quote
Old 24th September 2020, 19:20   #26  |  Link
anton_foy
Registered User
 
Join Date: Dec 2005
Location: Sweden
Posts: 702
@poisondeathray
You solved it!!! Thanks again, now I can make my movie
FFMPEG now reports it correctly as yuv444p10le.
Enormous difference colour grading the 10 bit version compared to the 8 bit one.
anton_foy is offline   Reply With Quote
Old 24th September 2020, 20:23   #27  |  Link
Cary Knoop
Cary Knoop
 
Cary Knoop's Avatar
 
Join Date: Feb 2017
Location: Newark CA, USA
Posts: 397
Quote:
Originally Posted by anton_foy View Post
@poisondeathray
You solved it!!! Thanks again, now I can make my movie
FFMPEG now reports it correctly as yuv444p10le.
Enormous difference colour grading the 10 bit version compared to the 8 bit one.
If the source is 8-bit it is not going to make any difference.
The same with converting 4:2:0 to 4:4:4, while there are some specific reasons this might be a good idea it usually is not.
Cary Knoop is offline   Reply With Quote
Old 24th September 2020, 21:29   #28  |  Link
anton_foy
Registered User
 
Join Date: Dec 2005
Location: Sweden
Posts: 702
@Cary Knoop
Filtering and denoising 8 bit material in 16 bit makes a great difference.
anton_foy is offline   Reply With Quote
Old 24th September 2020, 21:35   #29  |  Link
Cary Knoop
Cary Knoop
 
Cary Knoop's Avatar
 
Join Date: Feb 2017
Location: Newark CA, USA
Posts: 397
Quote:
Originally Posted by anton_foy View Post
@Cary Knoop
Filtering and denoising 8 bit material in 16 bit makes a great difference.
I would not use the word great, the advantage is minimum.

I actually recommend using 32-bit floats as much as possible for internal processing. Upsampling to 4:4:4 right before you encode is totally meaningless if you want to process the results into Resolve.

Looking at your workflow I am not quite sure the result will actually be an improvement. Especially the "shine" process raises some questions with me. But I await the pre and post comparison.

Also this caught my attention:
Stream #0:0: Video: rawvideo (Y3[0][10] / 0xA003359), yuv444p10le, 640x480, 24 fps, 24 tbr, 24 tbn, 24 tbc

640x480 for a 4k source? Quite a waste if you ask me.

If that is your target resolution, then there is a far better way to turn your 4:2:0 into 4:4:4 by resizing the the luma and chroma planes differently.

Last edited by Cary Knoop; 24th September 2020 at 21:38.
Cary Knoop is offline   Reply With Quote
Old 24th September 2020, 21:44   #30  |  Link
anton_foy
Registered User
 
Join Date: Dec 2005
Location: Sweden
Posts: 702
@Cary Knoop
Do it your way thats fine and yes I get a huge improvement. Now with the 10 bit Prores I get I can finally use the 3DLuts on it without introducing horrible banding and creeping noise I got with the old Avisynth with maximum 8 bit support.
The "shine" is like a glow, instead of just blurring the image loosing detail I overlay an expanded blur to shine over like a physical "pro mist" filter kind of. I still keep the detail. Just watch the clips if you are interested https://we.tl/t-yOeb6Tolr4
anton_foy is offline   Reply With Quote
Old 24th September 2020, 21:45   #31  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by Cary Knoop View Post

640x480 for a 4k source?

640x480 was just the blankclip() default resolution for the debugging test script - to see if there was an issue with this ffmpeg binary, or avisynth environment
poisondeathray is offline   Reply With Quote
Old 24th September 2020, 21:56   #32  |  Link
Cary Knoop
Cary Knoop
 
Cary Knoop's Avatar
 
Join Date: Feb 2017
Location: Newark CA, USA
Posts: 397
Quote:
Originally Posted by anton_foy View Post
@Cary Knoop
Do it your way thats fine and yes I get a huge improvement. Now with the 10 bit Prores I get I can finally use the 3DLuts on it without introducing horrible banding and creeping noise I got with the old Avisynth with maximum 8 bit support.
The "shine" is like a glow, instead of just blurring the image loosing detail I overlay an expanded blur to shine over like a physical "pro mist" filter kind of. I still keep the detail. Just watch the clips if you are interested https://we.tl/t-yOeb6Tolr4
The "non-processed" video is virtually pitch black and is 444, clearly this is not the straight out of camera clip.

Just take a second from the out of camera clip by for instance doing:

ffmpeg -i clip.mov -ss 10 -t 1 -c:v copy test.mov

This will take one second from the clip at the 10 second marker. Leaving -ss out will take the 1 second from the start.
Cary Knoop is offline   Reply With Quote
Old 24th September 2020, 22:01   #33  |  Link
anton_foy
Registered User
 
Join Date: Dec 2005
Location: Sweden
Posts: 702
@Cary Knoop
Quote:
The "non-processed" video is virtually pitch black and is 444, clearly this is not the straight out of camera clip.

Just take a second from the out of camera clip by for instance doing:

ffmpeg -i clip.mov -ss 10 -t 1 -c:v copy test.mov

This will take one second from the clip at the 10 second marker. Leaving -ss out will take the 1 second from the start.
Ah crap, I see that now. I was running it through avisynth without any filters or any conversion but something must have happened (me tired probably).

Thanks, I will use that (ffmpeg -i clip.mov -ss 10 -t 1 -c:v copy test.mov) tomorrow when I get home and post a link.
anton_foy is offline   Reply With Quote
Old 26th September 2020, 18:02   #34  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by age View Post
Does newer ffmpeg versions encode prores hq with the correct matrix metadata or is it always 470bg ?
You can control this in both places: ProRes private headers and MOV headers (if MOV used).
ProRes decoder/encoder got some updates recently and they are bit better now, though still not perfect when it comes to details (compared to Apple reference encoder).
kolak is offline   Reply With Quote
Old 26th September 2020, 18:42   #35  |  Link
age
Registered User
 
Join Date: Oct 2015
Posts: 54
Quote:
Originally Posted by Cary Knoop View Post
If the source is 8-bit it is not going to make any difference.
The same with converting 4:2:0 to 4:4:4, while there are some specific reasons this might be a good idea it usually is not.
Definitely wrong.
It's better to use high bitdepth for levels limited to full conversion, chroma upscaling, rgb conversion and of course filtering.
age is offline   Reply With Quote
Old 26th September 2020, 18:49   #36  |  Link
Cary Knoop
Cary Knoop
 
Cary Knoop's Avatar
 
Join Date: Feb 2017
Location: Newark CA, USA
Posts: 397
Quote:
Originally Posted by age View Post
Definitely wrong.
It's better to use high bitdepth for levels limited to full conversion, chroma upscaling, rgb conversion and of course filtering.
Yes, there are advantages of doing internal processing with a higher bit depths. I personally use float32 for internal processing.

But an 8-bit source is not going to be magically 10 bits or higher due to processing. And a 4:2:0 source is not going to be magically 4:4:4.
Cary Knoop 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 22:38.


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