Recherche avancée

Sur d’autres sites (13143)

• How to get Updated Shared Object Files of OpenCV and FFMPEG libraries to overcome Libpng vulnerability ? [duplicate]

  3 mars 2017, par Liya

  This question already has an answer here :

  • Libpng vulnerability
    
    2 answers
    

  We seek a technical help on a current issue which we are facing with one of our android application.

  Our application is for live video streaming and recording (both audio and video) using wifi camera . We have completed the development process and every functionality of the application is working as expected in current version. but once we tried to upload the application to Google has rejected the application stating that vulnerability issue with Libpng library version.

  Our application uses OpenCV, FFMPEG, JavaCV and JavaCPP libraries for Image processing for Video generation. But when we tried to upload to play store google have rejected application with following message :

  “ Hello Google Play Developer,

  We rejected Application name, for violating our Malicious Behavior or
  User Data policy. If you submitted an update, the previous version of
  your app is still available on Google Play.

  This app uses software that contains security vulnerabilities for
  users or allows the collection of user data without proper disclosure.

  Below is the list of issues and the corresponding APK versions that
  were detected in your recent submission. Please upgrade your app(s) as
  soon as possible and increment the version number of the upgraded APK.

  Vulnerability APK Version(s) Libpng library

  The vulnerabilities were fixed in libpng v1.0.66, v.1.2.56, v.1.4.19,
  v1.5.26 or higher. You can find more information about how resolve the
  issue in this Google Help Center article.”

  Since we have not used libpng library directly in our application we assume the problem is with opencv lib version which may be using libpng , so we replaced the opencv jar file with its gradle dependency and .so files of different libraries are combined in an armeabi.jar file and once we deleted the .so files from libs/armeabi.jar folder and uploaded to play store, then Google didn’t rejected with vulnerability issue and it got uploaded to the play store but the recording isn’t working in that version because we have removed the .SO files from the Project.

  So as per our assumptions the libpng vulnerability is not only due to opencv but also due to the other libraries or the .so files .So please kindly suggest us which all .SO files we can remove from the library , so our application functionality for video recording works properly .

  We tried to update the OpenCV, FFMPEG libraries and since the SO files are not getting regenerated so could not resolve this issue yet

  We already refer following links to find a solution :

  1. libpng-vulnerability

  2. opencv-in-android

  3. FFmpegAndroid

  For more information please read our stackover flow post regarding this issue :Libpng vulnerability

  We need help to solve this issue. Please let us know if you can help us to solve this issue since we are running out of time.

  PS : These are the assumptions we made on this issue, May be we are wrong , so please guide us to the right path so we can achieve our goal.

• Dreamcast Track Sizes

  1er mars 2015, par Multimedia Mike — Sega Dreamcast

  I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.

  You know what’s weird about these discs ? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.

  The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph) :

  
  
  

  Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation ? Why would the data track be split in 2 pieces like that ?

  I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.

  One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.

• avcodec/hap : add "compressor" option to Hap encoder to disable secondary compression

  8 novembre 2016, par Tom Butterworth

  avcodec/hap : add "compressor" option to Hap encoder to disable secondary compression
  The secondary compression in Hap is optional, this change exposes that option to
  
  the user as some use-cases favour higher bitrate files to reduce workload
  
  decoding.
  
  Adds "none" or "snappy" as options for "compressor". Selecting "none" disregards
  
  "chunks" option : chunking is only of benefit decompressing Snappy.
  Reviewed-by : Martin Vignali <martin.vignali@gmail.com>
  
  Signed-off-by : Tom Butterworth <bangnoise@gmail.com>
  

  • [DH] libavcodec/hap.h
  • [DH] libavcodec/hapenc.c