Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(libxmf): expose libvpx,add rust examples with it #55

Merged
merged 55 commits into from
Nov 20, 2024

Conversation

irvingoujAtDevolution
Copy link
Contributor

@irvingoujAtDevolution irvingoujAtDevolution commented Nov 13, 2024

This pull request exposes libvpx encoder/decoder alone with Images,Frames and Packets to the caller.

Updated rust xmf-sys and wrapped rust cadeau with a safe abstraction.

Added examples to cut the video at a block level precision.

The file timed-dvls.webm is a un-remuxed file copied directly from Gateway recording, which can be used to test the rust cut example.

@irvingoujAtDevolution irvingoujAtDevolution changed the title ARC 251 devolutions gateway video session shadowing feat(libxmf): expose libvpx,add rust examples with it Nov 13, 2024
libxmf/XmfVpxDecoder.c Outdated Show resolved Hide resolved
libxmf/XmfVpxDecoder.c Outdated Show resolved Hide resolved
libxmf/XmfVpxEncoder.c Outdated Show resolved Hide resolved
libxmf/XmfVpxEncoder.c Outdated Show resolved Hide resolved
@thenextman
Copy link
Member

I thought the C and bindings looks good to me

I didn't really look at the example, and I can't comment on how normative the rust files are.

It's hard to build a mental model of the C/rust interface but I didn't see anything that looked obviously bad or unsafe.

Good job!

Copy link
Member

@CBenoit CBenoit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went through most of it, but I still need some time to review the unsafe code. Since I have a lot of comments for you already, start by addressing them, and I’ll go over it again then.

media/timed-dvls.webm Outdated Show resolved Hide resolved
rust/cadeau/examples/cut/debug.rs Outdated Show resolved Hide resolved
rust/cadeau/examples/cut/main.rs Outdated Show resolved Hide resolved
rust/cadeau/examples/cut/main.rs Outdated Show resolved Hide resolved
rust/cadeau/examples/cut/main.rs Outdated Show resolved Hide resolved
rust/cadeau/src/xmf/vpx/mod.rs Outdated Show resolved Hide resolved
rust/cadeau/src/xmf/vpx/mod.rs Outdated Show resolved Hide resolved
rust/cadeau/src/xmf/vpx/mod.rs Outdated Show resolved Hide resolved
rust/cadeau/src/xmf/vpx/mod.rs Outdated Show resolved Hide resolved
rust/cadeau/src/xmf/vpx/mod.rs Outdated Show resolved Hide resolved
Comment on lines 142 to 145
if !(surface_step * height <= buffer.len()) {
if surface_step * height > buffer.len() {
return Err(RecorderError::BadArgument { name: "buffer" });
}
if !(width * height * 4 <= buffer.len()) {
if width * height * 4 > buffer.len() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This got reverted again. What’s happening?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I know why, it is because of clippy!

Copy link
Member

@CBenoit CBenoit Nov 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed! Can you annotate the function with this?

#[expect(clippy::nonminimal_bool)]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like expect is an experiment feature, can I use allow instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, it was stabilized recently. You can update the Rust toolchain instead 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to update rust-toolchain.toml

libxmf/XmfVpxImage.h Outdated Show resolved Hide resolved
@CBenoit
Copy link
Member

CBenoit commented Nov 19, 2024

Can you also try to run the examples with the LLVM memory sanitizers?

You’ll need to build the xmf C library with something like this (at the beginning of the CMakeLists.txt file)

target_compile_options(-fsanitize=address)
target_link_options(-fsanitize=address -static-libasan)

And Rust nightly + RUSTFLAGS="-Z sanitizer=address" for the Rust build.

Someone recently wrote a walkthrough blog post about exactly that: https://geo-ant.github.io/blog/2024/rust-address-sanitizer-with-c/

Maybe you can use that as a reference.

First, try to introduce a memory issue in the C code and verify that the sanitizer catches it. Then, remove it and try to run the examples, and see if you get any problem.

libxmf/XmfVpxPacket.h Outdated Show resolved Hide resolved
@irvingoujAtDevolution
Copy link
Contributor Author

Can you also try to run the examples with the LLVM memory sanitizers?

You’ll need to build the xmf C library with something like this (at the beginning of the CMakeLists.txt file)

target_compile_options(-fsanitize=address)
target_link_options(-fsanitize=address -static-libasan)

And Rust nightly + RUSTFLAGS="-Z sanitizer=address" for the Rust build.

Someone recently wrote a walkthrough blog post about exactly that: https://geo-ant.github.io/blog/2024/rust-address-sanitizer-with-c/

Maybe you can use that as a reference.

First, try to introduce a memory issue in the C code and verify that the sanitizer catches it. Then, remove it and try to run the examples, and see if you get any problem.

I really have problem doing this, I'll try valgrind in wsl instead,

@irvingoujAtDevolution
Copy link
Contributor Author

Here's the Valgrind report

==13623== Memcheck, a memory error detector
==13623== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==13623== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==13623== Command: ./target/debug/examples/cut -i ../media/clock.webm -o ../media/clock-cut.webm --lib-xmf ../build/lib/libxmf.so -c 10
==13623== Parent PID: 6846
==13623== 
==13623== 
==13623== HEAP SUMMARY:
==13623==     in use at exit: 83,256 bytes in 15 blocks
==13623==   total heap usage: 3,615 allocs, 3,600 frees, 91,209,539 bytes allocated
==13623== 
==13623== 23 bytes in 1 blocks are still reachable in loss record 1 of 10
==13623==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13623==    by 0x40271DF: malloc (rtld-malloc.h:56)
==13623==    by 0x40271DF: strdup (strdup.c:42)
==13623==    by 0x400A588: _dl_map_object (dl-load.c:2259)
==13623==    by 0x400E9A8: dl_open_worker_begin (dl-open.c:534)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400E34D: _dl_open (dl-open.c:883)
==13623==    by 0x491163B: dlopen_doit (dlopen.c:56)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x49F5B62: _dl_catch_error (dl-error-skeleton.c:227)
==13623==    by 0x491112D: _dlerror_run (dlerror.c:138)
==13623== 
==13623== 32 bytes in 1 blocks are still reachable in loss record 2 of 10
==13623==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13623==    by 0x4013E4D: malloc (rtld-malloc.h:56)
==13623==    by 0x4013E4D: allocate_dtv_entry (dl-tls.c:684)
==13623==    by 0x4013E4D: allocate_and_init (dl-tls.c:709)
==13623==    by 0x4013E4D: tls_get_addr_tail (dl-tls.c:907)
==13623==    by 0x401820B: __tls_get_addr (tls_get_addr.S:55)
==13623==    by 0x5324453: __cxa_get_globals (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==13623==    by 0x532431C: std::uncaught_exception() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==13623==    by 0x53B2E84: std::ostream::flush() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==13623==    by 0x5336891: std::ios_base::Init::~Init() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==13623==    by 0x48C6494: __run_exit_handlers (exit.c:113)
==13623==    by 0x48C660F: exit (exit.c:143)
==13623==    by 0x48AAD96: (below main) (libc_start_call_main.h:74)
==13623== 
==13623== 69 bytes in 2 blocks are still reachable in loss record 3 of 10
==13623==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13623==    by 0x40271DF: malloc (rtld-malloc.h:56)
==13623==    by 0x40271DF: strdup (strdup.c:42)
==13623==    by 0x4016A66: _dl_load_cache_lookup (dl-cache.c:527)
==13623==    by 0x400A981: _dl_map_object (dl-load.c:2193)
==13623==    by 0x4003494: openaux (dl-deps.c:64)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x4003C7B: _dl_map_object_deps (dl-deps.c:248)
==13623==    by 0x400EA0E: dl_open_worker_begin (dl-open.c:592)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400E34D: _dl_open (dl-open.c:883)
==13623== 
==13623== 69 bytes in 2 blocks are still reachable in loss record 4 of 10
==13623==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13623==    by 0x400DD20: malloc (rtld-malloc.h:56)
==13623==    by 0x400DD20: _dl_new_object (dl-object.c:199)
==13623==    by 0x4008C82: _dl_map_object_from_fd (dl-load.c:1063)
==13623==    by 0x400A600: _dl_map_object (dl-load.c:2327)
==13623==    by 0x4003494: openaux (dl-deps.c:64)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x4003C7B: _dl_map_object_deps (dl-deps.c:248)
==13623==    by 0x400EA0E: dl_open_worker_begin (dl-open.c:592)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400E34D: _dl_open (dl-open.c:883)
==13623== 
==13623== 151 bytes in 1 blocks are still reachable in loss record 5 of 10
==13623==    at 0x48487A9: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13623==    by 0x400DBD9: realloc (rtld-malloc.h:62)
==13623==    by 0x400DBD9: _dl_new_object (dl-object.c:218)
==13623==    by 0x4008C82: _dl_map_object_from_fd (dl-load.c:1063)
==13623==    by 0x400A600: _dl_map_object (dl-load.c:2327)
==13623==    by 0x400E9A8: dl_open_worker_begin (dl-open.c:534)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400E34D: _dl_open (dl-open.c:883)
==13623==    by 0x491163B: dlopen_doit (dlopen.c:56)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x49F5B62: _dl_catch_error (dl-error-skeleton.c:227)
==13623== 
==13623== 1,215 bytes in 1 blocks are still reachable in loss record 6 of 10
==13623==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13623==    by 0x400DA02: calloc (rtld-malloc.h:44)
==13623==    by 0x400DA02: _dl_new_object (dl-object.c:92)
==13623==    by 0x4008C82: _dl_map_object_from_fd (dl-load.c:1063)
==13623==    by 0x400A600: _dl_map_object (dl-load.c:2327)
==13623==    by 0x400E9A8: dl_open_worker_begin (dl-open.c:534)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400E34D: _dl_open (dl-open.c:883)
==13623==    by 0x491163B: dlopen_doit (dlopen.c:56)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x49F5B62: _dl_catch_error (dl-error-skeleton.c:227)
==13623== 
==13623== 2,409 bytes in 2 blocks are still reachable in loss record 7 of 10
==13623==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13623==    by 0x400DA02: calloc (rtld-malloc.h:44)
==13623==    by 0x400DA02: _dl_new_object (dl-object.c:92)
==13623==    by 0x4008C82: _dl_map_object_from_fd (dl-load.c:1063)
==13623==    by 0x400A600: _dl_map_object (dl-load.c:2327)
==13623==    by 0x4003494: openaux (dl-deps.c:64)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x4003C7B: _dl_map_object_deps (dl-deps.c:248)
==13623==    by 0x400EA0E: dl_open_worker_begin (dl-open.c:592)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400E34D: _dl_open (dl-open.c:883)
==13623== 
==13623== 2,520 bytes in 3 blocks are still reachable in loss record 8 of 10
==13623==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13623==    by 0x40162DC: calloc (rtld-malloc.h:44)
==13623==    by 0x40162DC: _dl_check_map_versions (dl-version.c:273)
==13623==    by 0x400ED13: dl_open_worker_begin (dl-open.c:600)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400E34D: _dl_open (dl-open.c:883)
==13623==    by 0x491163B: dlopen_doit (dlopen.c:56)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x49F5B62: _dl_catch_error (dl-error-skeleton.c:227)
==13623==    by 0x491112D: _dlerror_run (dlerror.c:138)
==13623==    by 0x49116C7: dlopen_implementation (dlopen.c:71)
==13623==    by 0x49116C7: dlopen@@GLIBC_2.34 (dlopen.c:81)
==13623== 
==13623== 4,064 bytes in 1 blocks are still reachable in loss record 9 of 10
==13623==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13623==    by 0x400BEA6: calloc (rtld-malloc.h:44)
==13623==    by 0x400BEA6: do_lookup_unique (dl-lookup.c:271)
==13623==    by 0x400BEA6: do_lookup_x (dl-lookup.c:556)
==13623==    by 0x400C210: _dl_lookup_symbol_x (dl-lookup.c:860)
==13623==    by 0x40114E7: elf_machine_rela (dl-machine.h:294)
==13623==    by 0x40114E7: elf_dynamic_do_Rela (do-rel.h:142)
==13623==    by 0x40114E7: _dl_relocate_object (dl-reloc.c:288)
==13623==    by 0x400EBAD: dl_open_worker_begin (dl-open.c:702)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400E34D: _dl_open (dl-open.c:883)
==13623==    by 0x491163B: dlopen_doit (dlopen.c:56)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x49F5B62: _dl_catch_error (dl-error-skeleton.c:227)
==13623== 
==13623== 72,704 bytes in 1 blocks are still reachable in loss record 10 of 10
==13623==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13623==    by 0x5321939: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==13623==    by 0x400647D: call_init.part.0 (dl-init.c:70)
==13623==    by 0x4006567: call_init (dl-init.c:33)
==13623==    by 0x4006567: _dl_init (dl-init.c:117)
==13623==    by 0x49F5AF4: _dl_catch_exception (dl-error-skeleton.c:182)
==13623==    by 0x400DFF5: dl_open_worker (dl-open.c:808)
==13623==    by 0x400DFF5: dl_open_worker (dl-open.c:771)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x400E34D: _dl_open (dl-open.c:883)
==13623==    by 0x491163B: dlopen_doit (dlopen.c:56)
==13623==    by 0x49F5A97: _dl_catch_exception (dl-error-skeleton.c:208)
==13623==    by 0x49F5B62: _dl_catch_error (dl-error-skeleton.c:227)
==13623==    by 0x491112D: _dlerror_run (dlerror.c:138)
==13623== 
==13623== LEAK SUMMARY:
==13623==    definitely lost: 0 bytes in 0 blocks
==13623==    indirectly lost: 0 bytes in 0 blocks
==13623==      possibly lost: 0 bytes in 0 blocks
==13623==    still reachable: 83,256 bytes in 15 blocks
==13623==         suppressed: 0 bytes in 0 blocks
==13623== 
==13623== For lists of detected and suppressed errors, rerun with: -s
==13623== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Copy link
Member

@CBenoit CBenoit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's merge! We'll need to create a new build of libcadeau before we publish. I want to try the memory sanitizers too, so I'll give a try on my Linux machine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants