Recherche avancée

Sur d’autres sites (9682)

• Cut detection with ffprobe

  8 juillet 2019, par Roman Volodin

  I’m trying to detect cuts between shots with ffprobe. I use the following command :

  ffprobe -show_frames -of compact=p=0 -f lavfi "movie=test_clip.avi,select=gt(scene\,.4)" > test_clip_cuts.txt

  It works just fine, there’s no question. But now I want to detect the cuts in certain range only. Let’s say from 3 to 8 seconds. How I could do that ?

  I tried to use -read_intervals 3%8 but it gave me an error :

  Could not seek to position 3000000: Invalid argument
  
  Could not read packets in interval id:0 start:3 end:8

  Command -read_intervals %+3 (read from the very begining to 3rd second) works, but in weird way - it detects cuts up to 4th second (and over, I guess).

  So I’m confused. What are those "intervals" and how to use them ? Is it possible to set the range in regular seconds ?

  Just in case here is my test clip https://yadi.sk/i/nd-c12mYeQ2nb

• 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))
  

• Why can't I get a manually modified MPEG-4 extended box (chunk) size to work ?

  15 avril 2019, par Moshe Rubin

  Overview

  As part of a project to write an MPEG-4 (MP4) file parser, I need to understand how an extended box (or chunk) size is processed within an MP4 file. When I tried to manually simulate an MP4 file with an extended box size, media players report that the file is invalid.

  Technical Information

  Paraphrasing the MPEG-4 specification :

  An MP4 file is formed as a series of objects called ’boxes’. All data is contained in boxes, there is no other data within the file.

  Here is a screen capture of Section 4.2 : Object Structure, which describes the box header and its size and type fields :

  

  

  Most MP4 box headers contain two fields : a 32-bit compact box size and a 32-bit box type. The compact box size supports a box’s data up to 4 GB. Occasionally an MP4 box may have more data than that (e.g., a large video file). In this case, the compact box size is set to 1, and eight (8) octets are added immediately following the box type. This 64-bit number is known as the ’extended box size’, and supports a box’s size up to 2^64.

  To understand the extended box size better, I took a simple MP4 file and wanted to modify the moov/trak/mdia box to use the extended box size, rather than the compact size.

  Here is what the MP4 file looks like before modifying it. The three box headers are highlighted in RED :

  

  My plan was as follows :

  1. Modify the moov/trak/mdia box
     • In the moov/trak/mdia, insert eight (8) octets immediately following the box type (’mdia’). This will eventually be our extended box size.
     • Copy the compact box size to the newly-inserted extended box size, adding 8 to the size to compensate for the newly inserted octets. The size is inserted in big-endian order.
     • Set the compact size to 1.
  2. Modify the moov/trak box
     • Add 8 to the existing compact box size (to compensate for the eight octets added to mdia).
  3. Modify the moov box
     • Add 8 to the existing compact box size (again, to compensate for the eight octets in mdia)

  Here’s what the MP4 file looks like now, with the modified octets are in RED :

  

  What have we done ?

  We have told the MP4 parser/player to take the moov/trak/mdia box size from the extended field rather than the compact size field, and have increased all parent boxes by eight (8) to compensate for the newly-inserted extended box size in the mdia box.

  What’s the problem ?

  When I attempt to play the modified MP4 file I receive error messages from different media players :

  

  

  Why do the media players see the modified file as invalid MP4 ?

  • Did I need to alter any other fields ?
  • Does the extended box size have to be greater than 2^32 ?
  • Can it be that only specific box types support extended box size (e.g., Media Data) ?