webrtc-rs/examples

Examples of WebRTC.rs

Crate moved

As of the 23rd of August 2022 this crate has been migrated to the webrtc-rs/webrtc monorepo.

examples's Issues

[data-channels-flow-control] Connection is abruptly broken

I ran cargo run --example data-channels-flow-control on my laptop after cloning the main repository and changing into the examples directory.

Upon running it, I get the following output:

Press ctrl-c to stop or wait for 5s
Peer Connection State has changed: connected (answerer)
Peer Connection State has changed: connected (offerer)
OnOpen-data-1 : Start sending a series of 1024-byte packets as fast as it can
OnOpen: Start receiving data
Throughput: 6.853 Mbps
Throughput: 7.021 Mbps
Throughput: 7.113 Mbps
Throughput: 7.125 Mbps
exit on_open
Peer Connection State has changed: closed (offerer)
Peer Connection State has changed: closed (answerer)

I added a simple print statement to see why the connection closes and the send loop is exited, and it outputs the following: DataChannel is not opened

Unable to run 'reflect' example

Hi,

I just cloned this repository and am trying to get the reflect example running. Following the steps in the README, I have navigated in my browser to the linked jsfiddle page, clicked to allow it to use my microphone and camera, copied the browser session token, and echoed it to target/debug/examples/reflect. This last step results in a message "one of audio or video must be enabled." How can I get this example running?

OS: Arch (Manjaro)
Browser: Firefox 100.0; Chrome 101.0.4951.64
Rust: 1.60.0

pasting offers results in `Error: EOF while parsing a string at line 1 column 3071`

Looks like most/all of the examples work by pasting a base64 string from a jsfiddle to the program via this snippet:

    // Wait for the offer to be pasted
    let line = signal::must_read_stdin()?;
    let desc_data = signal::decode(line.as_str())?;
    let offer = serde_json::from_str::<RTCSessionDescription>(&desc_data)?;

On my browser (Chrome 103.0.5060.114 on macOS), the base64 string is 11,308 bytes. This is over the 4,096-byte limit for line length for "canonical mode" terminal input on Linux (see e.g. this blog post), so pasting doesn't work right:

$ cargo run --example play-from-disk-h264 -- --video $HOME/out.mp4
...paste here...
Error: EOF while parsing a string at line 1 column 3071

Note (4096 - 1 [for \n]) * 3/4 rounds down to 3071.

If you run it through strace -oout -s8192, you can see the read(0, "...4095 characters...\n", 8192) = 4096 indicating that the kernel silently truncated the line.

Ideas:

• use rustyline or similar to take the terminal out of "canonical mode" before reading the input, to get rid of the 4,096-byte limitation. Note that pasting into e.g. vim works fine because they use raw mode.
• try to get the string be under 4,096 bytes by gzipping it or something
• have the examples start a webserver so you can navigate to their URL and have the browser send the offer directly to the webserver, rather than pasting it back and forth.

Audio not working on example play-from-disk-vpx

Hello, I m running the example play-from-disk-vpx.
the video streaming is working, but the audio is not.

the problem is that in this line : https://github.com/webrtc-rs/examples/blob/main/examples/play-from-disk-vpx/play-from-disk-vpx.rs#L258 I get the following error:

thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: ErrBadIDPageLength', examples/play-from-disk-vpx/play-from-disk-vpx.rs:272:61

( to print it I've changed that line like this: let (mut ogg, _) = OggReader::new(reader, true).unwrap(); )

I've tryed with an ogg file generated like in the guide and from a file download.

this is the ffprobe of the file I'm trying to use:

ffprobe test_data/output.ogg
ffprobe version 5.0.1 Copyright (c) 2007-2022 the FFmpeg developers
  built with Apple clang version 13.1.6 (clang-1316.0.21.2.5)
  configuration: --prefix=/opt/homebrew/Cellar/ffmpeg/5.0.1_2 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox --enable-neon
  libavutil      57. 17.100 / 57. 17.100
  libavcodec     59. 18.100 / 59. 18.100
  libavformat    59. 16.100 / 59. 16.100
  libavdevice    59.  4.100 / 59.  4.100
  libavfilter     8. 24.100 /  8. 24.100
  libswscale      6.  4.100 /  6.  4.100
  libswresample   4.  3.100 /  4.  3.100
  libpostproc    56.  3.100 / 56.  3.100
Input #0, ogg, from 'test_data/output.ogg':
  Duration: 00:01:30.46, start: 0.000000, bitrate: 123 kb/s
  Stream #0:0: Audio: vorbis, 44100 Hz, stereo, fltp, 128 kb/s
    Metadata:
      ARTIST          : Patrick de Arteaga
      TITLE           : Child's Nightmare
      COMMENTS        : Creative Commons Attribution 4.0
      DATE            : 2019

Thanks in advance!

clap issue required arguments were not provided

cargo run --example answer 

error: The following required arguments were not provided:
    --offer-address <offer-address>
    --answer-address <answer-address>

question regarding how the 2nd SDP is received

Hi,

I was trying to play with the broadcast example and somehow I have never got the 2nd SDP response for the "Join a broadcast". 1st SDP response is received and I can see the video and logs show 'connected'. However when I open a 2nd tab and get the 2nd SDP from "join a broadcast" and issue a POST to /sdp but I never got the response.

From the following code, it seems that it can only get the SDP once. Am I missing something ? Thanks!

examples/examples/broadcast/broadcast.rs

Line 76 in dbaf86c

let mut sdp_chan_rx = signal::http_sdp_server(port).await;

Cannot run example on Armv7 panicked at 'overflow when adding duration to instant'

Hello!

I have an issue running the example on a Raspberry Pi Zero 2 W armv7l.

It seems related this issue overflow when adding duration to instant on armv7
#chronotope/chrono#343

$ cat test.sdp | RUST_BACKTRACE=full ./play-from-disk-h264 --video output.h264
thread 'main' panicked at 'overflow when adding duration to instant', library/std/src/time.rs:550:31
stack backtrace:
   0:   0xab3708 - std::backtrace_rs::backtrace::libunwind::trace::h4bf3e5497ce7d0d1
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:   0xab3708 - std::backtrace_rs::backtrace::trace_unsynchronized::h6b664ef1002045f8
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:   0xab3708 - std::sys_common::backtrace::_print_fmt::h077a74dd0fd95079
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/sys_common/backtrace.rs:67:5
   3:   0xab3708 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::ha65a6b17248d4482
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/sys_common/backtrace.rs:46:22
   4:   0xad925c - core::fmt::write::h682b611af217d220
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/core/src/fmt/mod.rs:1150:17
   5:   0xaaccec - std::io::Write::write_fmt::h8cc061d257db1323
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/io/mod.rs:1667:15
   6:   0xab55d4 - std::sys_common::backtrace::_print::h8ea36d0a4c8c8101
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/sys_common/backtrace.rs:49:5
   7:   0xab55d4 - std::sys_common::backtrace::print::h27c30ada45da6e69
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/sys_common/backtrace.rs:36:9
   8:   0xab55d4 - std::panicking::default_hook::{{closure}}::h2ac34510ecc99ccd
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panicking.rs:210:50
   9:   0xab5030 - std::panicking::default_hook::ha1d2ed057431f9b0
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panicking.rs:227:9
  10:   0xab5cac - std::panicking::rust_panic_with_hook::h17c1e02f294ac808
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panicking.rs:624:17
  11:   0xab5788 - std::panicking::begin_panic_handler::{{closure}}::h9573bd22277952be
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panicking.rs:521:13
  12:   0xab3c90 - std::sys_common::backtrace::__rust_end_short_backtrace::h99bf7f87f84ce00f
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/sys_common/backtrace.rs:141:18
  13:   0xab56e0 - rust_begin_unwind
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panicking.rs:517:5
  14:   0x4aa220 - core::panicking::panic_fmt::h9bf8e44e3548ebaf
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/core/src/panicking.rs:101:14
  15:   0x4aa128 - core::option::expect_failed::h7b469729e8e287e8
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/core/src/option.rs:1615:5
  16:   0xab34d0 - core::option::Option<T>::expect::hbd7ce046258044e2
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/core/src/option.rs:698:21
  17:   0xab34d0 - <std::time::SystemTime as core::ops::arith::Add<core::time::Duration>>::add::h8c303cffbd39972b
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/time.rs:550:9
  18:   0x70331c - chrono::datetime::<impl core::convert::From<chrono::datetime::DateTime<Tz>> for std::time::SystemTime>::from::habe72c9a7cc9cb26
  19:   0x6fda70 - webrtc::peer_connection::certificate::RTCCertificate::from_params::hee995bbe460172fb
  20:   0x6fe394 - webrtc::peer_connection::certificate::RTCCertificate::from_key_pair::h1a7e64a6836c2821
  21:   0x76a264 - webrtc::peer_connection::RTCPeerConnection::init_configuration::he526c67849077f08
  22:   0x668dd4 - play_from_disk_h264::main::{{closure}}::heac723bac7819863
  23:   0x5540f8 - tokio::park::thread::CachedParkThread::block_on::hf1ad0ac1d6238337
  24:   0x55421c - tokio::runtime::thread_pool::ThreadPool::block_on::h2e6b8d84876a02e8
  25:   0x692a78 - play_from_disk_h264::main::h6f9f4e760d1648f7
  26:   0x53d0c0 - std::sys_common::backtrace::__rust_begin_short_backtrace::hb6001fa900b53d38
  27:   0x559cdc - std::rt::lang_start::{{closure}}::h57b02cdf22d786ad
  28:   0xab62d8 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h7ba1bdda2f342471
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/core/src/ops/function.rs:259:13
  29:   0xab62d8 - std::panicking::try::do_call::h4c3c648f73078093
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panicking.rs:403:40
  30:   0xab62d8 - std::panicking::try::h06ab9d03dd62fbbd
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panicking.rs:367:19
  31:   0xab62d8 - std::panic::catch_unwind::h82421e9e18ace5da
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panic.rs:129:14
  32:   0xab62d8 - std::rt::lang_start_internal::{{closure}}::h1cbfee7e0ebe057d
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/rt.rs:45:48
  33:   0xab62d8 - std::panicking::try::do_call::he9d4b690fd004a7c
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panicking.rs:403:40
  34:   0xab62d8 - std::panicking::try::hbd6ed135d4dc763a
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panicking.rs:367:19
  35:   0xab62d8 - std::panic::catch_unwind::h45dacf89f176e04b
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panic.rs:129:14
  36:   0xab62d8 - std::rt::lang_start_internal::hd4ee3abcdb019f91
                       at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/rt.rs:45:20
  37:   0x692f30 - main
  38: 0x76d29be0 - __libc_start_main
                       at ./csu/./csu/libc-start.c:308:16

Maybe is it possible to handle this error within the initialization of the configuration?

It seems to point to this code

https://github.com/webrtc-rs/webrtc/blob/f45bb4a35ffd13216cf182c1d699784a10764426/src/peer_connection/mod.rs#L249