Recherche avancée

Sur d’autres sites (13801)

• Anomalie #2691 : impossible de téléverser un fichier pgn spip/sqlite

  6 mai 2012, par Jacques Bouthier

  Il semble que ce soit un problème d’install du site... La table spip_types_documents étant vide. je réessaie plus tard.

• ffmpeg - maintain video quality as I apply multi-pass workflow, each includes decoding and encoding again, in video editing

  27 septembre 2020, par QRrabbit

  I'm using FFMPEG libraries do do some video manipulation, and due to complexity of filters and image overlaying, I have to run the process in multiple passes.
This means, my process is as such :
Open original video, decode it, run -complex_filter, recompress the video in whichever format the original video was encoded.
Open the output from the first pass, run another -complex_filter, etc-etc.
Sometimes I have to do the above 3-4 times. My concern is that the video, with every compression is losing quality - obvious signs of that is the file is shrinking in size with every pass.

  


  With the above, I have two questions :

  


  


  1. Would it make sense to, after first manipulation, instead of saving the video in its original format, I chose some format that is lossless, and then perform my passes one after the other, knowing that the quality remains the same, then on the final pass I recompress one-time into the format of the source. If so, what format of a video would you recommend ? ProRes 4444 ? Any other formats I shell consider ? Any parameters I should set and carry-over from encoding to encoding ?

     


  


  2. With every step I carry over all extra streams of audio and other meta data.
Wouldn't it be more efficient to strip everything except the video, run my video passages over and over and not to need for adding -c:a copy and c:s copy ? Then on my final run, merge all streams from the original source to the output file ? If yes, how will I carry the ffmpeg command specifically ? I have a video that has 1 video stream + 15 audio streams + some extra tmcd which my ffmpeg cannot read.

     


  


  


  Thank you.

  


  Edit 1 :

  


  if the input video has a video codec = dvvideo, and if dimensions of the video is 1280x1080, that means the video doesn't have a typical square pixels.
I first need to resize the video, in doing so I scale the video up. Then I can run my filters :

  


  pass-1 : -vf scale=1920x1080 (this step is skipped if the video is of a normal x to y ratio)
pass-2 : -filter_complex : which calls my special filter that adds some proprietary watermark to a video
pass-3 : -filter_complex : "0overlay=5:21:enable='between(t,2,3)+between(t,4,5)+between(t,6,8)'" (sole objective is to inserts an icon.png at a location near where the watermark was placed in previous step.)
pass-4 : -vf scale=1280x1080 (this step scales the video back, if pass-1 was executed)

  


  I could probably rewrite my 'C' filter code at some point in the future to accommodate this logic of checking for 1280x1080, as well as inserting this icon.png, and do it all in one step, but for right now, I thought just using 2-step process if a normal video, or a 4 passes if needs scaling, and utilize something of a lossless format as a temp file solution (I arbitrary chose ProRes 4444 v5, but open to suggestions), should minimize the losses during recompression to the video.

  


  Steps 1 and 4 are conditional, and only applicable if :&#xA;if vcodec == 'dvvideo' and aspect_ratio < 1.2 : # 1280x1080 ratio has about 1.16&#xA;I run steps 1->4. Otherwise only steps 2 & 3 :

  &#xA;

  Step1 :

  &#xA;

  ffmpeg -i in.mov -vf scale=1920x1080 -map 0:v? -map 0:a? -map 0:s? -map_metadata 0 -b:v 115084915 -maxrate 115084915 -minrate 115084915 -c:v prores_ks -profile:v 5 -preset ultrafast -crf 0 -c:a copy -timecode 00:00:00.00 -c:s copy -y step2.mov


  &#xA;

  Step2 :

  &#xA;

  ffmpeg -i step2.mov -filter_complex " myFilter=enable='between(t,0,30)':x=15:y=25:size=95:etc-etc..." -map 0:v? -map 0:a? -map 0:s? -map_metadata 0 -b:v 115084915 -maxrate 115084915 -minrate 115084915 -c:v prores_ks -profile:v 5 -preset ultrafast -crf 0 -c:a copy -timecode 00:00:00.00 -c:s copy -y step3.mov


  &#xA;

  Step3 :

  &#xA;

  ffmpeg -i step3.mov -i icon.png -filter_complex "[0][1]overlay=15:20:enable='between(t,1,3.600)+between(t,4,5.500)+between(t,6,20)' " -map 0:v? -map 0:a? -map 0:s? -map_metadata 0 -b:v 115084915 -maxrate 115084915 -minrate 115084915 -c:v prores_ks -profile:v 5 -preset ultrafast -crf 0 -c:a copy -timecode 00:00:00.00 -c:s copy -y step4.mov


  &#xA;

  Step4 :

  &#xA;

  ffmpeg -i step4.mov -map 0:v? -vf scale=1280x1080 -map 0:a? -map 0:s? -c:v dvvideo -pix_fmt yuv422p -b:v 115084915 -maxrate 115084915 -minrate 115084915 -r 29.97 -top 1 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -vtag dvh6 -map_metadata 0 -c:a copy -timecode 00:00:00.00 -c:s copy -y final-output.mov


  &#xA;

  Since I post my entire set of ffmpeg commands, maybe someone could recommend how to make my output match input so that I don't lose timecode entry :

  &#xA;

• Notes on Linux for Dreamcast

  23 février 2011, par Multimedia Mike — Sega Dreamcast, VP8

  I wanted to write down some notes about compiling Linux on Dreamcast (which I have yet to follow through to success). But before I do, allow me to follow up on my last post where I got Google’s libvpx library decoding VP8 video on the DC. Remember when I said the graphics hardware could only process variations of RGB color formats ? I was mistaken. Reading over some old documentation, I noticed that the DC’s PowerVR hardware can also handle packed YUV textures (UYVY, specifically) :

  
  
  

  The video looks pretty sharp in the small photo. Up close, less so, due to the low resolution and high quantization of the test vector combined with the naive chroma upscaling. For the curious, the grey box surrounding the image highlights the 256-square texture that the video frame gets plotted on. Texture dimensions have to be powers of 2.

  Notes on Linux for Dreamcast
  I’ve occasionally dabbled with Linux on my Dreamcast. There’s an ancient (circa 2001) distro based around a build of kernel 2.4.5 out there. But I wanted to try to get something more current compiled. Thus far, I have figured out how to cross compile kernels pretty handily but have been unsuccessful in making them run.

  Here are notes are the compilation portion :
  

  • kernel.org provides a very useful set of cross compiling toolchains
  • get the gcc 4.5.1 cross toolchain for SH-4 (the gcc 4.3.3 one won’t work because the binutils is too old ; it will fail to assemble certain instructions as described in this post)
  • working off of Linux kernel 2.6.37, edit the top-level Makefile ; find the ARCH and CROSS_COMPILE variables and set appropriately :

    ARCH ?= sh
    CROSS_COMPILE ?= /path/to/gcc-4.5.1-nolibc/sh4-linux/bin/sh4-linux-
    

  • $ make dreamcast_defconfig
  • $ make menuconfig ... if any changes to the default configuration are desired
  • manually edit arch/sh/Makefile, changing :

    cflags-$(CONFIG_CPU_SH4) := $(call cc-option,-m4,) \
            $(call cc-option,-mno-implicit-fp,-m4-nofpu)
    

    to :

    cflags-$(CONFIG_CPU_SH4) := $(call cc-option,-m4,) \
            $(call cc-option,-mno-implicit-fp)
    

    I.e., remove the '-m4-nofpu' option. According to the gcc man page, this will "Generate code for the SH4 without a floating-point unit." Why this is a default is a mystery since the DC’s SH-4 has an FPU and compilation fails when enabling this option.

  • On that note, I was always under the impression that the DC sported an SH-4 CPU with the model number SH7750. According to this LinuxSH wiki page as well as the Linux kernel help, it actually has an SH7091 variant. This photo of the physical DC hardware corroborates the model number.
  • $ make ... to build a Linux kernel for the Sega Dreamcast

  Running
  So I can compile the kernel but running the kernel (the resulting vmlinux ELF file) gives me trouble. The default kernel ELF file reports an entry point of 0x8c002000. Attempting to upload this through the serial uploading facility I have available to me triggers a system reset almost immediately, probably because that’s the same place that the bootloader calls home. I have attempted to alter the starting address via ’make menuconfig’ -> System type -> Memory management options -> Physical memory start address. This allows the upload to complete but it still does not run. It’s worth noting that the 2.4.5 vmlinux file from the old distribution can be executed when uploaded through the serial loader, and it begins at 0x8c210000.