Recherche avancée

Sur d’autres sites (8116)

• 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).

  


• FFMPEG stereo track stops capturing at random times during a capture session

  26 mai 2022, par mrwassen

  I am currently working on building a workflow to capture and archive a large stash of family and friends PAL and NTSC VHS tapes. The hardware setup is as follows :

  


  

  • JVC HR-7860S VCR

  


  • s-video / RCA audio >

  


  • ADVC-3000 converter

  


  • SDI / BNC cable >

  


  • Blackmagic Decklink Mini Recorder 4K PCIe card

  


  • installed in a fairly hi-spec windows machine : AMD Ryzen 9 5900X 3.7 Ghz base 12 core, GEFORCE RTX 3060 12 gB, 32 gB ram

  


  


  The plan is to capture to lossless AVI, then drop into an NLE (Vegas Pro v.16) to do a minimal amount of cleanup / trimming, then render to a more compressed video format (TBD) for upload to AWS S3 accessible through a family website.

  


  The issue I am having is that when I run the capture using ffmpeg/directshow e.g. for a perfectly fine 90 min. PAL tape, at some random point of time during the capture one of the 2 stereo channels just stops capturing. This has happened with all of the tapes I have tested so far, and it happens at different times during the same video. I have examined the frames surrounding points in time when this happens, and it doesn't correlate to any transitions or jitter, but often just randomly in the middle of a perfectly smooth scene. Once the one channel stops capturing it never starts back up again during that capture session.

  


  The ADVC-3000 and the VCR are both showing both stereo channels playing normally throughout the capture. The windows machine running the capture hardly breaks a sweat at any time, and the transfer easily keeps up constantly showing a speed = 1x which I assume means nothing lagging. Also there are no video/audio sync issues at any point in time even towards the end of long tapes e.g. 90 mins.

  


  I am fairly new at ffmpeg, so I have spent extensive amounts of time reading up on forum posts and experimenting and have ended up with the following syntax :

  


  ffmpeg -y -f dshow -rtbufsize 2000M -i video="Blackmagic WDM Capture":audio="Blackmagic WDM Capture" -codec:v v210 -pix_fmt yuv422p -codec:a pcm_s16le -b:a 128k -t 02:00:00 -r 25 -threads 4 -maxrate 2500k -filter:a "volume=1.5" output_v210_audio.avi


  


  The capture runs without a single dropped frame, the only error I am getting when launching (and perhaps this is a smoking gun ?) is :

  


  


  "Non-monotonous DTS in output stream 0:1 ; previous : 0, current : -30 ;
changing to 1. This may result in incorrect timestamps in the output
file."

  


  


  I have tried to troubleshoot this in the hopes that it is tied to my issue but so far without luck.

  


  Hoping somebody can help correct or modify my command line or perhaps other ideas to help resolve the issue.

  


• libavutil : Deprecate av_fopen_utf8, provide an avpriv version

  20 mai 2022, par Martin Storsjö

  libavutil : Deprecate av_fopen_utf8, provide an avpriv version
  Since every DLL can use an individual CRT on Windows, having
  
  an exported function that opens a FILE* won't work if that
  
  FILE* is going to be used from a different DLL (or from user
  
  application code).
  Internally within the libraries, the issue can be worked around
  
  by duplicating the function in all libraries (this already happened
  
  implicitly because the function resided in file_open.c) and renaming
  
  the function to ff_fopen_utf8 (so that it doesn't end up exported from
  
  the DLLs) and duplicating it in all libraries that use it.
  This makes the avpriv_fopen_utf8 / ff_fopen_utf8 function work in
  
  the exact same way as the existing avpriv_open / ff_open, with the
  
  same setup as introduced in e743e7ae6ee7e535c4394bec6fe6650d2b0dbf65.
  That mechanism doesn't work for external users, thus deprecate the
  
  existing function.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] doc/APIchanges
  • [DH] fftools/fopen_utf8.h
  • [DH] libavfilter/Makefile
  • [DH] libavfilter/file_open.c
  • [DH] libavutil/avutil.h
  • [DH] libavutil/file_open.c
  • [DH] libavutil/internal.h
  • [DH] libavutil/version.h
  • [DH] tests/ref/fate/source