Recherche avancée

Sur d’autres sites (8620)

• How to build ffmpeg and x264 for iOS 6.0 ?

  16 mai 2013, par user2388180

  Here's my configuration :

  ./configure --enable-libx264 --enable-gpl --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/lib --disable-doc --disable-ffmpeg --disable-ffplay --disable-ffserver --disable-avfilter --disable-debug --disable-decoders --enable-cross-compile --disable-encoders --disable-armv5te  --enable-decoder=h264 --enable-encoder=libx264 --enable-pic --cc=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc --as='gas-preprocessor/gas-preprocessor.pl /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc' --extra-ldflags='-arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk' --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk --target-os=darwin --arch=arm --cpu=cortex-a8 --extra-cflags='-arch armv7' --disable-asm

  I then run make and make install. But there's no file in /usr/local.

• cbs_mpeg2 : Fix parsing of picture and slice headers

  20 juin 2019, par Andreas Rheinhardt

  cbs_mpeg2 : Fix parsing of picture and slice headers
  1. The extra information in slice headers was parsed incorrectly :
  
  In the first reading pass to derive the length of the extra information,
  
  one should look at bits n, n + 9, n + 18, ... and check whether they
  
  equal one (further extra information) or zero (end of extra information),
  
  but instead bits n, n + 8, n + 16, ... were inspected. The second pass
  
  of reading (where the length is already known and the bytes between the
  
  length-determining bits are copied into a buffer) did not record what
  
  was in bits n, n + 9, n + 18, ..., presuming they equal one. And during
  
  writing, the bytes in the buffer are interleaved with set bits and
  
  written. This means that if the detected length of the extra information
  
  was greater than the real length, the output was corrupted. Fortunately
  
  no sample is known that made use of this mechanism : The extra information
  
  in slices is still marked as reserved in the specifications. cbs_mpeg2
  
  is now ready in case this changes.
  2. Furthermore, the buffer is now padded and slightly different, but
  
  very similar code for reading resp. writing has been replaced by code
  
  used for both. This was made possible by a new macro, the equivalent
  
  to cbs_h2645's fixed().
  3. These changes also made it possible to remove the extra_bit_slice
  
  element from the MPEG2RawSliceHeader structure. Said element was always
  
  zero except when the detected length of the extra information was less
  
  than the real length.
  4. The extra information in picture headers (which uses essentially the
  
  same syntax as the extra information in slice headers) has simply been
  
  forgotten. This meant that if this extra information was present, it was
  
  discarded during reading ; and unfortunately writing created invalid
  
  bitstreams in this case (an extra_bit_picture - the last set bit of the
  
  whole unit - indicated that there would be a further byte of data,
  
  although the output didn't contain said data).
  This has been fixed ; both types of extra information are now parsed via
  
  the same code and essentially passed through.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/cbs_mpeg2.c
  • [DH] libavcodec/cbs_mpeg2.h
  • [DH] libavcodec/cbs_mpeg2_syntax_template.c

• ffmpeg intensity histogram adjustment

  30 septembre 2016, par jlarsch

  I am using ffmpeg for background correction of a video and I would like to improve the intensity scaling of the output.

  My gray scale videos have dark moving objects on a light background. In 8 bit pixel intensities, the light background has pixel values around 240, the dark objects have intensities of around 120.

  outside of ffmpeg, I generate a background image by taking the median frame over some number of frames.
  Then, I use ffmpeg to blend/divide each frame by the background image. (I want to use division, not subtraction of the background).
  [there is also some cropping in my ffmpeg command, but it is irrelevant to my question]

  'ffmpeg.exe', '-i', u'inputVideo.avi', '-i', u'bgMed.tif', '-y', '-r', '160', '-filter_complex', "[1:0] setsar=sar=1 [1sared]; [0:0][1sared] blend=all_mode='divide':repeatlast=1,format=gray,split=1 [int1];[int1]crop=1097:1097:12:11:[out1]", '-map', '[out1]', '-c:v', 'libxvid', '-q:v', '5', '-g', '10', u'outputVideo'

  This procedure is basically working but the resulting video frames look too washed out. This is probably expected ? I am guessing ffmpeg does the division and produces an internal float result which it then maps back to an 8 bit output. I would like to stretch the histogram of the result from the division. It would be preferable to stretch before the mapping to 8 bit for a finer dynamic range.

  In my example, I am assuming that the background division produces a result frame that has a value close to 1 for the background, and values close to 0.5 for the dark objects. Then, ffmpeg seems to be mapping the full range 0-1 into 8 bit 0-255. I would like it to map the range 0.5-1 of the division result into the 8 bit range of the output. is this possible somehow ? Or how else can I achieve a similar result ?