now it uses faster settings with lower quality (but you actually can wait that long for encoding, unlike current default) tested with libaom-3.1.0 (3.1.1 already around) settings copied from https://trac.ffmpeg.org/wiki/Encode/AV1 ps: strange, other 'strict - 2' profile (ffmpeg's mjpeg2k encoder) works ok.. so, option processing not broken...
Amazing improvement in speed -- it makes it possible to create AOM media format. A 1 1/2 minute video with audio OLD took 43 minutes versus NEW took 7 minutes. The only thing that was a surprise and I have no explanation for is the size difference. 4101702 OLD versus 4403173 NEW but they seem to "play" the same. I will check this into GIT tomorrow (or the next time I turn on that computer). THANKS a lot, Andrew. On Tue, Jun 15, 2021 at 5:25 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
now it uses faster settings with lower quality (but you actually can wait that long for encoding, unlike current default)
tested with libaom-3.1.0 (3.1.1 already around)
settings copied from
https://trac.ffmpeg.org/wiki/Encode/AV1
ps: strange, other 'strict - 2' profile (ffmpeg's mjpeg2k encoder) works ok.. so, option processing not broken... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Wednesday, June 16, 2021, Phyllis Smith via Cin < [email protected]> wrote:
Amazing improvement in speed -- it makes it possible to create AOM media format. A 1 1/2 minute video with audio OLD took 43 minutes versus NEW took 7 minutes. The only thing that was a surprise and I have no explanation for is the size difference. 4101702 OLD versus 4403173 NEW but they seem to "play" the same.
Then I think it might be 'same quality at higher bitrate'...
I will check this into GIT tomorrow (or the next time I turn on that computer). THANKS a lot, Andrew.
On Tue, Jun 15, 2021 at 5:25 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
now it uses faster settings with lower quality (but you actually can wait that long for encoding, unlike current default)
tested with libaom-3.1.0 (3.1.1 already around)
settings copied from
https://trac.ffmpeg.org/wiki/Encode/AV1
ps: strange, other 'strict - 2' profile (ffmpeg's mjpeg2k encoder) works ok.. so, option processing not broken... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Does this mean that this later aom version is/can now be included in Cin-GG? I seem to recall Nasm 2.14 or later was required for that, and that integration of that in the Cin-GG source was not ready yet. MatN On Wed, 16 Jun 2021 02:25:18 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
now it uses faster settings with lower quality (but you actually can wait that long for encoding, unlike current default)
tested with libaom-3.1.0 (3.1.1 already around)
settings copied from
https://trac.ffmpeg.org/wiki/Encode/AV1
ps: strange, other 'strict - 2' profile (ffmpeg's mjpeg2k encoder) works ok.. so, option processing not broken...
On Wednesday, June 16, 2021, mnieuw--- via Cin <[email protected]> wrote:
Does this mean that this later aom version is/can now be included in Cin-GG? I seem to recall Nasm 2.14 or later was required for that, and that integration of that in the Cin-GG source was not ready yet.
yeah, i have patches for nasm-2.14 too... (but my current build platform is arm) https://github.com/Randrianasulu/CinelerraGG-slackbuild/blob/master/nasm_thi... you also obviously need to put nasm tarball in thirdparty/src but this one disables x86 detection, need to redo it for working on arm ) I think basically surrounding this thirdparty block in configure.ac with same test for x86-ness will work.. thirdparty/Makefile probably need some variables instead of hardcoding nasm as requirement for x264/x265/dav1d but all this machinery needed for old distros...
MatN
On Wed, 16 Jun 2021 02:25:18 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
now it uses faster settings with lower quality (but you actually can wait that long for encoding, unlike current default)
tested with libaom-3.1.0 (3.1.1 already around)
settings copied from
https://trac.ffmpeg.org/wiki/Encode/AV1
ps: strange, other 'strict - 2' profile (ffmpeg's mjpeg2k encoder) works ok.. so, option processing not broken...
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
MatN:
Does this mean that this later aom version is/can now be included in Cin-GG? I seem to recall Nasm 2.14 or later was required for that, and that integration of that in the Cin-GG source was not ready yet.
Yes, I will try to do this for June 30th ONLY for the newer distros AppImage. The av1.webm mod as supplied by Andrew, has been checked into GIT. (I also included 240 in theme.C because Gorge said that was a viable format and so might as well let users see it. It already worked with other checkin though.
I tried rendering with AV1.webm; it's still very slow: 1.3 fps to encode 291 frames (9s of video) in 224s. It is always unusable, in my opinion.
On Friday, June 18, 2021, Phyllis Smith via Cin <[email protected]> wrote:
MatN:
Does this mean that this later aom version is/can now be included in Cin-GG? I seem to recall Nasm 2.14 or later was required for that, and that integration of that in the Cin-GG source was not ready yet.
Yes, I will try to do this for June 30th ONLY for the newer distros AppImage.
The av1.webm mod as supplied by Andrew, has been checked into GIT. (I also included 240 in theme.C because Gorge said that was a viable format and so might as well let users see it. It already worked with other checkin though.
I also see there was fix for 'gang channels' mode... was it broken? (sorry not following our bugzilla closely). Did you/reporter test this change for say nested projects? (I can't see why it should affect those, but my C-fu definitely not strong enough to be confident..)
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
mnieuw＠zap.a2000.nl -
Phyllis Smith