GNOME Bugzilla – Bug 724103
Libav fails to encode buffer due to invalid timestamps
Last modified: 2018-05-01 09:46:24 UTC
During encoding with libav errors like: 0:00:04.264244710 17662 0x13fe90 ERROR libav :0:: Error, Invalid timestamp=30, last=30 0:00:04.264366460 17662 0x13fe90 ERROR libav gstavvidenc.c:659:gst_ffmpegvidenc_handle_frame:<video_encode> avenc_h263: failed to encode buffer appear in log. Problem that with seconds precision in time conversion gst_ffmpeg_time_gst_to_ff function converts frame->pts = 2958333333 to ffmpegenc->picture->pts = 30; as well as frame->pts = 3000000000; to ffmpegenc->picture->pts = 30; Given this, looks like that it's reasonable to increase time conversion precision from seconds to mseconds. Proposed patch in attachment.
Created attachment 268771 [details] [review] Proposed patch
Comment on attachment 268771 [details] [review] Proposed patch I don't think this is correct. These functions are converting from libav to GStreamer time by using the timebase provided as "base" parameter there. This timebase is what is provided by libav. You might want to adjust the timebase instead. Can you provide a testcase that reproduces your problem?
Looks like that my problem is different one. I'm trying to encode video with fixed fps. In given sample I use 10 fps so my timebase is 1/10 which is correct, and gst timestamp in nanosecs is correct as well. According to ffmpeg docs ( http://ffmpeg.org/doxygen/trunk/structAVCodecContext.html#ab7bfeb9fa5840aac090e2b0bd0ef7589 ) there should be several conditions passed: 1. timebase should be 1/framerate (passed in this case) 2. timestamp increments should be identically 1 (which is not passed) So problem is: avvidenc should know that fixed-fps mode is used for encoding and properly handle this case in gst_ffmpegvidenc_handle_frame (maybe some other places) Possible solutions: 1. add property to notify encoder that fixed-fps mode is required 2. drop not-needed frames using some other approach 3. pass frames to libav so libav will drop frames by itself Additional notes: videorate is used before encoder in pipeline, it doesn't generate monotonically increased timestamps with step 0.1 in my case so after rounding ts are duplicated
Closing. If this is still an issue with current stable GStreamer, please re-open.