Recherche avancée

Sur d’autres sites (9082)

• How to get full name of default microphone ?

  9 août 2019, par Jiapeng Li

  Been trying to get full name of microphone as a variable on Python for usage of ffmpeg. I have already tried

  p = pyaudio.PyAudio()
  
  default_device = p.get_default_input_device_info()
  
  print(default_device['name'])

  and here was the output :

  Microphone (Conexant SmartAudio         #it was truncated to 31 characters length

  Obviously,that was truncated and not what i wanted.
  Tried sounddevice too :

  import sounddevice as sd
  
  s = sd.query_devices()
  
  print(s)

  Output :

     0 Microsoft Sound Mapper - Input, MME (2 in, 0 out)
  
  >  1 Microphone (Conexant SmartAudio, MME (2 in, 0 out)           #still truncated
  
     2 Microsoft Sound Mapper - Output, MME (0 in, 2 out)
  
  <  3 Speakers (Conexant SmartAudio H, MME (0 in, 2 out)
  
     4 Primary Sound Capture Driver, Windows DirectSound (2 in, 0 out)
  
     5 Microphone (Conexant SmartAudio HD), Windows DirectSound (2 in, 0 out)    #now got normal,but why?
  
     6 Primary Sound Driver, Windows DirectSound (0 in, 2 out)
  
     7 Speakers (Conexant SmartAudio HD), Windows DirectSound (0 in, 2 out)
  
     8 Speakers (Conexant SmartAudio HD), Windows WASAPI (0 in, 2 out)
  
     9 Microphone (Conexant SmartAudio HD), Windows WASAPI (2 in, 0 out)
  
    10 Stereo Mix (Conexant HD Stereo Mix), Windows WDM-KS (2 in, 0 out)
  
    11 Microphone (Conexant HD Audio capture), Windows WDM-KS (2 in, 0 out)
  
    12 Speakers (Conexant HD Audio output), Windows WDM-KS (0 in, 2 out)

  It can be seen that device number 1 was my default one and if that was full name it would be perfect but unfortunately that was not.

  Then the only thing i could have thought of was to capture full name from list that ffmpeg provided :

  'ffmpeg -list_devices true -f dshow -i dummy':
  
  [dshow @ 000001cc4f298d00] DirectShow video devices (some may be both video and audio devices)
  
  [dshow @ 000001cc4f298d00]  "USB2.0 VGA UVC WebCam"
  
  [dshow @ 000001cc4f298d00]     Alternative name "@device_pnp_\\?\usb#vid_13d3&pid_5a07&mi_00#6&2f27e633&0&0000#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global"
  
  [dshow @ 000001cc4f298d00]  "screen-capture-recorder"
  
  [dshow @ 000001cc4f298d00]     Alternative name "@device_sw_{860BB310-5D01-11D0-BD3B-00A0C911CE86}\{4EA69364-2C8A-4AE6-A561-56E4B5044439}"
  
  [dshow @ 000001cc4f298d00] DirectShow audio devices
  
  [dshow @ 000001cc4f298d00]  "Microphone (Conexant SmartAudio HD)"
  
  [dshow @ 000001cc4f298d00]     Alternative name "@device_cm_{33D9A762-90C8-11D0-BD43-00A0C911CE86}\wave_{AFE404CD-A721-49BE-8AC5-669DA725185F}"
  
  [dshow @ 000001cc4f298d00]  "virtual-audio-capturer"
  
  [dshow @ 000001cc4f298d00]     Alternative name "@device_sw_{33D9A762-90C8-11D0-BD43-00A0C911CE86}\{8E146464-DB61-4309-AFA1-3578E927E935}"

  I used

  popen = subprocess.Popen('ffmpeg -list_devices true -f dshow -i dummy', stdout=subprocess.PIPE)
  
  popen.wait()
  
  
  
  lines = popen.stdout.readlines()
  
  print(lines)

  After that i got totally confused because the output was an empty list. Now i am lost in desert and know nowhere to go. Really appreciate it if you could help.

• avcodec/dvdsub_parser : Fix length check for short packets

  30 septembre 2022, par Aidan MacDonald

  avcodec/dvdsub_parser : Fix length check for short packets
  The DVD subtitle parser handles two types of packets : "normal"
  
  packets with a 16-bit length, and HD-DVD packets that set the
  
  16-bit length to 0 and encode a 32-bit length in the next four
  
  bytes. This implies that HD-DVD packets are at least six bytes
  
  long, but the code didn't actually verify this.
  The faulty length check results in an out of bounds read for
  
  zero-length "normal" packets that occur in the input, which are
  
  only 2 bytes long, but get misinterpreted as an HD-DVD packet.
  
  When this happens the parser reads packet_len from beyond the
  
  end of the input buffer. The subtitle stream is not correctly
  
  decoded after this point due to the garbage packet_len.
  Fixing this is pretty simple : fix the length check so packets
  
  less than 6 bytes long will not be mistakenly parsed as HD-DVD
  
  packets.
  Signed-off-by : Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
  
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DH] libavcodec/dvdsub_parser.c

• avcodec/rv34 : Don't needlessly copy VLC length and symbol arrays

  22 octobre 2020, par Andreas Rheinhardt

  avcodec/rv34 : Don't needlessly copy VLC length and symbol arrays
  Most of the VLCs used by RealVideo 3 and 4 obey three simple rules :
  
  Shorter codes are on the left of the tree, for each length, the symbols
  
  are ascending from left to right and the symbols either form a
  
  permutation of 1..size or 0..(size - 1). For the latter case, one just
  
  needs to store the length of each symbol and create the codes according
  
  to the other rules ; no explicit code or symbol array must be stored.
  
  The former case is also treated in much the same way by artificially
  
  assigning a length of zero to the symbol 0 ; when a length of zero was
  
  encountered, the element was ignored except that the symbol counter was
  
  still incremented. If the length was nonzero, the symbol would be
  
  assigned via the symbol counter and the length copied over into a new
  
  array.
  Yet this is unnecessary, as ff_init_vlc_sparse() follows exactly the
  
  same pattern : If a length of zero is encountered, the element is ignored
  
  and only the symbol counter incremented. So one can directly forward the
  
  length array and also need not create a symbol table oneself, because
  
  ff_init_vlc_sparse() will infer the same symbol table in this case.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/rv34.c