Recherche avancée

Sur d’autres sites (13771)

• configure : add ’-uninstalled’ to uninstalled .pc files

  28 octobre 2016, par Reynaldo H. Verdejo Pinochet

  configure : add ’-uninstalled’ to uninstalled .pc files
  pkg-config(1) expects uninstalled pc files to follow the
  
  blah-uninstalled.pc naming convention and the behavior
  
  of the program is impacted by it. Without this fix
  
  overriding PKGP_CONFIG_LIBDIR is required to ensure
  
  uninstalled files are preferred (overkill), instead of
  
  just adding pc-uninstalled/ to the utility’s search path
  
  by setting PKG_CONFIG_PATH accordingly.
  Signed-off-by : Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
  

  • [DH] configure

• avformat/evcdec : use an unsigned type for nalu_size

  20 juin 2023, par James Almer

  avformat/evcdec : use an unsigned type for nalu_size
  But ensure the value returned by evc_read_nal_unit_length() fits in an int.
  
  Should prevent integer overflows later in the code.
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] libavformat/evcdec.c

• Libav (ffmpeg) What is the most robust way to set the output stream time base ?

  29 octobre 2016, par Jason C

  This is a follow up to the solution to this question. My question is : When creating a new output stream, what is the most robust way to ensure that the output stream time base is set to a valid value for arbitrary formats ?

  Another way to phrase this question is : If I leave the output stream time base set to 0/0, will avformat_write_header always initialize it to something appropriate ?

  Consider the following snippet (assume, unlike the above linked question, that I’m just encoding video and I do not have any input video timing info to refer to or copy from) :

  AVFormatContext *formatx;
  
  AVCodec *codec;
  
  AVStream *stream;
  
  ...
  
  stream = avformat_new_stream(formatx, codec);
  
  stream->time_base = { 1, 10000 };
  
  ...
  
  avformat_write_header(formatx, NULL);

  Here, my rationale is as follows :

  • I observed, for MOV output formats, that if the stream time base is 0/0 when avformat_write_header is called, it is changed to 1/90000. Conclusion : At least one format (MOV) has a preferred time base that is set here, so others may be the same.
  • I do not know if avformat_write_header can be relied on to do this first, so I figure I’ll give it an initial reasonable value (1/10000) just in case.

  So this covers cases where avformat_write_header doesn’t set the time base. However, now I’ve observed two worrisome things :

  • If I do initialize the time base (to 1/10000 in this case), avformat_write_header does not modify it. No worries yet, except...
  • As an experiment I set it to 1/1000000. The MOV muxer issued a warning that the time base was too high. This means avformat_write_header seems to obey the time base that was set even if it’s not necessarily appropriate for the muxer.

  So my conflict is as follows :

  • If I don’t set the time base before writing the header, then I know that in at least some cases avformat_write_header will initialize it to something appropriate. However, I don’t know if this is true in all cases, so I run the risk of this failing (or do I ? that’s the question here).
  • If I do set the time base before writing the header, then I’m safe in situations where avformat_write_header doesn’t, but I run the risk of breaking the muxer, since I can’t know what time bases are valid for arbitrary muxers (or can I ?)
  • The time base can’t be changed after writing the header, of course. So I can’t initialize it to 0/0 then check it for validity and set it to something afterwards. That is, if I set it to 0/0, and avformat_write_header does not fill it in, then I’ve missed an opportunity to set it myself and the program unnecessarily fails.

  So what do I do ? How do I ensure that an output stream time base is both a) always set, and b) always set to something appropriate for the muxer ?