10bit VAAPI encoding test thread continued
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow. ==================== Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ... basically git's internal help messages usually helpful, so try to follow them?
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
ср, 6 нояб. 2024 г., 15:18 Terje J. Hanssen <[email protected]>:
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
sorry, I mean you of course should try to git am 0001-Experimental-try-10bit-vaapi-encoding.patch again, hopefully this time it will not complain about index? new git log hopefully should list it after application as newest, topmost patch.
Den 06.11.2024 14:41, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 15:18 Terje J. Hanssen <[email protected]>:
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
sorry, I mean you of course should try to git am 0001-Experimental-try-10bit-vaapi-encoding.patch
again, hopefully this time it will not complain about index?
new git log hopefully should list it after application as newest, topmost patch.
localhost:/ # cd /Cin localhost:/Cin # ls -l /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1 localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given. localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given. "git log" where? The log files I have are my own preserved localhost:/Cin # ls *log config.log make.log make_install_cin_to_use_ffmpeg_71.log configure.log make_cin_to_use_ffmpeg_71.log make_install_onevpl_support.log configure_onevpl_support.log make_install.log make_onevpl_support.log localhost:/Cin #
ср, 6 нояб. 2024 г., 17:13 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 14:41, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 15:18 Terje J. Hanssen <[email protected]>:
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
sorry, I mean you of course should try to git am 0001-Experimental-try-10bit-vaapi-encoding.patch
again, hopefully this time it will not complain about index?
new git log hopefully should list it after application as newest, topmost patch.
localhost:/ # cd /Cin localhost:/Cin # ls -l /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove .git/rebase-apply as instructed ?
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ... this is command, part of git suite of commands. displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
The log files I have are my own preserved
localhost:/Cin # ls *log config.log make.log make_install_cin_to_use_ffmpeg_71.log configure.log make_cin_to_use_ffmpeg_71.log make_install_onevpl_support.log configure_onevpl_support.log make_install.log make_onevpl_support.log localhost:/Cin #
Den 06.11.2024 15:17, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 17:13 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 14:41, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 15:18 Terje J. Hanssen <[email protected]>:
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
sorry, I mean you of course should try to git am 0001-Experimental-try-10bit-vaapi-encoding.patch
again, hopefully this time it will not complain about index?
new git log hopefully should list it after application as newest, topmost patch.
localhost:/ # cd /Cin localhost:/Cin # ls -l /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove
.git/rebase-apply
Oh, I forgot and missed that step. localhost:/home # find . -name "rebase-apply" ./cinelerra/.git/rebase-apply localhost:/home # rm -r ./cinelerra/.git/rebase-apply
as instructed ?
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding Looks better ......? localhost:/Cin # git log | more commit 68eb98be2183738684f1f4da2729d1ff9989ad16 Author: Andrew Randrianasulu <[email protected]> Date: Sun Oct 27 19:43:06 2024 +0300 Experimental: try 10bit vaapi encoding commit e5a5a6da907dbcd40d8612bdbfeea1a2a0ae6cc8 Author: Andrew Randrianasulu <[email protected]> Date: Fri Oct 18 10:07:33 2024 +0300 Add onevpl support to build system commit 8681d13675f32e870ab3632eaf89105415fb3961 Author: Andrew Randrianasulu <[email protected]> Date: Wed Oct 23 16:36:19 2024 +0300 Add DESCRIPTION commit 90138debee46e0b91adeb5d8a400158b131b0d61 Author: Andrew Randrianasulu <[email protected]> Date: Wed Oct 23 16:29:58 2024 +0300 Add BUGS commit 318c884532617e32904d6f4ec05a2b73832f418e Author: Andrew Randrianasulu <[email protected]> Date: Wed Oct 23 16:22:58 2024 +0300 Update README build instructions commit 16ef7f3d7af3edb454b19288f084f86b02631c86 Author: Andrew Randrianasulu <[email protected]> Date: Fri Sep 27 13:56:15 2024 +0300
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
ср, 6 нояб. 2024 г., 20:37 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 15:17, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 17:13 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 14:41, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 15:18 Terje J. Hanssen <[email protected]>:
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
sorry, I mean you of course should try to git am 0001-Experimental-try-10bit-vaapi-encoding.patch
again, hopefully this time it will not complain about index?
new git log hopefully should list it after application as newest, topmost patch.
localhost:/ # cd /Cin localhost:/Cin # ls -l /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove
.git/rebase-apply
Oh, I forgot and missed that step.
localhost:/home # find . -name "rebase-apply" ./cinelerra/.git/rebase-apply localhost:/home # rm -r ./cinelerra/.git/rebase-apply
as instructed ?
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding
Looks better ......?
localhost:/Cin # git log | more commit 68eb98be2183738684f1f4da2729d1ff9989ad16 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Sun Oct 27 19:43:06 2024 +0300
Experimental: try 10bit vaapi encoding
commit e5a5a6da907dbcd40d8612bdbfeea1a2a0ae6cc8 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Fri Oct 18 10:07:33 2024 +0300
Add onevpl support to build system
commit 8681d13675f32e870ab3632eaf89105415fb3961 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Wed Oct 23 16:36:19 2024 +0300
Add DESCRIPTION
commit 90138debee46e0b91adeb5d8a400158b131b0d61 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Wed Oct 23 16:29:58 2024 +0300
Add BUGS
commit 318c884532617e32904d6f4ec05a2b73832f418e Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Wed Oct 23 16:22:58 2024 +0300
Update README build instructions
commit 16ef7f3d7af3edb454b19288f084f86b02631c86 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Fri Sep 27 13:56:15 2024 +0300
so, now rebuild it ... and retry with newly-added env. variable set to 1 before launching bin/cin you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
Den 06.11.2024 19:11, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 20:37 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 15:17, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 17:13 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 14:41, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 15:18 Terje J. Hanssen <[email protected]>:
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
sorry, I mean you of course should try to git am 0001-Experimental-try-10bit-vaapi-encoding.patch
again, hopefully this time it will not complain about index?
new git log hopefully should list it after application as newest, topmost patch.
localhost:/ # cd /Cin localhost:/Cin # ls -l /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove
.git/rebase-apply
Oh, I forgot and missed that step.
localhost:/home # find . -name "rebase-apply" ./cinelerra/.git/rebase-apply localhost:/home # rm -r ./cinelerra/.git/rebase-apply
as instructed ?
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding
Looks better ......?
localhost:/Cin # git log | more commit 68eb98be2183738684f1f4da2729d1ff9989ad16 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Sun Oct 27 19:43:06 2024 +0300
Experimental: try 10bit vaapi encoding
commit e5a5a6da907dbcd40d8612bdbfeea1a2a0ae6cc8 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Fri Oct 18 10:07:33 2024 +0300
Add onevpl support to build system
commit 8681d13675f32e870ab3632eaf89105415fb3961 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:36:19 2024 +0300
Add DESCRIPTION
commit 90138debee46e0b91adeb5d8a400158b131b0d61 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:29:58 2024 +0300
Add BUGS
commit 318c884532617e32904d6f4ec05a2b73832f418e Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:22:58 2024 +0300
Update README build instructions
commit 16ef7f3d7af3edb454b19288f084f86b02631c86 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Fri Sep 27 13:56:15 2024 +0300
so, now rebuild it ...
I have to get confirmed and possibly modified the steps below to use this time. A couple a weeks ago when I rebuilt Cingg-with-system-FFmpeg 7.1 I used the following steps: localhost:/Cin # # export CFLAGS=-I/usr/include/ffmpeg # ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx But when I now check with # head config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by cinelerra configure 5.1, which was generated by GNU Autoconf 2.72. Invocation command line was $ ./configure --with-single-user --with-onevpl I don't know if this current config.log --with-onevpl was added by the later/recent onevpl patch? And should --with-onevpl be added to the long configure line above for the upcoming rebuilt? # make # make install # cp -R bin_use_system_ffmpeg-702/ffmpeg/video/* bin/ffmpeg/video
and retry with newly-added env. variable set to 1 before launching bin/cin
Syntax, please?
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
Den 06.11.2024 21:56, skrev Terje J. Hanssen:
Den 06.11.2024 19:11, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 20:37 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 15:17, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 17:13 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 14:41, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 15:18 Terje J. Hanssen <[email protected]>:
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
sorry, I mean you of course should try to git am 0001-Experimental-try-10bit-vaapi-encoding.patch
again, hopefully this time it will not complain about index?
new git log hopefully should list it after application as newest, topmost patch.
localhost:/ # cd /Cin localhost:/Cin # ls -l /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove
.git/rebase-apply
Oh, I forgot and missed that step.
localhost:/home # find . -name "rebase-apply" ./cinelerra/.git/rebase-apply localhost:/home # rm -r ./cinelerra/.git/rebase-apply
as instructed ?
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding
Looks better ......?
localhost:/Cin # git log | more commit 68eb98be2183738684f1f4da2729d1ff9989ad16 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Sun Oct 27 19:43:06 2024 +0300
Experimental: try 10bit vaapi encoding
commit e5a5a6da907dbcd40d8612bdbfeea1a2a0ae6cc8 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Fri Oct 18 10:07:33 2024 +0300
Add onevpl support to build system
commit 8681d13675f32e870ab3632eaf89105415fb3961 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:36:19 2024 +0300
Add DESCRIPTION
commit 90138debee46e0b91adeb5d8a400158b131b0d61 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:29:58 2024 +0300
Add BUGS
commit 318c884532617e32904d6f4ec05a2b73832f418e Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:22:58 2024 +0300
Update README build instructions
commit 16ef7f3d7af3edb454b19288f084f86b02631c86 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Fri Sep 27 13:56:15 2024 +0300
so, now rebuild it ...
I have to get confirmed and possibly modified the steps below to use this time.
A couple a weeks ago when I rebuilt Cingg-with-system-FFmpeg 7.1 I used the following steps:
localhost:/Cin #
# export CFLAGS=-I/usr/include/ffmpeg
# ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx
But when I now check with
# head config.log
This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake.
It was created by cinelerra configure 5.1, which was generated by GNU Autoconf 2.72. Invocation command line was
$ ./configure --with-single-user --with-onevpl
I don't know if this current config.log --with-onevpl was added by the later/recent onevpl patch? And should --with-onevpl be added to the long configure line above for the upcoming rebuilt?
I am sorry and afraid I have messed up here and forgot that my current Cingg is a later, second rebuilt since 24/10 when the onevpl patch was added 😳 https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008925.html As this also was a static built, this possibly explain why my latest system libSvtAv1Enc2 v. 2.3.0 was not found? The rebuild steps used last time were:
make clean
git am patch
./autogen.sh
./configure --with-single-user --with-onevpl
make
make install
return qsv profiles you saved before to bin/ffmpeg/video
bin/cin
# make
# make install
# cp -R bin_use_system_ffmpeg-702/ffmpeg/video/* bin/ffmpeg/video
and retry with newly-added env. variable set to 1 before launching bin/cin
Syntax, please?
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
ср, 6 нояб. 2024 г., 23:56 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 19:11, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 20:37 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 15:17, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 17:13 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 14:41, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 15:18 Terje J. Hanssen <[email protected]>:
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
sorry, I mean you of course should try to git am 0001-Experimental-try-10bit-vaapi-encoding.patch
again, hopefully this time it will not complain about index?
new git log hopefully should list it after application as newest, topmost patch.
localhost:/ # cd /Cin localhost:/Cin # ls -l /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove
.git/rebase-apply
Oh, I forgot and missed that step.
localhost:/home # find . -name "rebase-apply" ./cinelerra/.git/rebase-apply localhost:/home # rm -r ./cinelerra/.git/rebase-apply
as instructed ?
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding
Looks better ......?
localhost:/Cin # git log | more commit 68eb98be2183738684f1f4da2729d1ff9989ad16 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Sun Oct 27 19:43:06 2024 +0300
Experimental: try 10bit vaapi encoding
commit e5a5a6da907dbcd40d8612bdbfeea1a2a0ae6cc8 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Fri Oct 18 10:07:33 2024 +0300
Add onevpl support to build system
commit 8681d13675f32e870ab3632eaf89105415fb3961 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Wed Oct 23 16:36:19 2024 +0300
Add DESCRIPTION
commit 90138debee46e0b91adeb5d8a400158b131b0d61 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Wed Oct 23 16:29:58 2024 +0300
Add BUGS
commit 318c884532617e32904d6f4ec05a2b73832f418e Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Wed Oct 23 16:22:58 2024 +0300
Update README build instructions
commit 16ef7f3d7af3edb454b19288f084f86b02631c86 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Fri Sep 27 13:56:15 2024 +0300
so, now rebuild it ...
I have to get confirmed and possibly modified the steps below to use this time.
A couple a weeks ago when I rebuilt Cingg-with-system-FFmpeg 7.1 I used the following steps:
localhost:/Cin #
# export CFLAGS=-I/usr/include/ffmpeg
# ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx
But when I now check with
# head config.log
This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake.
It was created by cinelerra configure 5.1, which was generated by GNU Autoconf 2.72. Invocation command line was
$ ./configure --with-single-user --with-onevpl
I don't know if this current config.log --with-onevpl was added by the later/recent onevpl patch? And should --with-onevpl be added to the long configure line above for the upcoming rebuilt?
I think this time we try to make build with internal ffmpeg 7.0 because 7.1 introduced some changes ... so, please keep short ./configure line as currently in config.log looking at your another email: yeah, default static build does not do svt-av1 by default, but we can put this aside for now ...
# make
# make install
# cp -R bin_use_system_ffmpeg-702/ffmpeg/video/* bin/ffmpeg/video
and retry with newly-added env. variable set to 1 before launching bin/cin
Syntax, please?
export CIN_10BIT_ENC bin/cin
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
Den 07.11.2024 02:29, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 23:56 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 19:11, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 20:37 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 15:17, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 17:13 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 14:41, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 15:18 Terje J. Hanssen <[email protected]>:
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
By the way,testing
bin/cin compression: hevc_vaapi.mp4 Pixels: vaapi (no other options) cin_hw_dev=vaapi
Renders
Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
The same with CIN_10BIT_ENC=1 bin/cin
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
sorry, I mean you of course should try to git am 0001-Experimental-try-10bit-vaapi-encoding.patch
again, hopefully this time it will not complain about index?
new git log hopefully should list it after application as newest, topmost patch.
localhost:/ # cd /Cin localhost:/Cin # ls -l /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove
.git/rebase-apply
Oh, I forgot and missed that step.
localhost:/home # find . -name "rebase-apply" ./cinelerra/.git/rebase-apply localhost:/home # rm -r ./cinelerra/.git/rebase-apply
as instructed ?
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding
Looks better ......?
localhost:/Cin # git log | more commit 68eb98be2183738684f1f4da2729d1ff9989ad16 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Sun Oct 27 19:43:06 2024 +0300
Experimental: try 10bit vaapi encoding
commit e5a5a6da907dbcd40d8612bdbfeea1a2a0ae6cc8 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Fri Oct 18 10:07:33 2024 +0300
Add onevpl support to build system
commit 8681d13675f32e870ab3632eaf89105415fb3961 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:36:19 2024 +0300
Add DESCRIPTION
commit 90138debee46e0b91adeb5d8a400158b131b0d61 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:29:58 2024 +0300
Add BUGS
commit 318c884532617e32904d6f4ec05a2b73832f418e Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:22:58 2024 +0300
Update README build instructions
commit 16ef7f3d7af3edb454b19288f084f86b02631c86 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Fri Sep 27 13:56:15 2024 +0300
so, now rebuild it ...
I have to get confirmed and possibly modified the steps below to use this time.
A couple a weeks ago when I rebuilt Cingg-with-system-FFmpeg 7.1 I used the following steps:
localhost:/Cin #
# export CFLAGS=-I/usr/include/ffmpeg
# ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx
But when I now check with
# head config.log
This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake.
It was created by cinelerra configure 5.1, which was generated by GNU Autoconf 2.72. Invocation command line was
$ ./configure --with-single-user --with-onevpl
I don't know if this current config.log --with-onevpl was added by the later/recent onevpl patch? And should --with-onevpl be added to the long configure line above for the upcoming rebuilt?
I think this time we try to make build with internal ffmpeg 7.0 because 7.1 introduced some changes ...
so, please keep short ./configure line as currently in config.log
looking at your another email: yeah, default static build does not do svt-av1 by default, but we can put this aside for now ...
# make
# make install
# cp -R bin_use_system_ffmpeg-702/ffmpeg/video/* bin/ffmpeg/video
and retry with newly-added env. variable set to 1 before launching bin/cin
Syntax, please?
export CIN_10BIT_ENC bin/cin
The export part on a single line didn't work for me: localhost:/Cin # export CIN_10BIT_ENC bin/cin -bash: export: `bin/cin': not a valid identifier Works on two separate lines: localhost:/Cin # export CIN_10BIT_ENC localhost:/Cin # bin/cin Cinelerra Infinity - built: Nov 7 2024 16:27:40 ----- No hevc_vaapi 10bit worked: localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time. ------------------------------- hevc_qsv 10 bit worked with p010 and with y210 localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12 ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0] ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
чт, 7 нояб. 2024 г., 19:58 Terje J. Hanssen <[email protected]>:
Den 07.11.2024 02:29, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 23:56 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 19:11, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 20:37 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 15:17, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 17:13 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 14:41, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 15:18 Terje J. Hanssen <[email protected]>:
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen:
........snip
For me it looks like nothing has changed:
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove it again?
> By the way,testing > > bin/cin > compression: hevc_vaapi.mp4 > Pixels: vaapi (no other options) > cin_hw_dev=vaapi > > Renders > > Color space : YUV > Chroma subsampling : 4:2:0 > Bit depth : 8 bits > > > The same with > CIN_10BIT_ENC=1 bin/cin >
yeah, it does not exist in normal cin, only after you add patch.
may be just take a break from all this, I do not think we will solve this problem in few remaining days until end of October. So ... do not rush
Ok for me.
Den 04.11.2024 21:49, skrev Andrew Randrianasulu:
Terje, I think if you are ok with this idea we can return to testing 10bit-vaapi patch ... Hopefully in its final form it will just allow same format= string in encoding profiles as supported by per-file decoding opts files now ,,,
I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
sorry, I mean you of course should try to git am 0001-Experimental-try-10bit-vaapi-encoding.patch
again, hopefully this time it will not complain about index?
new git log hopefully should list it after application as newest, topmost patch.
localhost:/ # cd /Cin localhost:/Cin # ls -l /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove
.git/rebase-apply
Oh, I forgot and missed that step.
localhost:/home # find . -name "rebase-apply" ./cinelerra/.git/rebase-apply localhost:/home # rm -r ./cinelerra/.git/rebase-apply
as instructed ?
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding
Looks better ......?
localhost:/Cin # git log | more commit 68eb98be2183738684f1f4da2729d1ff9989ad16 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Sun Oct 27 19:43:06 2024 +0300
Experimental: try 10bit vaapi encoding
commit e5a5a6da907dbcd40d8612bdbfeea1a2a0ae6cc8 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Fri Oct 18 10:07:33 2024 +0300
Add onevpl support to build system
commit 8681d13675f32e870ab3632eaf89105415fb3961 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Wed Oct 23 16:36:19 2024 +0300
Add DESCRIPTION
commit 90138debee46e0b91adeb5d8a400158b131b0d61 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Wed Oct 23 16:29:58 2024 +0300
Add BUGS
commit 318c884532617e32904d6f4ec05a2b73832f418e Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Wed Oct 23 16:22:58 2024 +0300
Update README build instructions
commit 16ef7f3d7af3edb454b19288f084f86b02631c86 Author: Andrew Randrianasulu <[email protected]> <[email protected]> Date: Fri Sep 27 13:56:15 2024 +0300
so, now rebuild it ...
I have to get confirmed and possibly modified the steps below to use this time.
A couple a weeks ago when I rebuilt Cingg-with-system-FFmpeg 7.1 I used the following steps:
localhost:/Cin #
# export CFLAGS=-I/usr/include/ffmpeg
# ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx
But when I now check with
# head config.log
This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake.
It was created by cinelerra configure 5.1, which was generated by GNU Autoconf 2.72. Invocation command line was
$ ./configure --with-single-user --with-onevpl
I don't know if this current config.log --with-onevpl was added by the later/recent onevpl patch? And should --with-onevpl be added to the long configure line above for the upcoming rebuilt?
I think this time we try to make build with internal ffmpeg 7.0 because 7.1 introduced some changes ...
so, please keep short ./configure line as currently in config.log
looking at your another email: yeah, default static build does not do svt-av1 by default, but we can put this aside for now ...
# make
# make install
# cp -R bin_use_system_ffmpeg-702/ffmpeg/video/* bin/ffmpeg/video
and retry with newly-added env. variable set to 1 before launching bin/cin
Syntax, please?
export CIN_10BIT_ENC bin/cin
The export part on a single line didn't work for me:
localhost:/Cin # export CIN_10BIT_ENC bin/cin -bash: export: `bin/cin': not a valid identifier
Works on two separate lines:
localhost:/Cin # export CIN_10BIT_ENC localhost:/Cin # bin/cin Cinelerra Infinity - built: Nov 7 2024 16:27:40
sorry I mean set like this export CIN_10BIT_ENC=1
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
Den 07.11.2024 18:01, skrev Andrew Randrianasulu:
чт, 7 нояб. 2024 г., 19:58 Terje J. Hanssen <[email protected]>:
Den 07.11.2024 02:29, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 23:56 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 19:11, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 20:37 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 15:17, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 17:13 Terje J. Hanssen <[email protected]>:
Den 06.11.2024 14:41, skrev Andrew Randrianasulu:
ср, 6 нояб. 2024 г., 15:18 Terje J. Hanssen <[email protected]>:
Den 05.11.2024 16:19, skrev Andrew Randrianasulu:
вт, 5 нояб. 2024 г., 18:16 Terje J. Hanssen <[email protected]>:
Continued and extracted from previous threads_ https://lists.cinelerra-gg.org/pipermail/cin/2024-October/008967.html
Den 27.10.2024 21:11, skrev Terje J. Hanssen: > ........snip > > For me it looks like nothing has changed: > > localhost:/Cin # git am > 0001-Experimental-try-10bit-vaapi-encoding.patch > fatal: previous rebase directory > .git/rebase-apply still exists but mbox > given. > > > remove it again? > > > By the way,testing > > bin/cin > compression: hevc_vaapi.mp4 > Pixels: vaapi (no other options) > cin_hw_dev=vaapi > > Renders > > Color space : YUV > Chroma subsampling : 4:2:0 > Bit depth : 8 bits > > > The same with > CIN_10BIT_ENC=1 bin/cin > > > > yeah, it does not exist in normal cin, > only after you add patch. > > > may be just take a break from all this, > I do not think we will solve this > problem in few remaining days until end > of October. So ... do not rush > > Ok for me. >
Den 04.11.2024 21:49, skrev Andrew Randrianasulu: > > Terje, I think if you are ok with this > idea we can return to testing > 10bit-vaapi patch ... > Hopefully in its final form it will just > allow same format= string in encoding > profiles as supported by per-file > decoding opts files now ,,, > I'm not sure I understood the last line yet, but I should be ready to continue vaapi-testing to-morrow.
====================
Yeah, here we are. The problem as I understood lastly, was to apply the 10bit-vaapi-encoding.patch?
yes ...
basically git's internal help messages usually helpful, so try to follow them?
I thougt we just tried to do that by recapping the steps before:
Sorry, but now I get
localhost:/Cin # rm -r ../.git/rebase-apply
localhost:/Cin # git am 10bit.diff Patch format detection failed.
I was wondering if the patch needs .patch at the end like the previous patches?
sorry, it was git diff, not git add/git commit/git format-patch.
may be apply it with just cat | patch -p1 or something
or try attached
Hm?
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding error: cinelerra-5.1/cinelerra/ffmpeg.C: does not match index Patch failed at 0001 Experimental: try 10bit vaapi encoding hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
you probably have previous patch applied
try git reset --hard before git am.
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
The "onevpl.patch" was applied, yes. Should I apply it again, before "0001-Experimental-try-10bit-vaapi-encoding.patch" again?
no
So if I don't get a patch applied, I can't see I have something more to test (?)
sorry, I mean you of course should try to git am 0001-Experimental-try-10bit-vaapi-encoding.patch
again, hopefully this time it will not complain about index?
new git log hopefully should list it after application as newest, topmost patch.
localhost:/ # cd /Cin localhost:/Cin # ls -l /Cin lrwxrwxrwx 1 root root 29 Oct 22 20:23 /Cin -> /home/cinelerra/cinelerra-5.1
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given.
remove
.git/rebase-apply
Oh, I forgot and missed that step.
localhost:/home # find . -name "rebase-apply" ./cinelerra/.git/rebase-apply localhost:/home # rm -r ./cinelerra/.git/rebase-apply
as instructed ?
localhost:/Cin # git reset --hard HEAD is now at e5a5a6da Add onevpl support to build system
localhost:/Cin # git am 0001-Experimental-try-10bit-vaapi-encoding.patch Applying: Experimental: try 10bit vaapi encoding
Looks better ......?
localhost:/Cin # git log | more commit 68eb98be2183738684f1f4da2729d1ff9989ad16 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Sun Oct 27 19:43:06 2024 +0300
Experimental: try 10bit vaapi encoding
commit e5a5a6da907dbcd40d8612bdbfeea1a2a0ae6cc8 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Fri Oct 18 10:07:33 2024 +0300
Add onevpl support to build system
commit 8681d13675f32e870ab3632eaf89105415fb3961 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:36:19 2024 +0300
Add DESCRIPTION
commit 90138debee46e0b91adeb5d8a400158b131b0d61 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:29:58 2024 +0300
Add BUGS
commit 318c884532617e32904d6f4ec05a2b73832f418e Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Wed Oct 23 16:22:58 2024 +0300
Update README build instructions
commit 16ef7f3d7af3edb454b19288f084f86b02631c86 Author: Andrew Randrianasulu <[email protected]> <mailto:[email protected]> Date: Fri Sep 27 13:56:15 2024 +0300
so, now rebuild it ...
I have to get confirmed and possibly modified the steps below to use this time.
A couple a weeks ago when I rebuilt Cingg-with-system-FFmpeg 7.1 I used the following steps:
localhost:/Cin #
# export CFLAGS=-I/usr/include/ffmpeg
# ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx
But when I now check with
# head config.log
This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake.
It was created by cinelerra configure 5.1, which was generated by GNU Autoconf 2.72. Invocation command line was
$ ./configure --with-single-user --with-onevpl
I don't know if this current config.log --with-onevpl was added by the later/recent onevpl patch? And should --with-onevpl be added to the long configure line above for the upcoming rebuilt?
I think this time we try to make build with internal ffmpeg 7.0 because 7.1 introduced some changes ...
so, please keep short ./configure line as currently in config.log
looking at your another email: yeah, default static build does not do svt-av1 by default, but we can put this aside for now ...
# make
# make install
# cp -R bin_use_system_ffmpeg-702/ffmpeg/video/* bin/ffmpeg/video
and retry with newly-added env. variable set to 1 before launching bin/cin
Syntax, please?
export CIN_10BIT_ENC bin/cin
The export part on a single line didn't work for me:
localhost:/Cin # export CIN_10BIT_ENC bin/cin -bash: export: `bin/cin': not a valid identifier
Works on two separate lines:
localhost:/Cin # export CIN_10BIT_ENC localhost:/Cin # bin/cin Cinelerra Infinity - built: Nov 7 2024 16:27:40
sorry I mean set like this export CIN_10BIT_ENC=1
Now hevc_vaapi was able to render to yuv420p10le, that is 10-bit 420p, by selecting pixels p010le. Also rendering with pixels y210 resulted in yuv420p10le, that is not 10-bit 422p as for hevc_qsv below. I would assume this is caused due to the incomplete hevc_vapi.mp4 preset as shown below? ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0] ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
sorry I mean set like this export CIN_10BIT_ENC=1
Now hevc_vaapi was able to render to yuv420p10le, that is 10-bit 420p, by selecting pixels p010le. Also rendering with pixels y210 resulted in yuv420p10le, that is not 10-bit 422p as for hevc_qsv below.
I would assume this is caused due to the incomplete hevc_vapi.mp4 preset as shown below?
More like incomplete code that does not yet know how to get custom format ... so far as name says it only adds 10bit 4:2:0 encoding, not 4:2:2 subsampling. can you test other vaapi/qsv profiles too? also with test picture actually containing more than 8bit values? ;) (probably made up something in GIMP 2.10, save as tiff/EXR, import in cingg, set format to rgba-float, rendrer ..... hm, may be use YUView to see pixel values independently of cinelerra's decoding abilities? a bit of adventure, but should provide some proof about encoding)
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
Den 07.11.2024 20:41, skrev Andrew Randrianasulu:
sorry I mean set like this export CIN_10BIT_ENC=1
Now hevc_vaapi was able to render to yuv420p10le, that is 10-bit 420p, by selecting pixels p010le. Also rendering with pixels y210 resulted in yuv420p10le, that is not 10-bit 422p as for hevc_qsv below.
I would assume this is caused due to the incomplete hevc_vapi.mp4 preset as shown below?
More like incomplete code that does not yet know how to get custom format ... so far as name says it only adds 10bit 4:2:0 encoding, not 4:2:2 subsampling.
can you test other vaapi/qsv profiles too?
also with test picture actually containing more than 8bit values? ;)
To the latter; the input file cfhd01.mkv was 10bit 422: yuv422p10le Maybe have a look at and compare with the hevc_qsv code that managed 10bit 422: yuv422p10le?
(probably made up something in GIMP 2.10, save as tiff/EXR, import in cingg, set format to rgba-float, rendrer ..... hm, may be use YUView to see pixel values independently of cinelerra's decoding abilities? a bit of adventure, but should provide some proof about encoding)
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
Den 07.11.2024 22:53, skrev Terje J. Hanssen:
Den 07.11.2024 20:41, skrev Andrew Randrianasulu:
sorry I mean set like this export CIN_10BIT_ENC=1
Now hevc_vaapi was able to render to yuv420p10le, that is 10-bit 420p, by selecting pixels p010le. Also rendering with pixels y210 resulted in yuv420p10le, that is not 10-bit 422p as for hevc_qsv below.
I would assume this is caused due to the incomplete hevc_vapi.mp4 preset as shown below?
More like incomplete code that does not yet know how to get custom format ... so far as name says it only adds 10bit 4:2:0 encoding, not 4:2:2 subsampling.
can you test other vaapi/qsv profiles too?
also with test picture actually containing more than 8bit values? ;)
To the latter; the input file cfhd01.mkv was 10bit 422: yuv422p10le
Maybe have a look at and compare with the hevc_qsv code that managed 10bit 422: yuv422p10le?
Summary ---------------- hevc_vaapi.mp4 and av1_vaapi.mp4 Pixels: vaapi (default and only option) works and results in yuv420p p010 or p010le written works and result in yuv420p10le y210 or all variants y210le/Y210/le render (with fallback) to yuv420p10le h264_vaapi.mp4 didn't render (error message) av1_qsv.mp4 is for external ffmpeg
(probably made up something in GIMP 2.10, save as tiff/EXR, import in cingg, set format to rgba-float, rendrer ..... hm, may be use YUView to see pixel values independently of cinelerra's decoding abilities? a bit of adventure, but should provide some proof about encoding)
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
> > > > > > > > > > > >
сб, 9 нояб. 2024 г., 01:58 Terje J. Hanssen <[email protected]>:
Den 07.11.2024 22:53, skrev Terje J. Hanssen:
Den 07.11.2024 20:41, skrev Andrew Randrianasulu:
sorry I mean set like this export CIN_10BIT_ENC=1
Now hevc_vaapi was able to render to yuv420p10le, that is 10-bit 420p, by selecting pixels p010le. Also rendering with pixels y210 resulted in yuv420p10le, that is not 10-bit 422p as for hevc_qsv below.
I would assume this is caused due to the incomplete hevc_vapi.mp4 preset as shown below?
More like incomplete code that does not yet know how to get custom format ... so far as name says it only adds 10bit 4:2:0 encoding, not 4:2:2 subsampling.
can you test other vaapi/qsv profiles too?
also with test picture actually containing more than 8bit values? ;)
To the latter; the input file cfhd01.mkv was 10bit 422: yuv422p10le
Maybe have a look at and compare with the hevc_qsv code that managed 10bit 422: yuv422p10le?
Summary ----------------
hevc_vaapi.mp4 and av1_vaapi.mp4 Pixels: vaapi (default and only option) works and results in yuv420p p010 or p010le written works and result in yuv420p10le y210 or all variants y210le/Y210/le render (with fallback) to yuv420p10le
h264_vaapi.mp4 didn't render (error message)
yeah, no 10bit h264 here (while possible by spec)
av1_qsv.mp4 is for external ffmpeg
if you still have my onevpl patch applied (and enabled it earlier with configure switch) too - qsv should work ... try it too just in case?
(probably made up something in GIMP 2.10, save as tiff/EXR, import in cingg, set format to rgba-float, rendrer ..... hm, may be use YUView to see pixel values independently of cinelerra's decoding abilities? a bit of adventure, but should provide some proof about encoding)
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
"git log" where?
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
> > > > > > >
Den 09.11.2024 00:10, skrev Andrew Randrianasulu:
сб, 9 нояб. 2024 г., 01:58 Terje J. Hanssen <[email protected]>:
Den 07.11.2024 22:53, skrev Terje J. Hanssen:
Den 07.11.2024 20:41, skrev Andrew Randrianasulu:
sorry I mean set like this export CIN_10BIT_ENC=1
Now hevc_vaapi was able to render to yuv420p10le, that is 10-bit 420p, by selecting pixels p010le. Also rendering with pixels y210 resulted in yuv420p10le, that is not 10-bit 422p as for hevc_qsv below.
I would assume this is caused due to the incomplete hevc_vapi.mp4 preset as shown below?
More like incomplete code that does not yet know how to get custom format ... so far as name says it only adds 10bit 4:2:0 encoding, not 4:2:2 subsampling.
can you test other vaapi/qsv profiles too?
also with test picture actually containing more than 8bit values? ;)
To the latter; the input file cfhd01.mkv was 10bit 422: yuv422p10le
Maybe have a look at and compare with the hevc_qsv code that managed 10bit 422: yuv422p10le?
Summary ----------------
hevc_vaapi.mp4 and av1_vaapi.mp4 Pixels: vaapi (default and only option) works and results in yuv420p p010 or p010le written works and result in yuv420p10le y210 or all variants y210le/Y210/le render (with fallback) to yuv420p10le
h264_vaapi.mp4 didn't render (error message)
yeah, no 10bit h264 here (while possible by spec)
av1_qsv.mp4 is for external ffmpeg
if you still have my onevpl patch applied (and enabled it earlier with configure switch) too - qsv should work ...
try it too just in case?
av1_qsv.mp4 Would not render at all [av1_qsv @ 0x7fe19826f240] Current picture structure is unsupported [av1_qsv @ 0x7fe19826f240] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. FFMPEG::open_encoder err: Function not implemented int FFMPEG::open_encoder(const char*, const char*): open failed av1_qsv:/Videoklipp/Cineform/cfhd01_av1_qsv_pix_nv12.mp4 Render::render_single: Session finished. hevc_qsv.mp4 Does render, but only to yuv420p now. For one or another reason pixel formats p010le and y210le results in yuv420p. That is I am not able to reconstruct the previous 10bit results below. I do another attempt next day.
(probably made up something in GIMP 2.10, save as tiff/EXR, import in cingg, set format to rgba-float, rendrer ..... hm, may be use YUView to see pixel values independently of cinelerra's decoding abilities? a bit of adventure, but should provide some proof about encoding)
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
> > > > "git log" where? > > > > in cinelerra-5.1 directory, or some down the > hierarchy ... > > this is command, part of git suite of commands. > > displays log of commits in git repo. (for me > it uses l"less" as pager, so you can scroll > around and search) > > > >> >> >> >> >> >> >> >> >> >> >> >> >
Den 09.11.2024 10:48, skrev Terje J. Hanssen:
Den 09.11.2024 00:10, skrev Andrew Randrianasulu:
сб, 9 нояб. 2024 г., 01:58 Terje J. Hanssen <[email protected]>:
Den 07.11.2024 22:53, skrev Terje J. Hanssen:
Den 07.11.2024 20:41, skrev Andrew Randrianasulu:
sorry I mean set like this export CIN_10BIT_ENC=1
Now hevc_vaapi was able to render to yuv420p10le, that is 10-bit 420p, by selecting pixels p010le. Also rendering with pixels y210 resulted in yuv420p10le, that is not 10-bit 422p as for hevc_qsv below.
I would assume this is caused due to the incomplete hevc_vapi.mp4 preset as shown below?
More like incomplete code that does not yet know how to get custom format ... so far as name says it only adds 10bit 4:2:0 encoding, not 4:2:2 subsampling.
can you test other vaapi/qsv profiles too?
also with test picture actually containing more than 8bit values? ;)
To the latter; the input file cfhd01.mkv was 10bit 422: yuv422p10le
Maybe have a look at and compare with the hevc_qsv code that managed 10bit 422: yuv422p10le?
Summary ----------------
hevc_vaapi.mp4 and av1_vaapi.mp4 Pixels: vaapi (default and only option) works and results in yuv420p p010 or p010le written works and result in yuv420p10le y210 or all variants y210le/Y210/le render (with fallback) to yuv420p10le
h264_vaapi.mp4 didn't render (error message)
yeah, no 10bit h264 here (while possible by spec)
av1_qsv.mp4 is for external ffmpeg
if you still have my onevpl patch applied (and enabled it earlier with configure switch) too - qsv should work ...
try it too just in case?
av1_qsv.mp4 Would not render at all
[av1_qsv @ 0x7fe19826f240] Current picture structure is unsupported [av1_qsv @ 0x7fe19826f240] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. FFMPEG::open_encoder err: Function not implemented int FFMPEG::open_encoder(const char*, const char*): open failed av1_qsv:/Videoklipp/Cineform/cfhd01_av1_qsv_pix_nv12.mp4 Render::render_single: Session finished.
hevc_qsv.mp4 Does render, but only to yuv420p now. For one or another reason pixel formats p010le and y210le results in yuv420p. That is I am not able to reconstruct the previous 10bit results below. I do another attempt next day.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post ! # profile=main # cin_pix_fmt=nv12 Works both with and without export CIN_10BIT_ENC=1 before cin/bin
(probably made up something in GIMP 2.10, save as tiff/EXR, import in cingg, set format to rgba-float, rendrer ..... hm, may be use YUView to see pixel values independently of cinelerra's decoding abilities? a bit of adventure, but should provide some proof about encoding)
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
> > you also can set bin/ffmpeg/encode.opts loglevel > to debug, but render exactly one frame so log > will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
> > > > > > >> >> >> >> "git log" where? >> >> >> >> in cinelerra-5.1 directory, or some down >> the hierarchy ... >> >> this is command, part of git suite of commands. >> >> displays log of commits in git repo. (for >> me it uses l"less" as pager, so you can >> scroll around and search) >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >
сб, 9 нояб. 2024 г., 19:10 Terje J. Hanssen <[email protected]>:
Den 09.11.2024 10:48, skrev Terje J. Hanssen:
Den 09.11.2024 00:10, skrev Andrew Randrianasulu:
сб, 9 нояб. 2024 г., 01:58 Terje J. Hanssen <[email protected]>:
Den 07.11.2024 22:53, skrev Terje J. Hanssen:
Den 07.11.2024 20:41, skrev Andrew Randrianasulu:
sorry I mean set like this export CIN_10BIT_ENC=1
Now hevc_vaapi was able to render to yuv420p10le, that is 10-bit 420p, by selecting pixels p010le. Also rendering with pixels y210 resulted in yuv420p10le, that is not 10-bit 422p as for hevc_qsv below.
I would assume this is caused due to the incomplete hevc_vapi.mp4 preset as shown below?
More like incomplete code that does not yet know how to get custom format ... so far as name says it only adds 10bit 4:2:0 encoding, not 4:2:2 subsampling.
can you test other vaapi/qsv profiles too?
also with test picture actually containing more than 8bit values? ;)
To the latter; the input file cfhd01.mkv was 10bit 422: yuv422p10le
Maybe have a look at and compare with the hevc_qsv code that managed 10bit 422: yuv422p10le?
Summary ----------------
hevc_vaapi.mp4 and av1_vaapi.mp4 Pixels: vaapi (default and only option) works and results in yuv420p p010 or p010le written works and result in yuv420p10le y210 or all variants y210le/Y210/le render (with fallback) to yuv420p10le
h264_vaapi.mp4 didn't render (error message)
yeah, no 10bit h264 here (while possible by spec)
av1_qsv.mp4 is for external ffmpeg
if you still have my onevpl patch applied (and enabled it earlier with configure switch) too - qsv should work ...
try it too just in case?
av1_qsv.mp4 Would not render at all
[av1_qsv @ 0x7fe19826f240] Current picture structure is unsupported [av1_qsv @ 0x7fe19826f240] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. FFMPEG::open_encoder err: Function not implemented int FFMPEG::open_encoder(const char*, const char*): open failed av1_qsv:/Videoklipp/Cineform/cfhd01_av1_qsv_pix_nv12.mp4 Render::render_single: Session finished.
hevc_qsv.mp4 Does render, but only to yuv420p now. For one or another reason pixel formats p010le and y210le results in yuv420p. That is I am not able to reconstruct the previous 10bit results below. I do another attempt next day.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ... thanks for continued (and very exhaustive!) testing
(probably made up something in GIMP 2.10, save as tiff/EXR, import in cingg, set format to rgba-float, rendrer ..... hm, may be use YUView to see pixel values independently of cinelerra's decoding abilities? a bit of adventure, but should provide some proof about encoding)
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
> > "git log" where? >
in cinelerra-5.1 directory, or some down the hierarchy ...
this is command, part of git suite of commands.
displays log of commits in git repo. (for me it uses l"less" as pager, so you can scroll around and search)
> > > > > > >> >> >> >> >> >> >> >
Den 09.11.2024 17:16, skrev Andrew Randrianasulu:
сб, 9 нояб. 2024 г., 19:10 Terje J. Hanssen <[email protected]>:
Den 09.11.2024 10:48, skrev Terje J. Hanssen:
Den 09.11.2024 00:10, skrev Andrew Randrianasulu:
сб, 9 нояб. 2024 г., 01:58 Terje J. Hanssen <[email protected]>:
Den 07.11.2024 22:53, skrev Terje J. Hanssen:
Den 07.11.2024 20:41, skrev Andrew Randrianasulu:
sorry I mean set like this export CIN_10BIT_ENC=1
Now hevc_vaapi was able to render to yuv420p10le, that is 10-bit 420p, by selecting pixels p010le. Also rendering with pixels y210 resulted in yuv420p10le, that is not 10-bit 422p as for hevc_qsv below.
I would assume this is caused due to the incomplete hevc_vapi.mp4 preset as shown below?
More like incomplete code that does not yet know how to get custom format ... so far as name says it only adds 10bit 4:2:0 encoding, not 4:2:2 subsampling.
can you test other vaapi/qsv profiles too?
also with test picture actually containing more than 8bit values? ;)
To the latter; the input file cfhd01.mkv was 10bit 422: yuv422p10le
Maybe have a look at and compare with the hevc_qsv code that managed 10bit 422: yuv422p10le?
Summary ----------------
hevc_vaapi.mp4 and av1_vaapi.mp4 Pixels: vaapi (default and only option) works and results in yuv420p p010 or p010le written works and result in yuv420p10le y210 or all variants y210le/Y210/le render (with fallback) to yuv420p10le
h264_vaapi.mp4 didn't render (error message)
yeah, no 10bit h264 here (while possible by spec)
av1_qsv.mp4 is for external ffmpeg
if you still have my onevpl patch applied (and enabled it earlier with configure switch) too - qsv should work ...
try it too just in case?
av1_qsv.mp4 Would not render at all
[av1_qsv @ 0x7fe19826f240] Current picture structure is unsupported [av1_qsv @ 0x7fe19826f240] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. FFMPEG::open_encoder err: Function not implemented int FFMPEG::open_encoder(const char*, const char*): open failed av1_qsv:/Videoklipp/Cineform/cfhd01_av1_qsv_pix_nv12.mp4 Render::render_single: Session finished.
hevc_qsv.mp4 Does render, but only to yuv420p now. For one or another reason pixel formats p010le and y210le results in yuv420p. That is I am not able to reconstruct the previous 10bit results below. I do another attempt next day.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ...
thanks for continued (and very exhaustive!) testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul. As mentioned already above: hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post ! # profile=main # cin_pix_fmt=nv12 I experimented additional and got y210/profile=1 ==> yuv422p10le y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le I got similar results with my own dynamic Cingg built with ffmpeg 7.1. -------------------------- So a question beside: Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1 After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv. Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before: ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8 So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
(probably made up something in GIMP 2.10, save as tiff/EXR, import in cingg, set format to rgba-float, rendrer ..... hm, may be use YUView to see pixel values independently of cinelerra's decoding abilities? a bit of adventure, but should provide some proof about encoding)
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
> >> >> you also can set bin/ffmpeg/encode.opts >> loglevel to debug, but render exactly one >> frame so log will be smaller. > > How to render render exactly one frame ? > > > In render dialog window there is selection of > render range with 4 choices ... 1 frame mp4/webm > should be perfectly legal :) > > >> >> >> >> >> >> >>> >>> >>> >>> "git log" where? >>> >>> >>> >>> in cinelerra-5.1 directory, or some >>> down the hierarchy ... >>> >>> this is command, part of git suite of >>> commands. >>> >>> displays log of commits in git repo. >>> (for me it uses l"less" as pager, so >>> you can scroll around and search) >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >
On Mon, Nov 11, 2024 at 8:43 PM Terje J. Hanssen <[email protected]> wrote:
Den 09.11.2024 17:16, skrev Andrew Randrianasulu:
сб, 9 нояб. 2024 г., 19:10 Terje J. Hanssen <[email protected]>:
Den 09.11.2024 10:48, skrev Terje J. Hanssen:
Den 09.11.2024 00:10, skrev Andrew Randrianasulu:
сб, 9 нояб. 2024 г., 01:58 Terje J. Hanssen <[email protected]>:
Den 07.11.2024 22:53, skrev Terje J. Hanssen:
Den 07.11.2024 20:41, skrev Andrew Randrianasulu:
sorry I mean set like this export CIN_10BIT_ENC=1
Now hevc_vaapi was able to render to yuv420p10le, that is 10-bit 420p, by selecting pixels p010le. Also rendering with pixels y210 resulted in yuv420p10le, that is not 10-bit 422p as for hevc_qsv below.
I would assume this is caused due to the incomplete hevc_vapi.mp4 preset as shown below?
More like incomplete code that does not yet know how to get custom format ... so far as name says it only adds 10bit 4:2:0 encoding, not 4:2:2 subsampling.
can you test other vaapi/qsv profiles too?
also with test picture actually containing more than 8bit values? ;)
To the latter; the input file cfhd01.mkv was 10bit 422: yuv422p10le
Maybe have a look at and compare with the hevc_qsv code that managed 10bit 422: yuv422p10le?
Summary ----------------
hevc_vaapi.mp4 and av1_vaapi.mp4 Pixels: vaapi (default and only option) works and results in yuv420p p010 or p010le written works and result in yuv420p10le y210 or all variants y210le/Y210/le render (with fallback) to yuv420p10le
h264_vaapi.mp4 didn't render (error message)
yeah, no 10bit h264 here (while possible by spec)
av1_qsv.mp4 is for external ffmpeg
if you still have my onevpl patch applied (and enabled it earlier with configure switch) too - qsv should work ...
try it too just in case?
av1_qsv.mp4 Would not render at all
[av1_qsv @ 0x7fe19826f240] Current picture structure is unsupported [av1_qsv @ 0x7fe19826f240] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. FFMPEG::open_encoder err: Function not implemented int FFMPEG::open_encoder(const char*, const char*): open failed av1_qsv:/Videoklipp/Cineform/cfhd01_av1_qsv_pix_nv12.mp4 Render::render_single: Session finished.
hevc_qsv.mp4 Does render, but only to yuv420p now. For one or another reason pixel formats p010le and y210le results in yuv420p. That is I am not able to reconstruct the previous 10bit results below. I do another attempt next day.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ...
thanks for continued (and very exhaustive!) testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le
I got similar results with my own dynamic Cingg built with ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
onevpl/vaapi/vdpau - they all linked dynamically (not sure if static version of them even possible)
(probably made up something in GIMP 2.10, save as tiff/EXR, import in cingg, set format to rgba-float, rendrer ..... hm, may be use YUView to see pixel values independently of cinelerra's decoding abilities? a bit of adventure, but should provide some proof about encoding)
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
you also can set bin/ffmpeg/encode.opts loglevel to debug, but render exactly one frame so log will be smaller.
How to render render exactly one frame ?
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
> > > > > >> >> "git log" where? >> > > > in cinelerra-5.1 directory, or some down the hierarchy ... > > this is command, part of git suite of commands. > > displays log of commits in git repo. (for me it uses l"less" as > pager, so you can scroll around and search) > > > >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >> >
Den 11.11.2024 19:01, skrev Andrew Randrianasulu:
On Mon, Nov 11, 2024 at 8:43 PM Terje J. Hanssen <[email protected]> wrote:
Den 09.11.2024 17:16, skrev Andrew Randrianasulu:
сб, 9 нояб. 2024 г., 19:10 Terje J. Hanssen <[email protected]>:
Den 09.11.2024 10:48, skrev Terje J. Hanssen:
Den 09.11.2024 00:10, skrev Andrew Randrianasulu:
сб, 9 нояб. 2024 г., 01:58 Terje J. Hanssen <[email protected]>:
Den 07.11.2024 22:53, skrev Terje J. Hanssen:
Den 07.11.2024 20:41, skrev Andrew Randrianasulu:
> > > > sorry I mean set like this > export CIN_10BIT_ENC=1 > >
Now hevc_vaapi was able to render to yuv420p10le, that is 10-bit 420p, by selecting pixels p010le. Also rendering with pixels y210 resulted in yuv420p10le, that is not 10-bit 422p as for hevc_qsv below.
I would assume this is caused due to the incomplete hevc_vapi.mp4 preset as shown below?
More like incomplete code that does not yet know how to get custom format ... so far as name says it only adds 10bit 4:2:0 encoding, not 4:2:2 subsampling.
can you test other vaapi/qsv profiles too?
also with test picture actually containing more than 8bit values? ;)
To the latter; the input file cfhd01.mkv was 10bit 422: yuv422p10le
Maybe have a look at and compare with the hevc_qsv code that managed 10bit 422: yuv422p10le?
Summary ----------------
hevc_vaapi.mp4 and av1_vaapi.mp4 Pixels: vaapi (default and only option) works and results in yuv420p p010 or p010le written works and result in yuv420p10le y210 or all variants y210le/Y210/le render (with fallback) to yuv420p10le
h264_vaapi.mp4 didn't render (error message)
yeah, no 10bit h264 here (while possible by spec)
av1_qsv.mp4 is for external ffmpeg
if you still have my onevpl patch applied (and enabled it earlier with configure switch) too - qsv should work ...
try it too just in case?
av1_qsv.mp4 Would not render at all
[av1_qsv @ 0x7fe19826f240] Current picture structure is unsupported [av1_qsv @ 0x7fe19826f240] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters. FFMPEG::open_encoder err: Function not implemented int FFMPEG::open_encoder(const char*, const char*): open failed av1_qsv:/Videoklipp/Cineform/cfhd01_av1_qsv_pix_nv12.mp4 Render::render_single: Session finished.
hevc_qsv.mp4 Does render, but only to yuv420p now. For one or another reason pixel formats p010le and y210le results in yuv420p. That is I am not able to reconstruct the previous 10bit results below. I do another attempt next day.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ...
thanks for continued (and very exhaustive!) testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le
I got similar results with my own dynamic Cingg built with ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
onevpl/vaapi/vdpau - they all linked dynamically (not sure if static version of them even possible)
Ah, I see. I tried to compare the two configure lines for my full dynamic Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively: ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx ./configure --with-single-user --with-onevpl As the first line didn't mention "vpl" I searched backwards and got the understanding that the source code was patched to use the system libvpl. In the second case the build-system itself was patched with onevpl (default off) to use the same system libvpl, I assume? Is/will possibly the current or upcoming Cingg appimage/rpm available with the onevpl patch, so it can be switched on and tested on other available hardware? .
(probably made up something in GIMP 2.10, save as tiff/EXR, import in cingg, set format to rgba-float, rendrer ..... hm, may be use YUView to see pixel values independently of cinelerra's decoding abilities? a bit of adventure, but should provide some proof about encoding)
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
> > ----- > > No hevc_vaapi 10bit worked: > > localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 > mp4 hevc_vaapi > # cin_hw_dev=vaapi > > I tested hevc_vaapi.m4 and tried to write > p010 both in the pixels field and as > format=p010 in the widget, > but only 8bit 420p each time. > > ------------------------------- > > hevc_qsv 10 bit worked with p010 and with y210 > > localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 > # only usable with ext. ffmpeg, another > pixfmt is yuyv422 > mp4 hevc_qsv > # profile=main > # cin_pix_fmt=nv12 > > > ffprobe -hide_banner > cfhd01_hevc_qsv_pix_p010le.mp4 > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from > 'cfhd01_hevc_qsv_pix_p010le.mp4': > Metadata: > major_brand : isom > minor_version : 512 > compatible_brands: isomiso2mp41 > encoder : Lavf61.1.100 > Duration: 00:01:11.20, start: 0.000000, > bitrate: 28276 kb/s > Stream #0:0[0x1](und): Video: hevc (Main > 10) (hev1 / 0x31766568), yuv420p10le(tv, > bt709/unknown/unknown, top coded first > (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], > 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) > Metadata: > handler_name : VideoHandler > vendor_id : [0][0][0][0] > > > ffprobe -hide_banner > cfhd01_hevc_qsv_pix_y210le.mp4 > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from > 'cfhd01_hevc_qsv_pix_y210le.mp4': > Metadata: > major_brand : isom > minor_version : 512 > compatible_brands: isomiso2mp41 > encoder : Lavf61.1.100 > Duration: 00:01:11.20, start: 0.000000, > bitrate: 32074 kb/s > Stream #0:0[0x1](und): Video: hevc (Rext) > (hev1 / 0x31766568), yuv422p10le(tv, > bt709/unknown/unknown, top coded first > (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], > 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) > Metadata: > handler_name : VideoHandler > vendor_id : [0][0][0][0] > >> >>> >>> you also can set >>> bin/ffmpeg/encode.opts loglevel to >>> debug, but render exactly one frame so >>> log will be smaller. >> >> How to render render exactly one frame ? >> >> >> In render dialog window there is selection >> of render range with 4 choices ... 1 frame >> mp4/webm should be perfectly legal :) >> >> >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> "git log" where? >>>> >>>> >>>> >>>> in cinelerra-5.1 directory, or >>>> some down the hierarchy ... >>>> >>>> this is command, part of git >>>> suite of commands. >>>> >>>> displays log of commits in git >>>> repo. (for me it uses l"less" as >>>> pager, so you can scroll around >>>> and search) >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >
пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen <[email protected]>: {snip}
.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ...
thanks for continued (and very exhaustive!) testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le
I got similar results with my own dynamic Cingg built with ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
onevpl/vaapi/vdpau - they all linked dynamically (not sure if static version of them even possible)
Ah, I see.
I tried to compare the two configure lines for my full dynamic Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively:
./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx ./configure --with-single-user --with-onevpl
As the first line didn't mention "vpl" I searched backwards and got the understanding that the source code was patched to use the system libvpl.
not exactly, in first case it just uses libav* from system ffmpeg package... and this in your case uses libvpl. In the second case the build-system itself was patched with onevpl (default
off) to use the same system libvpl, I assume?
Is/will possibly the current or upcoming Cingg appimage/rpm available with the onevpl patch, so it can be switched on and tested on other available hardware?
I was about to ask if onevpl patch can be added to git ... Dear Phyllis, can you add onevpl.patch so future QSV testing will be easier (it defaults to off so should not break anything ... by default). while there, Terje, can you pack your latest profile work and send it separately? I think we use codec_encoder_additional_params.container as format so 10bit 420 hevc qsv for mp4 will look like hevc_qsv_10bit.mp4 with content you experimentally determinated. and y210 probably will be named hevc_qsv_y210.mp4
.
(probably made up something in GIMP 2.10, save as tiff/EXR, import in cingg, set format to rgba-float, rendrer ..... hm, may be use YUView to see pixel values independently of cinelerra's decoding abilities? a bit of adventure, but should provide some proof about encoding)
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_vaapi_pix_y210.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_vaapi_pix_y210.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 11082 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-----
No hevc_vaapi 10bit worked:
localhost:/Cin/ffmpeg/video # cat hevc_vaapi.mp4 mp4 hevc_vaapi # cin_hw_dev=vaapi
I tested hevc_vaapi.m4 and tried to write p010 both in the pixels field and as format=p010 in the widget, but only 8bit 420p each time.
-------------------------------
hevc_qsv 10 bit worked with p010 and with y210
localhost:/Cin/ffmpeg/video # cat hevc_qsv.mp4 # only usable with ext. ffmpeg, another pixfmt is yuyv422 mp4 hevc_qsv # profile=main # cin_pix_fmt=nv12
ffprobe -hide_banner cfhd01_hevc_qsv_pix_p010le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_p010le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 28276 kb/s Stream #0:0[0x1](und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
ffprobe -hide_banner cfhd01_hevc_qsv_pix_y210le.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cfhd01_hevc_qsv_pix_y210le.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 32074 kb/s Stream #0:0[0x1](und): Video: hevc (Rext) (hev1 / 0x31766568), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
> > you also can set bin/ffmpeg/encode.opts loglevel to debug, but > render exactly one frame so log will be smaller. > > > How to render render exactly one frame ? >
In render dialog window there is selection of render range with 4 choices ... 1 frame mp4/webm should be perfectly legal :)
> > > > >> >> >> >> >> >>> >>> "git log" where? >>> >> >> >> in cinelerra-5.1 directory, or some down the hierarchy ... >> >> this is command, part of git suite of commands. >> >> displays log of commits in git repo. (for me it uses l"less" as >> pager, so you can scroll around and search) >> >> >> >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >
Den 11.11.2024 22:20, skrev Andrew Randrianasulu:
пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen <[email protected]>:
{snip}
.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ...
thanks for continued (and very exhaustive!) testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le
I got similar results with my own dynamic Cingg built with ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
onevpl/vaapi/vdpau - they all linked dynamically (not sure if static version of them even possible)
Ah, I see.
I tried to compare the two configure lines for my full dynamic Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively:
./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx ./configure --with-single-user --with-onevpl
As the first line didn't mention "vpl" I searched backwards and got the understanding that the source code was patched to use the system libvpl.
not exactly, in first case it just uses libav* from system ffmpeg package... and this in your case uses libvpl.
In the second case the build-system itself was patched with onevpl (default off) to use the same system libvpl, I assume?
Is/will possibly the current or upcoming Cingg appimage/rpm available with the onevpl patch, so it can be switched on and tested on other available hardware?
I was about to ask if onevpl patch can be added to git ...
Dear Phyllis, can you add onevpl.patch so future QSV testing will be easier (it defaults to off so should not break anything ... by default).
while there, Terje, can you pack your latest profile work and send it separately? I think we use codec_encoder_additional_params.container as format
so 10bit 420 hevc qsv for mp4 will look like
hevc_qsv_10bit.mp4
with content you experimentally determinated.
and y210 probably will be named
hevc_qsv_y210.mp4
What about hevc_qsv_10bit-420.mp4 and hevc_qsv_10bit-422.mp4 respectively?
.
> (probably made up something in GIMP 2.10, save > as tiff/EXR, import in cingg, set format to > rgba-float, rendrer ..... hm, may be use YUView > to see pixel values independently of cinelerra's > decoding abilities? a bit of adventure, but > should provide some proof about encoding) > > > ffprobe -hide_banner > cfhd01_hevc_vaapi_pix_p010le.mp4 > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from > 'cfhd01_hevc_vaapi_pix_p010le.mp4': > Metadata: > major_brand : isom > minor_version : 512 > compatible_brands: isomiso2mp41 > encoder : Lavf61.1.100 > Duration: 00:01:11.20, start: 0.000000, > bitrate: 11082 kb/s > Stream #0:0[0x1](und): Video: hevc (Main > 10) (hev1 / 0x31766568), yuv420p10le(tv, > bt709/unknown/unknown, top coded first > (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], > 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) > Metadata: > handler_name : VideoHandler > vendor_id : [0][0][0][0] > > ffprobe -hide_banner > cfhd01_hevc_vaapi_pix_y210.mp4 > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from > 'cfhd01_hevc_vaapi_pix_y210.mp4': > Metadata: > major_brand : isom > minor_version : 512 > compatible_brands: isomiso2mp41 > encoder : Lavf61.1.100 > Duration: 00:01:11.20, start: 0.000000, > bitrate: 11082 kb/s > Stream #0:0[0x1](und): Video: hevc (Main > 10) (hev1 / 0x31766568), yuv420p10le(tv, > bt709/unknown/unknown, top coded first > (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], > 11080 kb/s, 25 fps, 25 tbr, 12800 tbn (default) > Metadata: > handler_name : VideoHandler > vendor_id : [0][0][0][0] > >> >> ----- >> >> No hevc_vaapi 10bit worked: >> >> localhost:/Cin/ffmpeg/video # cat >> hevc_vaapi.mp4 >> mp4 hevc_vaapi >> # cin_hw_dev=vaapi >> >> I tested hevc_vaapi.m4 and tried to >> write p010 both in the pixels field and >> as format=p010 in the widget, >> but only 8bit 420p each time. >> >> ------------------------------- >> >> hevc_qsv 10 bit worked with p010 and >> with y210 >> >> localhost:/Cin/ffmpeg/video # cat >> hevc_qsv.mp4 >> # only usable with ext. ffmpeg, another >> pixfmt is yuyv422 >> mp4 hevc_qsv >> # profile=main >> # cin_pix_fmt=nv12 >> >> >> ffprobe -hide_banner >> cfhd01_hevc_qsv_pix_p010le.mp4 >> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from >> 'cfhd01_hevc_qsv_pix_p010le.mp4': >> Metadata: >> major_brand : isom >> minor_version : 512 >> compatible_brands: isomiso2mp41 >> encoder : Lavf61.1.100 >> Duration: 00:01:11.20, start: >> 0.000000, bitrate: 28276 kb/s >> Stream #0:0[0x1](und): Video: hevc >> (Main 10) (hev1 / 0x31766568), >> yuv420p10le(tv, bt709/unknown/unknown, >> top coded first (swapped)), 1920x1080 >> [SAR 1:1 DAR 16:9], 28273 kb/s, 25 fps, >> 25 tbr, 12800 tbn (default) >> Metadata: >> handler_name : VideoHandler >> vendor_id : [0][0][0][0] >> >> >> ffprobe -hide_banner >> cfhd01_hevc_qsv_pix_y210le.mp4 >> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from >> 'cfhd01_hevc_qsv_pix_y210le.mp4': >> Metadata: >> major_brand : isom >> minor_version : 512 >> compatible_brands: isomiso2mp41 >> encoder : Lavf61.1.100 >> Duration: 00:01:11.20, start: >> 0.000000, bitrate: 32074 kb/s >> Stream #0:0[0x1](und): Video: hevc >> (Rext) (hev1 / 0x31766568), >> yuv422p10le(tv, bt709/unknown/unknown, >> top coded first (swapped)), 1920x1080 >> [SAR 1:1 DAR 16:9], 32071 kb/s, 25 fps, >> 25 tbr, 12800 tbn (default) >> Metadata: >> handler_name : VideoHandler >> vendor_id : [0][0][0][0] >> >>> >>>> >>>> you also can set >>>> bin/ffmpeg/encode.opts loglevel >>>> to debug, but render exactly one >>>> frame so log will be smaller. >>> >>> How to render render exactly one >>> frame ? >>> >>> >>> In render dialog window there is >>> selection of render range with 4 >>> choices ... 1 frame mp4/webm should be >>> perfectly legal :) >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> "git log" where? >>>>> >>>>> >>>>> >>>>> in cinelerra-5.1 directory, >>>>> or some down the hierarchy ... >>>>> >>>>> this is command, part of git >>>>> suite of commands. >>>>> >>>>> displays log of commits in >>>>> git repo. (for me it uses >>>>> l"less" as pager, so you can >>>>> scroll around and search) >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
вт, 12 нояб. 2024 г., 00:31 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:20, skrev Andrew Randrianasulu:
пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen <[email protected]>:
{snip}
.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ...
thanks for continued (and very exhaustive!) testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le
I got similar results with my own dynamic Cingg built with ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
onevpl/vaapi/vdpau - they all linked dynamically (not sure if static version of them even possible)
Ah, I see.
I tried to compare the two configure lines for my full dynamic Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively:
./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx ./configure --with-single-user --with-onevpl
As the first line didn't mention "vpl" I searched backwards and got the understanding that the source code was patched to use the system libvpl.
not exactly, in first case it just uses libav* from system ffmpeg package... and this in your case uses libvpl.
In the second case the build-system itself was patched with onevpl
(default off) to use the same system libvpl, I assume?
Is/will possibly the current or upcoming Cingg appimage/rpm available with the onevpl patch, so it can be switched on and tested on other available hardware?
I was about to ask if onevpl patch can be added to git ...
Dear Phyllis, can you add onevpl.patch so future QSV testing will be easier (it defaults to off so should not break anything ... by default).
while there, Terje, can you pack your latest profile work and send it separately? I think we use codec_encoder_additional_params.container as format
so 10bit 420 hevc qsv for mp4 will look like
hevc_qsv_10bit.mp4
with content you experimentally determinated.
and y210 probably will be named
hevc_qsv_y210.mp4
What about
hevc_qsv_10bit-420.mp4
and
hevc_qsv_10bit-422.mp4
respectively?
if those relative long names fit their box - then ok ...
Den 11.11.2024 22:34, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 00:31 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:20, skrev Andrew Randrianasulu:
пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen <[email protected]>:
{snip}
.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ...
thanks for continued (and very exhaustive!) testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le
I got similar results with my own dynamic Cingg built with ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
onevpl/vaapi/vdpau - they all linked dynamically (not sure if static version of them even possible)
Ah, I see.
I tried to compare the two configure lines for my full dynamic Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively:
./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx ./configure --with-single-user --with-onevpl
As the first line didn't mention "vpl" I searched backwards and got the understanding that the source code was patched to use the system libvpl.
not exactly, in first case it just uses libav* from system ffmpeg package... and this in your case uses libvpl.
In the second case the build-system itself was patched with onevpl (default off) to use the same system libvpl, I assume?
Is/will possibly the current or upcoming Cingg appimage/rpm available with the onevpl patch, so it can be switched on and tested on other available hardware?
I was about to ask if onevpl patch can be added to git ...
Dear Phyllis, can you add onevpl.patch so future QSV testing will be easier (it defaults to off so should not break anything ... by default).
while there, Terje, can you pack your latest profile work and send it separately?
Do you mean to attach them with filenames to a separate post here or?
I think we use codec_encoder_additional_params.container as format
so 10bit 420 hevc qsv for mp4 will look like
hevc_qsv_10bit.mp4
with content you experimentally determinated.
and y210 probably will be named
hevc_qsv_y210.mp4
What about
hevc_qsv_10bit-420.mp4
and
hevc_qsv_10bit-422.mp4
respectively?
if those relative long names fit their box - then ok ...
An alternative short(er) form and still a relative unambiguous description hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4
вт, 12 нояб. 2024 г., 11:41 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:34, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 00:31 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:20, skrev Andrew Randrianasulu:
пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen <[email protected]>:
{snip}
.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ...
thanks for continued (and very exhaustive!) testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le
I got similar results with my own dynamic Cingg built with ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
onevpl/vaapi/vdpau - they all linked dynamically (not sure if static version of them even possible)
Ah, I see.
I tried to compare the two configure lines for my full dynamic Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively:
./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx ./configure --with-single-user --with-onevpl
As the first line didn't mention "vpl" I searched backwards and got the understanding that the source code was patched to use the system libvpl.
not exactly, in first case it just uses libav* from system ffmpeg package... and this in your case uses libvpl.
In the second case the build-system itself was patched with onevpl
(default off) to use the same system libvpl, I assume?
Is/will possibly the current or upcoming Cingg appimage/rpm available with the onevpl patch, so it can be switched on and tested on other available hardware?
I was about to ask if onevpl patch can be added to git ...
Dear Phyllis, can you add onevpl.patch so future QSV testing will be easier (it defaults to off so should not break anything ... by default).
while there, Terje, can you pack your latest profile work and send it separately?
Do you mean to attach them with filenames to a separate post here or?
yes.
I think we use codec_encoder_additional_params.container as format
so 10bit 420 hevc qsv for mp4 will look like
hevc_qsv_10bit.mp4
with content you experimentally determinated.
and y210 probably will be named
hevc_qsv_y210.mp4
What about
hevc_qsv_10bit-420.mp4
and
hevc_qsv_10bit-422.mp4
respectively?
if those relative long names fit their box - then ok ...
An alternative short(er) form and still a relative unambiguous description
hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4
then make them so!
Den 12.11.2024 09:59, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 11:41 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:34, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 00:31 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:20, skrev Andrew Randrianasulu:
пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen <[email protected]>:
{snip}
.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ...
thanks for continued (and very exhaustive!) testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le
I got similar results with my own dynamic Cingg built with ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
onevpl/vaapi/vdpau - they all linked dynamically (not sure if static version of them even possible)
Ah, I see.
I tried to compare the two configure lines for my full dynamic Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively:
./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx ./configure --with-single-user --with-onevpl
As the first line didn't mention "vpl" I searched backwards and got the understanding that the source code was patched to use the system libvpl.
not exactly, in first case it just uses libav* from system ffmpeg package... and this in your case uses libvpl.
In the second case the build-system itself was patched with onevpl (default off) to use the same system libvpl, I assume?
Is/will possibly the current or upcoming Cingg appimage/rpm available with the onevpl patch, so it can be switched on and tested on other available hardware?
I was about to ask if onevpl patch can be added to git ...
Dear Phyllis, can you add onevpl.patch so future QSV testing will be easier (it defaults to off so should not break anything ... by default).
while there, Terje, can you pack your latest profile work and send it separately?
Do you mean to attach them with filenames to a separate post here or?
yes.
I think we use codec_encoder_additional_params.container as format
so 10bit 420 hevc qsv for mp4 will look like
hevc_qsv_10bit.mp4
with content you experimentally determinated.
and y210 probably will be named
hevc_qsv_y210.mp4
What about
hevc_qsv_10bit-420.mp4
and
hevc_qsv_10bit-422.mp4
respectively?
if those relative long names fit their box - then ok ...
An alternative short(er) form and still a relative unambiguous description
hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4
then make them so!
I have some questions: I know how to edit the content of the included "generic" video preset cat /Cin/bin/ffmpeg/video/hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12 to create three additional, typical types: hevc_qsv_8b420.mp4 hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4 I can load these compression types, but Cingg won't render with other names than with the hevc_qsv.mp4? What decide what become available in the Video Preset Pixel field, one single default or nv12 on top of a drop down menu? Testing with added global_quality=25 works seemingly well and uses higher bit rate vs without this flag (default): hdv input: 5938 kb/s vs 3090 kb/s cfhd input: 4644 kb/s vs 2245 kb/s
вт, 12 нояб. 2024 г., 18:32 Terje J. Hanssen <[email protected]>:
Den 12.11.2024 09:59, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 11:41 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:34, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 00:31 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:20, skrev Andrew Randrianasulu:
пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen <[email protected]>:
{snip}
.
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ...
thanks for continued (and very exhaustive!) testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le
I got similar results with my own dynamic Cingg built with ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
onevpl/vaapi/vdpau - they all linked dynamically (not sure if static version of them even possible)
Ah, I see.
I tried to compare the two configure lines for my full dynamic Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively:
./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx ./configure --with-single-user --with-onevpl
As the first line didn't mention "vpl" I searched backwards and got the understanding that the source code was patched to use the system libvpl.
not exactly, in first case it just uses libav* from system ffmpeg package... and this in your case uses libvpl.
In the second case the build-system itself was patched with onevpl
(default off) to use the same system libvpl, I assume?
Is/will possibly the current or upcoming Cingg appimage/rpm available with the onevpl patch, so it can be switched on and tested on other available hardware?
I was about to ask if onevpl patch can be added to git ...
Dear Phyllis, can you add onevpl.patch so future QSV testing will be easier (it defaults to off so should not break anything ... by default).
while there, Terje, can you pack your latest profile work and send it separately?
Do you mean to attach them with filenames to a separate post here or?
yes.
I think we use codec_encoder_additional_params.container as format
so 10bit 420 hevc qsv for mp4 will look like
hevc_qsv_10bit.mp4
with content you experimentally determinated.
and y210 probably will be named
hevc_qsv_y210.mp4
What about
hevc_qsv_10bit-420.mp4
and
hevc_qsv_10bit-422.mp4
respectively?
if those relative long names fit their box - then ok ...
An alternative short(er) form and still a relative unambiguous description
hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4
then make them so!
I have some questions:
I know how to edit the content of the included "generic" video preset
cat /Cin/bin/ffmpeg/video/hevc_qsv.mp4
mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
to create three additional, typical types:
hevc_qsv_8b420.mp4 hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4
I can load these compression types, but Cingg won't render with other names than with the hevc_qsv.mp4?
show content of those for all of us? ;)
What decide what become available in the Video Preset Pixel field, one single default or nv12 on top of a drop down menu?
whatever individual encoder describes in their pixfmt array .... (inside libavcodec)
Testing with added
global_quality=25
works seemingly well and uses higher bit rate vs without this flag (default):
hdv input: 5938 kb/s vs 3090 kb/s cfhd input: 4644 kb/s vs 2245 kb/s
good.
Den 12.11.2024 16:42, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 18:32 Terje J. Hanssen <[email protected]>:
Den 12.11.2024 09:59, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 11:41 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:34, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 00:31 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:20, skrev Andrew Randrianasulu:
пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen <[email protected]>:
{snip}
> .
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
Works both with and without export CIN_10BIT_ENC=1 before cin/bin
we most likely will need new profiles for 10bit everything anyway ...
thanks for continued (and very exhaustive!) testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le
I got similar results with my own dynamic Cingg built with ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
onevpl/vaapi/vdpau - they all linked dynamically (not sure if static version of them even possible)
Ah, I see.
I tried to compare the two configure lines for my full dynamic Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively:
./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx ./configure --with-single-user --with-onevpl
As the first line didn't mention "vpl" I searched backwards and got the understanding that the source code was patched to use the system libvpl.
not exactly, in first case it just uses libav* from system ffmpeg package... and this in your case uses libvpl.
In the second case the build-system itself was patched with onevpl (default off) to use the same system libvpl, I assume?
Is/will possibly the current or upcoming Cingg appimage/rpm available with the onevpl patch, so it can be switched on and tested on other available hardware?
I was about to ask if onevpl patch can be added to git ...
Dear Phyllis, can you add onevpl.patch so future QSV testing will be easier (it defaults to off so should not break anything ... by default).
while there, Terje, can you pack your latest profile work and send it separately?
Do you mean to attach them with filenames to a separate post here or?
yes.
I think we use codec_encoder_additional_params.container as format
so 10bit 420 hevc qsv for mp4 will look like
hevc_qsv_10bit.mp4
with content you experimentally determinated.
and y210 probably will be named
hevc_qsv_y210.mp4
What about
hevc_qsv_10bit-420.mp4
and
hevc_qsv_10bit-422.mp4
respectively?
if those relative long names fit their box - then ok ...
An alternative short(er) form and still a relative unambiguous description
hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4
then make them so!
I have some questions:
I know how to edit the content of the included "generic" video preset
cat /Cin/bin/ffmpeg/video/hevc_qsv.mp4
mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
to create three additional, typical types:
hevc_qsv_8b420.mp4 hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4
I can load these compression types, but Cingg won't render with other names than with the hevc_qsv.mp4?
show content of those for all of us? ;)
Of course, we can clarify the questions this way. cat hevc_qsv_8b420.mp4 mp4 hevc_qsv_8b420 # usable with Pixels: nv12 profile=main # global_quality=25 cat hevc_qsv_10b420.mp4 mp4 hevc_qsv_10b420 # usable with Pixels: p010le profile=main10 # global_quality=25 cat hevc_qsv_10b422.mp4 mp4 hevc_qsv_10b422 # usable with Pixels: y210le profile=0 # global_quality=25 If I load these compression Preset types, two issues arise: 1. The window content is correct, but the Pixel field is not: no drop down menu, but preferably nv12, p010le or y210le should be selected directly. (I have tested these work, but not all other options on the drop down menu) 2. Rendering won't run and the error output int FFMPEG::open_encoder(const char*, const char*): cant find codec hevc_qsv_8b420:/Videoklipp/Cineform/cfhd01_hevc_qsv_pix_nv12.mp4 However, as mentioned, if I load the default hevc_qsv.mp4 instead and copy the content above in its window and select the right Pixel format, rendering works fine. ffprobe -hide_banner cfhd01_hevc_qsv_pix_nv12.mp4 Duration: 00:01:11.20, start: 0.000000, bitrate: 2245 kb/s Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 2242 kb/s, 25 fps, 25 tbr, 12800 tbn (default) and with the gobal_quality=25 flag enabled: ffprobe -hide_banner cfhd01_hevc_qsv_pix_nv12_gq25.mp4 Duration: 00:01:11.20, start: 0.000000, bitrate: 4644 kb/s Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 4642 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
What decide what become available in the Video Preset Pixel field, one single default or nv12 on top of a drop down menu?
whatever individual encoder describes in their pixfmt array .... (inside libavcodec)
Testing with added
global_quality=25
works seemingly well and uses higher bit rate vs without this flag (default):
hdv input: 5938 kb/s vs 3090 kb/s cfhd input: 4644 kb/s vs 2245 kb/s
good.
Den 12.11.2024 21:53, skrev Terje J. Hanssen:
Den 12.11.2024 16:42, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 18:32 Terje J. Hanssen <[email protected]>:
Den 12.11.2024 09:59, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 11:41 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:34, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 00:31 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:20, skrev Andrew Randrianasulu:
пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen <[email protected]>:
{snip}
>> . > > > hevc_qsv.mp4 revised: > pixel formats p010le and y210le render > again to yuv420p10le and .yuv422p10le > respectively > Woops; only when these window lines are > commented out as written in my previous > post ! > > # profile=main > # cin_pix_fmt=nv12 > > Works both with and without > export CIN_10BIT_ENC=1 > before cin/bin > > > > we most likely will need new profiles for > 10bit everything anyway ... > > thanks for continued (and very exhaustive!) > testing
Also the preset's combination of pixel formats and the right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised: pixel formats p010le and y210le render again to yuv420p10le and .yuv422p10le respectively Woops; only when these window lines are commented out as written in my previous post !
# profile=main # cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==> yuv420p10le
I got similar results with my own dynamic Cingg built with ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of Tumbleweed-Slowroll, which replaced Packman package libs and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel ffmpeg-7-libswscale-devel libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like it is dependent of one or more system packages/libs beside? Any idea what packages it can be ?
onevpl/vaapi/vdpau - they all linked dynamically (not sure if static version of them even possible)
Ah, I see.
I tried to compare the two configure lines for my full dynamic Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively:
./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx ./configure --with-single-user --with-onevpl
As the first line didn't mention "vpl" I searched backwards and got the understanding that the source code was patched to use the system libvpl.
not exactly, in first case it just uses libav* from system ffmpeg package... and this in your case uses libvpl.
In the second case the build-system itself was patched with onevpl (default off) to use the same system libvpl, I assume?
Is/will possibly the current or upcoming Cingg appimage/rpm available with the onevpl patch, so it can be switched on and tested on other available hardware?
I was about to ask if onevpl patch can be added to git ...
Dear Phyllis, can you add onevpl.patch so future QSV testing will be easier (it defaults to off so should not break anything ... by default).
while there, Terje, can you pack your latest profile work and send it separately?
Do you mean to attach them with filenames to a separate post here or?
yes.
I think we use codec_encoder_additional_params.container as format
so 10bit 420 hevc qsv for mp4 will look like
hevc_qsv_10bit.mp4
with content you experimentally determinated.
and y210 probably will be named
hevc_qsv_y210.mp4
What about
hevc_qsv_10bit-420.mp4
and
hevc_qsv_10bit-422.mp4
respectively?
if those relative long names fit their box - then ok ...
An alternative short(er) form and still a relative unambiguous description
hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4
then make them so!
I have some questions:
I know how to edit the content of the included "generic" video preset
cat /Cin/bin/ffmpeg/video/hevc_qsv.mp4
mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
to create three additional, typical types:
hevc_qsv_8b420.mp4 hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4
I can load these compression types, but Cingg won't render with other names than with the hevc_qsv.mp4?
show content of those for all of us? ;)
Of course, we can clarify the questions this way.
cat hevc_qsv_8b420.mp4
mp4 hevc_qsv_8b420 # usable with Pixels: nv12 profile=main # global_quality=25
cat hevc_qsv_10b420.mp4
mp4 hevc_qsv_10b420 # usable with Pixels: p010le profile=main10 # global_quality=25
cat hevc_qsv_10b422.mp4
mp4 hevc_qsv_10b422 # usable with Pixels: y210le profile=0 # global_quality=25
Attached the three presets
If I load these compression Preset types, two issues arise:
1. The window content is correct, but the Pixel field is not: no drop down menu, but preferably nv12, p010le or y210le should be selected directly. (I have tested these work, but not all other options on the drop down menu)
2. Rendering won't run and the error output int FFMPEG::open_encoder(const char*, const char*): cant find codec hevc_qsv_8b420:/Videoklipp/Cineform/cfhd01_hevc_qsv_pix_nv12.mp4
However, as mentioned, if I load the default hevc_qsv.mp4 instead and copy the content above in its window and select the right Pixel format, rendering works fine.
ffprobe -hide_banner cfhd01_hevc_qsv_pix_nv12.mp4 Duration: 00:01:11.20, start: 0.000000, bitrate: 2245 kb/s Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 2242 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
and with the gobal_quality=25 flag enabled:
ffprobe -hide_banner cfhd01_hevc_qsv_pix_nv12_gq25.mp4 Duration: 00:01:11.20, start: 0.000000, bitrate: 4644 kb/s Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 4642 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
What decide what become available in the Video Preset Pixel field, one single default or nv12 on top of a drop down menu?
whatever individual encoder describes in their pixfmt array .... (inside libavcodec)
Testing with added
global_quality=25
works seemingly well and uses higher bit rate vs without this flag (default):
hdv input: 5938 kb/s vs 3090 kb/s cfhd input: 4644 kb/s vs 2245 kb/s
good.
Den 12.11.2024 21:58, skrev Terje J. Hanssen:
Den 12.11.2024 21:53, skrev Terje J. Hanssen:
Den 12.11.2024 16:42, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 18:32 Terje J. Hanssen <[email protected]>:
Den 12.11.2024 09:59, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 11:41 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:34, skrev Andrew Randrianasulu:
вт, 12 нояб. 2024 г., 00:31 Terje J. Hanssen <[email protected]>:
Den 11.11.2024 22:20, skrev Andrew Randrianasulu:
пн, 11 нояб. 2024 г., 23:43 Terje J. Hanssen <[email protected]>:
{snip}
>>> . >> >> >> hevc_qsv.mp4 revised: >> pixel formats p010le and y210le render >> again to yuv420p10le and .yuv422p10le >> respectively >> Woops; only when these window lines are >> commented out as written in my previous >> post ! >> >> # profile=main >> # cin_pix_fmt=nv12 >> >> Works both with and without >> export CIN_10BIT_ENC=1 >> before cin/bin >> >> >> >> we most likely will need new profiles for >> 10bit everything anyway ... >> >> thanks for continued (and very exhaustive!) >> testing > > Also the preset's combination of pixel > formats and the right (ffmpeg) codec > profiles would need an overhaul. > > As mentioned already above: > > hevc_qsv.mp4 revised: > pixel formats p010le and y210le render again > to yuv420p10le and .yuv422p10le respectively > Woops; only when these window lines are > commented out as written in my previous post ! > > # profile=main > # cin_pix_fmt=nv12 > > > I experimented additional and got > > y210/profile=1 ==> yuv422p10le > > y210/ profile=main10/ profile=2/ profile=3 > ==> yuv420p10le > > I got similar results with my own dynamic > Cingg built with ffmpeg 7.1. > > -------------------------- > > So a question beside: > > Yesterday I did a new (monthly) upgrade of > Tumbleweed-Slowroll, which replaced Packman > package libs and ffmpeg 7.1 > > After that, the static Cingg with onevpl and > 10bit patch would not render hevc_qsv. > > Today's upgrade with new Packman packages > up-to-date with the new Slowroll version, > and now Cingg worked as before: > > ffmpeg-7 ffmpeg-7-libavcodec-devel > ffmpeg-7-libavdevice-devel > ffmpeg-7-libavfilter-devel > ffmpeg-7-libavformat-devel > ffmpeg-7-libavutil-devel > ffmpeg-7-libpostproc-devel > ffmpeg-7-libswresample-devel > ffmpeg-7-libswscale-devel libavcodec61 > libavdevice61 libavfilter10 libavformat61 > libavutil59 libpostproc58 > libswresample5 libswscale8 > > So even Cingg with onevpl is static built, > it looks like it is dependent of one or more > system packages/libs beside? > Any idea what packages it can be ? > > > > onevpl/vaapi/vdpau - they all linked dynamically > (not sure if static version of them even possible)
Ah, I see.
I tried to compare the two configure lines for my full dynamic Cingg/ffmpeg7.1 built and static-dynamic Cingg/ffmpeg7.0 respectively:
./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx ./configure --with-single-user --with-onevpl
As the first line didn't mention "vpl" I searched backwards and got the understanding that the source code was patched to use the system libvpl.
not exactly, in first case it just uses libav* from system ffmpeg package... and this in your case uses libvpl.
In the second case the build-system itself was patched with onevpl (default off) to use the same system libvpl, I assume?
Is/will possibly the current or upcoming Cingg appimage/rpm available with the onevpl patch, so it can be switched on and tested on other available hardware?
I was about to ask if onevpl patch can be added to git ...
Dear Phyllis, can you add onevpl.patch so future QSV testing will be easier (it defaults to off so should not break anything ... by default).
while there, Terje, can you pack your latest profile work and send it separately?
Do you mean to attach them with filenames to a separate post here or?
yes.
I think we use codec_encoder_additional_params.container as format
so 10bit 420 hevc qsv for mp4 will look like
hevc_qsv_10bit.mp4
with content you experimentally determinated.
and y210 probably will be named
hevc_qsv_y210.mp4
What about
hevc_qsv_10bit-420.mp4
and
hevc_qsv_10bit-422.mp4
respectively?
if those relative long names fit their box - then ok ...
An alternative short(er) form and still a relative unambiguous description
hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4
then make them so!
I have some questions:
I know how to edit the content of the included "generic" video preset
cat /Cin/bin/ffmpeg/video/hevc_qsv.mp4
mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
to create three additional, typical types:
hevc_qsv_8b420.mp4 hevc_qsv_10b420.mp4 hevc_qsv_10b422.mp4
I can load these compression types, but Cingg won't render with other names than with the hevc_qsv.mp4?
show content of those for all of us? ;)
Of course, we can clarify the questions this way.
cat hevc_qsv_8b420.mp4
mp4 hevc_qsv_8b420 # usable with Pixels: nv12 profile=main # global_quality=25
cat hevc_qsv_10b420.mp4
mp4 hevc_qsv_10b420 # usable with Pixels: p010le profile=main10 # global_quality=25
cat hevc_qsv_10b422.mp4
mp4 hevc_qsv_10b422 # usable with Pixels: y210le profile=0 # global_quality=25
Attached the three presets
If I load these compression Preset types, two issues arise:
1. The window content is correct, but the Pixel field is not: no drop down menu, but preferably nv12, p010le or y210le should be selected directly. (I have tested these work, but not all other options on the drop down menu)
2. Rendering won't run and the error output int FFMPEG::open_encoder(const char*, const char*): cant find codec hevc_qsv_8b420:/Videoklipp/Cineform/cfhd01_hevc_qsv_pix_nv12.mp4
However, as mentioned, if I load the default hevc_qsv.mp4 instead and copy the content above in its window and select the right Pixel format, rendering works fine.
ffprobe -hide_banner cfhd01_hevc_qsv_pix_nv12.mp4 Duration: 00:01:11.20, start: 0.000000, bitrate: 2245 kb/s Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 2242 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
and with the gobal_quality=25 flag enabled:
ffprobe -hide_banner cfhd01_hevc_qsv_pix_nv12_gq25.mp4 Duration: 00:01:11.20, start: 0.000000, bitrate: 4644 kb/s Stream #0:0[0x1](und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], 4642 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
I think I solved it. The first line in all presets need to be identical with the original preset to get the original drop down Pixel menu mp4 hevc_qsv That is all three presets content and as attached edited: hevc_qsv_8b420.mp4 mp4 hevc_qsv # usable with Pixels: nv12 profile=main # global_quality=25 hevc_qsv_10b420.mp4 mp4 hevc_qsv # usable with Pixels: p010le profile=main10 # global_quality=25 hevc_qsv_10b422.mp4 mp4 hevc_qsv # usable with Pixels: y210le profile=0 # global_quality=25
What decide what become available in the Video Preset Pixel field, one single default or nv12 on top of a drop down menu?
whatever individual encoder describes in their pixfmt array .... (inside libavcodec)
Testing with added
global_quality=25
works seemingly well and uses higher bit rate vs without this flag (default):
hdv input: 5938 kb/s vs 3090 kb/s cfhd input: 4644 kb/s vs 2245 kb/s
good.
Phyllis, can you add onevpl.patch so future QSV testing will be easier (it defaults to off so should not break anything ... by default).
OK, has the onevpl.patch changed since I downloaded it on Oct. 18th? I want to make sure I have the correct version so am attaching the one I have. Let me know if it changed and I missed the update.
while there, Terje, can you pack your latest profile work and send it separately? I think we use codec_encoder_additional_params.container as format
so 10bit 420 hevc qsv for mp4 will look like
hevc_qsv_10bit.mp4
with content you experimentally determinated.
and y210 probably will be named
hevc_qsv_y210.mp4
ср, 13 нояб. 2024 г., 02:00 Phyllis Smith <[email protected]>:
Phyllis, can you add onevpl.patch so future QSV testing will be easier
(it defaults to off so should not break anything ... by default).
OK, has the onevpl.patch changed since I downloaded it on Oct. 18th? I want to make sure I have the correct version so am attaching the one I have. Let me know if it changed and I missed the update.
No, I think this one was first and last version (I removed x264-high bit depth option because we always build multilib x264 nowadays)
while there, Terje, can you pack your latest profile work and send it separately? I think we use codec_encoder_additional_params.container as format
so 10bit 420 hevc qsv for mp4 will look like
hevc_qsv_10bit.mp4
with content you experimentally determinated.
and y210 probably will be named
hevc_qsv_y210.mp4
participants (3)
-
Andrew Randrianasulu -
Phyllis Smith -
Terje J. Hanssen