Recherche avancée

Sur d’autres sites (14104)

• Ffmpeg libx264rgb and libx264 yuv444p gives very different results

  1er février 2020, par Mustafa Akın Yılmaz

  I am trying to create a lossy compressed video from several .png files. I am using the following ffmpeg commdans :

  ffmpeg -i %8d.png -frames:v 4 -c:v libx264rgb -pix_fmt rgb24 -g 4 -qp 30 -r 25 out.mp4

  and

  ffmpeg -i %8d.png -frames:v 4 -c:v libx264 -pix_fmt yuv444p -g 4 -qp 30 -r 25 out.mp4

  Then I am extracting frames from the videos with the command :

  ffmpeg -i out.mp4 -r 25 %8d.png

  When I compare the bitrate and PSNR, I found that the yuv444p gives about 2 db gain at the same bitrate. Why such a huge difference is observed even I did set yuv444p which does not apply chroma subsampling ?

• 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 ?

• openRTSP TCP 100% Cpu

  25 avril 2014, par user1199722

  First thanks for the great work for live media group.
  I am currently facing a problem with OpenRTSP utilizing cpu 100%.
  I am using the following commands to stream from remote ipcamera through internet. It works fine with local cameras.
  But when I try to stream from Internet IP camera (720p), At random times openRTSP start uses 100% cpu and stops output of streaming. The process is not exiting it stay with 100% cpu.

  I have observed that stream stops with a series of "c9c99c999......."
  I am using TCP streaming of rtsp.
  Please find the command that i am using.

  openRTSP -d 60 -v -t -c -b 800000 | /bin/ffmpeg -r 15 -i - -codec copy -hls_list_size 65535 -hls_time 5

  Please provide your suggestions regarding the problem
  Waiting for your valuable pointers.