GNOME Bugzilla – Bug 754898
vaapidecode Fails when decoding 1080p streaming video
Last modified: 2017-03-07 15:01:18 UTC
Created attachment 311167 [details] Screenshot of DDD Used pipeline is like following: gst-launch-1.0 rtspsrc ! rtph264depay ! h264parse ! vaapidecode ! queue ! vaapisink This pipeline works for 720p and 960p resolutions with the same IP Camera. However the pipeline does not work with 1080p resolution. The following is output of gst-launch when the following environment variable is exported: GST_DEBUG=vaapidecode:5 0:00:00.265695959 4149 0x7f3d10003190 INFO vaapidecode gstvaapidecode.c:168:gst_vaapidecode_update_sink_caps:<vaapidecode0> new sink caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, codec_data=(buffer)01640028ffe1007567640028ad84054562b8ac5474202a2b15c562a3a1015158ae2b151d080a8ac57158a8e84054562b8ac5474202a2b15c562a3a10248521393c9f27e4fe4fc9f279b9b34d081242909c9e4f93f27f27e4f93cdcd9a6b403c0113f2ca9000003007800001c206040003567c0003c14dbdef85e1108d401000468ee3c00, level=(string)4, profile=(string)high, width=(int)1920, height=(int)1080, framerate=(fraction)0/1, parsed=(boolean)true 0:00:00.266014187 4149 0x7f3d10003190 DEBUG vaapidecode gstvaapipluginbase.c:463:ensure_sinkpad_buffer_pool: assume video buffer pool format is NV12 0:00:00.271809350 4149 0x7f3d10003190 ERROR vaapidecode gstvaapidecode.c:834:gst_vaapidecode_parse_frame: parse error 8 ERROR: from element /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0: No valid frames decoded before end of stream Additional debug info: gstvideodecoder.c(1256): gst_video_decoder_sink_event_default (): /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0: no valid frames found I debug gst-inspect with DDD and note that the decoder cannot be opened by the function named gst_vaapi_decoder_h264_open() since priv->is_opened set as false. The following lines are from gstvaapidecoder_h264.c: 4345 if (!priv->is_opened) { 4346 priv->is_opened = gst_vaapi_decoder_h264_open(decoder); 4347 if (!priv->is_opened) 4348 return GST_VAAPI_DECODER_STATUS_ERROR_UNSUPPORTED_CODEC; Additionally I have attached a screenshot from DDD for ones that want to see call stack.
Thanks for taking the time to report this. Please, provide a log of the pipeline with --gst-debug="h264parse:5", because the parser is failing. Also, try to use vaapiparse_h264, if you are using GStreamer 1.4 Finally, the backtraces are not useful as a screenshot. It would be better if you use gdb and upload the backtrace as text. http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-troubleshooting.html#idm45485034356288
Created attachment 311204 [details] Output with following env. var. is defined as: GST_DEBUG=h264parse:5
Thanks! But I was wrong, I need more logs. Could you repeat it with GST_DEBUG="vaapi*:5,*:3" ?? Sorry! vmjl
Created attachment 311207 [details] Output with following env. var. is defined as: GST_DEBUG=vaapi*:5,*:3 This is the output of gst-launch when the GST_DEBUG is set as: vaapi*:5,*:3
(In reply to Víctor Manuel Jáquez Leal from comment #3) > Thanks! > > But I was wrong, I need more logs. Could you repeat it with > GST_DEBUG="vaapi*:5,*:3" ?? > > Sorry! > > vmjl No problem, I have attached the specified output.
Sorry again, I didn't validate the debug order :'( I forgot that vaapi*:5,*:3 inhibit the vaapi messages. The correct log (which should be long) is GST_DEBUG="*:3,vaapi*:5" You should see messages from gstvaapidecoder_h264.c
Created attachment 311210 [details] Output with following env. var. is defined as: GST_DEBUG=*:3,vaapi*:5
:) No problem. I have attached the stuff you want.
Created attachment 311298 [details] Obtained output when vaapiparse_h264 element is used I have tried the same with the following configuration: gstreamer 1.4.3, gstreamer-vaapi 0.6.0 One can find the output of the application. 720p videos can be decoded buy 1080p ones cannot.
Hi, A couple further questions: 1) Is the media playable locally? 2) Can you share the media file? 3) If it is playable, and it only fails when it is received through rtspsrc, can you explain how to setup the rtsp sink?
I realized something interesting: Whenever the media is being played simultaneously from a different location, the pipeline fails but if the pipeline is the only place where media is played it plays without any problems. This problem is not seen when the resolution is 720p or 960p. It is too strange. Moreover, I have tried with different IP cameras. I have seen cases where the pipeline does not even work with 720p video resolution. About your questions: 1. What locally means here? 2. I can share the media, I think you want it as rtp streams? Does a pipeline like rtspsrc -> filesink sufficient for this?
Ah, its a stream from an IP camera. It is not a file that can be played locally. > 2. I can share the media, I think you want it as rtp streams? Does a > pipeline like rtspsrc -> filesink sufficient for this? No. I would need the rtsp:// address, reachable through internet. Have you try to use playbin?? gst-launch-1.0 playbin uri=rtsp:// Have you tried to add a queue in your pipeline for buffering?? gst-launch-1.0 rtspsrc ! queue ! rtph264depay ! queue2 use-buffering=true ! h264parse ! vaapidecode ! vaapisink (In reply to Engin FIRAT from comment #11) > I realized something interesting: > > Whenever the media is being played simultaneously from a different location, > the pipeline fails but if the pipeline is the only place where media is > played it plays without any problems. This problem is not seen when the > resolution is 720p or 960p. It is too strange. > > Moreover, I have tried with different IP cameras. I have seen cases where > the pipeline does not even work with 720p video resolution. > A bandwidth issue, perhaps??
(In reply to Víctor Manuel Jáquez Leal from comment #12) > Ah, its a stream from an IP camera. It is not a file that can be played > locally. > > > 2. I can share the media, I think you want it as rtp streams? Does a > > pipeline like rtspsrc -> filesink sufficient for this? > > No. I would need the rtsp:// address, reachable through internet. > > Have you try to use playbin?? > > gst-launch-1.0 playbin uri=rtsp:// > May be you can test with gst-rtsp-server,,,, If i remember correctly there were sample programs in example folder ... It was quite simple, running those test programs basically start the rtsp server... :)
(In reply to sreerenj from comment #13) > (In reply to Víctor Manuel Jáquez Leal from comment #12) > > > 2. I can share the media, I think you want it as rtp streams? Does a > > > pipeline like rtspsrc -> filesink sufficient for this? > > > > No. I would need the rtsp:// address, reachable through internet. > > > > May be you can test with gst-rtsp-server,,,, If i remember correctly there > were sample programs in example folder ... It was quite simple, running > those test programs basically start the rtsp server... :) True! Also I found this https://github.com/kreopt/gst-rtspsink/ But it is better with something that I already have.
I have tried playbin and placing a buffer. These don't work. :(
The case is clearly failing in parser itself (as per what I can see in log), can't parse the PPS header. Is it working with software decoder? gst-launch-1.0 rtspsrc ! rtph264depay ! h264parse ! avdec_h264 ! queue ! vaapisink If so then please save the stream and share it here. gst-launch-1.0 rtspsrc ! rtph264depay ! h264parse ! "video/x-h264, stream-format=(string)byte-stream" ! filesink location=sample.264
Also, I myself tested with the following setup -- gst-rtsp-server as the server, captured the webcam stream, scaled to 1080p, encoded with hardware (tested with software encoder too) , rtppayloaded -- client side received the stream, depayloaded , decoded with hardware deocder, rendered with vaapisink Everything works fine too. Please test with software decoder as I mentioned in comment16 and let me know. For now this is low priority bug for 0.7 release. Postponing...
Moving to Product:GStreamer, Component:gstreamer-vaapi
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!