Recherche avancée

Sur d’autres sites (6154)

• Revision 790fb13215 : Use above/left (instead of previous in scan-order) as token context. Pearson co

  27 mars 2013, par Ronald S. Bultje

  Changed Paths : Modify /vp9/common/vp9_default_coef_probs.h Modify /vp9/common/vp9_entropy.c Modify /vp9/common/vp9_entropy.h Modify /vp9/common/vp9_onyxc_int.h Modify /vp9/decoder/vp9_decodframe.c Modify /vp9/decoder/vp9_detokenize.c Modify /vp9/encoder/vp9_bitstream.c (...)

• Next pts does not match previous pts plus duration when transcoding an AAC audio with ffmpeg

  17 septembre 2021, par b1sub

  In my understanding, the following statement must hold :

  


  next pts = previous pts + duration


  


  But, I got this list of PTSes from ffprobe that looks odd to me :

  


  <packet pts="63000" duration="2089">&#xA;<packet pts="65070" duration="2089">&#xA;<packet pts="67140" duration="2089">&#xA;<packet pts="69300" duration="2089">&#xA;<packet pts="71370" duration="2089">&#xA;<packet pts="73440" duration="2089">&#xA;<packet pts="75510" duration="2089">&#xA;<packet pts="77670" duration="2089">&#xA;</packet></packet></packet></packet></packet></packet></packet></packet>

  


  The corresponding PTS gaps are as follows. You can see none of the below gaps matches 2089 :

  


  63000 <> 65070: 2070
65070 <> 67140: 2070
67140 <> 69300: 2160
69300 <> 71370: 2070
71370 <> 73440: 2070
73440 <> 75510: 2070
75510 <> 77670: 2160


  


  I have no deep understanding of AAC or transcoding, so I talked with some random guy on #ffmpeg. As per what he said, the gap should be a fixed value :

  


  20:01 -!- Icedream [~icedream@hzn-b.serverkomplex.de] has quit [Quit: A lol made me boom.]
20:02 < DeHackEd> I would expect them to increment at a constant rate, since AAC (which is probably what you're using) uses fixed size
                  audio chunks. But that's very inconsistent
20:03 < DeHackEd> (+/- 1 pts number would be acceptable)


  


  To tell you the truth, this is a problematic video, but not in a way you would expect. I'm getting intermittent audio clipping sound, if two or more audio packets are crammed into a single PES packet. What's special about this configuration is that, the player must guess PTSes for the trailing audio packets except the first one. Since the PTS gaps are not consistent, the player must have used wrong PTSes for the trailing ones, and this looks to me like the cause.

  


  But, what could be the trigger ? Here are some contexts you can kindly refer to :

  


  

  • the original video has no surprising PTS gap. This is the result from my custom-made script to extract all unique gaps :

  


  


  $ ./foo.sh ./original.flv
diff 296448 occurs at 296448 // just a first packet (=has no previous packet)
diff 24 occurs at 296472
diff 23 occurs at 296495


  


  

  • this is the command I used for transcoding :

  


  


  $FFMPEG -hide_banner -loglevel info -nostats \
    -i $input \
    -map "[out1]" -c:v libx264 -r 30 -force_key_frames "expr:gte(t, n_forced*$keyFrameInterval)" -preset veryfast -vprofile high -minrate 4.5M -maxrate 6M -bufsize 6M \
    -map 0:a -c:a aac -b:a:1 128K -af "aformat=sample_rates=44100|48000:channel_layouts=stereo" \
    -map 0:a -c:a aac -b:a:2 32K -af "aformat=sample_rates=44100|48000:channel_layouts=stereo" \
    -f mpegts -tune zerolatency pipe:1 > \
        >($FFMPEG -hide_banner -loglevel info -nostats \
            -i - \
            -map 0:v -c:v copy -map 0:1 -c:a copy -bsf:a aac_adtstoasc -tune zerolatency -f flv -max_muxing_queue_size 1024 ${output}_1080 \
            -map 0:v -s $(width 1280 720 $orientation)x$(height 1280 720 $orientation) -c:v libx264 -r 30 -force_key_frames "expr:gte(t, n_forced*$keyFrameInterval)" -preset veryfast -vprofile high -minrate 3M -maxrate 4M -bufsize 4M -map 0:1 -c:a copy -bsf:a aac_adtstoasc -f flv -tune zerolatency -max_muxing_queue_size 1024 ${output}_720 \
            ...


  


• Anomalie #4342 (Fermé) : Erreur 1071 de mysql : Specified key was too long ; max key length is 1000 ...

  26 mai 2019

  Bonjour,

  Après avoir configuré MariaDB pour être en UTF8MB4, je n’ai pas pu installer un plugin (comme il y a aussi un bug SVP, je vais faire un autre ticket spécifique).
  Pour être précis, un table du plugin n’a pas été créée et sql.log contient :
  

  2019-05-25 16:23:59 78.205.175.37 (pid 16091) :Pri:ERREUR : Erreur 1071 de mysql : Specified key was too long ; max key length is 1000 bytes
  in ecrire/base/create.php L73 [sql_create(),creer_ou_upgrader_table(),alterer_base(),maj_tables(),serie_alter(),maj_while(),maj_plugin(),referer_spam_upgrade(),spip_plugin_install(),plugins_installer_dist(),installer_plugin(),do_install(),do_action(),one_action(),action_actionner_dist(),traiter_appels_actions()]
  CREATE  TABLE IF NOT EXISTS `mutu_pro2spipf126`.spip_referer_spam (
          date DATE NOT NULL,
          referer VARCHAR (255) ,
          PRIMARY KEY (referer)) ENGINE=MyISAM
  

  La documentation sur ce sujet est abondante.
  Ceci m’a semblé un bon résumé du problème : https://stackoverflow.com/questions/6172798/mysql-varchar255-utf8-is-too-long-for-key-but-max-length-is-1000-bytes
  Et la solution générale consiste à faire un index de seulement 191 : https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-conversion.html :
  

  In an InnoDB table that uses COMPACT or REDUNDANT row format, these column and index definitions are legal :
  col1 VARCHAR(500) CHARACTER SET utf8, INDEX (col1(255))
  To use utf8mb4 instead, the index must be smaller :
  
  col1 VARCHAR(500) CHARACTER SET utf8mb4, INDEX (col1(191))