rust-av/grav1synth

Grain Synth analyzer and editor for AV1 files

Rust-AV

Pure-rust implementation of multimedia primitives and eventually some examples of demuxers, muxers and codecs.

Compiling

cargo build --workspace

Running tests

cargo test --workspace

Examples

Examples can be found in the examples repository.

Notes

The code is still in flux and the API is getting slowly fleshed out, please refer to the sub-crates. Until we reach version 1.0 assume that the API could change a lot.

License

Released under the MIT License.

Developing

I suggest to use the cargo paths override to have a local rust-av:

# Clone the trees
$ git clone https://github.com/rust-av/rust-av
$ git clone https://github.com/rust-av/${other package}
# Setup the override
$ cd ${other package}
$ mkdir .cargo
$ echo 'paths=["../rust-av"]' > .cargo/config
# Check it is doing the right thing
$ cargo build

Getting in Touch

Come chat with us on our IRC channel clicking the badge above! You can also use a web client to join with a web browser.

Otherwise, you can open a new discussion explaining your idea or problem as best as possible.

grav1synth's Issues

Add a progress bar

Please add a progress bar for the diff function

CapacityError in grain.rs

Hello, I get a CapacityError when trying to run this on a video I encoded with SVT-AV1. This will be an amazing tool if I can get it working properly, I've been very disappointed that SVT-AV1 doesn't have external denoising, and this will work perfectly to achieve the same thing.

RUST_BACKTRACE=full grav1synth inspect --output out.txt S01E01.mkv
[libdav1d @ 0x55d9b85e6100] libdav1d 0.9.2
[libdav1d @ 0x55d9b87f46c0] libdav1d 0.9.2
thread 'main' panicked at 'called Result::unwrap() on an Err value: CapacityError: insufficient capacity', src/parser/grain.rs:170:26
stack backtrace:
0: 0x55d9b651c974 - std::backtrace_rs::backtrace::libunwind::trace::hf4179216f2af7039
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x55d9b651c974 - std::backtrace_rs::backtrace::trace_unsynchronized::hfa14eb12e4b8ce4f
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x55d9b651c974 - std::sys_common::backtrace::_print_fmt::hc81cbee2043ec868
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/sys_common/backtrace.rs:65:5
3: 0x55d9b651c974 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h7b2be2009a6bcba2
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/sys_common/backtrace.rs:44:22
4: 0x55d9b63c3ede - core::fmt::write::hccee7882499b620f
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/core/src/fmt/mod.rs:1209:17
5: 0x55d9b64ff245 - std::io::Write::write_fmt::h69e1f37bb24a9f49
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/io/mod.rs:1682:15
6: 0x55d9b651c735 - std::sys_common::backtrace::print::h86df92192f156e4c
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/sys_common/backtrace.rs:47:5
7: 0x55d9b651c735 - std::sys_common::backtrace::print::h3b76d5113eea7ae3
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/sys_common/backtrace.rs:34:9
8: 0x55d9b6508cbf - std::panicking::default_hook::{{closure}}::h634bc187e8e58de8
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/panicking.rs:267:22
9: 0x55d9b6508975 - std::panicking::default_hook::h262aef5e4abfc826
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/panicking.rs:286:9
10: 0x55d9b650927f - std::panicking::rust_panic_with_hook::hedb8a8e4067bf251
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/panicking.rs:688:13
11: 0x55d9b651cc84 - std::panicking::begin_panic_handler::{{closure}}::hf501de419c9dcde3
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/panicking.rs:579:13
12: 0x55d9b651caac - std::sys_common::backtrace::__rust_end_short_backtrace::h8542e72ad556a307
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/sys_common/backtrace.rs:137:18
13: 0x55d9b6508e32 - rust_begin_unwind
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/panicking.rs:575:5
14: 0x55d9b63381d3 - core::panicking::panic_fmt::h1688e859668ba1d0
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/core/src/panicking.rs:65:14
15: 0x55d9b63384a3 - core::result::unwrap_failed::h9f204f08b8ff9323
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/core/src/result.rs:1791:5
16: 0x55d9b6409849 - grav1synth::parser::grain::film_grain_params::h16b105321cfcbdd2
17: 0x55d9b64032b5 - grav1synth::parser::frame::<impl grav1synth::parser::BitstreamParser<>>::parse_frame_header::hc0fc0a2ebc706c90
18: 0x55d9b641c116 - grav1synth::main::heea484d139b3a3b5
19: 0x55d9b63ea1c3 - std::sys_common::backtrace::__rust_begin_short_backtrace::hae45523b8e7b83a7
20: 0x55d9b63ea4ed - std::rt::lang_start::{{closure}}::hb87baa42a4512f12
21: 0x55d9b64fe3f9 - core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once::h37feed43940ccfab
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/core/src/ops/function.rs:286:13
22: 0x55d9b64fe3f9 - std::panicking::try::do_call::h8fe1ed7bdb58d0f5
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/panicking.rs:483:40
23: 0x55d9b64fe3f9 - std::panicking::try::h87c3f91ef362d0ca
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/panicking.rs:447:19
24: 0x55d9b64fe3f9 - std::panic::catch_unwind::hd6a68686ac8f53ed
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/panic.rs:137:14
25: 0x55d9b64fe3f9 - std::rt::lang_start_internal::{{closure}}::hdc22961783632ef0
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/rt.rs:148:48
26: 0x55d9b64fe3f9 - std::panicking::try::do_call::h92fd045c6d8aed83
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/panicking.rs:483:40
27: 0x55d9b64fe3f9 - std::panicking::try::haa1526bc83feb2c9
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/panicking.rs:447:19
28: 0x55d9b64fe3f9 - std::panic::catch_unwind::hb3d0e1586c57c804
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/panic.rs:137:14
29: 0x55d9b64fe3f9 - std::rt::lang_start_internal::hed890805d128cbd3
at /build/rustc-ujz1Py/rustc-1.66.1+dfsg0ubuntu1/library/std/src/rt.rs:148:20
30: 0x55d9b643b705 - main
31: 0x7fa162dc4d90 -
32: 0x7fa162dc4e40 - __libc_start_main
33: 0x55d9b6340d45 - _start
34: 0x0 -

CapacityError

I'm getting this error on all aomenc encodes (haven't tested on svt/rav1e)
thread 'main' panicked at 'called Result::unwrap() on an Err value: CapacityError: insufficient capacity', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/arrayvec-0.7.2/src/arrayvec_impl.rs:39:32
If you need a rust backtrace, let me know what command to use.

Crash when trying to remove grain

When trying to run grav1synth remove --output nograin.mkv lightgrain.mkv (v0.1.0-beta.5), grav1synth immediately dies with the error:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: CapacityError: insufficient capacity'

Any ideas?

inspect no worky

thread 'main' panicked at 'range start index 18446744073709551615 out of range for slice of length 410174', library\core\src\slice\index.rs:52:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

running inspect on every video I tested on gives me this

Error while generating with latest version

When I try to generate film grain for a video .ivf file encoded using SvtAv1EncApp and ffmpeg, I get the following error:

[libdav1d @ 0x5598f5d69280] libdav1d ed63a74
[libdav1d @ 0x5598f5dd3600] libdav1d ed63a74
[av1_metadata @ 0x5598f5dbd1c0] zero_bit out of range: 1, but must be in [0,0].
[av1_metadata @ 0x5598f5dbd1c0] Failed to read unit 0 (type 6).
[av1_metadata @ 0x5598f5dbd1c0] Failed to read temporal unit from packet.
[ivf @ 0x5598f5dbbfc0] Error applying bitstream filters to an output packet for stream #0: Invalid data found when processing input
Error: Invalid data found when processing input

What am I doing wrong here? Here's the command used:

grav1synth generate S01E04-video.av1.ivf -o S01E04-video.gen.ivf --iso 2000 --chroma

ffmpeg 7.0 support

ffmpeg 7.0 support would be great

Arbitrary end time value for final segment of grain table file

To add multiprocessing, I performed grav1synth diff on multiple clips made from a single video. Specifically I made source and denoised source using av1an and I'm performing the diff operation on the chunks generated before concatenation, and I was hoping to combine the generated tables to apply to the concatenated file. I was hoping I could offset the start and end times of each segment based on the timestamps from the previous grain table file, but the last segment end time of each grain table file is always "9223372036854775807". Here are the first 3 grain table files:
1st Table

filmgrn1
E 0 9223372036854775807 1 10956 1
	p 3 8 0 11 0 1 128 192 256 128 192 256
	sY 5  0 38 107 38 148 36 188 32 255 31
	sCb 7 0 17 54 17 107 15 134 14 188 17 215 17 255 17
	sCr 5 0 20 54 20 148 17 228 19 255 19
	cY 4 -1 2 11 3 -3 6 5 5 -18 -3 -3 -1 -2 0 -44 21 86 24 7 3 1 58 70
	cCb 3 0 -4 13 -4 -8 2 7 -6 -23 21 4 -3 -2 -9 -45 9 87 23 18 3 -2 81 80 7
	cCr 5 -2 -3 13 -4 -6 3 2 -7 -19 15 8 0 -4 -7 -36 7 77 24 15 4 7 75 71 10

2nd Table

filmgrn1
E 0 417083 1 10956 1
	p 3 8 0 11 0 1 128 192 256 128 192 256
	sY 8  0 62 54 62 107 60 134 56 188 47 201 45 215 44 255 41
	sCb 3 0 18 148 19 255 17
	sCr 6 0 23 188 22 215 18 228 15 242 15 255 15
	cY 8 -1 6 -1 4 -6 9 -4 10 -15 6 -8 7 -6 7 -26 22 58 22 4 14 -3 43 58
	cCb 2 2 -9 22 0 -8 -2 9 -3 -19 24 -2 -3 -9 -6 -48 -6 80 20 21 15 -5 64 102 14
	cCr 2 -1 -9 18 0 -7 3 -2 4 0 23 -8 0 -6 4 -39 -4 66 20 18 12 -2 51 89 14
E 417083 9223372036854775807 1 0 1
	p 3 8 0 11 0 1 128 192 256 128 192 256
	sY 3  0 37 107 36 255 34
	sCb 4 0 24 107 24 174 23 255 21
	sCr 5 0 22 121 21 188 20 242 16 255 16
	cY 0 0 3 10 1 -3 3 5 4 -19 -13 -4 -4 -1 -1 -40 26 93 27 17 8 -5 54 67
	cCb 3 0 -1 8 -4 -8 -2 4 -9 -17 13 10 -2 -1 -11 -37 36 84 20 21 8 -3 84 42 9
	cCr 2 0 -1 9 -5 -8 1 4 -7 -16 12 6 -1 0 -9 -39 33 89 23 19 7 -3 80 44 5

3rd Table

filmgrn1
E 0 417083 1 10956 1
	p 3 8 0 11 0 1 128 192 256 128 192 256
	sY 7  0 72 94 71 121 70 174 61 215 49 242 47 255 47
	sCb 7 0 42 54 42 81 39 121 29 134 28 201 17 255 19
	sCr 8 0 35 54 35 81 33 121 26 161 23 215 16 228 14 255 14
	cY 8 1 9 1 9 -2 11 -4 16 -8 0 -4 15 -4 15 -11 12 52 8 0 12 1 27 45
	cCb 0 -6 -3 19 5 -4 1 -2 16 -13 -6 -5 4 2 10 -33 -13 105 10 5 5 0 38 100 6
	cCr 3 -7 2 13 2 -4 -1 -5 14 -7 -1 3 0 2 1 -26 -9 102 15 10 1 6 38 83 3
E 417083 9223372036854775807 1 0 1
	p 3 8 0 11 0 1 128 192 256 128 192 256
	sY 7  0 51 54 51 81 49 121 43 161 39 188 34 255 33
	sCb 7 0 37 54 37 81 34 121 26 201 19 215 19 255 19
	sCr 9 0 34 54 34 81 32 121 26 134 25 174 22 201 17 242 15 255 15
	cY 4 0 2 8 2 -3 6 6 8 -18 -11 -6 -1 -1 3 -44 18 94 28 8 3 -6 49 84
	cCb 2 -3 -3 13 -1 -6 2 4 7 -13 3 0 1 1 0 -42 0 96 18 10 6 -3 59 89 2
	cCr 1 -3 -1 11 1 -3 -1 1 5 -11 4 3 0 2 -2 -34 4 93 15 11 7 0 55 85 2

As is I have no way of telling when the last segment of each file should end and the next segment in the next file should start.

wrong framerates

I get a resulting file with 24fps in mkv container and 25 fps on the extracted videostream inputing a 23,976 mkv file with the generate --iso 400 command.
Any ideas how i can solve that?

Greetings

Eof in lr_params

Hey, this is more of a request for help debugging. I have a sample that fails to parse, I managed to track it down to frame.rs:1377 which yields something like:
Error: VerboseError { errors: [([], Nom(Eof)), ([51, 87, 36, 5, 136, 241, 134, 134, 226, 205, 2, 8, 32, 130, 0, 0, 0, 128, 0, 183, 192, 205, 57, 244], Context("Failed parsing frame header")), ([51, 87, 36, 5, 136, 241, 134, 134, 226, 205, 2, 8, 32, 130, 0, 0, 0, 128, 0, 183, 192, 205, 57, 244], Context("Failed parsing frame obu"))] }

Do you have any idea why we could encounter Eof here? It looks like we should only be on the 7th bit (we have three planes). In the meantime, I will try to whittle the sample down for better reproduction.

Thanks!

resolution mistake

Getting this error: Error: Luma resolutions were not equal, 960x544 != 960x540 with grav1synth diff -f 'resize:alg=hermite,width=960,height=540' with the source being 1920x1080 and the encode being 960x540.
For some reason it thinks the scaled source is 960x544 even though that's not what I provided in the filters params.
Seems to be an issue with this specific resolution because running diff with the same source encoded in 720p instead worked flawlessly with the source was downscaled with the expected resolution.

Diff produces a broken table

Diff'ing these two files produces a broken film grain table. The coefficients are b0rked somehow, and if you use the table in aomenc, you get a very interesting grain layer there..

https://drive.google.com/file/d/1V2e8DRlNO_KGfEVfiRWO83dwSV2YthkB/view?usp=drive_link
https://drive.google.com/file/d/1hVUvOne-WRNX2QpYfY8w8XETBjQbtedN/view?usp=drive_link
tng s06e02_grain.txt

The same happens if you use the original source (1080p) and crop the left and right side borders (244 pixels both) off and try working on that without downscaling to 720p. If you crop and add the borders back before encoding the reference and lossless clip, no problems so the problem is somewhere in grav1synth.

I also tried various cropping parameters but none of them worked. Cropping the top and bottom borders has not caused any problems in my tests.