Recherche avancée

Sur d’autres sites (8446)

• lavf : add oggparsedaala and bump micro

  21 octobre 2015, par Rostislav Pehlivanov

  lavf : add oggparsedaala and bump micro
  This commit introduces a parser for the current bitstream produced by
  
  Daala. It currently bears a large similarity with Theora, another
  
  codec produced by Xiph. While likely to change in the future, its basic
  
  format of packet parsing should remain fairly identical with its current
  
  structure.
  
  Once the bitstream freezes, there are a few probable simplifications
  
  that could be made. Also, the current version (major, minor and micro)
  
  is stuck at zero so it’s unusable as a way to warn about possible
  
  incompatibilities. This will change once the bitstream freezes,
  
  however until then this file is strictly targeting the current git
  
  master of the reference encoder, libdaala.
  This file was developed independently at the same time by both myself
  
  and Vittorio Giovara, who used libav as a starting point. For fairness,
  
  and to prevent confusion and allegations, his name has been added to the
  
  copyright in the license header as well, and vice versa.
  

  • [DH] libavformat/Makefile
  • [DH] libavformat/oggdec.c
  • [DH] libavformat/oggdec.h
  • [DH] libavformat/oggparsedaala.c
  • [DH] libavformat/version.h

• ARM compiler update

  15 janvier 2010, par Mans — ARM, Compilers

  Since my last shootout, all the tested vendors have updated their compilers. Here is a quick update on each of them.

  Both the 4.3 and 4.4 branches of FSF GCC have had bugfix releases, bringing them to 4.3.4 and 4.4.2, respectively. Neither update contains anything particularly noteworthy.

  The CodeSourcery 2009q3 release sees an update to a GCC 4.4 base, a significant change from the 4.3 base used in 2009q1. The update is a mixed blessing. In fact, it is mostly a curse and hardly a blessing at all. On the bright side, the floating-point speed regressions in 2009q1 are gone, 2009q3 being a few per cent faster even than 2007q3. Unfortunately, this improvement is completely overshadowed by a major speed regression on integer code, a whopping 24% in one case. This ties in with the slowdown previously observed with FSF GCC 4.4 compared to 4.3.

  ARM RVCT 4.0 is now at Build 697. This update fixes some bugs and introduces others. Notably, it no longer builds FFmpeg correctly. The issue has been reported to ARM.

  Texas Instruments, finally, have made a formal release, v4.6.1, of their TMS470 compiler incorporating various fixes allowing it to build a moderately patched FFmpeg. The performance remains somewhere between GCC and RVCT on average.

  In light of the above, my recommendations remain unchanged :

  • For a free compiler, choose CodeSourcery 2009q1. It beats GCC 4.3.4 by 5-10% in most cases.
  • GNU purists are best served by GCC 4.3.4, which is up to 20% faster than 4.4.2 and rarely slower.
  • When price is not a concern, ARM RCVT is a good option, outperforming GCC by up to a factor 2.
  • In all cases, disable any auto-vectorisation features.

  Regardless of which compiler is chosen, I cannot overstress the importance of testing. All compilers are crawling with bugs, and even the most innocent-looking code change can trigger one of them. When using a compiler other than GCC, extra caution is advised considering a lot of code is developed using only GCC and may thus fall prey to bugs unique to said other compiler.

• FFMPEG : Transcode H265 10-bit to H264 8-bit without color loss

  24 novembre 2020, par Abhinandan Chakraborty

  I'm testing FFMPEG on my server. I'm trying to transcode H265 10-bit to H264 8-bit to support playing the video on all major web browser.

  


  1. This is the first command :

  


  ffmpeg -i 4K.ts -c:a aac -c:v h264 -crf 19 -preset ultrafast out.mp4


  


  Result : Video only playable on VLC media player. Doesn't play on any browser

  


  2. Then I tried using this command :

  


  ffmpeg -i 4K.ts -c:a aac -c:v h264 -crf 19 -profile:v main -preset ultrafast -vf "format=yuv420p" out.mp4


  


  Result : Video is playable everywhere but massive color loss.

  


  3. Then I tried another command :

  


  ffmpeg -i 4K.ts -c:a aac -c:v h264 -crf 19 -profile:v main -preset ultrafast -vf "format=yuvj420p" out.mp4


  


  Result : Video is playable everywhere but increased color range

  


  I don't know if I am missing anything or If I should completely disallow users to upload video with 10-bit depth. Any help will be greatly appreciated

  


  If anyone interested in the video which I am testing on then here is the link : https://drive.google.com/uc?export=download&id=1pGsnknkoIDRPKrW-YPFS7U31J09PeM4N

  


  I followed through many google results to come up with these command, Some of them are :

  


  

  1. FFMPEG Transcode H265 video from 10-bit to 8-bit

  


  2. https://blender.stackexchange.com/questions/73743/lossless-10-bit-colorspace-yuvj420p-video-output

  


  3. https://askubuntu.com/questions/922563/set-bit-depth-in-ffmpeg-encoding-for-hevc