Recherche avancée

Sur d’autres sites (4277)

• "Convert regions extracted from wav audio file into Flac audio file " python using FFMPAG in Django

  9 avril 2019, par maryam mehboob

  Regions extracted from wav audio file have "Invalid duration specification for ss"
  For Example in my case duration is in this format

  [(0.006000000000000005, 1.03), (2.0540000000000003, 4.870000000000003)]

  This is for converting regions into Flac format.

       class FLACConverter(object):
  
           # pylint: disable=too-few-public-methods
  
      """
  
           Class for converting a region of an input audio or video file into a FLAC audio file
  
      """
  
  
  
       def __init__(self, source_path, include_before=0.25, include_after=0.25):
  
          self.source_path = source_path
  
          self.include_before = include_before
  
          self.include_after = include_after
  
  
  
  
  
       def __call__(self, region):
  
          try:
  
              print("regions to convert in flac:{}".format(region))
  
              start = region
  
              end = region
  
            #  start = max(0, start - self.include_before)
  
              start = list(map(lambda x: tuple(max(0, y - self.include_before) for y in x), start))
  
              end = list(map(lambda x: tuple(y + self.include_after for y in x), end))
  
              temp = tempfile.NamedTemporaryFile(suffix='.flac', delete=False)
  
              command = ["ffmpeg", "-ss", str(start), "-t", str([tuple(x-y for x, y in zip(x1, x2)) for (x1, x2) in zip(end, start)]),
  
                         "-y", "-i", self.source_path,
  
                         "-loglevel", "error", temp.name]
  
              use_shell = True if os.name == "nt" else False
  
              subprocess.check_output(command)
  
              print(temp.name)
  
              #subprocess.check_output(command, stdin=open(os.devnull), shell=use_shell)
  
              read_data = temp.read()
  
              temp.close()
  
              os.unlink(temp.name)
  
              print("read_data :{}".format(read_data))
  
              print("temp :{}".format(temp.name))
  
  
  
              return read_data
  
  
  
          except KeyboardInterrupt:
  
              return None

  I expect the output of /var/folders/p1/6ttydjfx2sq9zl4cnmjxgjh40000gp/T/tmpwz5n4fnv.flac but it returns an error

  CalledProcessError at /

  Command '['ffmpeg', '-ss', '[(0.006000000000000005, 1.03), (2.0540000000000003, 4.870000000000003)]', '-t', '[(0.5, 0.5), (0.5, 0.5)]', '-y', '-i', '/var/folders/p1/6ttydjfx2sq9zl4cnmjxgjh40000gp/T/tmpuyi5spat.wav', '-loglevel', 'error', '/var/folders/p1/6ttydjfx2sq9zl4cnmjxgjh40000gp/T/tmp0vdewoyd.flac']' returned non-zero exit status 1.```

• Turn off sw_scale conversion to planar YUV 32 byte alignment requirements

  8 novembre 2022, par flansel

  I am experiencing artifacts on the right edge of scaled and converted images when converting into planar YUV pixel formats with sw_scale. I am reasonably sure (although I can not find it anywhere in the documentation) that this is because sw_scale is using an optimization for 32 byte aligned lines, in the destination. However I would like to turn this off because I am using sw_scale for image composition, so even though the destination lines may be 32 byte aligned, the output image may not be.

  


  Example.

  


  Full output frame is 1280x720 yuv422p10le. (this is 32 byte aligned)
However into the top left corner I am scaling an image with an outwidth of 1280 / 3 = 426.
426 in this format is not 32 byte aligned, but I believe sw_scale sees that the output linesize is 32 byte aligned and overwrites the width of 426 putting garbage in the next 22 bytes of data thinking this is simply padding when in my case this is displayable area.

  


  This is why I need to actually disable this optimization or somehow trick sw_scale into believing it does not apply while keeping intact the way the program works, which is otherwise fine.

  


  I have tried adding extra padding to the destination lines so they are no longer 32 byte aligned,
this did not help as far as I can tell.

  


  Edit with code Example. Rendering omitted for ease of use.
Also here is a similar issue, unfortunately as I stated there fix will not work for my use case. https://github.com/obsproject/obs-studio/pull/2836

  


  Use the commented line of code to swap between a output width which is and isnt 32 byte aligned.

  


  #include "libswscale/swscale.h"
#include "libavutil/imgutils.h"
#include "libavutil/pixelutils.h"
#include "libavutil/pixfmt.h"
#include "libavutil/pixdesc.h"
#include 
#include 
#include 

int main(int argc, char **argv) {

/// Set up a 1280x720 window, and an item with 1/3 width and height of the window.
int window_width, window_height, item_width, item_height;
window_width = 1280;
window_height = 720;
item_width = (window_width / 3);
item_height = (window_height / 3);

int item_out_width = item_width;
/// This line sets the item width to be 32 byte aligned uncomment to see uncorrupted results
/// Note %16 because outformat is 2 bytes per component
//item_out_width -= (item_width % 16);

enum AVPixelFormat outformat = AV_PIX_FMT_YUV422P10LE;
enum AVPixelFormat informat = AV_PIX_FMT_UYVY422;
int window_lines[4] = {0};
av_image_fill_linesizes(window_lines, outformat, window_width);

uint8_t *window_planes[4] = {0};
window_planes[0] = calloc(1, window_lines[0] * window_height);
window_planes[1] = calloc(1, window_lines[1] * window_height);
window_planes[2] = calloc(1, window_lines[2] * window_height); /// Fill the window with all 0s, this is green in yuv.


int item_lines[4] = {0};
av_image_fill_linesizes(item_lines, informat, item_width);

uint8_t *item_planes[4] = {0};
item_planes[0] = malloc(item_lines[0] * item_height);
memset(item_planes[0], 100, item_lines[0] * item_height);

struct SwsContext *ctx;
ctx = sws_getContext(item_width, item_height, informat,
               item_out_width, item_height, outformat, SWS_FAST_BILINEAR, NULL, NULL, NULL);

/// Check a block in the normal region
printf("Pre scale normal region %d %d %d\n", (int)((uint16_t*)window_planes[0])[0], (int)((uint16_t*)window_planes[1])[0],
       (int)((uint16_t*)window_planes[2])[0]);

/// Check a block in the corrupted region (should be all zeros) These values should be out of the converted region
int corrupt_offset_y = (item_out_width + 3) * 2; ///(item_width + 3) * 2 bytes per component Y PLANE
int corrupt_offset_uv = (item_out_width + 3); ///(item_width + 3) * (2 bytes per component rshift 1 for horiz scaling) U and V PLANES

printf("Pre scale corrupted region %d %d %d\n", (int)(*((uint16_t*)(window_planes[0] + corrupt_offset_y))),
       (int)(*((uint16_t*)(window_planes[1] + corrupt_offset_uv))), (int)(*((uint16_t*)(window_planes[2] + corrupt_offset_uv))));
sws_scale(ctx, (const uint8_t**)item_planes, item_lines, 0, item_height,window_planes, window_lines);

/// Preform same tests after scaling
printf("Post scale normal region %d %d %d\n", (int)((uint16_t*)window_planes[0])[0], (int)((uint16_t*)window_planes[1])[0],
       (int)((uint16_t*)window_planes[2])[0]);
printf("Post scale corrupted region %d %d %d\n", (int)(*((uint16_t*)(window_planes[0] + corrupt_offset_y))),
       (int)(*((uint16_t*)(window_planes[1] + corrupt_offset_uv))), (int)(*((uint16_t*)(window_planes[2] + corrupt_offset_uv))));

return 0;


  


  }

  


  Example Output:

//No alignment
Pre scale normal region 0 0 0
Pre scale corrupted region 0 0 0
Post scale normal region 400 400 400
Post scale corrupted region 512 36865 36865

//With alignment
Pre scale normal region 0 0 0
Pre scale corrupted region 0 0 0
Post scale normal region 400 400 400
Post scale corrupted region 0 0 0


  


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