Recherche avancée

Sur d’autres sites (6060)

• x86inc : AVX-512 support

  25 mars 2017, par Henrik Gramner

  x86inc : AVX-512 support
  AVX-512 consists of a plethora of different extensions, but in order to keep
  
  things a bit more manageable we group together the following extensions
  
  under a single baseline cpu flag which should cover SKL-X and future CPUs :
  
   * AVX-512 Foundation (F)
  
   * AVX-512 Conflict Detection Instructions (CD)
  
   * AVX-512 Byte and Word Instructions (BW)
  
   * AVX-512 Doubleword and Quadword Instructions (DQ)
  
   * AVX-512 Vector Length Extensions (VL)
  On x86-64 AVX-512 provides 16 additional vector registers, prefer using
  
  those over existing ones since it allows us to avoid using `vzeroupper`
  
  unless more than 16 vector registers are required. They also happen to
  
  be volatile on Windows which means that we don't need to save and restore
  
  existing xmm register contents unless more than 22 vector registers are
  
  required.
  Big thanks to Intel for their support.
  

  • [DH] libavutil/x86/x86inc.asm

• avformat/mpegtsenc : Fix mpegts_write_pes() for private_stream_2 and other types

  25 avril 2021, par zheng qian

  avformat/mpegtsenc : Fix mpegts_write_pes() for private_stream_2 and other types
  According to the PES packet definition defined in Table 2-17 of ISO_IEC_13818-1
  
  specification, some fields like PTS/DTS or pes_extension could only appears if
  
  the stream_id meets the condition :
  if (stream_id != 0xBC &&  // program_stream_map
  
      stream_id != 0xBE &&  // padding_stream
  
      stream_id != 0xBF &&  // private_stream_2
  
      stream_id != 0xF0 &&  // ECM
  
      stream_id != 0xF1 &&  // EMM
  
      stream_id != 0xFF &&  // program_stream_directory
  
      stream_id != 0xF2 &&  // DSMCC_stream
  
      stream_id != 0xF8)    // ITU-T Rec. H.222.1 type E stream
  And the following stream_id types don't have fields like PTS/DTS :
  else if ( stream_id == program_stream_map
  
  || stream_id == private_stream_2
  
  || stream_id == ECM
  
  || stream_id == EMM
  
  || stream_id == program_stream_directory
  
  || stream_id == DSMCC_stream
  
  || stream_id == ITU-T Rec. H.222.1 type E stream ) 
  
      for (i = 0 ; i < PES_packet_length ; i++) 
  
          PES_packet_data_byte
  
      
  
  
  Current implementation skipped the check of stream_id causing some kind of
  
  streams like private_stream_2 to be incorrectly written with actually a
  
  private_stream_1-like PES header with PTS/DTS field. For example, Japan DTV
  
  transmits news and alerts through ARIB superimpose that utilizes
  
  private_stream_2 still could not be remuxed correctly for now.
  This patch set fixes the remuxing for private_stream_2 and
  
  other stream_id types.
  Signed-off-by : zheng qian <xqq@xqq.im>
  
  Signed-off-by : Marton Balint <cus@passwd.hu>
  

  • [DH] libavformat/mpegtsenc.c

• Transcode HLS Segments individually using FFMPEG

  27 mai 2013, par rayh

  I am recording a continuous, live stream to a high-bitrate HLS stream. I then want to asynchronously transcode this to different formats/bitrates. I have this working, mostly, except audio artefacts are appearing between each segment (gaps and pops).

  Here is an example ffmpeg command line :

  ffmpeg -threads 1 -nostdin -loglevel verbose \
  
     -nostdin -y -i input.ts -c:a libfdk_aac \
  
     -ac 2 -b:a 64k -y -metadata -vn output.ts

  Inspecting an example sound file shows that there is a gap at the end of the audio :

  

  And the start of the file looks suspiciously attenuated (although this may not be an issue) :

  

  My suspicion is that these artefacts are happening because transcoding are occurring without the context of the stream as a whole.

  Any ideas on how to convince FFMPEG to produce audio that will fit back into a HLS stream ?

  ** UPDATE 1 **

  Here are the start/end of the original segment. As you can see, the start still appears the same, but the end is cleanly ended at 30s. I expect some degree of padding with lossy encoding, but I there is some way that HLS manages to do gapless playback (is this related to iTunes method with custom metadata ?)

  
  

  ** UPDATED 2 **

  So, I converted both the original (128k aac in MPEG2 TS) and the transcoded (64k aac in aac/adts container) to WAV and put the two side-by-side. This is the result :

  
  

  I'm not sure if this is representative of how a client will play it back, but it seems a bit odd that decoding the transcoded one introduces a gap at the start and makes the segment longer. Given they are both lossy encoding, I would have expected padding to be equally present in both (if at all).

  ** UPDATE 3 **

  According to http://en.wikipedia.org/wiki/Gapless_playback - Only a handful of encoders support gapless - for MP3, I've switched to lame in ffmpeg, and the problem, so far, appears to have gone.

  For AAC (see http://en.wikipedia.org/wiki/FAAC), I have tried libfaac (as opposed to libfdk_aac) and it also seems to produce gapless audio. However, the quality of the latter isn't that great and I'd rather use libfdk_aac is possible.