Problem with rtspsrc->rtph264depay->qtmux->fil
Locked
 
|
Hi,
I have the following pipeline to capture a video streamed from an RTSP server. gst-launch rtspsrc location=rtsp://192.168.1.64:554/video0 ! rtph264depay ! qtmux ! filesink location=b.mov I got the following error: gstbasesrc.c(2378): gst_base_src_loop (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc0: streaming task paused, reason not-negotiated (-4) According to another post (http://old.nabble.com/rtsp---h264---mp4mux-td23866919.html#a23866919), I changed the pipeline to: gst-launch rtspsrc location=rtsp://192.168.1.64:5554/video0 ! rtph264depay ! video/x-h264, width=640, height=480, framerate=15/1 ! qtmux ! filesink location=b.mov I got this error: gstqtmux.c(1347): gst_qt_mux_add_buffer (): /GstPipeline:pipeline0/GstQTMux:qtmux0: Failed to determine time to mux. I tried this pipeline, by setting byte-stream property of rtph264depay to false: gst-launch rtspsrc location=rtsp://192.168.1.64:5554/video0 ! rtph264depay byte-stream=false ! video/x-h264, width=640, height=480, framerate=15/1 ! qtmux ! filesink location=b.mov I got the same error, Failed to determine time to mux. I also tried ffmux_mp4. The pipeline can continue, but it looks like that only the access unit delimiter RBSP is captured. To verify the function of the server, I tried following 2 pipelines and both are working properly. gst-launch rtspsrc location=rtsp://192.168.1.64:554/video0 ! rtph264depay ! ffdec_h264 ! xvimagesink gst-launch rtspsrc location=rtsp://192.168.1.64:554/video0 ! rtph264depay ! filesink location=c.mov Can anyone familiar with the behavior of the quicktime mux give some hint on what the problem might be? Thanks, Yiliang |
Re: Problem with rtspsrc->rtph264depay->qtmux->fil
|
|
Hi,
Yiliang Bao a écrit : > I got this error: > > gstqtmux.c(1347): gst_qt_mux_add_buffer (): > /GstPipeline:pipeline0/GstQTMux:qtmux0: > Failed to determine time to mux. i got the same error and have had no success using qtmux or mp4mux. > I also tried ffmux_mp4. The pipeline can continue, but it looks like that > only the access unit delimiter RBSP is captured. I use ffmux_mp4 with success in my pipeline. Could you provide yours to check what's wrong? Florian ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
Hi Florian,
Thanks for replying to my message. ffmux_mp4 did not work for me either when I posted the original message. All I got are access unit delimiter RBSP's. An acces unit delimiter RBSP is something like 000000010910 for the I frame, and 000000010030 for the non-I frame. Since the AU delimiter has the same timestamp as the following NAL, I was wondering whether that was a problem. And indeed it was. In the function compute_pkt_fields2() in file: /gst-ffmpeg-0.10.9/gst-libs/ext/ffmpeg/libavformat/utils.c I changed the following line to allow two consecutive packets have same time stamp: #if 1 if(st->cur_dts && st->cur_dts != AV_NOPTS_VALUE && st->cur_dts > pkt->dts){ #else if(st->cur_dts && st->cur_dts != AV_NOPTS_VALUE && st->cur_dts >= pkt->dts){ #endif Now I can capture video correctly. I am wondering if anyone working on ffmpeg can verify whether this fix is a valid solution. Maybe I should post a separate message on ffmux_mp4. However, this does not solve my problem. I still need to make qtmux work since it supports the audio codec which ffmux_mp4 does not support. Thanks, Yiliang On Tue, Nov 24, 2009 at 12:05 AM, florian iragne <[hidden email]> wrote: Hi, ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Problem with rtspsrc->rtph264depay->qtmux->fil
|
|
On Tue, Nov 24, 2009 at 7:19 PM, Yiliang Bao <[hidden email]> wrote: Hi Florian, Some fixes were pushed to qtmux/mp4mux for improving timestamps and durations handling yesterday. Could you retry and check if it works now?
-- Thiago Sousa Santos ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
|
|
Hi Thiago,
Thanks for the information. I just tried the latest code, but it did not work either. The mux jumped to label "no_time" just as the previous version did. if (buf == NULL || !GST_BUFFER_TIMESTAMP_IS_VALID (last_buf) || !GST_BUFFER_TIMESTAMP_IS_VALID (buf) || GST_BUFFER_TIMESTAMP (buf) < GST_BUFFER_TIMESTAMP (last_buf)) { if (!GST_BUFFER_DURATION_IS_VALID (last_buf)) { /* be forgiving for some possibly last upstream flushed buffer */ if (buf) goto no_time; If I commented out the last two lines, the file can be captured now. The captured video can be played correctly by VLC, but I observed some jerkiness when I played it in totem. Could that be a problem in qtdemux, since totem is based on gstreamer, and VLC is not? The captured file is attached to the email if you are interested in looking into the details. Here is the a trace from playback "gst-launch filesrc location=a_30.mov ! decodebin ! xvimagesink). Please note some frames have the same timestamp. 0:00:01.972883491 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff -16495981, timestamp 0:00:01.692000000 0:00:01.999683398 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff -11739020, timestamp 0:00:01.717000000 0:00:02.030359901 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff -21690153, timestamp 0:00:01.753333333 0:00:02.064175070 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff -29498016, timestamp 0:00:01.792000000 0:00:02.097518598 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff -28982855, timestamp 0:00:01.825333333 0:00:02.130852310 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff -29174458, timestamp 0:00:01.858666666 0:00:02.164338707 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff -28967572, timestamp 0:00:01.892000000 0:00:02.189270327 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff -20473058, timestamp 0:00:01.917000000 0:00:02.211482344 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff 4209870, timestamp 0:00:01.917000000 0:00:02.214562919 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff 26280241, timestamp 0:00:01.917000000 0:00:02.217906820 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff 29624745, timestamp 0:00:01.917000000 0:00:02.221188594 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff 32906654, timestamp 0:00:01.917000000 0:00:02.224190717 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff 35908727, timestamp 0:00:01.917000000 0:00:02.262820788 8491 0x9e30800 INFO GST_EVENT gstevent.c:839:gst_event_new_qos: creating qos proportion 0.000000, diff -34995449, timestamp 0:00:01.990666666 I looked at "stts" atom. The duration of a sample is not fixed at 100 as it should be, but they are varying around that value. I guess it is because the duration is calculated from the timestamp during running time in qtmux. The samples that have zero duration are RBSP's that do not have frame data. Examples are SPS/PPS/SEI/Access Unit Delimiter, etc. I guess the actual problem is in rtph264depay. Similar to a problem fixed in v4l2src, rtph264depay does not provide a valid duration either. I think the best solution is that every element generates duration correctly. But if I compare ffmux_mp4 and qtmux, ffmux_mp4 is more forgiving by setting duration to 0 (line 645 ~ 650) in gstffmpegmux.c. Thanks, Yiliang On Thu, Nov 26, 2009 at 3:27 AM, [hidden email] <[hidden email]> wrote:
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |