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'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 r
ead() 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?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Locked
