After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 789752 - msdk: h265dec: failed to play with h265parse if framerate is not provided.
msdk: h265dec: failed to play with h265parse if framerate is not provided.
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other Linux
: Normal normal
: 1.14.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 793781 793786 (view as bug list)
Depends on:
Blocks: 789886
 
 
Reported: 2017-11-01 09:15 UTC by Hyunjun Ko
Modified: 2018-03-29 23:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
msdk: h265dec: remove framerate field from sink caps template (1.02 KB, patch)
2017-11-01 09:26 UTC, Hyunjun Ko 		committed Details | Review
msdk: dec: set framerate to the driver only if provided (1.47 KB, patch)
2017-11-01 09:27 UTC, Hyunjun Ko 		committed Details | Review

Description Hyunjun Ko 2017-11-01 09:15:28 UTC 
Currently h265parse doesn't provide framerate by itself while msdkh265dec needs it via sink caps.

So negotiation fails when we try to play raw h265 stream just like below.

Step to reproduce.
# gst-launch-1.0 filesrc location=test_stream.265 ! h265parse ! msdkh265dec ! videoconvert ! xvimagesink

The tested stream is from samples in mediaSDK.
Comment 1 Tim-Philipp Müller 2017-11-01 09:25:28 UTC 
Is the framerate really required by the decoder API?
Comment 2 Hyunjun Ko 2017-11-01 09:26:14 UTC 
Created attachment 362727 [details] [review]
msdk: h265dec: remove framerate field from sink caps  template

Removes unessential field framerate for decoder so that negotiation works
even if framerate is not provided from upstream.
Comment 3 Hyunjun Ko 2017-11-01 09:26:32 UTC 
(In reply to Tim-Philipp Müller from comment #1)
> Is the framerate really required by the decoder API?

I don't think so :)
Comment 4 Hyunjun Ko 2017-11-01 09:27:11 UTC 
Created attachment 362728 [details] [review]
msdk: dec: set framerate to the driver only if provided

For example, if framerate 0/1 is provided from upstream, the driver fails to
configure and complain about it. 

We can let it go and make the driver assuming framerate itself.
Comment 5 Hyunjun Ko 2017-11-01 09:29:04 UTC 
(In reply to Hyunjun Ko from comment #3)
> (In reply to Tim-Philipp Müller from comment #1)
> > Is the framerate really required by the decoder API?
> 
> I don't think so :)

Probably it's because the driver requires framerate at configuration.
But IMHO it could be skipped. See the second patch I proposed.
Comment 6 Nicolas Dufresne (ndufresne) 2017-11-01 14:19:05 UTC 
I think framerate could be needed if one of the decoders is deadline based, and the deadline is not explicitly provided but deduces from the frame duration. Could that be the case ?
Comment 7 sreerenj 2018-03-29 00:27:17 UTC 
It fails if we set 0/1 but no issue with 0/0 :) :)
Better fix it with the second patch.
Comment 8 Hyunjun Ko 2018-03-29 07:31:59 UTC 
(In reply to sreerenj from comment #7)
> It fails if we set 0/1 but no issue with 0/0 :) :)
> Better fix it with the second patch.

The first patch is to succeed in negotiation with h265parser.
Comment 9 sreerenj 2018-03-29 19:40:59 UTC 
Better remove the framerate from all decoders template caps too.
Comment 10 sreerenj 2018-03-29 20:08:52 UTC 
Review of attachment 362727 [details] [review]:

pushed
Comment 11 sreerenj 2018-03-29 20:09:10 UTC 
Review of attachment 362728 [details] [review]:

pushed
Comment 12 sreerenj 2018-03-29 20:09:59 UTC 
Pushed to both master and 1.14
Comment 13 sreerenj 2018-03-29 23:19:18 UTC 
*** Bug 793786 has been marked as a duplicate of this bug. ***
Comment 14 sreerenj 2018-03-29 23:24:40 UTC 
*** Bug 793781 has been marked as a duplicate of this bug. ***