is there a problem with vp8enc/rtpvp8pay?

Andres Gonzalez andres.agoralabs at gmail.com
Thu Mar 17 04:42:51 UTC 2016


I am having a problem with vp8enc and would like to ask a couple of
questions.

I have an application that generates a stream using rtpbin with the
following pipeline:

appsrc ! queue ! timeoverlay textoverlay x264enc ! rtph264pay

This pipeline is working very well, I can use a typical gst-launch script on
another local host and receive the video and audio fine.

But when I then change the x264/rtph264pay  to vp8/rtpvp8pay the
corresponding gst-launch script does not process the stream. I am using the
default properties for vp8, and rtpvp8pay uses the same basic properties as
rtph264pay. I have verified that RTP pkts are being sent, and running the
gst-launch script using GST_DEBUG=3,*rtp*:6 shows no obvious errors.

When I compare the working h264 debug output with the non-working vp8 debug
output I find that all the vp8 frames are dropped:

...<rtpvp8depay0> Dropping inter-frame before intra-frame

The reason appears to be related to the dts and pts. Here is a debug output
from both a working h264 stream and a non-working vp8 stream:

...<rtpvp8depay0> discont 0, seqnum 654, rtptime 282916,     pts
0:00:22.869452680, dts 0:00:22.871813393
...<rtph264depay0> discont 0, seqnum 18570, rtptime 3109586, pts
0:00:31.537955395, dts 0:00:31.536494323

The working h264 has a pts before the dts, which seems reasonable since the
frame has a decode time before the presentation time. But the vp8 has the
pts BEFORE the dts.  

Question #1: Is that analysis correct, that is, the dts must be younger than
the pts?

Question #2: What in the server pipeline is changing the dts and pts?  
Since this stream is generated with an appsrc, my application is loading the
video data and my code is setting the dts and pts of a GstBuffer before it
is pushed into the appsrc:

GST_BUFFER_PTS(pVideoBuffer) = tCaptureTime - m_tBaseClockTime;
GST_BUFFER_DTS(pVideoBuffer) = tCaptureTime - m_tBaseClockTime;

So my code is setting the pts and the dts to the *same* time, but when the
client receives the RTP pkt they are different, and for the vp8 case it
appears the change was incorrect. Again, the h264 case is working fine.

Question #3: Am I correct in setting the pts and the dts to the *same* time
when I load and push the GstBuffer?

Question #4: Assuming the pts/dts are the problem, are there any properties
of rtpvp8pay that I should set that will fix this?

Thanks,
-Andres



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/is-there-a-problem-with-vp8enc-rtpvp8pay-tp4676403.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.


More information about the gstreamer-devel mailing list