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 679456 - videodecoder: fix compiler optimization hint macro usage
videodecoder: fix compiler optimization hint macro usage
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.11.x
Other Linux
: Normal normal
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-07-05 15:03 UTC by sreerenj
Modified: 2012-10-28 23:12 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
videodecoder: Fix the compiler optimization hint macro usage. (960 bytes, patch)
2012-07-05 15:03 UTC, sreerenj 		committed Details | Review

Description sreerenj 2012-07-05 15:03:29 UTC 
Created attachment 218101 [details] [review]
videodecoder: Fix the compiler optimization hint macro  usage.

videodecoder: Fix the compiler optimization hint macro
 usage.

As far as the output_state->caps is not explicitly setting(which is the usual case), gst_video_decoder_set_src_caps should create the caps for src pad from output_state->info which is G_LIKELY case...
Comment 1 sreerenj 2012-07-05 15:36:21 UTC 
Currently there is no case in which the "output_state->caps != NULL".. Since i haven't seen any option to set the output_state->caps. 

So what can i do to set a custom caps on the src pad of decoder???
Because it seems that gst_video_set_output_state () is not touching the caps of the output_state...

How about a new API to set the the output_state->caps explicitly ??
Comment 2 sreerenj 2012-07-05 15:55:45 UTC 
hm,,,for comment 1,

state = set_output_state()
state->caps = caps    

is fine for me :)
Comment 3 Tim-Philipp Müller 2012-10-28 23:12:28 UTC 
Ok, fair enough, I've pushed this, but without the compiler hint. This is not an often-used code path, we should not litter the code with such optimisation macros here IMHO.

I'm not sure I understand comment 1 and comment 2. It sounds like a support question and appears unrelated to the patch? (Please re-open or file a new bug if not)