Recherche avancée

Sur d’autres sites (5159)

• avcodec/cbs : Avoid leaving the ... out in calls to variadic macros

  22 mars 2020, par Andreas Rheinhardt

  avcodec/cbs : Avoid leaving the ... out in calls to variadic macros
  According to C99, there has to be at least one argument for every ...
  
  in a variadic function-like macro. In practice most (all ?) compilers also
  
  allow to leave it completely out, but it is nevertheless required : In a
  
  variadic macro "there shall be more arguments in the invocation than there
  
  are parameters in the macro definition (excluding the ...)." (C99,
  
  6.10.3.4).
  CBS (not the framework itself, but the macros used in the
  
  cbs_*_syntax_template.c files) relies on the compiler allowing to leave
  
  a variadic macro argument out. This leads to warnings when compiling in
  
   pedantic mode, e.g. "warning : must specify at least one argument for
  
  '...' parameter of variadic macro [-Wgnu-zero-variadic-macro-arguments]"
  
  from Clang.
  Most of these warnings can be easily avoided : The syntax_templates
  
  mostly contain helper macros that expand to more complex variadic macros
  
  and these helper macros often omit an argument for the .... Modifying
  
  them to always expand to complex macros with an empty argument for the
  
  ... at the end fixes most of these warnings : The number of warnings went
  
  down from 400 to 0 for cbs_av1, from 1114 to 32 for cbs_h2645, from 38 to
  
  0 for cbs_jpeg, from 166 to 0 for cbs_mpeg2 and from 110 to 8 for cbs_vp9.
  These eight remaining warnings for cbs_vp9 have been fixed by switching
  
  to another macro in cbs_vp9_syntax_template : The fixed values for the
  
  sync bytes as well as the trailing bits for byte-alignment are now read
  
  via the fixed() macro (this also adds a check to ensure that trailing
  
  bits are indeed zero as they have to be).
  Reviewed-by : Mark Thompson <sw@jkqxz.net>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/cbs_av1.c
  • [DH] libavcodec/cbs_h2645.c
  • [DH] libavcodec/cbs_jpeg.c
  • [DH] libavcodec/cbs_mpeg2.c
  • [DH] libavcodec/cbs_vp9.c
  • [DH] libavcodec/cbs_vp9_syntax_template.c

• Random sounds in discord.js

  1er septembre 2020, par Audiophile

  I'm programming a discord bot using discord.js. I want to make a random sound player !
What am I doing wrong ? Can you help me ?

  



  case 'ps':
            var voiceChannel = message.member.voiceChannel
                voiceChannel.join().then(connection => {
                number = 5;
            var random = Math.floor (Math.random() * (number - 1 + 1 )) + 1;
            var rs = ( {files: [__dirname + '/Library/folder/' + "sound" + " (" + random + ")" + ".jpg"]} );
            const dispatcher = connection.playFile(rs);
                dispatcher.on('end', end => voiceChannel.leave());
            })
        break;


  



  There aren't any errors in terminal.

  


• avcodec : Add explicit capability flag for encoder flushing

  10 avril 2020, par Philip Langdale

  avcodec : Add explicit capability flag for encoder flushing
  Previously, there was no way to flush an encoder such that after
  
  draining, the encoder could be used again. We generally suggested
  
  that clients teardown and replace the encoder instance in these
  
  situations. However, for at least some hardware encoders, the cost of
  
  this tear down/replace cycle is very high, which can get in the way of
  
  some use-cases - for example : segmented encoding with nvenc.
  To help address that use case, we added support for calling
  
  avcodec_flush_buffers() to nvenc and things worked in practice,
  
  although it was not clearly documented as to whether this should work
  
  or not. There was only one previous example of an encoder implementing
  
  the flush callback (audiotoolboxenc) and it's unclear if that was
  
  intentional or not. However, it was clear that calling
  
  avocdec_flush_buffers() on any other encoder would leave the encoder in
  
  an undefined state, and that's not great.
  As part of cleaning this up, this change introduces a formal capability
  
  flag for encoders that support flushing and ensures a flush call is a
  
  no-op for any other encoder. This allows client code to check if it is
  
  meaningful to call flush on an encoder before actually doing it.
  I have not attempted to separate the steps taken inside
  
  avcodec_flush_buffers() because it's not doing anything that's wrong
  
  for an encoder. But I did add a sanity check to reject attempts to
  
  flush a frame threaded encoder because I couldn't wrap my head around
  
  whether that code path was actually safe or not. As this combination
  
  doesn't exist today, we'll deal with it if it ever comes up.
  

  • [DH] doc/APIchanges
  • [DH] libavcodec/audiotoolboxenc.c
  • [DH] libavcodec/avcodec.h
  • [DH] libavcodec/decode.c
  • [DH] libavcodec/nvenc_h264.c
  • [DH] libavcodec/nvenc_hevc.c
  • [DH] libavcodec/version.h