Recherche avancée

Sur d’autres sites (3788)

• libFLAC : More metadata_iterators fixes

  22 mai 2016, par Erik de Castro Lopo

  libFLAC : More metadata_iterators fixes
  The previous fixes for metadata_iterators didn’t completely fix the problem.
  The behavior of chain_prepare_for_write_() must always be the same as the
  
  behavior of FLAC__metadata_chain_check_if_tempfile_needed(). Before this
  
  fix, one check was missing in FLAC__metadata_chain_check_if_tempfile_needed(),
  
  and also chain_prepare_for_write_() checked the sizes of the metadata blocks
  
  *after* making the changes to the chain, while
  
  FLAC__metadata_chain_check_if_tempfile_needed() does it *before* the changes.
  This patch changes FLAC__metadata_chain_check_if_tempfile_needed() so that it
  
  keeps some info (lbs_state, lbs_size) about estimated changes and then uses
  
  it to check the block sizes.
  It also simplifies FLAC__metadata_chain_check_if_tempfile_needed() a little.
  Patch-from : lvqcl <lvqcl.mail@gmail.com>
  

  • [DH] src/libFLAC/metadata_iterators.c

• Could there be an unexpected collision of MS VC runtimes ?

  25 mai 2016, par sharpener

  I have learned the hard way, it’s not very good to share heap pointers between two dlls who each depends on different MS VC runtime. Fair enough. Based on this experience and current weird behavior of a program chain being debugged I would like to ask a

  Question :

  Could lib1.dll using one runtime (eg. msvcrt.dll) possibly damage heap of lib2.dll using different runtime (eg. vcruntime140d.dll) ? No pointers shared, just pairs of malloc/free on the same runtime.

  Background : (for those who would ask for it)

  • I have standard zeranoe ffmpeg libraries dependent on msvcrt.dll.
  • I created small C dll covering required functionality based on those ffmpeg libs, let’s call it libvideo.dll. It’s dependent on VS2015 runtime.
  • I created libvideosharp.dll a managed C# wrapper library (also VS2015) for libvideo.dll (marshalling).
  • I created C# test app using the libvideosharp.dll (also VS2015).
  • Debugging the C# test app (and associated libraries in the chain) I experience following :
    1. libvideo.dll mallocs and inits a data structure.
    2. libvideo.dll calls some ffmpeg init routines (av_register_all, avformat_network_init) which might malloc on its own runtime.
    3. libvideo.dll’s data structure is corrupted (not even passed to ffmpeg libs in any way, just independent malloced block).

• Configure ffmpeg to work with native client

  11 juin 2016, par Mohammad Abu Musa

  I followed the steps https://chromium.googlesource.com/webports/+/master to port ffmpeg to native client. I do not know what is the issue here. here are the configuration and here what I get

  NACL_ARCH=pnacl TOOLCHAIN=pnacl make ffmpeg

  Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\@anchor{ <-- HERE (?:[^\}]*)\}/ at /home/user/Desktop/webports/src/out/build/ffmpeg/ffmpeg-2.6.1/doc/texi2pod.pl line 387.
MAN doc/ffmpeg.1
MAN doc/ffprobe.1
MAN doc/ffmpeg-all.1
MAN doc/ffprobe-all.1
LD  ffmpeg_g
LD  ffprobe_g
/home/user/Desktop/webports/src/out/build/ffmpeg/ffmpeg-2.6.1/Makefile:124: recipe for target 'ffprobe_g' failed
make[1]: *** [ffprobe_g] Error 247
make[1]: *** Waiting for unfinished jobs....
/home/user/Desktop/webports/src/out/build/ffmpeg/ffmpeg-2.6.1/Makefile:124: recipe for target 'ffmpeg_g' failed
make[1]: *** [ffmpeg_g] Error 247
make[1]: Leaving directory '/home/user/Desktop/webports/src/out/build/ffmpeg/build_pnacl'
webports: Build failed: 'ffmpeg' [pnacl/release]
Makefile:89: recipe for target 'ffmpeg' failed
make: *** [ffmpeg] Error 1