After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 724103 - Libav fails to encode buffer due to invalid timestamps
Libav fails to encode buffer due to invalid timestamps
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other All
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-02-11 08:28 UTC by Dmitry
Modified: 2018-05-01 09:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (1.05 KB, patch)
2014-02-11 09:20 UTC, Dmitry
needs-work Details | Review

Description Dmitry 2014-02-11 08:28:05 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.
Comment 1 Dmitry 2014-02-11 09:20:11 UTC
Created attachment 268771 [details] [review]
Proposed patch
Comment 2 Sebastian Dröge (slomo) 2014-02-11 20:15:59 UTC
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?
Comment 3 Dmitry 2014-02-12 15:12:55 UTC
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
Comment 4 Edward Hervey 2018-05-01 09:46:24 UTC
Closing. If this is still an issue with current stable GStreamer, please re-open.