How to handle offset in fill method of a GstBaseSrc subclass?

[Tony Houghton]

I'm writing an element which is supposed to act much like a GstFileSrc but
reads the file over a TCP socket with HTS protocol. The documentation for
GstBaseSrc's 'fill' pure virtual method is very brief and I'm not really
sure how to handle the offset parameter.

I looked at gstfilesrc.c
<https://gitlab.freedesktop.org/gstreamer/gstreamer/blob/master/plugins/elements/gstfilesrc.c>'s
implementation, but I'm still a bit puzzled, because of the way it handles
the special value of -1 (GST_BUFFER_OFFSET_NONE). When performing the
actual read it simply reads from the file's current position. But the
debugging message doesn't handle this special case:

  GST_LOG_OBJECT (src, "Reading %d bytes at offset 0x%" G_GINT64_MODIFIER
"x",
      to_read, offset + bytes_read);

So if it doesn't manage to get all the requested bytes in a single read() and
has to loop with bytes_read non-zero, the offset shown in the message won't
really make sense. Then, after reading the data, it does much the same
thing again for the end offset:

  GST_BUFFER_OFFSET (buf) = offset;
 GST_BUFFER_OFFSET_END (buf) = offset + bytes_read;

Shouldn't it set both to -1 in this case?

I guess it's OK to mark the buffer as not having an offset, but seeing as
the method "knows" the file offset it read from, it could just as easily
set a valid offset. So why does it mark the buffer this way? Why would a
downstream element want a buffer with an unknown offset?

-- 
TH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200929/8a3dfaf5/attachment.htm>