Recherche avancée

Sur d’autres sites (11974)

• avcodec/mpegvideo : Move [fb]_code to Mpeg4Dec and MPVEncContext

  25 mars, par Andreas Rheinhardt

  avcodec/mpegvideo : Move [fb]_code to Mpeg4Dec and MPVEncContext
  It is only used by the MPEG-4 decoder and the encoders.
  
  Notice that this field is a per-frame property and therefore
  
  does not need to by synced in mpeg4_update_thread_context().
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/motion_est.c
  • [DH] libavcodec/mpeg12enc.c
  • [DH] libavcodec/mpeg4videodec.c
  • [DH] libavcodec/mpeg4videodec.h
  • [DH] libavcodec/mpeg4videoenc.c
  • [DH] libavcodec/mpegvideo.h
  • [DH] libavcodec/mpegvideo_enc.c
  • [DH] libavcodec/mpegvideoenc.h
  • [DH] libavcodec/msmpeg4enc.c
  • [DH] libavcodec/nvdec_mpeg4.c
  • [DH] libavcodec/ratecontrol.c
  • [DH] libavcodec/rv20enc.c
  • [DH] libavcodec/snowenc.c
  • [DH] libavcodec/svq1enc.c
  • [DH] libavcodec/vaapi_mpeg4.c
  • [DH] libavcodec/vdpau_mpeg4.c

• SDL_CreateThread exception thrown in ntdll just in Release mode

  6 avril 2018, par Ogox

  I have the problem that my program builds in both Debug and Release mode, but just the Debug one doesn’t crash.

  The crash in Release mode happens at

  SDL_CreateThread(ReadThread, "ReadThread", videoState);

  where the function basically looks like

  int SDLCALL ReadThread(void* arg) {...}
  
  
  
  static VideoState* OpenStream(/*...*/)
  
  {
  
      VideoState* videoState = (VideoState*)av_mallocz(sizeof(VideoState));
  
  
  
      if (videoState == nullptr)
  
          return nullptr;
  
  
  
      // ...
  
  
  
      videoState->SDLReadThread= SDL_CreateThread(ReadThread, "ReadThread", videoState); // <- Exception Thrown
  
  
  
      if (!videoState->SDLReadThread)
  
      {
  
          // cleanup ...
  
  
  
          return nullptr;
  
      }
  
  
  
      // ...
  
  }

  and the thrown exception looks like

  Exception thrown at 0x77CCE0E6 (ntdll.dll) in MyProgram.exe: 
  
  0xC0000005: Access violation reading location 0x00000044. occurred

  My callstack looks like

  ntdll.dll!77cce0e6()
  
  [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]             
  
  MyProgram.exe!_calloc_impl(unsigned int num, unsigned int size, int * errno_tmp) Line 47                                                                
  
  MyProgram.exe!_calloc_crt(unsigned int count, unsigned int size) Line 61                
  
  MyProgram.exe!_beginthreadex(void * security, unsigned int stacksize, unsigned int(__stdcall*)(void *) initialcode, void * argument, unsigned int createflag, unsigned int * thrdaddr) Line 151 
  
  SDL2.dll!0f39bf71() 
  
  SDL2.dll!0f39ba50() 
  
  SDL2.dll!0f39baff() 
  
  MyProgram.exe!OpenStream(const char *) Line 236 
  
  MyProgram.exe!main(int argCount, char * * args) Line 733    
  
  [External Code]     

  But the thing is, that it works in Debug mode, so the code is probably correct.

  I have an x86 application and link against x86 libs which are all built with the msvc toolchain for VS2010. (I build in VS2017 with v100 toolset)

  I got SDL2 from https://buildbot.libsdl.org/sdl-builds/sdl-visualstudio/?C=M ;O=D and tried out build 3924 and 3939 as well as the version 2.0.8 dll from https://www.libsdl.org/download-2.0.php .

  The is no difference between the libs used for debug and release mode, and there is no distinct debug or release version for these libs (so just one version for both).

  I tried out to change a few settings in the Release property pages, but I have no clue what I have to change to make both builds work.

  EDIT :

  the VideoState is basically this struct from FFmpeg but as a C++ class with member functions (so object oriented).

  the int SDLCALL ReadThread(void* arg) {...} is basically the static int read_thread(void *arg) from FFplay but in C++ and using more OOP

  EDIT2 :

  If ReadThread is defined as

  int SDLCALL ReadThread(void * arg) { return 0; }

  I still get the exception, so the problem is not an uninitialized VideoState* as the arg of the thread

• New cookie behaviour in browsers may cause regressions

  24 février 2020, par Matomo Core Team — Community, Development

  Last year the Chromium browser team announced they would change their default behaviour for cookies. In particular about a property called samesite. Over the last few months, we have made various changes to our cookie handling to get Matomo ready for this. Depending on your setup and the features you use, some things may not work anymore.

  You can avoid most of the issues by using HTTPS on your Matomo, and ideally also use HTTPS on your website(s).

  If you are not running the latest version of Matomo yet (3.13.3 at the time of writing), then we highly recommend that you upgrade as soon as possible. Previous versions are not compatible with these cookie browser changes.

  Opt out screen

  If you embed the opt out screen on your website running on HTTP, there is a chance the Matomo opt out no longer works. In these cases it may still work over http:

  • when the privacy policy page that embeds the opt out screen (via iframe) also has the Matomo JavaScript tracker embedded,
  • and when both the opt out and the JS tracker point to the same Matomo installation.

  In other cases when HTTP is used, the opt out feature will likely be broken.

  We recommend you test whether the opt out on your site still works by opening your privacy policy page in an incognito browser window. Then test to opt out of tracking, and then reload the page. If the checkbox “You are not opted out. Uncheck this box to opt out.” is still ticked, then your opt out is not working.

  If the opt out is not working anymore, it is most likely due to HTTP being used. In that case you should change the opt out URL to HTTPS. For example change from &lt;iframe src=”<strong>http://</strong>…” to &lt;iframe src=”<strong>https://</strong>...” . If your Matomo doesn’t support HTTPS yet, you will need to contact your webhoster or system administrator to get SSL enabled on your Matomo domain.

  JavaScript tracker

  In most cases, everything related to the JavaScript Tracker will still work as expected.

  But there is an edge case : when you are also reading Matomo’s cookie server side. You may be affected by this edge case issue when :

  • you track part of the user behaviour in the browser (using Matomo JS Tracker),
  • and also track user behavior in your server (for example using one of Matomo SDKs in PHP, Java, Python, C#, etc.).

  In that case, for you to still be able to read the so-called visitorId on your server, we recommend you add this line to your JS tracking code :

  _paq.push([‘setSecureCookie’, location.protocol === 'https:']);

  The cookie can be only retrieved if your website is loaded through HTTPS.

  Should you have any questions, or notice anything isn’t working as expected, please visit our forum.

  Third party cookies

  If you are using third party cookies, using HTTPS on your Matomo is now a requirement to make them work across different domains. Otherwise Chrome and in the near future other browsers would not accept the cookie. If you don’t know if you are using third party cookies or first party cookies, you’re likely using first party cookies and this does not affect you.