GNOME Bugzilla – Bug 635720
vp8enc incorrectly sets timestamps based on theoretical framerate
Last modified: 2010-12-01 11:03:26 UTC
The vp8enc plugin incorrectly sets timestamps based on the theoretical framerate. As a result, the following pipeline does not work: gst-launch v4l2src ! video/x-raw-yuv, width=320, height=240, framerate=30/1 ! ffmpegcolorspace ! vp8enc ! vp8dec ! xvimagesink vp8enc should copy the timestamp directly from the incoming buffer, as is done, for example, by theoraenc.
It appears that gstbasevideoencoder sets the timestamps correctly, so the following patch gets things working fine for streaming apps. I suspect that this code is in there for streaming from a file, and I'm not sure what the correct way to generate the timestamps is when reading from a file. Based on comparing with other encoders, I do not think that synthesizing timestamps in the encoder is the right thing to do. --- gstvp8enc.c.orig 2010-11-24 14:26:50.000000000 -0800 +++ gstvp8enc.c 2010-11-24 16:45:30.000000000 -0800 @@ -953,9 +953,6 @@ encoder->keyframe_distance++; } - GST_BUFFER_TIMESTAMP (buf) = gst_video_state_get_timestamp (state, - &base_video_encoder->segment, frame->presentation_frame_number); - GST_BUFFER_DURATION (buf) = 0; GST_BUFFER_OFFSET_END (buf) = _to_granulepos (frame->presentation_frame_number + 1, inv_count, encoder->keyframe_distance); @@ -983,11 +980,6 @@ encoder->keyframe_distance++; } - GST_BUFFER_TIMESTAMP (buf) = gst_video_state_get_timestamp (state, - &base_video_encoder->segment, frame->presentation_frame_number); - GST_BUFFER_DURATION (buf) = gst_video_state_get_timestamp (state, - &base_video_encoder->segment, - frame->presentation_frame_number + 1) - GST_BUFFER_TIMESTAMP (buf); GST_BUFFER_OFFSET_END (buf) = _to_granulepos (frame->presentation_frame_number + 1, 0, encoder->keyframe_distance);
commit 01574dc012495522170a97c1902ca18e6038785e Author: David Schleef <ds@schleef.org> Date: Mon Nov 29 20:21:31 2010 -0800 vp8enc: Don't override timestamps set by base class Because the base class does it correctly. Fixes: #635720, #625558.