Recherche avancée

Sur d’autres sites (11434)

• avutil/cpu_internal : Fix check for SSE2SLOW

  15 juin 2022, par Andreas Rheinhardt

  avutil/cpu_internal : Fix check for SSE2SLOW
  For SSE2 and SSE3, there are four states that the two flags
  
  involved (AV_CPU_FLAG_SSE[23] and AV_CPU_FLAG_SSE[23]SLOW) can convey.
  
  When ordered from worst to best they are :
  
  1. both flags unset (SSE[23] unavailable)
  
  2. the slow flag set, the ordinary flag unset (this is designed
  
  for cases where SSE2 is available, but so slow that MMX(EXT)/SSE
  
  code is usually faster)
  
  3. both flags set (SSE2 is available, but there might be scenarios
  
  where MMX(EXT)/SSE code is faster)
  
  4. the ordinary flag set, the slow flag unset (this is the normal case)
  The ordinary macros for checking cpuflags return true
  
  in the latter two cases ; the fast macros only return true for
  
  the latter case. Yet the macros to check for slow currently
  
  only return true in case three.
  This seems unintended. In fact, the only uses of the slow macros
  
  are all of the form
  
  if (EXTERNAL_SSE2(cpu_flags) || EXTERNAL_SSE2_SLOW(cpu_flags))
  
  where the check for EXTERNAL_SSE2_SLOW is completely redundant.
  
  Even more importantly, it is not what was intended. Before
  
  6369ba3c9cc74becfaad2a8882dff3dd3e7ae3c0, the checks passed
  
  in cases 2 to 4. Said commit changed this to something that
  
  only passes for the third case. Commits
  
  7fb758cd8ed08e4a37f10e25003953d13c68b8cd and
  
  c1913064e38cb338039f29c280a0dacc3fd1e451 restored the old behaviour,
  
  yet merging 4efab89332ea39a77145e8b15562b981d9dbde68 (in commit
  
  ac774cfa571734c49c26e2d3387adccff8957ff8) broke this again
  
  by changing it to what it is now.*
  This commit changes the macros to make the slow macros check
  
  whether a specific instruction is supported, even if slow.
  
  This restores the intended meaning to all uses of the SLOW macros
  
  and is generally more natural.
  * : Libav only checks for EXTERNAL_SSE2_SLOW, i.e. for the third case
  
  only.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavutil/cpu_internal.h

• avformat/sccdec : Don't use uninitialized data, fix crash, simplify logic

  1er octobre 2021, par Andreas Rheinhardt

  avformat/sccdec : Don't use uninitialized data, fix crash, simplify logic
  Up until now, the scc demuxer not only read the line that it intends
  
  to process, but also the next line, in order to be able to calculate
  
  the duration of the current line. This approach leads to unnecessary
  
  complexity and also to bugs : For the last line, the timing of the
  
  next subtitle is not only logically indeterminate, but also
  
  uninitialized and the same applies to the duration of the last packet
  
  derived from it.* Worse yet, in case of e.g. an empty file, it is not
  
  only the duration that is uninitialized, but the whole timing as well
  
  as the line buffer itself.** The latter is used in av_strtok(), which
  
  could lead to crashes. Furthermore, the current code always outputs
  
  at least one packet, even for empty files.
  This commit fixes all of this : It stops using two lines at a time ;
  
  instead only the current line is dealt with and in case there is
  
  a packet after that, the duration of the last packet is fixed up
  
  after having already parsed it ; consequently the duration of the
  
  last packet is left in its default state (meaning "unknown/up until
  
  the next subtitle"). If no further line could be read, processing
  
  is stopped ; in particular, no packet is output for an empty file.
  * : Due to stack reuse it seems to be zero quite often ; for the same
  
  reason Valgrind does not report any errors for a normal input file.
  
  ** : While ff_subtitles_read_line() claims to always zero-terminate
  
  the buffer like snprintf(), it doesn't do so if it didn't read anything.
  
  And even if it did, it would not necessarily help here : The current
  
  code jumps over 12 bytes that it deems to have read even when it
  
  hasn't.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavformat/sccdec.c

• Run ffmpeg audio under Windows with Flutter

  11 janvier, par Chris

  I'd like to stream audio comming from my microphone in my flutter app in the windows desktop version.

  


  Since there is no library that seems to do such thing while supporting windows desktop app, I have tried using Process like this :

  


  // Start the FFmpeg process to capture audio
ffmpegProcess = await Process.start(
  'ffmpeg',
  [
    '-f', 'dshow', // Specify DirectShow input for Windows
    '-i', 'audio="$selectedMic"', // Input audio device (selected mic)
    '-f', 'wav', // Set audio format
    '-ar', '44100', // Set audio sample rate
    '-ac', '1', // Mono channel
    '-b:a', '128k', // Set audio bitrate
    'pipe:1', // Output to stdout
  ],
);

// Listen for data on stdout (audio stream)
ffmpegProcess.stdout.listen((data) async {
  // Send audio data to the server as it comes in
  await sendAudioToServer(data);
});


  


  I've tested the command directly in my terminal (not in the flutter app) and it works fine.

  


  When I run this code in my Flutter app, my task manager also shows a "ffmpeg" process, but somehow there is no stream output in flutter, even after ensuring that the selectedMic variable is correct or even when its hardcoded.

  


  Since this command runs without issue in my terminal and even in python, I am wondering why it does not work in Flutter.

  


  Starting my vscode as administrator also don't solve the issue (I wanted to check if it's a permission issue).

  


  Also relevant : When I run the "ffmpeg -version" command, I get an output for the version, meaning that this is not an installation problem (ffmpeg bin folder is in my PATH environment variable). The problem seems to come from recording from the microphone in flutter, but I don't get why.

  


  ffmpegProcess = await Process.start('ffmpeg', ['-version']);  // this works


  


  I'd love to get some suggestions where the problem could come from or any kind of alternative solutions.