(In reply to Randy Spruyt from comment #0)

> But any video I try to stream has large amount studder/missing frames.
> Turning sync=false on the client renderer does not seem to help.

Yup. It seems there's a problem in the internal parsing. Don't know for sure.

> gst-launch-1.0 udpsrc caps = "application/x-rtp, media\=video,
> clock-rate=90000, encoding-name=H264, packetization-mode=1,
> profile-level-id=4d4029,
> sprop-parameter-sets=\"J01AKakYDwBE/LgDUBAQG2wrXvfAQA\\\=\\\=\\\,
> KN4JyA\\\=\\\=\", payload=96, ssrc=765248706, timestamp-offset=4096462552,
> seqnum-offset=1276" port=5000 ! rtpjitterbuffer! rtph264depay !
> vaapiparse_h264 ! vaapidecode ! vaapisink

I think there's some improvement if you use queues. Can you replace 'vaapiparse_h264 ! vaapidecode' with decodebin ??

decodebin will use vaapidecodebin and some queues that seems to improve a bit the issue.

>  
> gst-launch-1.0 udpsrc caps = "application/x-rtp, media=video,
> clock-rate=90000, encoding-name=H264,
> sprop-parameter-sets=\"J01AKakYDwBE/LgDUBAQG2wrXvfAQA\\\=\\\=\\\,
> KN4JyA\\\=\\\=\", payload=96, ssrc=1798546747, timestamp-offset=3287499078,
> seqnum-offset=25830" port=5000 ! rtpjitterbuffer! rtph264depay ! h264parse !
> avdec_h264 ! xvimagesink

Yep. It works much better, but I still see some artifacts, less notorious than the ones with vaapidecode, but still ... :)

From the mailing list:

On 05/20/15 at 12:58pm, Nicolas Dufresne wrote:                                                                                                                                                                    
> Ok, next step would be to dig into vaapi elements. I'm suspecting a bug                                                                                                                                          
> in the LATENCY_QUERY implementation. Could be un-implemented, or miss                                                                                                                                            
> -implemented. I'm giving you guidance since I don't have time myself to                                                                                                                                          
> have a looks.                                                                                                                                                                                                    
                                                                                                                                                                                                                   
Indeed, LATENCY_QUERY is not implemented in gstreamer-vaapi. Thanks Nicolas!                                                                                                                                       
I'll dig on it tomorrow

Thanks for looking at this :) The entire project I am working on depends on the hardware decoding to function.

Just to follow up with Victor's original question, if we try to use the vaapidecodebin without the vaapiparse_h264, the caps negotiation fails. If we use vaapiparse_h264 ! vaapidecodebin we see the same output of dropped/stuttering frames as before. 

The DOT graph shows vaapidecodebin resolved as the following in brackets when used with vaapiparse_h264 (probably not what we want, but just FYI):

vaapiparse_h264 -> ( vaapidecoder -> queue -> vaapipostproc ) -> vaapisink


dev@dev-pheonix:~/gstreamer-vaapi$ gst-launch-1.0 udpsrc caps = "application/x-rtp, media\=video, clock-rate=90000, encoding-name=H264, packetization-mode=1, profile-level-id=4d4029, sprop-parameter-sets=\"J01AKakYDwBE/LgDUBAQG2wrXvfAQA\\\=\\\=\\\,KN4JyA\\\=\\\=\", payload=96, ssrc=765248706, timestamp-offset=4096462552, seqnum-offset=1276" port=5000 ! rtpjitterbuffer! rtph264depay ! vaapidecodebin ! vaapisink
libva info: VA-API version 0.37.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_37
libva info: va_openDriver() returns 0
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Got context from element 'vaapidecode': gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL;
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.391266017 25603      0x24bfb20 ERROR            vaapidecode gstvaapidecode.c:443:gst_vaapidecode_handle_frame:<vaapidecode> not negotiated
ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2943): gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
streaming task paused, reason not-negotiated (-4)
Execution ended after 0:00:00.238784054
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

(In reply to Víctor Manuel Jáquez Leal from comment #2)
> From the mailing list:
> 
> On 05/20/15 at 12:58pm, Nicolas Dufresne wrote:                             
> 
> > Ok, next step would be to dig into vaapi elements. I'm suspecting a bug                                                                                                                                          
> > in the LATENCY_QUERY implementation. Could be un-implemented, or miss                                                                                                                                            
> > -implemented. I'm giving you guidance since I don't have time myself to                                                                                                                                          
> > have a looks.                                                                                                                                                                                                    
>                                                                             
> 
> Indeed, LATENCY_QUERY is not implemented in gstreamer-vaapi. Thanks Nicolas!
> 
> I'll dig on it tomorrow

Hi Victor, did you have any luck with this?

(In reply to Randy Spruyt from comment #4)
> 
> Hi Victor, did you have any luck with this?

Last Friday I work on a patch for latency (bug #740419). If you can test it would be great. But from my side it didn't improve this this issue.

Gave the patch a try, but the result is the same you are seeing, the issue still remains.

Yeah. It looks like if the frame doesn't arrive as the decoder expects the decoder chokes and freezes the pipeline for a moment. We need to measure when and why those freezes appear.

Any timeline for a fix?

I don't know if Gwenole would say something different, but I cannot give you an ETA.

It could be a regression introduced by the h264 decoder patches for handling missing pictures..


Randy, Could you please try with the gstremaer-vaapi from master ( commit: 22f4d8b768e8506034ea9b3dac9d2ec2e7f15905) ..? this is bit older commit hash, but not including the recent h264 decoder changes...

Would be good if you can do a git bisect..

tried both latest eb510e23cecd02ffc9c3906807487fa1d156e627
and git master 22f4d8b768e8506034ea9b3dac9d2ec2e7f15905 a try as requested. 

using:

server:
gst-launch-1.0 -v filesrc location=/mnt/share/demo/big_buck_bunny_1080p_h264.mov ! qtdemux ! vaapiparse_h264 ! rtph264pay ! udpsink host=127.0.0.1 port=6000

client:
gst-launch-1.0 udpsrc caps = "application/x-rtp, media=video, clock-rate=90000, encoding-name=H264, packetization-mode=1, profile-level-id=4d4029, sprop-parameter-sets=\"J01AKakYDwBE/LgDUBAQG2wrXvfAQA==,KN4JyA==\", payload=96, ssrc=1589574764, timestamp-offset=3965114202, seqnum-offset=28081" port=6000 ! rtpjitterbuffer! rtph264depay ! vaapiparse_h264 ! vaapidecode ! vaapisink

current HEAD shows a few frames before freezing now, if we use sync=false on the renderer, both 22f4d8b and eb510e23 show the same things as before, intermittent pausing, then some data loss until the next keyframe. 

Are you able to reproduce the issue?

22f4d8b768e8506034ea9b3dac9d2ec2e7f15905 is working okay for me...There are artifacts(due to missing frames i guess) here and there,,but still i can play the stream quite okay...
But the git master is just stalling for me...

Moving to Product:GStreamer, Component:gstreamer-vaapi

I am not able to reproduce this problem using the current gstreamer-vaapi and the pipeline in Comment 1.

This seems to be fixed in current stable (1.14) If the problem persist, please reopen.