GNOME Bugzilla – Bug 710149
[tsdemux] - should allow byte based seeks to go through
Last modified: 2013-10-16 15:33:43 UTC
When using a source such as souphttpsrc, byte seek requests should result in an updated GET request with a Range header reflecting the requested byte position. When format of content is mpeg2 ts, the tsdemux does not allow the byte seek request to be processed. If I comment out the following in mpegtsbase.c - mpegts_base_handle_seek_event() if (format != GST_FORMAT_TIME) return FALSE; the HTTP GET request is updated with the appropriate RANGE header value and video plays at the approximate position requested - seek works.
That's not valid, if a demuxer receives a seek request in BYTES on a source pad, it essentially means "seek to that position in bytes on that pad (i.e. that elementary stream)" and not "seek to that position in bytes in the overall/muxed stream (i.e. upstream)". If you want to seek to a specific position in bytes in HTTP ... you essentially need to seek on the souphttpsrc element itself (who will then downstream the appropriate segment events).
Yes, as Edward said. And implementing seeks in BYTE format on the srcpads properly is rather uninteresting and impossible with mpegts.
What is your use case for this? Why do you need it?
My use case is streaming an mpeg2 ts content item from a server. I am using playbin. I am trying to support servers that do not support time based seeks. I have a simple c program test application which issues a byte based seek. The event is propagated through the pipeline starting with playbin but before souphttpsrc gets a shot at it, it is rejected by tsdemux. I can attach my pipeline diagram if that would be useful.
Then just seek in time, tsdemux should convert that seek event into a BYTE seek event.
Yes - time based seeks are not an issue but I would like to "honor" the application's request of a byte based seek. From an application perspective, they feel there is no reason a byte based seek can not be supported - all it takes is a new HTTP GET request with a RANGE header.
If you really need that for whatever reason, you can get the source from playbin and send the seek to that. A byte-based seek to tsdemux is not going to do what you expect (if it's implemented, and implemented properly).
The right way for application developers to deal with this is if they want to do a byte based seek, they get playbin's source element and send the seek event to the source element. What about time based seeks? Can they still send directly to playbin or should they get the source element in that case also?
Can we move this to the gst-devel mailing list ? :)
I am going to investigate this some more and if I have additional questions or want to discuss this further, I will send to gst-devel mailing list. Thanks for following up.