is there a problem with vp8enc/rtpvp8pay?

[Nicolas Dufresne]

I believe you forgot to mention which version of GStreamer.

Le mercredi 16 mars 2016 à 21:42 -0700, Andres Gonzalez a écrit :
> 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.

For vp8enc, you probably want to set a "deadline", otherwise libvpx
seems to wait random amount of time before producing a frame. For both
VP8 and H264, you probably want to control the keyframe distance.

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

At reception of RTP packet, the DTS is simply set to the time of
arrival according to local clock. To void issues, you should use an
rtpjitterbuffer before the depayloaders.

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

It is wrong, though most likely that this is a side effect of not using
a jitterbuffer. As VP8 does not have B-Frames, it might make sense to
bugfix the depayloader to ensure the PTS and DTS are always equal
though.

> 
> Question #2: What in the server pipeline is changing the dts and
> pts?  

It's not in the server, it's at reception time (udpsrc).

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

It's raw data, you should only set the PTS, and leave the DTS to
GST_CLOCK_TIME_NONE. Though, GStreamer should behave correct if you set
both to the same thing.

> 
> 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.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160317/ef42959b/attachment.sig>