Recherche avancée

Sur d’autres sites (17115)

• understanding HEVC NAL SEI termination and byte alignment parsing with ffmpeg

  3 mars, par rodeomacon

  The NAL SEI timecode message I am currently writing to file is 00 00 01 4E 01 88 06 XX XX XX XX XX 10 80 (The termination portion being 10 80, payloadSize set to 0x06 and the XX bytes being an encoding of the frames/seconds/minutes/hours).

  


  My goal is to read the timecode with ffmpeg -i video.h265 -c:v copy -bsf:v trace_headers -f null - and ffprobe -show_frames video.mov with no errors.

  


  The 3 left most 0 bits of the final 0x10 byte are the conclusion of the time_offset_length (Equal to 0) data. Following this, I am intending to have a rbsp_stop_one_bit followed by four rbsp_alignment_zero_bits to result in byte alignment.

  


  With this termination configuration (No trailing 0x80 byte and the payloadSize set to 0x05 like 00 00 01 4E 01 88 05 XX XX XX XX XX 10), ffmpeg reports Invalid value at time_offset_length[i]: bitstream ended.

  


  With the addition of the trailing 0x80 byte and changing the payloadSize to 0x06 to match, ffmpeg does not throw a warning but instead indicates there are extra, unused bits :

  


  [trace_headers @ 0000015aff793a80] Prefix Supplemental Enhancement Information
[trace_headers @ 0000015aff793a80] 0           forbidden_zero_bit                                          0 = 0
[trace_headers @ 0000015aff793a80] 1           nal_unit_type                                          100111 = 39
[trace_headers @ 0000015aff793a80] 7           nuh_layer_id                                           000000 = 0
[trace_headers @ 0000015aff793a80] 13          nuh_temporal_id_plus1                                     001 = 1
[trace_headers @ 0000015aff793a80] 16          last_payload_type_byte                               10001000 = 136
[trace_headers @ 0000015aff793a80] 24          last_payload_size_byte                               00000110 = 6
[trace_headers @ 0000015aff793a80] Time Code
[trace_headers @ 0000015aff793a80] 32          num_clock_ts                                               01 = 1
[trace_headers @ 0000015aff793a80] 34          clock_timestamp_flag[0]                                     1 = 1
[trace_headers @ 0000015aff793a80] 35          units_field_based_flag[0]                                   0 = 0
[trace_headers @ 0000015aff793a80] 36          counting_type[0]                                        00000 = 0
[trace_headers @ 0000015aff793a80] 41          full_timestamp_flag[0]                                      1 = 1
[trace_headers @ 0000015aff793a80] 42          discontinuity_flag[0]                                       0 = 0
[trace_headers @ 0000015aff793a80] 43          cnt_dropped_flag[0]                                         0 = 0
[trace_headers @ 0000015aff793a80] 44          n_frames[0]                                         000110101 = 53
[trace_headers @ 0000015aff793a80] 53          seconds_value[0]                                       010010 = 18
[trace_headers @ 0000015aff793a80] 59          minutes_value[0]                                       010100 = 20
[trace_headers @ 0000015aff793a80] 65          hours_value[0]                                          01010 = 10
[trace_headers @ 0000015aff793a80] 70          time_offset_length[0]                                   00000 = 0
[trace_headers @ 0000015aff793a80] 75          bit_equal_to_one                                            1 = 1
[trace_headers @ 0000015aff793a80] 76          bit_equal_to_zero                                           0 = 0
[trace_headers @ 0000015aff793a80] 77          bit_equal_to_zero                                           0 = 0
[trace_headers @ 0000015aff793a80] 78          bit_equal_to_zero                                           0 = 0
[trace_headers @ 0000015aff793a80] 79          bit_equal_to_zero                                           0 = 0
[trace_headers @ 0000015aff793a80] 80          rbsp_stop_one_bit                                           1 = 1
[trace_headers @ 0000015aff793a80] 81          rbsp_alignment_zero_bit                                     0 = 0
[trace_headers @ 0000015aff793a80] 82          rbsp_alignment_zero_bit                                     0 = 0
[trace_headers @ 0000015aff793a80] 83          rbsp_alignment_zero_bit                                     0 = 0
[trace_headers @ 0000015aff793a80] 84          rbsp_alignment_zero_bit                                     0 = 0
[trace_headers @ 0000015aff793a80] 85          rbsp_alignment_zero_bit                                     0 = 0
[trace_headers @ 0000015aff793a80] 86          rbsp_alignment_zero_bit                                     0 = 0
[trace_headers @ 0000015aff793a80] 87          rbsp_alignment_zero_bit                                     0 = 0


  


  Without the bit_equal_to_one, ffmpeg gives a generic error Failed to read unit 0 (type 39) after reading the time_offset_length correctly.

  


  What is the meaning of bit_equal_to_one and bit_equal_to_zero in this context and is this the intended SEI termination method ? Why are those bits not parsed as the alignment bits ?

  


• NDK r8c warning for asm objects regarding "Cortex-A8 erratum" - should I be worried ?

  7 décembre 2012, par Alex Cohn

  Question : What is the meaning of this warning ? If there are no real-life consequences, I can live with it for a while... But I am concerned with what will happen if our program gets loaded on one of the faulty chips.

  Background : With NDK r8c, linking of X264 encoder issues warnings :

  cannot scan executable section 1 of libx264.a(dct-a.o) for Cortex-A8 erratum because it has no mapping symbols

  ... same warning for all assembly files in libx264.

  libx264.a itself was cross-compiled on the same machine with the same 4.6 toolchain taken from NDK.

  Here are the instructions to easily reproduce the problem (Ubuntu or MacOS) :

  1. Download x264-snapshot-20121203-2245 from ftp://ftp.videolan.org/pub/x264/snapshots/last_x264.tar.bz2

  2. Run ./configure --enable-pic --enable-strip --enable-static --cross-prefix=~/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi- --sysroot=~/android-ndk-r8c/platforms/android-14/arch-arm --host=arm-linux

  3. Run ~/android-ndk-r8c/prebuilt/linux-x86/bin/make

  It will build the static library, and after that display the Cortex-A8 warning while linking the x265 executable. I am not worried about the compiler warnings, because building libx264.a is done offline, it is not part of our official daily build.

  I have reported this as http://code.google.com/p/android/issues/detail?id=40794.

  I tried to add the mapping symbols manually to dct-a.S following the ARM.com instructions, but this had no effect.

• Different code(.java file) for different platform ?

  2 mars 2016, par AR792

  I have a code where image data is passed from bitmap to FFmpeg frame recorder and converted to a video. But i need to make small changes while running it on LG G3(armv7) from Asus zenfone 5(x86).

  Following are the class variables that create the issue :(declared under, class Main Activity)

  inputWidth = 1024 ;

  inputHeight = 650 ;

  Following is the method where the issue occurs :

   byte [] getNV21(int inputWidth, int inputHeight, Bitmap bitmap) {
  
  
  
      int [] argb = new int[inputWidth * inputHeight];
  
  
  
      bitmap.getPixels(argb, 0, inputWidth, 0, 0, inputWidth, inputHeight);
  
  
  
      byte [] yuv = new byte[inputWidth*inputHeight*3/2];
  
      encodeYUV420SP(yuv, argb, inputWidth, inputHeight);
  
  
  
      return yuv;
  
  }
  
  
  
  void encodeYUV420SP(byte[] yuv420sp, int[] argb, int width, int height) {
  
      final int frameSize = width * height;
  
  
  
      int yIndex = 0;
  
      int uvIndex = frameSize;
  
  
  
      int a, R, G, B, Y, U, V;
  
      int index = 0;
  
      for (int j = 0; j < height; j++) {
  
          for (int i = 0; i < width; i++) {
  
  
  
              a = (argb[index] & 0xff000000) >> 24; // a is not used obviously
  
              R = (argb[index] & 0xff0000) >> 16;
  
              G = (argb[index] & 0xff00) >> 8;
  
              B = (argb[index] & 0xff) >> 0;
  
  
  
              // well known RGB to YUV algorithm
  
              Y = ( (  66 * R + 129 * G +  25 * B + 128) >> 8) +  16;
  
              U = ( ( -38 * R -  74 * G + 112 * B + 128) >> 8) + 128;
  
              V = ( ( 112 * R -  94 * G -  18 * B + 128) >> 8) + 128;
  
  
  
              // NV21 has a plane of Y and interleaved planes of VU each sampled by a factor of 2
  
              //    meaning for every 4 Y pixels there are 1 V and 1 U.  Note the sampling is every other
  
              //    pixel AND every other scanline.
  
              yuv420sp[yIndex++] = (byte) ((Y < 0) ? 0 : ((Y > 255) ? 255 : Y));
  
              if (j % 2 == 0 && index % 2 == 0) {
  
                  yuv420sp[uvIndex++] = (byte)((V<0) ? 0 : ((V > 255) ? 255 : V));
  
                  yuv420sp[uvIndex++] = (byte)((U<0) ? 0 : ((U > 255) ? 255 : U));
  
              }
  
  
  
              index ++;
  
          }
  
      }
  
  }

  Working CODE :

  LG G3 :I can use the above variables at any place in the code to get the required output.
  Bitmap size returned = 2734200

  Asus Zenfone 5 : Except at creating the bitmap, I have to use everywhere else bitmap.getHeight() and bitmap.getWidth(), to get the required output.

  Surprisingly here Bitmap size returned = 725760 (So its not setting according to set bitmap parameters ?)

  INCORRECT CODE :

  LG G3 : IF i use bitmap.getHeight() and bitmap.getWidth(), i get java.lang.ArrayIndexOutOfBoundsException : length = 102354 , index = 102354. @getNV21 method

  Asus Zenfone 5 : If i use inputWidth , inputHeight i get
  java.lang.IllegalArgumentException : x + width must be <= bitmap.width() @getNV21 method

  How can i generalize the above code for both phones ?