13 comments on “How to capture & replay WebRTC video streams with video_replay (Stian Selnes)

  1. Interesting article, thanks for sharing!

    To share our experience, we have a similar feature in Janus, which we mostly use for recording but sometimes for debugging as well. Our recordings basically consist in a structured dump of the plain RTP packets we receive (so after the Janus core has decrypted the SRTP layer) to a custom format, and we have a simple tool to go through that file offline and depacketize the payload to a playable format (e.g., webm), in a similar but probably less sophisticated way to how video_replay seems to work. The cool thing is that we don’t need to disable encryption, which wouldn’t work anyway when setting up the PeerConnection with Janus, but the custom format makes it less reusable (e.g., for bug reports). Adding support for rtpdump and/or pcap as well, besides our custom target file, would indeed be an interesting way to make debugging even easier, so thanks again for this cool tutorial!

  2. Pingback: Debugging WebRTC errors with video_replay – Pexip | Your world connected

  3. This is really good stuff !
    However I have a problem generating the Ninja project file, Running the [gn gen out/Default] command on a windows environment (from a command prompt started with administrator privilege).
    I don’t see any error in the previous phases, but when running the generation I get the below error. Has any one seen this ?
    (unfortunately I only have a windows environment at home…)

    ERROR at //third_party/protobuf/proto_library.gni:229:15: File is not inside out
    put directory.
    outputs = get_path_info(protogens, “abspath”)
    The given file should be in the output directory. Normally you would specify
    “$target_out_dir/foo” or “$target_gen_dir/foo”. I interpreted this as
    See //webrtc/rtc_tools/BUILD.gn:184:3: whence it was called.
    proto_library(“chart_proto”) {
    See //BUILD.gn:16:5: which caused the file to be included.
    Traceback (most recent call last):
    File “D:/temp/webrtc-checkout/src/build/vs_toolchain.py”, line 459, in
    File “D:/temp/webrtc-checkout/src/build/vs_toolchain.py”, line 455, in main
    return commands[sys.argv[1]](*sys.argv[2:])
    File “D:/temp/webrtc-checkout/src/build/vs_toolchain.py”, line 431, in GetTool
    win_sdk_dir = SetEnvironmentAndGetSDKDir()
    File “D:/temp/webrtc-checkout/src/build/vs_toolchain.py”, line 424, in SetEnvi
    return NormalizePath(os.environ[‘WINDOWSSDKDIR’])
    File “D:\temp\depot_tools\win_tools-2_7_6_bin\python\bin\lib\os.py”, line 423,
    in __getitem__
    return self.data[key.upper()]

  4. For replay of audio RTP streams, captured or simulated, I’ve found SIPP to be a useful tool to exercise jitter buffers and reproduce errors as it plays out with more or less correct timing, and handles the sip signalling. Does anyone know any other RTP regurgitators? Fantastic post, thanks for sharing and documenting!

  5. Pingback: Ways to capture incoming WebRTC video streams (client side) – program faq

  6. Great Article!!

    To decode H264, you need to explicitly request it at makefile creation time

    gn gen out/Default –args=’rtc_use_h264=true ffmpeg_branding=”Chrome”‘

    ninja -C out/Default video_replay

    video_replay –input_file d3.rtpdump –ssrc 2176537790 –media_payload_type 96 –codec H264

  7. Note: video_replay supports simple pcaps nowadays (while text2pcap’s -n writes pcapng)
    Wiresharks support for exporting rtpdumps seems to be limited to a single ssrc which is not good for rtx.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.