[Bug 758160] splitmuxsink with mpegtsmux, curlftpsink generates only the first fragment and pipeline exits with a timeout error.

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=758160

--- Comment #2 from Raghavendra <raghava.447 at gmail.com> ---
I tried the following pipelines.

1. gst-launch-1.0 filesrc location=/root/big_buck_bunny_270p.mp4 ! decodebin !
videoconvert ! x264enc ! mp4mux name=muxer ! curlftpsink user=test22
passwd=test22 location=ftp://10.0.0.16/ file-name=new.mp4

This works with gstreamer-1.2.2 and gstreamer-1.5.2 & I could see the file dump
at destination. But the same pipeline exits with gstreamer-1.6.0.

2. gst-launch-1.0 filesrc location=/root/big_buck_bunny_270p.mp4 ! decodebin !
videoconvert ! x264enc ! mpegtsmux name=muxer ! curlftpsink user=test22
passwd=test22 location=ftp://10.0.0.16/ file-name=new.ts

This pipeline works and I could see the file dump at destination.

3. gst-launch-1.0 filesrc location=/root/big_buck_bunny_270p.mp4 ! decodebin !
videoconvert ! x264enc ! splitmuxsink muxer="mpegtsmux name=muxer"
sink="curlftpsink user=test22 passwd=test22"
location=ftp://10.0.0.16/test_bunny.ts max-size-time=10000000000
max-size-bytes=18446744073709551615

This pipeline generates first fragment and then timesout. Pipeline exits after
throwing timeout error.

If I disable the code which I mentioned in earlier comment (in the function
"handle_transfer" of the file gstcurlbasesink.c of gst-plugins-bad where
gst_poll_wait API is being used and GST_FLOW_ERROR is returned if no activity
is found the concerned fd), I could see all the fragments getting generated. 

This is seen with gstreamer-1.6.0

4. gst-launch-1.0 filesrc location=/root/big_buck_bunny_270p.mp4 ! decodebin !
videoconvert ! x264enc ! splitmuxsink muxer="mp4mux name=muxer"
sink="curlftpsink user=test22 passwd=test22"
location=ftp://10.0.0.16/test_bunny.mp4 max-size-time=10000000000
max-size-bytes=18446744073709551615

This pipelne just exits with gstreamer-1.6.0

Regards,
Raghavendra Rao

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.