Recherche avancée

Sur d’autres sites (7583)

• Modifying incorrect h.264 dimension in existing video file

  11 juin 2015, par RichyJ

  After searching a lot, I’m more confused than ever !! To summarise :

  I recorded a video using my HTC One M8, using 1920x1088 resolution, and it came out fine. The next day, for some reason, in the settings I changed to 1920x1080 and the next video was weird - green bar across the top, diagonal green lines throughout and odd colour stripes. The underlying image was fine, although there seem to be some ’frame jumps’ at times. Unfortunately, this second video contained a section I would like to keep, so I’m trying to fix it...

  I’ve learned a bit about AVC/H.264, but it’s pretty confusing. Essentially, I wonder whether I can just change the ’1080’ in the file info to ’1088’ and salvage the footage - there’s no audio to worry about. I read that since 1080 is not directly divisible by 16, most encoders actually do 1088 then the player discards the remaining 8 lines at playback time. I wonder whether this is the root of the problem ? I tried to get into NALs, SPS/PPS etc, but couldn’t really fathom whether this was even relevant to my problem. A hex search didn’t even find anything that looked like the NALs given as examples elsewhere :

  Finding SPS/PPS data strings

  What does this NAL header data mean ?

  Fetching dimensions of a video

  I’ve loaded both files into a Hex editor and compared as best I can (around the moov and avcC parts), but haven’t fixed it yet. One of the single byte changes I made and saved to a new ’test’ file brought up additional info in the mediainfo program, showing that the original recording was at 1088 - this hadn’t been there before, but it still played wrongly. I found info regarding the encoding of height and width (units-1 * 16) but couldn’t work out how to use this info in practice.

  I tried ffmpeg and dumping to raw video, but couldn’t make this play at all as a yuv file.

  So, my question is, will I be able to change just one byte (or a few) in the file, to make it read as 1088 to the player, or am I looking in totally the wrong direction ?!? Is this even possible ? As I say, the actual images look intact throughout, just the colours are wrong and the lines are there, so I believe it’s something to do with YCrCb problems, but at this point, I’m lost...

  I know this isn’t specifically about programming, but the above links were all from this site, so thought it might be OK to ask here. Any help would be much appreciated !!

  I’ve recreated the conditions and done 2 short clips at 1080 and 1088 for you to see the problem but as I’m new, I can’t post them here yet. They’re on my Photobucket page if you are willing to look at them (hope this isn’t breaking the rules !!). The blueish line at the bottom is the windowsill...

  1088 still

  1080 still

• Android NDK - ffmpeg header files not found by compiler

  7 septembre 2015, par markt

  I am trying to use the ffmpeg libraries with Android NDK in the experimental plugin.

  I am attempting to compile this example :
  https://github.com/roman10/android-ffmpeg-tutorial/blob/master/android-ffmpeg-tutorial01/jni/tutorial01.c

  My problem is that the header files are not being found by the compiler :

  Error:(13, 32) libavcodec/avcodec.h: No such file or directory

  I added flags to build.grade :

  cppFlags += "-ilibavcodec -ilibavutil -ilibavformat -ilibswscale"
  
  ldFlags += "-llibavcodec -llibavutil -llibavformat -llibswscale"

  Which seems to keep lint happy, but not the compiler. (Not sure if I have done this right ?)

  I Have added the header files to the /jni folder :
  

  And build.grade looks like this :

  apply plugin: 'com.android.model.application'
  
  model {
  
      android {
  
          compileSdkVersion = 23
  
          buildToolsVersion = "23.0.1"
  
  
  
          defaultConfig.with { 
  
              applicationId = "roman10.tutorial.android_ffmpeg_tutorial01"
  
              minSdkVersion.apiLevel = 10
  
              targetSdkVersion.apiLevel = 23
  
  
  
          }
  
      }
  
  
  
      compileOptions.with {
  
          sourceCompatibility = JavaVersion.VERSION_1_7
  
          targetCompatibility = JavaVersion.VERSION_1_7
  
      }
  
  
  
      android.buildTypes {
  
          release {
  
              minifyEnabled = false
  
              proguardFiles += file('proguard-rules.pro')
  
          }
  
      }
  
  
  
  
  
      android.ndk {
  
          moduleName = "tutorial01"
  
          ldLibs += ["android","log","jnigraphics","z"]
  
          cppFlags += "-ilibavcodec -ilibavutil -ilibavformat -ilibswscale"
  
          ldFlags += "-llibavcodec -llibavutil -llibavformat -llibswscale"
  
      }
  
  }
  
  
  
  dependencies {
  
      compile fileTree(dir: 'libs', include: ['*.jar'])
  
      compile 'com.android.support:support-v4:23.0.1'
  
  }

  Thanks.

• common.mak : Use CCFLAGS for assembly generation as well

  2 décembre 2015, par Timothy Gu

  common.mak : Use CCFLAGS for assembly generation as well
  CCFLAGS is equivalent to CPPFLAGS + CFLAGS, and it is already being used
  
  by other make rules like %.i and %.o. Simplifies common.mak.
  

  • [DH] common.mak