Recherche avancée

Sur d’autres sites (7577)

• ffmpeg video replay with time-sync needs actual recording times

  16 juillet 2018, par navySV

  I am attempting to use ffmpeg to replay multiple video files time-synched, but the zero-based video start time is preventing this.

  I have ffmpeg commands to successfully capture a Microsoft Windows 7 desktop into a video file and replay it with a timestamp value (see below), but the internal timestamp is always starting near zero. How can ffmpeg display the actual time when the video was recorded (and not the time since the start of the video i.e. zero) ?

  For example, if the video started to be recorded at 10:47 am, the ffplay command should display a timestamp similar to "10:47:31" during playback (and not "00:00:31").

  video-capture command :

  ffmpeg -f gdigrab -offset_x 0 -offset_y 0 -video_size 1920x1080 -i desktop -c:v libx264 -preset medium -f mpegts -framerate 24 -y fileA.ts

  playback command :

  ffplay -vf "drawtext=fontfile=/windows/fonts/arial.ttf: text='%{pts\:gmtime\:0\:%H\\\:%M\\\:%S}':box=1:x=(w-tw)/2:y=h-(2*lh)" fileA.ts

  parameters I’ve tried unsuccessfully in the previous commands (including moving these around into different places in the commands) :

  -timestamp now
  
  
  
  -vsync 0
  
  
  
  -copyts

  (every attempt to use -copyts generates errors about "non-strictly-monotonic PTS" or "Non-monotonous DTS in output stream" no matter where I put this parameter)

  -filter_complex "[0:v] setpts=PTS"

  The ultimate goal is to capture four video files (recorded on four different computers and probably having different start times), and then to replay all four in time-sync (which is not possible using only the zero-based start times).

  For example, I’ve been successful at replaying four video files in a 2x2 arrangement, using the following command (I added the -ss parameter to demonstrate I can move the start time of the replay). Unfortunately, they always time-sync to the zero-based first video frame (so they all play from the beginning of the video file). I need the replay to be time-syncing to the actual recorded time for each video. If the four videos were captured starting at times 10:47:00, 10:47:51, 10:48:44, and 10:49:01, I want to be able to replay all of them so that all are displaying the same timestep at the same time (so if one video were displaying 10:48:33, all of the videos would be displaying the same time or a blank screen if that time was unavailable) .

  ffmpeg -ss 00:00:30 -i fileA.ts -i fileB.ts -i fileC.ts -i fileD.ts -filter_complex "[0:v][1:v]hstack[top];[2:v][3:v]hstack[bottom];[top][bottom]vstack[v]" -map "[v]" -timestamp now -f mpegts - | ./ffplay - -x 1920 -y 1080

  Ideally, I would also like to be able to use a real time value (something like "ffplay -ss 10:48:00 ...") to start the video replay at a different position, but worst-case I can write a script to do the needed conversion of the time value.

  My ffmpeg version is a Windows 7 64-bit static build "N-90810-g153e920892" on 2018Apr22 (downloaded from https://www.ffmpeg.org/download.html)

• Evolution #3720 (Nouveau) : Refaire un éditeur à base de CodeMirror + ajouts

  27 février 2016, par RastaPopoulos ♥

  Cahier des charges :
  - Dans l’éditeur lui-même, avoir une vue plus sémantique de ce que l’on tape (WYSIWY Mean !)
  - Pouvoir mettre en plein écran
  - Pouvoir prévisualiser le vrai rendu HTML final (avec les images, modèles, etc)
  - Pouvoir éditer côte à côte avec la prévisu
  - Être pérenne et que le noyau puisse reconnaitre plusieurs syntaxes

  Des gens ont fait ça pour Markdown mais malheureusement QUE pour Markdown. Mais en fait quasiment tout ce qui est important est géré en sous-main par CodeMirror !
  https://simplemde.com/

  Leur éditeur est en fait relativement simple :
  => c’est CodeMirror à 80%
  + ils ajoutent une CSS qui ne change pas juste la couleur pour la syntaxe, mais aussi la taille, pour les titres, gras, italique, etc
  + ils ajoutent une barre de boutons
  + ils ajoutent un système de prévisu (seul ou côte à côte)

  CodeMirror est entre l’autre l’éditeur de code de Chrome et Firefox, et de milles autres choses. Il est à priori (très) pérenne, modulaire, et sait gérer plusieurs syntaxes en les déclarant dans un module JS (un "mode"). En plus de la reconnaissance de syntaxe, il gère déjà plein de plugins comme raccourcis claviers, continuer une liste quand on fait Entrée, etc.

  Pour SPIP je propose cela :
  - faire un mode CodeMirror qui gère uniquement les modèles SPIP, et peut-être les liens (ce qui permettrait de l’utiliser avec d’autres syntaxes que SPIP, notamment dans Markdown)
  - faire un mode CodeMirror pour tous les trucs SPIP autre que modèles
  - faire une CSS qui rend plus sémantique la saisie SPIP (agrandir les intertitres, etc)
  - récupérer la CSS pour la saisie Markdown de SimpleMDE
  - trouver une barre de boutons se basant déjà sur CodeMirror : les boutons ne feraient qu’appeler des comportements CodeMirror
  - re-implémenter notre système de prévisu + de fullscreen et côte à côte dans cette nouvelle barre (= comme SimpleMDE !), sachant que nous la prévisu ça appelle un truc serveur, alors que SimpleMDE il semble que c’est tout en JS client.

  Je pense que le plus gros est de faire les deux modes de syntaxes SPIP pour CodeMirror. Mais une personne a fait un projet très cool qui apparemment fonctionne déjà : une déclaration de grammaire en JSON, beaucoup mieux que la programmation JS des modes de CodeMirror :
  https://github.com/foo123/codemirror-grammar
  Et ça marche !

  Pour le reste, on doit pouvoir s’inspirer de SimpleMDE mais en généralisant :
  1) Ce serait bien d’avoir une barre de bouton pour SPIP et pour Markdown en même temps (en fait avoir deux déclarations, suivant le mode voulu)
  2) Avoir notre prévisu-serveur.

  Comme on le remarque, je propose deux choses qui permettent de garder Markdown sous la main :
  1) séparer la déclaration des modèles (et peut-être des liens)
  2) avoir deux déclarations de boutons

  Cela permettra d’office, avec le même éditeur, la même base commune, de savoir gérer à la fois SPIP et Markdown. Cela me semble important à prendre en compte dès le début.

• The 11th Hour RoQ Variation

  12 avril 2012, par Multimedia Mike — Game Hacking, dreamroq, Reverse Engineering, roq, Vector Quantization

  I have been looking at the RoQ file format almost as long as I have been doing practical multimedia hacking. However, I have never figured out how the RoQ format works on The 11th Hour, which was the game for which the RoQ format was initially developed. When I procured the game years ago, I remember finding what appeared to be RoQ files and shoving them through the open source decoders but not getting the right images out.

  I decided to dust off that old copy of The 11th Hour and have another go at it.

  
  
  

  Baseline
  The game consists of 4 CD-ROMs. Each disc has a media/ directory that has a series of files bearing the extension .gjd, likely the initials of one Graeme J. Devine. These are resource files which are merely headerless concatenations of other files. Thus, at first glance, one file might appear to be a single RoQ file. So that’s the source of some of the difficulty : Sending an apparent RoQ .gjd file through a RoQ player will often cause the program to complain when it encounters the header of another RoQ file.

  I have uploaded some samples to the usual place.

  However, even the frames that a player can decode (before encountering a file boundary within the resource file) look wrong.

  Investigating Codebooks Using dreamroq
  I wrote dreamroq last year– an independent RoQ playback library targeted towards embedded systems. I aimed it at a gjd file and quickly hit a codebook error.

  RoQ is a vector quantizer video codec that maintains a codebook of 256 2×2 pixel vectors. In the Quake III and later RoQ files, these are transported using a YUV 4:2:0 colorspace– 4 Y samples, a U sample, and a V sample to represent 4 pixels. This totals 6 bytes per vector. A RoQ codebook chunk contains a field that indicates the number of 2×2 vectors as well as the number of 4×4 vectors. The latter vectors are each comprised of 4 2×2 vectors.

  Thus, the total size of a codebook chunk ought to be (# of 2×2 vectors) * 6 + (# of 4×4 vectors) * 4.

  However, this is not the case with The 11th Hour RoQ files.

  Longer Codebooks And Mystery Colorspace
  Juggling the numbers for a few of the codebook chunks, I empirically determined that the 2×2 vectors are represented by 10 bytes instead of 6. Now I need to determine what exactly these 10 bytes represent.

  I should note that I suspect that everything else about these files lines up with successive generations of the format. For example if a file has 640×320 resolution, that amounts to 40×20 macroblocks. dreamroq iterates through 40×20 8×8 blocks and precisely exhausts the VQ bitstream. So that all looks valid. I’m just puzzled on the codebook format.

  Here is an example codebook dump :
  

  ID 0x1002, len = 0x0000014C, args = 0x1C0D
    0 : 00 00 00 00 00 00 00 00 80 80
    1 : 08 07 00 00 1F 5B 00 00 7E 81
    2 : 00 00 15 0F 00 00 40 3B 7F 84
    3 : 00 00 00 00 3A 5F 18 13 7E 84
    4 : 00 00 00 00 3B 63 1B 17 7E 85
    5 : 18 13 00 00 3C 63 00 00 7E 88
    6 : 00 00 00 00 00 00 59 3B 7F 81
    7 : 00 00 56 23 00 00 61 2B 80 80
    8 : 00 00 2F 13 00 00 79 63 81 83
    9 : 00 00 00 00 5E 3F AC 9B 7E 81
    10 : 1B 17 00 00 B6 EF 77 AB 7E 85
    11 : 2E 43 00 00 C1 F7 75 AF 7D 88
    12 : 6A AB 28 5F B6 B3 8C B3 80 8A
    13 : 86 BF 0A 03 D5 FF 3A 5F 7C 8C
    14 : 00 00 9E 6B AB 97 F5 EF 7F 80
    15 : 86 73 C8 CB B6 B7 B7 B7 85 8B
    16 : 31 17 84 6B E7 EF FF FF 7E 81
    17 : 79 AF 3B 5F FC FF E2 FF 7D 87
    18 : DC FF AE EF B3 B3 B8 B3 85 8B
    19 : EF FF F5 FF BA B7 B6 B7 88 8B
    20 : F8 FF F7 FF B3 B7 B7 B7 88 8B
    21 : FB FF FB FF B8 B3 B4 B3 85 88
    22 : F7 FF F7 FF B7 B7 B9 B7 87 8B
    23 : FD FF FE FF B9 B7 BB B7 85 8A
    24 : E4 FF B7 EF FF FF FF FF 7F 83
    25 : FF FF AC EB FF FF FC FF 7F 83
    26 : CC C7 F7 FF FF FF FF FF 7F 81
    27 : FF FF FE FF FF FF FF FF 80 80
  

  Note that 0x14C (the chunk size) = 332, 0x1C and 0x0D (the chunk arguments — count of 2×2 and 4×4 vectors, respectively) are 28 and 13. 28 * 10 + 13 * 4 = 332, so the numbers check out.

  Do you see any patterns in the codebook ? Here are some things I tried :

  • Treating the last 2 bytes as U & V and treating the first 4 as the 4 Y samples :
    
    
    
  • Treating the last 2 bytes as U & V and treating the first 8 as 4 16-bit little-endian Y samples :
    
    
    
  • Disregarding the final 2 bytes and treating the first 8 bytes as 4 RGB565 pixels (both little- and big-endian, respectively, shown here) :
    
    
    
  • Based on the type of data I’m seeing in these movies (which appears to be intended as overlays), I figured that some of these bits might indicate transparency ; here is 15-bit big-endian RGB which disregards the top bit of each pixel :
    
    
    

  These images are taken from the uploaded sample bdpuz.gjd, apparently a component of the puzzle represented in this screenshot.

  Unseen Types
  It has long been rumored that early RoQ files could contain JPEG images. I finally found one such specimen. One of the files bundled early in the uploaded fhpuz.gjd sample contains a JPEG frame. It’s a standard JFIF file and can easily be decoded after separating the bytes from the resource using ‘dd’. JPEGs serve as intraframes in the coding scheme, with successive RoQ frames moving objects on top.

  However, a new chunk type showed up as well, one identified by 0×1030. I have never encountered this type. Where could I possibly find data about this ? Fortunately, iD Games recently posted all of their open sourced games at Github. Reading through the code for their official RoQ decoder, I see that this is called a RoQ_PACKET. The name and the code behind it are both supremely unhelpful. The code is basically a no-op. The payloads of the various RoQ_PACKETs from one sample are observed to be either 8784, 14752, or 14760 bytes in length. It’s very likely that this serves the same purpose as the JPEG intraframes.

  Other Tidbits
  I read through the readme.txt on the first game disc and found this nugget :

          g)      Animations displayed normally or in SPOOKY MODE
                  SPOOKY MODE is blue-tinted grayscale with color cursors, puzzle
  
                  and game pieces.  It is the preferred display setting of the
  
                  developers at Trilobyte.  Just for fun, try out the SPOOKY
  
                  MODE.
  

  The MobyGames screenshot page has a number of screenshots labeled as being captured in spooky mode. Color tricks ?

  Meanwhile, another twist arose as I kept tweaking dreamroq to deal with more RoQ weirdness : After modifying my dreamroq code to handle these 10-byte vectors, it eventually chokes on another codebook. These codebooks happen to have 6-byte vectors again ! Fortunately, I was already working on a scheme to automatically detect which codebook is in play (plugging the numbers into a formula and seeing which vector size checks out).