Recherche avancée

Sur d’autres sites (9065)

• Slowing down 960 fps video with ffmpeg (setpts is not working)

  7 novembre 2016, par haridsv

  I am trying to slow down a video recorded on an Android phone at 960fps. I found a lot of previous posts and blogs that all basically say the same thing, that you need to change the "presentation timestamp" (pts). I also found the official documentation that is saying the same thing. The command-line basically looks like this :

  ffmpeg -i input.mp4 -filter:v "setpts=4*PTS" -r 30 -y output.mp4

  I copied the video file using Android Filter Transfer and when I use the above command-line, it works to slow it down, but the resulting output is choppy. The output of the ffmpeg also indicates that it is duplicating the frames :

  frame=  687 fps=103 q=-1.0 Lsize=    4454kB time=00:00:22.80 bitrate=1600.1kbits/s dup=515 drop=0 speed=3.42x

  Running ffprobe on the file shows this :

  ffprobe version 3.1.1 Copyright (c) 2007-2016 the FFmpeg developers
  
    built with Apple LLVM version 7.3.0 (clang-703.0.31)
  
    configuration: --prefix=/usr/local/Cellar/ffmpeg/3.1.1 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-lda
  
    libavutil      55. 28.100 / 55. 28.100
  
    libavcodec     57. 48.101 / 57. 48.101
  
    libavformat    57. 41.100 / 57. 41.100
  
    libavdevice    57.  0.101 / 57.  0.101
  
    libavfilter     6. 47.100 /  6. 47.100
  
    libavresample   3.  0.  0 /  3.  0.  0
  
    libswscale      4.  1.100 /  4.  1.100
  
    libswresample   2.  1.100 /  2.  1.100
  
    libpostproc    54.  0.100 / 54.  0.100
  
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'VID_20161030_213810.mp4':
  
    Metadata:
  
      major_brand     : mp42
  
      minor_version   : 0
  
      compatible_brands: isommp42
  
      creation_time   : 2016-10-30 16:08:14
  
      location        : +17.3874+078.3395/
  
      location-eng    : +17.3874+078.3395/
  
      com.android.version: 6.0.1
  
      com.android.capture.fps: 120.000000
  
    Duration: 00:00:05.73, start: 0.000000, bitrate: 14991 kb/s
  
      Stream #0:0(eng): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p, 1280x720, 13859 kb/s, SAR 1:1 DAR 16:9, 30 fps, 30 tbr, 90k tbn, 180k tbc (default)
  
      Metadata:
  
        creation_time   : 2016-10-30 16:08:14
  
        handler_name    : VideoHandle

  This seems to detect that the video is 30 fps instead of 960 fps, which is probably why it is filling in with duplicate frames instead of using the existing frames.

  I recording the video on Lenovo Z2 Plus (AKA Zuk Z2). If I playback the video using the built-in player at a slow speed it looks extremely smooth, so the frames are definitely there. Could someone help me figure out the right way ? The file is available here (about 10MB), in case someone would like to try it.

  Update : Video playback at slo-mo on the phone recorded with another phone. Notice how smooth and slow the sparks are thrown around, which is impossible if the original video is 30fps.

  • Slow-mo clip 1
  • Slow-mo click 2
  • Full video played in slow-mo (47s, probably at 120fps)

• Tools/Techniques for investigating video corruption — ffmpeg / libavcodec

  17 juillet 2013, par Gopherkhan

  In my current work I'm trying to encode some images to h264 video using the FFMPEG's C library. The resulting video plays fine in VLC, but has no preview image. The video can play in VLC and Mplayer on ubuntu, but won't play on Mac or PC (in fact, it causes a "VTDecoderXPCService quit unexpectedly" error on Mac).

  If I run the resulting file through FFMPEG using the command line, the resulting file has a preview image, and plays correctly everywhere.

  Apparently the file that I get out of the program is corrupt in some weird place, but I don't have any output during my compilation or run to indicate where. I can't share my code at the moment (work code isn't open source yet :-( ), but I have tried a number of things :

  1. Writing only header and trailer data (av_write_trailer) and no frames
  2. writing frames only minus the trailer (using avcodec_encode_video2 and av_write_frame)
  3. Adjusting our time_base and frame pts values to encode only one frame per second
  4. Removing all variable frame rate code
  5. Numerous other variants that I won't bother you with here

  In creating my project, I've also followed the following tutorials :

  • Dr. Anger's FFMPEG tutorial
  • FFmpeg's Own Tutorials
  • An older tutorial from FFmpeg

  And consulted the deprecated ffmpeg functions list

  And compiled FFMPEG on ubuntu according to the official doc

  And consulted numerous StackOverflow questions :

  • Raw H264 frames in mpegts container using libavcodec
  • How to encode Bitmaps into a video using MediaCodec ?
  • How to convert RGB from YUV420p for ffmpeg encoder ?
  • Encoding H.264 video using FFmpeg C API
  • ffmpeg : how to save h264 raw data as mp4 file

  But every run of the program runs into the exact same problem.

  My question is, is there anything obvious that causes a programmatic run of FFMpeg to differ from a console run (e.g., an incomplete finalization, some threading issues, etc.) ? Like some obvious reason that a console run could repair a corrupted file ? Or is there a decent tool/method for inspecting a video file and finding the point of corruption ?

• add libaribb24 ARIB STD-B24 caption decoder

  14 janvier 2019, par Jan Ekström

  add libaribb24 ARIB STD-B24 caption decoder
  * Outputs ASS lines with basic coloring and font scaling for each
  
    given region.
  
  * Sets the default style to the resolution of the subtitle plane
  
    (for example, 960x540 / 36pt font for profile A).
  
  * Has options to :
  
    * Disable ruby text (which is coded as regions which have
  
      half-height text in libaribb24).
  
      Enabled by default as without positioning ruby text only
  
      confuses as it is usually coded in the beginning of the decoded
  
      subtitle line.
  
    * Set the working directory, in which libaribb24 will read
  
      configuration as well as into which it may save broadcast extra
  
      symbols as PNG.
  
      Unset by default.
  The unconventional library check can be explained by the library's
  
  current master branch being licensed as LGPLv3, but at the time of
  
  writing the latest official release is still licensed under GPLv3.
  Thus, one either has to wait for the following release, or enable
  
  GPLv3.
  

  • [DH] Changelog
  • [DH] configure
  • [DH] doc/decoders.texi
  • [DH] libavcodec/Makefile
  • [DH] libavcodec/allcodecs.c
  • [DH] libavcodec/avcodec.h
  • [DH] libavcodec/codec_desc.c
  • [DH] libavcodec/libaribb24.c
  • [DH] libavcodec/profiles.c
  • [DH] libavcodec/profiles.h
  • [DH] libavcodec/version.h