Recherche avancée

Sur d’autres sites (10687)

• CMTimeGetSeconds doesn't get the right video duration

  26 février 2015, par JLCastillo

  some users don’t get the right duration of videos they capture with their own device. The funny thing is others do actually see it right, using the same device models and OS version. Anyway, we observed it in a iPhone 5c 7.1.2 and an iPhone 5s 8.1.3.

  This code works for most users, but not all :

  ALAssetRepresentation *representation = [mediaObject.asset defaultRepresentation];
  
  NSURL *url = [representation url];
  
  NSDictionary *options = @{ AVURLAssetPreferPreciseDurationAndTimingKey : @YES };
  
  AVAsset *avAsset = [AVURLAsset URLAssetWithURL:url options:options];
  
  videoDurationTime = CMTimeGetSeconds(avAsset.duration);

  I asked them to send the input videos, and this is the output from "ffmpeg -i"

  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bug_duration1.MOV':
  
    Metadata:
  
      major_brand     : qt
  
      minor_version   : 0
  
      compatible_brands: qt
  
      creation_time   : 2015-02-23 08:30:01
  
      encoder         : 8.1.3
  
      encoder-eng     : 8.1.3
  
      date            : 2015-02-23T16:30:01+0800
  
      date-eng        : 2015-02-23T16:30:01+0800
  
      model           : iPhone 5s
  
      model-eng       : iPhone 5s
  
      make            : Apple
  
      make-eng        : Apple
  
    Duration: 00:00:03.67, start: 0.000000, bitrate: 16793 kb/s
  
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080, 16719 kb/s, 29.99 fps, 29.97 tbr, 600 tbn, 1200 tbc (default)
  
      Metadata:
  
        creation_time   : 2015-02-23 08:30:01
  
        handler_name    : Core Media Data Handler
  
        encoder         : H.264
  
      Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 61 kb/s (default)
  
      Metadata:
  
        creation_time   : 2015-02-23 08:30:01
  
        handler_name    : Core Media Data Handler

  The video is detected with a duration of several minutes. Did anybody face this problem before ?

  Thanks in advance.

• fftools/ffmpeg_dec : move decoding to a separate thread

  2 juin 2023, par Anton Khirnov

  fftools/ffmpeg_dec : move decoding to a separate thread
  This is only a preparatory step to a fully threaded architecture and
  
  does not yet make decoding truly parallel - the main thread will
  
  currently submit a packet and wait until it has been fully processed by
  
  the decoding thread before moving on. Decoder behavior as observed by
  
  the rest of the program should remain unchanged. That will change in
  
  future commits after encoders and filters are moved to threads and a
  
  thread-aware scheduler is added.
  

  • [DH] fftools/ffmpeg.c
  • [DH] fftools/ffmpeg.h
  • [DH] fftools/ffmpeg_dec.c
  • [DH] fftools/ffmpeg_mux.c

• Merge commit ’d78fd2fa21cde28465e40dd0be4446b1387d22a6’

  14 juillet 2016, par Clément Bœsch

  Merge commit ’d78fd2fa21cde28465e40dd0be4446b1387d22a6’
  * commit ’d78fd2fa21cde28465e40dd0be4446b1387d22a6’ :
  
    Add MagicYUV decoder
  Changes observed from Libav :
  
   many cosmetics (function renames/move, spacing, line breaks)
  
   MagicYUVContext.slices_size is now unsigned
  
   use of pixdesc (include fixed in FFmpeg)
  
   mention of "Lossless" in the long name dropped (also removed from
  
    general.texi in FFmpeg)
  
   addition of the FF_CODEC_CAP_INIT_THREADSAFE caps
  
   use of qsort() instead of AV_QSORT() (NOT MERGED)
  
   use of AVCodecContext.width,height instead of AVCodecContext.coded_width,height (NOT MERGED)
  See also 77f9c4b7aa9eb793b3019025e177245896821816
  Merged-by : Clément Bœsch <u@pkh.me>
  

  • [DH] doc/general.texi
  • [DH] libavcodec/codec_desc.c
  • [DH] libavcodec/magicyuv.c