weird behaviour of rtsp element. Possible bug?
Locked
weird behaviour of rtsp element. Possible bug?
 
|
Hello guys,
I banged my head several days and I did not came to a conclusion. The full sources you can get form here: https://github.com/ggetchev/gst_test The file which is used is named gsttest2.c The media file is located in the same repository, named 1.movie.bz2 (you should bunzip2 it first). Use the makefile to build the example. The example is intended to be run against Gstreamer 1.0.4 (tagged, taken straight from the git repository, no snapshots, no tarballs). I have the following pipelines: Transmission pipeline: appsrc -- x264enc -- capsfilter -- rtph264depay -- udpsink Settings: appsrc properties: caps = video/x-raw; format=I420; framerate=20; width=480; height=640 format = GST_FORMAT_TIME, max-latency = min-latency = 0 size = -1 max-bytes = 5 * 480 * 640 * 3 / 2; x264enc: bitrate = 3 * 512 tune = 4 speed-preset = 3 threads = 1 bframes = 0 b-adapt = 0 cabac = 0 dct8x8 = 0 aud = 0 byte-stream=1 key-int-max = 10 quantizer = 50 vbv-buf-capacity = 0 capsfilter: caps = "video/x-h264;stream-format=byte-stream; alignment=au" udpsink: host = HOST port = PORT force-ipv4 = 1 sync = FALSE Reception pipeline: rtspsrc --- capsfilter(1) -- rtph264depay --- h264parse --- capsfilter(2) --- avdec_h264 --- appsink Settings: appsink: caps = "video/x-raw;format=BGRA" capsfilter(2): caps = "video/x-h264;alignment=au" capsfilter(1): caps = "application/x-rtp;media=video;payload=96;clock-rate=90000;encoding-name=H264" The only media that is used is video. The server used in that example is a Wowza Media Server. The transmission pipeline works fine. It's output can be observed with the use of QuickTime or VLC. Which proves both the server and the pipeline are working. However on the receiving pipeline some weird things happen: I get this assertion: (gsttest:7390): GStreamer-CRITICAL **: gst_segment_to_running_time: assertion `segment->format == format' failed This assertion however terminates the pipeline job. The backtrace (obtained after setting G_DEBUG="fatal-criticals") is: Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 0xb62ffb40 (LWP 7402)] 0xb7dd669d in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 (gdb) bt #0 0xb7dd669d in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 #1 0xb7dd6823 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 #2 0xb7dd686d in g_return_if_fail_warning () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0xb7f4e2c8 in gst_segment_to_running_time (segment=0xb71300b8, format=GST_FORMAT_TIME, position=1717999299) at gstsegment.c:476 #4 0xb6e11b57 in gst_rtp_base_depayload_chain (pad=0xb7108d70, parent=0xb7130000, in=0xb36f8658) at gstrtpbasedepayload.c:270 #5 0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3068204944, pad=0xb7108d70) at gstpad.c:3654 #6 gst_pad_push_data (pad=0xb712e138, type=3068204944, data=0xb36f8658) at gstpad.c:3871 #7 0xb7b0eeb1 in gst_base_transform_chain (pad=0xb712e000, parent=0xb71108c8, buffer=0xb36f8658) at gstbasetransform.c:2203 #8 0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3081825424, pad=0xb712e000) at gstpad.c:3654 #9 gst_pad_push_data (pad=0x8141018, type=3081825424, data=0xb36f8658) at gstpad.c:3871 #10 0xb7f1ba72 in gst_proxy_pad_chain_default (pad=0x8142028, parent=0x8141018, buffer=0xb36f8658) at gstghostpad.c:128 #11 0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3086072256, pad=0x8142028) at gstpad.c:3654 #12 gst_pad_push_data (pad=0xb3604b00, type=3086072256, data=0xb36f8658) at gstpad.c:3871 #13 0xb645a54d in gst_rtp_dec_chain_rtp (pad=0xb3604140, parent=0xb3601000, buffer=0xb36f8658) at gstrtpdec.c:532 #14 0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3058016688, pad=0xb3604140) at gstpad.c:3654 #15 gst_pad_push_data (pad=0xb712eea0, type=3058016688, data=0xb36f8658) at gstpad.c:3871 #16 0xb7b04ffe in gst_base_src_loop (pad=0xb712eea0) at gstbasesrc.c:2710 #17 0xb7f5cf38 in gst_task_func (task=0xb6335bc8) at gsttask.c:316 #18 0xb7f5e198 in default_func (tdata=0xb6301090, pool=0x805f410) at gsttaskpool.c:70 #19 0xb7df3047 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #20 0xb7df26b3 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #21 0xb7b7cd4c in start_thread (arg=0xb62ffb40) at pthread_create.c:308 #22 0xb7cbfd3e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 It is obvious a media segment has a format of GST_FORMAT_UNDEFINED but the expected format is GST_FORMAT_TIME After debugging on the rtsp element I found out that by some reason a RECONFIGURE event is pushed. However the reception pipeline is not being reconfigured - all its elements are created and added at the same time. All links are made between them. Except the link rtsp -- capsfilter(1), obviously because rtsp element has no pads. The link between the rtsp element and the capsfilter(1) is made upon pad-added signal occurrence. The RECONFIGURE event comes shortly after the link rtsp -- capsfilter is established. After a short talk with Tim on the Gstreamer IRC channel he stated that this might be a bug. However I am not sure whether I do something wrong or that is a real bug. The case is trivial, IMHO. Can someone help me? Regards, Vahan _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
weird behaviour of rtsp element. Possible bug? Follow up (yes, it is a bug).
|
|
Hello again, guys. Today I saw that this assertion: GStreamer-CRITICAL **: gst_segment_to_running_time: assertion `segment->format == format' failed remains valid even with the classic usage of get-launch (Gstreamer 1.0.4): gst-launch-1.0 rtspsrc location=rtsp://bbs.darktech.org:1935/live/iphone.sdp ! capsfilter caps=application/x-rtp,media=video,payload=96,clock-rate=90000,encoding-name=H264 ! rtph264depay ! h264parse ! capsfilter caps=video/x-h264,alignment=au ! avdec_h264 ! filesink location=./bla.movie Just before that call you need to start the executable built from that git repository: https://github.com/ggetchev/gst_test You can initiate the stream by using the command line: ./gsttest <file> --no-reception Where <file> is the bunzip2-ed file 1.move.bz2 from the same repository. I believe this is a bug in Gstreamer. Regards, G On Dec 21, 2012, at 2:18 AM, Guetcho Guetchev <[hidden email]> wrote: > Hello guys, > > I banged my head several days and I did not came to a conclusion. > The full sources you can get form here: https://github.com/ggetchev/gst_test > The file which is used is named gsttest2.c > The media file is located in the same repository, named 1.movie.bz2 (you should bunzip2 it first). > > Use the makefile to build the example. > The example is intended to be run against Gstreamer 1.0.4 (tagged, taken straight from the git repository, no snapshots, no tarballs). > > I have the following pipelines: > > Transmission pipeline: > > appsrc -- x264enc -- capsfilter -- rtph264depay -- udpsink > > > Settings: > > appsrc properties: > caps = video/x-raw; format=I420; framerate=20; width=480; height=640 > format = GST_FORMAT_TIME, > max-latency = min-latency = 0 > size = -1 > max-bytes = 5 * 480 * 640 * 3 / 2; > > x264enc: > bitrate = 3 * 512 > tune = 4 > speed-preset = 3 > threads = 1 > bframes = 0 > b-adapt = 0 > cabac = 0 > dct8x8 = 0 > aud = 0 > byte-stream=1 > key-int-max = 10 > quantizer = 50 > vbv-buf-capacity = 0 > > capsfilter: > caps = "video/x-h264;stream-format=byte-stream; alignment=au" > > udpsink: > host = HOST > port = PORT > force-ipv4 = 1 > sync = FALSE > > > Reception pipeline: > > rtspsrc --- capsfilter(1) -- rtph264depay --- h264parse --- capsfilter(2) --- avdec_h264 --- appsink > > Settings: > > appsink: > caps = "video/x-raw;format=BGRA" > > capsfilter(2): > caps = "video/x-h264;alignment=au" > > capsfilter(1): > caps = "application/x-rtp;media=video;payload=96;clock-rate=90000;encoding-name=H264" > > The only media that is used is video. > > The server used in that example is a Wowza Media Server. The transmission pipeline works fine. It's output can be observed with the use of QuickTime or VLC. Which proves both the server and the pipeline are working. > > However on the receiving pipeline some weird things happen: > I get this assertion: > > (gsttest:7390): GStreamer-CRITICAL **: gst_segment_to_running_time: assertion `segment->format == format' failed > This assertion however terminates the pipeline job. > > The backtrace (obtained after setting G_DEBUG="fatal-criticals") is: > > Program received signal SIGTRAP, Trace/breakpoint trap. > [Switching to Thread 0xb62ffb40 (LWP 7402)] > 0xb7dd669d in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 > (gdb) bt > #0 0xb7dd669d in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #1 0xb7dd6823 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #2 0xb7dd686d in g_return_if_fail_warning () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #3 0xb7f4e2c8 in gst_segment_to_running_time (segment=0xb71300b8, format=GST_FORMAT_TIME, position=1717999299) at gstsegment.c:476 > #4 0xb6e11b57 in gst_rtp_base_depayload_chain (pad=0xb7108d70, parent=0xb7130000, in=0xb36f8658) at gstrtpbasedepayload.c:270 > #5 0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3068204944, pad=0xb7108d70) at gstpad.c:3654 > #6 gst_pad_push_data (pad=0xb712e138, type=3068204944, data=0xb36f8658) at gstpad.c:3871 > #7 0xb7b0eeb1 in gst_base_transform_chain (pad=0xb712e000, parent=0xb71108c8, buffer=0xb36f8658) at gstbasetransform.c:2203 > #8 0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3081825424, pad=0xb712e000) at gstpad.c:3654 > #9 gst_pad_push_data (pad=0x8141018, type=3081825424, data=0xb36f8658) at gstpad.c:3871 > #10 0xb7f1ba72 in gst_proxy_pad_chain_default (pad=0x8142028, parent=0x8141018, buffer=0xb36f8658) at gstghostpad.c:128 > #11 0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3086072256, pad=0x8142028) at gstpad.c:3654 > #12 gst_pad_push_data (pad=0xb3604b00, type=3086072256, data=0xb36f8658) at gstpad.c:3871 > #13 0xb645a54d in gst_rtp_dec_chain_rtp (pad=0xb3604140, parent=0xb3601000, buffer=0xb36f8658) at gstrtpdec.c:532 > #14 0xb7f2b8aa in gst_pad_chain_data_unchecked (data=0xb36f8658, type=3058016688, pad=0xb3604140) at gstpad.c:3654 > #15 gst_pad_push_data (pad=0xb712eea0, type=3058016688, data=0xb36f8658) at gstpad.c:3871 > #16 0xb7b04ffe in gst_base_src_loop (pad=0xb712eea0) at gstbasesrc.c:2710 > #17 0xb7f5cf38 in gst_task_func (task=0xb6335bc8) at gsttask.c:316 > #18 0xb7f5e198 in default_func (tdata=0xb6301090, pool=0x805f410) at gsttaskpool.c:70 > #19 0xb7df3047 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #20 0xb7df26b3 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #21 0xb7b7cd4c in start_thread (arg=0xb62ffb40) at pthread_create.c:308 > #22 0xb7cbfd3e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 > > It is obvious a media segment has a format of GST_FORMAT_UNDEFINED but the expected format is GST_FORMAT_TIME > > After debugging on the rtsp element I found out that by some reason a RECONFIGURE event is pushed. However the reception pipeline is not being reconfigured - all its elements are created and added at the same time. > All links are made between them. Except the link rtsp -- capsfilter(1), obviously because rtsp element has no pads. The link between the rtsp element and the capsfilter(1) is made upon pad-added signal occurrence. > The RECONFIGURE event comes shortly after the link rtsp -- capsfilter is established. > > After a short talk with Tim on the Gstreamer IRC channel he stated that this might be a bug. However I am not sure whether I do something wrong or that is a real bug. > The case is trivial, IMHO. > Can someone help me? > > Regards, > Vahan > > > > > > > > _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: weird behaviour of rtsp element. Possible bug? Follow up (yes, it is a bug).
|
|
On Sat, 2012-12-22 at 00:19 +0200, Guetcho Guetchev wrote:
Hi, > Today I saw that this assertion: GStreamer-CRITICAL **: gst_segment_to_running_time: assertion `segment->format == format' failed > remains valid even with the classic usage of get-launch (Gstreamer 1.0.4): > > gst-launch-1.0 rtspsrc location=rtsp://bbs.darktech.org:1935/live/iphone.sdp ! capsfilter caps=application/x-rtp,media=video,payload=96,clock-rate=90000,encoding-name=H264 ! rtph264depay ! h264parse ! capsfilter caps=video/x-h264,alignment=au ! avdec_h264 ! filesink location=./bla.movie > > Just before that call you need to start the executable built from that git repository: https://github.com/ggetchev/gst_test > You can initiate the stream by using the command line: > > ./gsttest <file> --no-reception > Where <file> is the bunzip2-ed file 1.move.bz2 from the same repository. > > I believe this is a bug in Gstreamer. Yes, I'm quite certain it's a bug. (Did we talk about this on IRC a few days ago?) As such, it's best dealt with in bugzilla. Have you filed a bug yet? Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: weird behaviour of rtsp element. Possible bug? Follow up (yes, it is a bug).
|
|
Hello guys, Yes, a bug has been reported: https://bugzilla.gnome.org/show_bug.cgi?id=690632 Regards, Getcho
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |