Recherche avancée

Sur d’autres sites (6244)

• Proper reading of MP3 file disrupted by ID3 tags

  3 septembre 2016, par PookyFan

  My semestral project is due this Thursday and I have major problem with reading MP3 file (the project is about sound analysis, don’t ask my what exactly is it about and why I’m doing it so late).

  First, I read first 10 bytes to check for ID3 tags. If they’re present, I’ll just skip to the first MP3 header - or at least that’s the big idea. Here is how I count ID3 tag size :

  if (inbuf[0] == 'I' && inbuf[1] == 'D' && inbuf[2] == '3') //inbuf contains first 10 bytes from file
  
  {
  
      int size = inbuf[3] * 2097152 + inbuf[4] * 16384 + inbuf[5] * 128 + inbuf[6]; //Will change to binary shifts later
  
      //Do something else with it - skip rest of ID3 tags etc
  
  }

  It works ok for files without ID3 tags and for some files with them, but for some other files ffmpeg (which I use for decoding) returns "no header" error, which means it didn’t catch MP3 header correctly. I know that since if I remove ID3 from that .mp3 file (with Winamp for example), no errors occur. The conclusion is that size count algorithm isn’t always valid.

  So the question is : how do I get to know how big exactly is entire ID3 part of the .mp3 file (all possible tags, album picture and whatever) ? I’m looking for it everywhere but I just keep finding this algorithm I posted above. Sometimes also something about some 10 bytes footer I need to take into account, but it seems it frequently gets more than 10 bytes for it to eventually catch proper MP3 frame.

• Why is the library built for armv7 even though I set -march=armv6 ?

  13 juillet 2018, par Luca Carlon

  I’m trying to build libx264 for armv6, but what I get seems to be built for armv7. I’m using this configure line :

  ./configure --host=arm-linux-gnueabihf --enable-static --cross-prefix=${CCPREFIX} --prefix=... --extra-cflags='-march=armv6' --extra-ldflags='-march=armv6' --extra-asflags='-march=armv6'

  which results in an output like this :

  [...]
  
  arm-linux-gnueabihf-gcc -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math  -Wall -I. -I. -march=armv6 -std=gnu99 -D_GNU_SOURCE -fomit-frame-pointer -fno-tree-vectorize   -c -o common/opencl.o common/opencl.c
  
  arm-linux-gnueabihf-gcc -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math  -Wall -I. -I. -march=armv6 -std=gnu99 -D_GNU_SOURCE -fomit-frame-pointer -fno-tree-vectorize   -c -o encoder/slicetype-cl.o encoder/slicetype-cl.c
  
  arm-linux-gnueabihf-gcc -I. -I. -march=armv6 -c -DSTACK_ALIGNMENT=4 -DHIGH_BIT_DEPTH=0 -DBIT_DEPTH=8 -o common/arm/cpu-a.o common/arm/cpu-a.S
  
  [...]

  now this is what I see :

  $ readelf -A x264
  
  Attribute Section: aeabi
  
  File Attributes
  
    Tag_CPU_name: "7-A"
  
    Tag_CPU_arch: v7
  
    Tag_CPU_arch_profile: Application
  
    Tag_ARM_ISA_use: Yes
  
    Tag_THUMB_ISA_use: Thumb-2
  
    Tag_FP_arch: VFPv3
  
    Tag_Advanced_SIMD_arch: NEONv1
  
    Tag_ABI_PCS_wchar_t: 4
  
    Tag_ABI_FP_denormal: Needed
  
    Tag_ABI_FP_exceptions: Needed
  
    Tag_ABI_FP_number_model: IEEE 754
  
    Tag_ABI_align_needed: 8-byte
  
    Tag_ABI_enum_size: int
  
    Tag_ABI_HardFP_use: Deprecated
  
    Tag_ABI_VFP_args: VFP registers
  
    Tag_CPU_unaligned_access: v6
  
    Tag_DIV_use: Not allowed

  also I see this :

  $ readelf -A encoder/slicetype-cl.o
  
  Attribute Section: aeabi
  
  File Attributes
  
    Tag_CPU_name: "6"
  
    Tag_CPU_arch: v6
  
    Tag_ARM_ISA_use: Yes
  
    Tag_THUMB_ISA_use: Thumb-1
  
    Tag_FP_arch: VFPv2
  
    Tag_ABI_PCS_wchar_t: 4
  
    Tag_ABI_FP_number_model: Finite
  
    Tag_ABI_align_needed: 8-byte
  
    Tag_ABI_align_preserved: 8-byte, except leaf SP
  
    Tag_ABI_enum_size: int
  
    Tag_ABI_HardFP_use: Deprecated
  
    Tag_ABI_VFP_args: VFP registers
  
    Tag_ABI_optimization_goals: Aggressive Speed
  
    Tag_CPU_unaligned_access: v6

  but :

  $ readelf -A common/arm/cpu-a.o
  
  Attribute Section: aeabi
  
  File Attributes
  
    Tag_CPU_name: "7-A"
  
    Tag_CPU_arch: v7
  
    Tag_CPU_arch_profile: Application
  
    Tag_ARM_ISA_use: Yes
  
    Tag_THUMB_ISA_use: Thumb-2
  
    Tag_FP_arch: VFPv3
  
    Tag_Advanced_SIMD_arch: NEONv1

  Can someone explain why those commands seem to output an armv6 binary once but an armv7 binary in the other case ? May that be the reason why the resulting binary is marked as armv7 ?
  Thank you for any explanation.

• configure : arm : Don't add -march= to the compiler if no preference was passed

  20 septembre 2021, par Martin Storsjö

  configure : arm : Don't add -march= to the compiler if no preference was passed
  If no —cpu= option was passed to configure, we detect what the
  
  compiler defaults to. This detected value was then fed back to the
  
  rest of the configure logic, as if it was an explicit choice.
  This breaks on Ubuntu 21.10 with GCC 11.1.
  Since GCC 8, it's possible to add configure extra features via the
  
   march option, like e.g. -march=armv7-a+neon. If the -mfpu= option
  
  is configured to default to 'auto', the fpu setting gets taken
  
  from the -march option.
  GCC 11.1 in Ubuntu seems to be configured to use -mfpu=auto. This
  
  has the effect of breaking any compilation command that specifies
  
   march=armv7-a, because the driver implicitly also adds -mfloat-abi=hard,
  
  and that combination results in this error :
      cc1 : error : ‘-mfloat-abi=hard’ : selected processor lacks an FPU
  One can compile successfully by passing e.g. -march=armv7-a+fp.
  Therefore, restructure configure. If no specific preference was set
  
  (and the 'cpu' configure variable was set as the output of
  
  probe_arm_arch), the value we tried to set via -march= was the same
  
  value that we just tried to detect as the compiler default.
  So instead, just try to detect what the compiler defaults to, with
  
  to allow setting other configure settings (such as 'fast_unaligned'),
  
  but don't try to spell out the compiler's default via the -march flag.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] configure