Recherche avancée

Sur d’autres sites (11682)

• FFmpeg : Windows vs Linux issues

  16 octobre 2022, par Chris

  I have run into an issue that I am pretty sure I have narrowed down to FFmpeg.

  


  I have a Flask app that restreams live streams using FFmpeg.

  


  ...

@app.route("/play/", methods=["GET"])
def play():
    def streamData():
        try:
            with subprocess.Popen(
                ffmpegcmd,
                stdin=subprocess.DEVNULL,
                stdout=subprocess.PIPE,
                stderr=subprocess.PIPE,
            ) as ffmpeg_sb:
                while True:
                    chunk = ffmpeg_sb.stdout.read(1024)
                    if len(chunk) == 0:
                        break
                    yield chunk
        except:
            pass
        finally:
            ffmpeg_sb.kill()

    return Response(streamData())

...



  


  I am using the following command.

  


  ffmpeg -loglevel panic -hide_banner -i <url> -vcodec copy -acodec copy -f mpegts pipe:</url>

  


  When I run my Flask app on Windows, both VLC and TVHeadend play the piped output perfectly.
However under Linux only VLC will play the piped output. I can get TVHeadend to play the stream from Linux, but it requires me to enable the AV Library option in TVHeadend, which I want to avoid. I have tested this using WSL (Ubuntu) and Docker (alpine + Ubuntu) on my Ubuntu server where the app will live.

  


  I can only assume its because FFmpeg behaves differently between Windows and Linux ? I have tried several different version of FFmpeg... So I don't think its a version issue.

  


  The version of FFmpeg I am currently using on Windows is this one https://www.gyan.dev/ffmpeg/builds/ but I experienced the same success on older versions, so again, I don't think its a version number issue.

  


  Can anyone suggest how I can go about finding out what the cause is ?
Is it possible that some default values differ between Windows and Linux ?

  


  Any advice is appreciated !

  


• checkasm : Remove unnecessary const on scalar parameters

  15 décembre 2023, par Martin Storsjö

  checkasm : Remove unnecessary const on scalar parameters
  The ffmpeg coding style doesn't usually use const on scalar
  
  parameters (or on the pointer values - as opposed to the type
  
  that is pointed to, where it has a semantic meaning), contrary
  
  to the dav1d coding style (where this was imported from).
  This avoids warnings about differences in the type signatures
  
  between declaration and definition of this function, with older
  
  versions of MSVC.
  The issue was observed with one version of MSVC 2017,
  
  19.16.27024.1, with warnings like these :
      src/tests/checkasm/checkasm.c(969) : warning C4028 : formal parameter 3 different from declaration
  The warning itself is bogus as the const here is harmless, and
  
  newer versions of MSVC no longer warn about this.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] tests/checkasm/checkasm.c
  • [DH] tests/checkasm/checkasm.h

• configure : Improve the check for the rsync —contimeout option

  24 janvier, par Martin Storsjö

  configure : Improve the check for the rsync —contimeout option
  Traditionally, macOS has shipped an old version of rsync that lacked
  
  support for this option, hence this check (added in
  
  a8b3f0c5cf548f654e30c981988bb71981a3f8d3).
  However, in macOS 15.x, Apple have switched to providing rsync as a
  
  different tool, openrsync. The version of openrsync in at least
  
  macOS 15.2 does include "[—contimeout]" (note the lack of "=" after
  
  the option), in the output of "rsync —help", but when used, the tool
  
  errors out with "rsync : —contimeout=60 : unknown option". So apparently
  
  the tool erroenously lists the option as supported, while it really
  
  isn't.
  The original rsync tool (with a new enough version) prints
  
  "—contimeout=SECONDS" in the output of "rsync —help".
  It is unclear which version of openrsync Apple are shipping ; the latest
  
  upstream openrsync from OpenBSD does support the option and includes
  
  "[—contimeout=seconds]" in the output of "—help", and older versions
  
  don't seem to include the option as listed at all.
  Therefore, check for "—conntimeout=" with the "=", this should
  
  properly detect both new enough rsync and openrsync.
  This fixes running "fate-rsync" on macOS 15.x.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] configure