Recherche avancée

Sur d’autres sites (19267)

• avformat/matroskaenc : Don't waste bytes on BlockGroup length fields

  16 janvier 2022, par Andreas Rheinhardt

  avformat/matroskaenc : Don't waste bytes on BlockGroup length fields
  This commit uses the new EbmlWriter API to write the length fields
  
  of the BlockGroup and its descendants that are themselves Master
  
  elements (namely BlockAdditions and BlockMore) on the least amount of
  
  bytes.
  This fixes regressions introduced when the special code for writing
  
  general subtitles was removed. Accordingly, the binsub-mksenc and
  
  matroska-zero-length-block FATE-tests have now been reverted back
  
  to their old state again ; the advantages of this approach are evident
  
  with the matroska-vp8-alpha-remux test which up until now wrote
  
  all the length fields of all BlockGroups, BlockAdditions and BlockMore
  
  on eight bytes.
  Using the EbmlWriter API also allowed to improve locality in
  
  mkv_write_block() : E.g. both DiscardPadding as well as the
  
  BlockAdditional side-data are now directly used to add elements
  
  to the writer whereas the earlier code had to first check
  
  for whether a BlockGroup should be used and then check again
  
  (after the place where a BlockGroup would be opened if one were
  
  used) for whether there is DiscardPadding or BlockAdditional
  
  side-data to write.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavformat/matroskaenc.c
  • [DH] tests/ref/fate/binsub-mksenc
  • [DH] tests/ref/fate/matroska-vp8-alpha-remux
  • [DH] tests/ref/fate/matroska-zero-length-block
  • [DH] tests/ref/fate/webm-dash-chapters

• Anomalie #2855 : mauvais traitement du signe par textwheel

  9 août 2014, par cedric -

  Coquille dans le test, corrigée par http://zone.spip.org/trac/spip-zone/changeset/84111
  Si on dit que les < doivent être échappés dans la mesure du possible, le patch suivant semble faire le boulot sans casser aucun autre test.
  Mais est-ce que ça en vaut vraiment la peine ?

  Index : wheels/spip/spip.yaml
  ===================================================================
  
  — - wheels/spip/spip.yaml       (revision 83994)
  +++ wheels/spip/spip.yaml       (working copy)
  @@ -183,3 +183,9 @@
     match : ["\x1\x1", "\x1\x2", "\x1\x3", "\x1\x4"]
     replace : [’’, ’’, ’_’, ’-’]
     type : str
  +
  +echapg-�chevron-ouvrant :
  +  #if_str : "
  &lt;script&quot; <br />
  
  +  type: preg<br />
  
  +  match: &quot;/&lt;([^&gt;&lt;]*)(?=&lt;|$)/Uims&quot; <br />
  
  +  replace: &quot;&amp;amp;lt;$1&quot; <br />
  
  &lt;/pre&gt;

• How can i decode an mp3 and encode it as aac with ezstream

  8 avril 2015, par Roberto Arosemena

  This is my current ezstream config

  <ezstream>
  
     <url>http://localhost:8000/test</url>
  
     <sourcepassword>password</sourcepassword>
  
     <format>MP3</format>
  
     <filename>playlist.m3u</filename>
  
     <reencode>
  
        <enable>1</enable>
  
        <encdec>
  
           <format>MP3</format>
  
           <match>.mp3</match>
  
           <decode>madplay -b 16 -R 44100 -S -o raw:- "@T@"</decode>
  
           <encode>lame --preset cbr 32 -r -s 44.1 --bitwidth 16 - -</encode>
  
        </encdec>
  
     </reencode>
  
  </ezstream>

  It’s mounting to an icecast server, its decoding and encoding mp3 to a lower bitrate, I’m trying to encode it to aac instead of mp3 in hopes that the quality improves as i heard that aac is better than mp3 for lower bitrates.

  What i would like to know is if i can use an aac encoder such as FFmpeg instead of the lame mp3 encoder and get an aac to the end user instead of mp3, if so what parameters should i pass to FFmpeg so that it works with my current config.