Recherche avancée

Sur d’autres sites (7196)

• avformat/ffmenc : Make ffm_write_header_codec_ctx() use codecpar

  1er décembre 2016, par Michael Niedermayer

  avformat/ffmenc : Make ffm_write_header_codec_ctx() use codecpar
  This would be simpler if codecpar supported AVOptions
  
  modern ffserver should be unaffected by this, older ffserver which required the
  
  muxer to directly access the encoder could have issues with this, but this
  
  direct access is just wrong and unsafe
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/ffmenc.c
  • [DH] tests/ref/lavf/ffm

• What H.264 encoding profile is considered "safe" in 2017 ?

  12 avril 2017, par degenerate

  Have streaming services adopted a certain H.264 profile as "standard" or "safe" for use in 2017 ? For example are all modern Youtube videos at least "High" profile for H.264 ?

  Or does Youtube continue to serve all encoding profiles, down to "Baseline" depending on hardware ?

  I would like to start encoding my videos with "High" profile or higher, but cannot find any recent documentation on which profile is standard practice or safe to use.

  Searching google is not fruitful :

  Old blog post from 2008 :
  http://blog.mediacoderhq.com/h264-profiles-and-levels/

  Old blog post from 2014 :
  http://leightronix.com/blog/when-to-choose-high-main-and-baseline-while-encoding-h-264/

  I cannot find any updated 2017 information on this.

• How to successfully decode ffmpeg frames with http timeouts without parsers

  28 août 2019, par igal k

  I’m facing a scenario where connectivity issues cause ffmpeg generate false / messed artifacts(frames) contrary to what the manual states.

  We use curl as our http transmitting library and ffmpeg as the processing library. To simulate network timeouts, I place several breakpoints in the AVIOContext which is passed to the AVFormatContext

  avformat_open_input('http://some.com/1.ts')
  
  while(!eof)
  
    av_read_frame
  
    av_send_packet
  
    while(!av_receive_frame)
  
       do_something
  
  close

  av_receive_frame should either return 0 upon success or error -35 for cases where additional data is needed.

  So after timeout-ing the session, ffmpeg can still somehow extract (av_receive_frame) the first frame even though it hadn’t have the chance to download / accumulate enough data.

  

  My question, without using parsers is there a way to validate that the decoder can successfully decode the packet ?

  "EDIT" : i saw that av_read_frame use parsing if AVStream::need_parsing attribute is anything than NONE, any ideas on how setting it up ?