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 739276 - y4mdec: porting to videodecoder base class
y4mdec: porting to videodecoder base class
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-10-28 05:29 UTC by Vineeth
Modified: 2018-05-04 09:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
port to videodecoder base class (23.94 KB, patch)
2014-10-28 05:31 UTC, Vineeth
none Details | Review

Description Vineeth 2014-10-28 05:29:29 UTC
y4mdec should use videodecoder base class instead of element class.
Porting the same to videodecoder class

The pipeline to test is
gst-launch-1.0 filesrc location=../example.y4m ! y4mdec ! videoconvert ! ximagesink
Comment 1 Vineeth 2014-10-28 05:31:23 UTC
Created attachment 289496 [details] [review]
port to videodecoder base class
Comment 2 Luis de Bethencourt 2014-10-31 14:11:18 UTC
gsty4mdec.c: In function 'gst_y4mdec_parse':
gsty4mdec.c:432:7: error: format '%d' expects argument of type 'int', but argument 8 has type 'gsize' [-Werror=format=]
       GST_DEBUG ("not enough data for frame %d < %" G_GSIZE_FORMAT,
       ^
Comment 3 Tim-Philipp Müller 2014-10-31 14:22:03 UTC
It's not entirely clear to me that this should be ported to the videodecoder base class, since the element is a bit of a mixed bag, it's really more of a parser/demuxer than a decoder, isn't it? What benefits are there from porting it to the videodecoder base class? What about features such as seeking?
Comment 4 Vineeth 2014-11-21 05:45:38 UTC
The name y4mdec is quite misleading in this case..


it is more of a demuxer rather than a decoder..
I thought maybe it might be better to rename the same to y4mdemux, but Thiago suggested that it might break applications which already use the same..

Will there be any need to create a new element which does just decoding using videodecoder base class, rather than demuxing?? 
If that doesnt make sense, then probably we can resolve this issue as WONTFIX or NOTABUG...

Please advice.
Comment 5 Tim-Philipp Müller 2014-11-21 15:26:39 UTC
Don't get too hung up on the name. Maybe it's not ideal, but it's not really a problem. There's no need to rename it, and little benefit IMO.

How to proceed: as I see it, the question was if GstBaseParse class would be a more suitable base class.

The other question was: what about seeking? If I read your patch correctly, you just removed seeking support?
Comment 6 Vineeth 2014-11-21 15:45:33 UTC
Actually i removed seeking support thinking it is not needed for a decoder..
Comment 7 Tim-Philipp Müller 2014-11-21 16:13:26 UTC
Might be good to familiarise yourself a little with the y4m format then if you haven't done so yet.
Comment 8 Vineeth 2014-11-27 05:46:03 UTC
Hi Tim,
   I have been going through y4m format and baseparse class in general..

   if we port y4m to baseparse class, wont it need a decoder again to decode and show the media? right now y4mdec acts more like a decoder as well
   it is better practice to have decoder/parser/demuxer as separate elements right?

  the more i look into it the more i get confused about it :(...


Regards,
Vineeth
Comment 9 Edward Hervey 2018-05-04 08:59:48 UTC
This hasn't seen any activity in 4 years. Closing. If you can rebase the patch against current master, please re-open the bug. Thanks.
Comment 10 Tim-Philipp Müller 2018-05-04 09:18:34 UTC
Still not sure if it's really a good fit for any of the base classes.