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 567497 - [fakesrc] respect output size/offset of basesrc
[fakesrc] respect output size/offset of basesrc
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-01-12 13:57 UTC by Zeeshan Ali
Modified: 2011-04-13 12:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test app that reproduces this bug (5.61 KB, text/plain)
2009-01-12 14:00 UTC, Zeeshan Ali
Details
The generated C file for vala-impaired (15.12 KB, text/plain)
2009-01-12 14:09 UTC, Zeeshan Ali
Details
The original C file (14.89 KB, text/plain)
2009-01-12 14:15 UTC, Zeeshan Ali
Details

Description Zeeshan Ali 2009-01-12 13:57:43 UTC
Seems like 'stop' parameter of a (segment) seek event is ignored by basesrc. I was facing this problem in Rygel that uses filesrc ! fakesink and now I have a test-app that reproduces this issue with 'fakesrc ! fakesink' that I am going to attach to this bug.

The app asks for byte 20 to 45 but gets the whole 4096-byte buffer (default blocksize on the source).
Comment 1 Zeeshan Ali 2009-01-12 14:00:24 UTC
Created attachment 126274 [details]
Test app that reproduces this bug

To build, get yourself the recent version of valac and:

valac -o test-seekable --pkg gstreamer-0.10 test-seekable.vala
Comment 2 Zeeshan Ali 2009-01-12 14:09:16 UTC
Created attachment 126276 [details]
The generated C file for vala-impaired
Comment 3 Zeeshan Ali 2009-01-12 14:15:49 UTC
Created attachment 126280 [details]
The original C file

Sorry! the previous one i pasted was generated after I made a change to the vala source: set the blocksize of src to "5", though it seems that size is ignored so it didn't really make any diff.
Comment 4 Jan Schmidt 2009-01-12 14:17:04 UTC
Like I said on IRC, seek requests for a particular time range don't necessarily
clip the buffers to be within that time range, it just sends all buffers that
fall within the given range, along with a new-segment that describes which
portions are 'valid'.

We probably want some element that does the clipping for you to use.
Comment 5 René Stadler 2009-01-18 12:33:38 UTC
Audio sinks clip to a TIME segment, so my thinking is that filesink should clip to BYTES segments.  Same for all ANY caps sinks in fact.
Comment 6 Tim-Philipp Müller 2009-06-09 00:03:20 UTC
> Audio sinks clip to a TIME segment, so my thinking is that filesink should clip
> to BYTES segments.  Same for all ANY caps sinks in fact.

I think audiosinks can only do that because GST_BUFFER_TIMESTAMP() can be assumed to be reliable if it is set, which is something that can't be said for GST_BUFFER_OFFSET(), partly because it's not used a lot, or at least not consistently, but also because it can mean different things in different circumstances if not the same circumstances, so using it automatically for clipping is likely to lead to disaster.
Comment 7 René Stadler 2009-06-09 07:14:58 UTC
Right, offset is "media specific", so there can't be a general way of handling it.
Comment 8 Zeeshan Ali 2011-04-13 12:49:08 UTC
I now have my own sink in rygel that does the require clipping.