Recherche avancée

Sur d’autres sites (10233)

• av_format/hlsenc : fix %v handling by format_name function

  17 juin 2019, par Bodecs Bela

  av_format/hlsenc : fix %v handling by format_name function
  Hi All,
  When multiple variant streams are specified by var_stream_map option, %v
  
  placeholder in various names ensures that each variant has its unique
  
  names. Most of %v handlng is done in format_name function. Currently
  
  in this function the result buffer is the same as the
  
  input pattern buffer, so you must allocate it before calling format_name
  
  function. It also means, that it is silently assumed that the result
  
  string will NOT be
  
  longer that the pattern string. It is true most of the time, because %v
  
  may appear only once in the pattern string and number of variant streams
  
  is less than 100 in practical cases. But theoretically it will fail if
  
  specified number of variant streams is greater than 100 (i.e. longer
  
  than 2 digits).
  
  This patch fixes this behaviour by altering format_name function to
  
  allocate the
  
  result buffer and return it to the caller.
  Please, review this patch.
  best,
  Bela
  
  >From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001
  
  From : Bela Bodecs <bodecsb@vivanet.hu>
  
  Date : Mon, 17 Jun 2019 14:31:36 +0200
  
  Subject : [PATCH] av_format/hlsenc : fix %v handling by format_name function
  When multiple variant streams are specified by var_stream_map option, %v
  
  placeholder in various names ensures that each variant has its unique
  
  names. Most of %v handlng is done in format_name function. Currently
  
  in this function the result buffer is the same as the input pattern
  
  buffer, so you must allocate it before calling format_name function. It
  
  also means, that it is silently assumed that the result string will NOT
  
  be longer that the pattern string. It is true most of the time, because
  
  %v may appear only once in the pattern string and number of variant
  
  streams is less than 100 in practical cases. But theoretically it will
  
  fail if specified number of variant streams is greater than 100. This
  
  patch fixes this behaviour by altering format_name function to allocate
  
  the result buffer and return it to the caller.
  Signed-off-by : Bela Bodecs <bodecsb@vivanet.hu>
  

  • [DH] libavformat/hlsenc.c

• Dreamcast Track Sizes

  1er mars 2015, par Multimedia Mike — Sega Dreamcast

  I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.

  You know what’s weird about these discs ? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.

  The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph) :

  
  
  

  Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation ? Why would the data track be split in 2 pieces like that ?

  I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.

  One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.

• Dreamcast Track Sizes

  1er mars 2015, par Multimedia Mike — Sega Dreamcast

  I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.

  You know what’s weird about these discs ? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.

  The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph) :

  
  
  

  Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation ? Why would the data track be split in 2 pieces like that ?

  I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.

  One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.