Recherche avancée

Sur d’autres sites (10647)

• Q.For encoding error of ffmpeg

  21 mars 2016, par 社畜根性

  I ran the following command.

  ffmpeg -i test.mp4 -threads 2 -codec:v libx264 -s:v 1280x720 -aspect:v 16:9 -b:v 256k -map 0 -f segment -segment_format mpegts -segment_time 10 -segment_list stream.m3u8 streamfiles/stream%03d.ts

  Execution result

  ffmpeg version N-75926-gce0834b Copyright (c) 2000-2015 the FFmpeg developers
  
    built with gcc 4.6 (Debian 4.6.3-14+rpi1)
  
    configuration: --arch=armel --target-os=linux --enable-shared --enable-gpl --enable-libx264 --enable-nonfree
  
    libavutil      55.  3.100 / 55.  3.100
  
    libavcodec     57.  5.100 / 57.  5.100
  
    libavformat    57.  3.100 / 57.  3.100
  
    libavdevice    57.  0.100 / 57.  0.100
  
    libavfilter     6. 11.100 /  6. 11.100
  
    libswscale      4.  0.100 /  4.  0.100
  
    libswresample   2.  0.100 /  2.  0.100
  
    libpostproc    54.  0.100 / 54.  0.100
  
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mp4':
  
    Metadata:
  
      major_brand     : isom
  
      minor_version   : 512
  
      compatible_brands: isomiso2avc1mp41
  
      encoder         : Lavf56.40.100
  
    Duration: 00:00:03.28, start: 0.000000, bitrate: 10159 kb/s
  
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 10156 kb/s, 25 fps, 25 tbr, 1200k tbn, 2400k tbc (default)
  
      Metadata:
  
        handler_name    : VideoHandler
  
  Illegal instruction

  The result is that an error occurred.
  Someone told me that it’s an error if you do not put the option to ./configure of libx264. That option is the --extra-cflags='-march=armv6' --extra-ldflags='-march=armv6'. Otherwise it would use the instruction of unsupported.

  So I ran ./configure with the option, then I ran the make and now I’m getting an error message :

  common/arm/quant-a.S: Assembler messages:
  
  common/arm/quant-a.S:362: Error: selected processor does not support ARM mode `rbit r1,r1'
  
  common/arm/quant-a.S:363: Error: selected processor does not support ARM mode `rbit r1,r1'
  
  Makefile:217: recipe for target 'common/arm/quant-a.o' failed
  
  make: *** [common/arm/quant-a.o] Error 1

  I do not know the meaning of this error. How should you deal me this error ?

  I use the machine is Raspberry PI B+ and my OS is Raspbian. I want to use ffmpeg and libx264.

  Any advice and suggestions will be greatly appreciated.

• avutil/cpu_internal : Fix check for SSE2SLOW

  15 juin 2022, par Andreas Rheinhardt

  avutil/cpu_internal : Fix check for SSE2SLOW
  For SSE2 and SSE3, there are four states that the two flags
  
  involved (AV_CPU_FLAG_SSE[23] and AV_CPU_FLAG_SSE[23]SLOW) can convey.
  
  When ordered from worst to best they are :
  
  1. both flags unset (SSE[23] unavailable)
  
  2. the slow flag set, the ordinary flag unset (this is designed
  
  for cases where SSE2 is available, but so slow that MMX(EXT)/SSE
  
  code is usually faster)
  
  3. both flags set (SSE2 is available, but there might be scenarios
  
  where MMX(EXT)/SSE code is faster)
  
  4. the ordinary flag set, the slow flag unset (this is the normal case)
  The ordinary macros for checking cpuflags return true
  
  in the latter two cases ; the fast macros only return true for
  
  the latter case. Yet the macros to check for slow currently
  
  only return true in case three.
  This seems unintended. In fact, the only uses of the slow macros
  
  are all of the form
  
  if (EXTERNAL_SSE2(cpu_flags) || EXTERNAL_SSE2_SLOW(cpu_flags))
  
  where the check for EXTERNAL_SSE2_SLOW is completely redundant.
  
  Even more importantly, it is not what was intended. Before
  
  6369ba3c9cc74becfaad2a8882dff3dd3e7ae3c0, the checks passed
  
  in cases 2 to 4. Said commit changed this to something that
  
  only passes for the third case. Commits
  
  7fb758cd8ed08e4a37f10e25003953d13c68b8cd and
  
  c1913064e38cb338039f29c280a0dacc3fd1e451 restored the old behaviour,
  
  yet merging 4efab89332ea39a77145e8b15562b981d9dbde68 (in commit
  
  ac774cfa571734c49c26e2d3387adccff8957ff8) broke this again
  
  by changing it to what it is now.*
  This commit changes the macros to make the slow macros check
  
  whether a specific instruction is supported, even if slow.
  
  This restores the intended meaning to all uses of the SLOW macros
  
  and is generally more natural.
  * : Libav only checks for EXTERNAL_SSE2_SLOW, i.e. for the third case
  
  only.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavutil/cpu_internal.h

• avformat/sccdec : Don't use uninitialized data, fix crash, simplify logic

  1er octobre 2021, par Andreas Rheinhardt

  avformat/sccdec : Don't use uninitialized data, fix crash, simplify logic
  Up until now, the scc demuxer not only read the line that it intends
  
  to process, but also the next line, in order to be able to calculate
  
  the duration of the current line. This approach leads to unnecessary
  
  complexity and also to bugs : For the last line, the timing of the
  
  next subtitle is not only logically indeterminate, but also
  
  uninitialized and the same applies to the duration of the last packet
  
  derived from it.* Worse yet, in case of e.g. an empty file, it is not
  
  only the duration that is uninitialized, but the whole timing as well
  
  as the line buffer itself.** The latter is used in av_strtok(), which
  
  could lead to crashes. Furthermore, the current code always outputs
  
  at least one packet, even for empty files.
  This commit fixes all of this : It stops using two lines at a time ;
  
  instead only the current line is dealt with and in case there is
  
  a packet after that, the duration of the last packet is fixed up
  
  after having already parsed it ; consequently the duration of the
  
  last packet is left in its default state (meaning "unknown/up until
  
  the next subtitle"). If no further line could be read, processing
  
  is stopped ; in particular, no packet is output for an empty file.
  * : Due to stack reuse it seems to be zero quite often ; for the same
  
  reason Valgrind does not report any errors for a normal input file.
  
  ** : While ff_subtitles_read_line() claims to always zero-terminate
  
  the buffer like snprintf(), it doesn't do so if it didn't read anything.
  
  And even if it did, it would not necessarily help here : The current
  
  code jumps over 12 bytes that it deems to have read even when it
  
  hasn't.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavformat/sccdec.c