Recherche avancée

Sur d’autres sites (19398)

• macOS terminal bug "can't see typed characters" after execution ffmpeg coommand inside shell script

  29 décembre 2017, par kostya572

  I execute from Terminal :

  sh 1.sh

  1.sh contents :

  #!/bin/bash
  
  S1=$(ffmpeg -i correct.wav -af silencedetect=noise=-50dB:d=0.1 -f null -  2>&1 | grep silence_duration -m 1 | awk '{print $NF}')
  
  echo $S1

  After execution I can’t see any typed characters in macOS Terminal. Only invisible typing reset helps to solve the problem, but all previous output clears.

  How can I modify the code to solve this bug ? I guess the problem somewhere in 2>&1.

  Bug screenshot if press enter several times after script execution :
  

• Terminal prompt disappears after asyncio script with ffmpeg writing things is run

  8 avril 2022, par David I

  I've followed a simple example https://docs.python.org/3/library/asyncio-task.html#running-tasks-concurrently in trying to learn the basics of asyncio.

  


  It works as expected with most commands however when employed with three ffmpeg commands that take an input and write an output, see the example below, the terminal window prompt becomes invisible after the script has (seemingly successfully run). It responds to typed commands and shows the result but the input isn't shown until I start a new terminal session. It's the same with Code's bash terminal as with Kitty.

  


  It doesn't seem to be a "write to file system concurrantly" problem as the echo lines don't produce the problem. The ffprobe commands don't produce it either but "command1" and 2 and 3 always do. It's the same with other ffmpeg commands that write to the file system via a conversion or a split of an audio input file.

  


  The processes exit with 0 and ffmpeg issues most output to stderr so the output looks like

  


  


  ['ffmpeg -y -i "01 Dia Artio.m4a" "oof1.wav"' exited with 0]
[stderr]
ffmpeg version N-104926-gc8b5f2848d Copyright (c) 2000-2021 the FFmpeg developers
built with gcc 11 (GCC)...

  


  


  import asyncio

async def run(cmd):
    proc = await asyncio.create_subprocess_shell(
        cmd,
        stdout=asyncio.subprocess.PIPE,
        stderr=asyncio.subprocess.PIPE)

    stdout, stderr = await proc.communicate()
    print(f'[{cmd!r} exited with {proc.returncode}]')
    print(f'[stderr]\n{stderr.decode()}')

async def main():
    # Schedule three calls *concurrently*:
    command1 = "ffmpeg -y -i '01 Dia Artio.m4a' 'oof1.wav'"
    command2 = "ffmpeg -y -i '03 Cleansing.m4a' 'oof3.wav'"
    command3 = "ffmpeg -y -i 'The Cranberries - 10 - Dreaming My Dreams.flac' 'oof2.wav'"

    cat1 = "echo 'cat' > cat.txt"
    cat2 = "echo 'kitteh' > kat.txt"
    cat3 = "echo 'eirlyss' > eirlyss.txt"

    ffprobe1 = "ffprobe oof1.wav"
    ffprobe2 = "ffprobe oof2.wav"
    ffprobe3 = "ffprobe oof1.wav"
    await asyncio.gather(
        run(command1),
        run(command2),
        run(command3)
    )
    
 
asyncio.run(main())


  


  This problem has only happened with this combination of asyncio and ffmpeg and it appears consistent and I would very much like to know what might be the cause of it.

  


  I'm on Fedora 35 with Python 3.10.4 and a self built (via ffmpegs instructs) ffmpeg from a few months back).

  


• How to send encoded video (or audio) data from server to client in a way that's decodable by webcodecs API using minimal latency and data overhead

  11 janvier 2023, par Tiger Yang

  My question (read entire post for context) :

  


  Given the unique circumstance of only ever decoding data from a specifically-configured encoder, what is the best way I can send the encoded bitstream along with the bare minimum extra bytes required to properly configure the decoder on the client's end (including only things that change per stream, and omitting things that don't, such as resolution) ? I'm a sucker for zero compromises, and I think I am willing to design my own minimal container format to accomplish this.

  


  Context and problem :

  


  I'm working on a remote desktop implementation that consists of a server that captures and encodes the display and speakers using FFmpeg and forwards it via pipe to a go (language) program which sends it on two unidirectional webtransport streams to my client, which I plan to decode using the webcodecs API. According to MDN, the video decoder needs to be fed via .configure() an object containing the following : https://developer.mozilla.org/en-US/docs/Web/API/VideoDecoder/configure before it's able to decode anything.

  


  same goes for the audio decoder : https://developer.mozilla.org/en-US/docs/Web/API/AudioDecoder/configure

  


  What I've tried so far :

  


  Because this remote desktop will be for my personal use only, it would only ever receive streams from a specific encoder configured in a specific way encoding video at a specific resolution, framerate, color space, etc.. Therefore, I took my video capture FFmpeg command...

  


  videoString := []string{
        "ffmpeg",
        "-init_hw_device", "d3d11va",
        "-filter_complex", "ddagrab=video_size=1920x1080:framerate=60",
        "-vcodec", "hevc_nvenc",
        "-tune", "ll",
        "-preset", "p7",
        "-spatial_aq", "1",
        "-temporal_aq", "1",
        "-forced-idr", "1",
        "-rc", "cbr",
        "-b:v", "500K",
        "-no-scenecut", "1",
        "-g", "216000",
        "-f", "hevc", "-",
    }


  


  ...and instructed it to write to an mp4 file instead of outputting to pipe, and then I had this webcodecs demo https://w3c.github.io/webcodecs/samples/video-decode-display/ demux it using mp4box.js. Knowing that the demo outputs a proper .configure() object, I blindly copied it and had my client configure using that every time. Sadly, it didn't work, and I since noticed that the "description" part of the configure object changes despite the encoder and parameters being the same.

  


  I knew that mp4 files worked via mp4box, but they can't be streamed with low latency over a network, and additionally, ffmpeg's -f parameters specifies the muxer to use, but there are so many different types.

  


  At this point, I think I'm completely out of my depth, so :

  


  Given the unique circumstance of only ever decoding data from a specifically-configured encoder, what is the best way I can send the encoded bitstream along with the bare minimum extra bytes required to properly configure the decoder on the client's end (including only things that change per stream, and omitting things that don't, such as resolution) ? I'm a sucker for zero compromises, and I think I am willing to design my own minimal container format to accomplish this. (copied above)