TIME seek with filesrc - using demuxer and muxer unnecessarily

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

TIME seek with filesrc - using demuxer and muxer unnecessarily

amitchawla
Hi,

I was using the following pipeline

gst_parse_launch(" filesrc blocksize=4194304 location=bbc-japan_1080p.mov !
tcpclientsink blocksize=4194304 host=192.168.100.58 port=3000", &error);

but I was unable to perform a TIME_SEEK on it. I need to do a time_seek since there is a demuxer and decoder at the other side of the network, which fails if I do a BYTE_SEEK on the above pipeline.

So, in order to a time seek, I modified the above pipeline like
 
gst_parse_launch("filesrc blocksize=4194304 location=bbc-japan_1080p.mov ! qtdemux name=demux ! queue ! video/x-h264 ! qtmux name=mux streamable=true fragment-duration=10 ! tcpclientsink blocksize=4194304 host=192.168.100.58 port=3000 demux.audio_0 ! queue ! audio/mpeg ! mux.audio_0", &error);

and introduce a demuxer followed by muxer element , which are actually not required.

Is there a way to perform a time_seek without introducing demuxer and muxer unnecessarily ? Is a parser plugin available which can perform time_seek without demuxing the stream ?

Thanks and Regards
Amit
Reply | Threaded
Open this post in threaded view
|

Re: TIME seek with filesrc - using demuxer and muxer unnecessarily

Sebastian Dröge-3
On So, 2016-06-12 at 22:12 -0700, amitchawla wrote:

> Hi,
>
> I was using the following pipeline
>
> gst_parse_launch(" filesrc blocksize=4194304 location=bbc-japan_1080p.mov ! 
> tcpclientsink blocksize=4194304 host=192.168.100.58 port=3000", &error);
>
> but I was unable to perform a TIME_SEEK on it. I need to do a time_seek
> since there is a demuxer and decoder at the other side of the network, which
> fails if I do a BYTE_SEEK on the above pipeline.
>
> So, in order to a time seek, I modified the above pipeline like
>  
> gst_parse_launch("filesrc blocksize=4194304 location=bbc-japan_1080p.mov !
> qtdemux name=demux ! queue ! video/x-h264 ! qtmux name=mux streamable=true
> fragment-duration=10 ! tcpclientsink blocksize=4194304 host=192.168.100.58
> port=3000 demux.audio_0 ! queue ! audio/mpeg ! mux.audio_0", &error);
>
> and introduce a demuxer followed by muxer element , which are actually not
> required.
>
> Is there a way to perform a time_seek without introducing demuxer and muxer
> unnecessarily ? Is a parser plugin available which can perform time_seek
> without demuxing the stream ?
You could do the TIME->BYTES conversion at the receiver where the
demuxer is used and needed anyway, and then do a BYTES seek on the
sender.

Alternatively, you could write a parser element for MOV. Such an
element does not exist currently, but for other formats like Matroska
for example it exists.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TIME seek with filesrc - using demuxer and muxer unnecessarily

amitchawla
Hi Sebastian,

Thanks very much for your reply.

A quick query....

Do I have to do TIME to BYTES conversion myself or do I have a gstreamer support for that ?

Thanks
Amit
Reply | Threaded
Open this post in threaded view
|

Re: TIME seek with filesrc - using demuxer and muxer unnecessarily

Sebastian Dröge-3
On Mo, 2016-06-13 at 02:50 -0700, amitchawla wrote:
> Hi Sebastian,
>
> Thanks very much for your reply.
>
> A quick query....
>
> Do I have to do TIME to BYTES conversion myself or do I have a
> gstreamer support for that ?

qtdemux does that, and a parser for MOV/MP4 would also do that the same
way as qtdemux does. If you want to implement such a parser, you would
have to implement it yourself in there.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TIME seek with filesrc - using demuxer and muxer unnecessarily

amitchawla
Hi Sebastian,

I have been doing a experiment to check if a proper BYTES value from the receiver gives me correct playback of a .mov file when I do a BYTES seek at the sender.

So, I ran the receiver without tcpserversrc but with a filesrc, and from qtdemux DEBUG messages, I figured the byte offset generated by doing a TIME seek at 40 seconds.

Then, I ran my original set up with tcpseversrc and tcpclientsink at either ends, and hard-coded the byte offset as position parameter in BYTES seek operation at the sender. The receiver exited with unable to decode stream error. It seems that the position mentioned in BYTES seek operation at the sender is not correct. ...... I have used the same .mov file for both the experiments.

Before doing a BYTES seek at the sender, do I have do a pipeline flush at the receiver and the sender ?

I would be thankful for your reply.

Regards
Amit
Reply | Threaded
Open this post in threaded view
|

Re: TIME seek with filesrc - using demuxer and muxer unnecessarily

amitchawla
Hi Sebastian,

Could you please share your thoughts on this.

Regards
Amit
Reply | Threaded
Open this post in threaded view
|

Re: TIME seek with filesrc - using demuxer and muxer unnecessarily

amitchawla
Hi ,

Could anyone please provide some suggestions?

Regards
Amit