Recherche avancée

Sur d’autres sites (9201)

• Fastest seek speed and decoding with ffmpeg and x265 ProRes

  17 mai 2018, par Christopher Jarvis

  I’m trying to optimize seek speed with x265. No matter what encoding settings I try, ProRes still seeks more quickly/gracefully. This makes sense since it was built for editing, but I’m sure there’s got to be something I’m missing to better improve x265.

  So far, -tune fastdecode, keyint=1, maxrate and -b (to remove B Frame calculations) yield the best results, but they’re still unsatisfactory. I’ve been pouring over the docs but there’s so much jargon I just don’t understand. Perhaps another codec like VP9 / WebM would be better for this purpose ?

  From what I can tell, there’s no bottleneck with CPU, read speed or RAM... or GPU for that matter. Monitoring these processes show minimal drain. Is there just an amount of decoding in a highly compressed format like x265 that can’t be circumvented ?

  Thank you in advance for your help.

• ffmpeg : use new decode API

  1er octobre 2016, par wm4

  ffmpeg : use new decode API
  This is a bit messy, mainly due to timestamp handling.
  decode_video() relied on the fact that it could set dts on a flush/drain
  
  packet. This is not possible with the old API, and won’t be. (I think
  
  doing this was very questionable with the old API. Flush packets should
  
  not contain any information ; they just cause a FIFO to be emptied.) This
  
  is replaced with checking the best_effort_timestamp for AV_NOPTS_VALUE,
  
  and using the suggested DTS in the drain case.
  The modified tests (fate-cavs and others) still fails due to dropping
  
  the last frame. This happens because the timestamp of the last frame
  
  goes backwards (ffprobe -show_frames shows the same thing). I suspect
  
  that this "worked" due to the best effort timestamp logic picking the
  
  DTS over the decreasing PTS. Since this logic is in libavcodec (where
  
  it probably shouldn’t be), this can’t be easily fixed. The timestamps
  
  of the cavs samples are weird anyway, so I chose not to fix it.
  Another strange thing is the timestamp handling in the video path of
  
  process_input_packet (after the decode_video() call). It looks like
  
  the code to increase next_dts and next_pts should be run every time
  
  a frame is decoded - but it’s needed even if output is skipped.
  

  • [DH] ffmpeg.c
  • [DH] ffmpeg.h
  • [DH] tests/ref/fate/cavs
  • [DH] tests/ref/fate/mpeg2-ticket186
  • [DH] tests/ref/fate/svq3-watermark

• What are all the command `options` to execute with ?

  25 janvier 2023, par Phil Lucks

  I'd like to be able to compress the video in a way to help improve upload times.

  


  In reading the docs for FFMpeg Kit, using React Native, there is a basic execute command string of '-i file1.mp4 -c:v mpeg4 file2.mp4'... I can guess at what some of this means, in terms of input & output file names based on the ffMPEG docs, however, some of these options I am not sure of.

  


  Like why is there a -i flag prefix ? Is this "input" ?
Why is there -c:v ? Is this "convert video" ?
What if I want to reduce frame rate, or change size of video ?

  


  The TS def is just a string...

  


  Is there a good place to understand what the official docs options map to the strings ? I think