$ git clone https://github.com/ruffle-rs/h263-rs
$ cd h263-rs
$ rg --count unsafe
$упс. Кажется, у кого-то ясновидение замутнилось.
Или может дьявол кроется в депендансах?
$ find . -name Cargo.toml -exec cat {} \;
[workspace]
members = [
"h263",
"yuv",
]
resolver = "2"
# Don't optimize build scripts and macros.
[profile.release.build-override]
opt-level = 0
[profile.dev]
panic = "abort"
[profile.release]
panic = "abort"
[profile.dev.package.h263-rs]
opt-level = 3
[profile.dev.package.h263-rs-yuv]
opt-level = 3[package]
name = "h263-rs"
version = "0.1.0"
authors = ["Mike Welsh <mwelsh@gmail.com>"]
edition = "2018"
license = "MIT OR Apache-2.0"
[dependencies]
bitflags = "1.3.2"
thiserror = "1.0"
num-traits = "0.2.12"
lazy_static = "1.4.0"[package]
name = "h263-rs-yuv"
version = "0.1.0"
authors = ["Mike Welsh <mwelsh@gmail.com>"]
edition = "2018"
license = "MIT OR Apache-2.0"
bitflags, thiserror, num-traits, lazy_static... Чисто декларативные депендансы. Там в bitflags могут быть unsafe связанные с преобразованиями целочисленных типов, но скорее всего там тоже нет. В lazy_static... хз, может быть, но я подозреваю, что там на Mutex да RefCell всё сделано, и весь смысл существования этого lazy_static, чтобы объявление "безопасной" глобальной переменной укладывалось бы в две строки, а не в десять.
Но вот то, что они позволяют себе писать Cargo.toml, не добавляя lf в конец последней строки -- это, конечно, ай-яй-яй, как так можно, вывод в консоль перекосило из-за этого.
Вот к чему есть вопросы, так это к производительности этой реализации. Она ж небось на cpu декодирует, и моё ясновидение подсказывает, что использование всяких SSE и тп отдано на откуп компилятору -- если он справится соптимизировать в sse, значит будет, не справится, значит не будет. И вот тут реально встают вопросы, как быстро всё это работает.
