[gst-devel] Problem with rtspsrc->rtph264depay->qtmux->filesink
Yiliang Bao
yiliangb at gmail.com
Thu Nov 26 23:25:41 CET 2009
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, thiagossantos at gmail.com <
thiagossantos at gmail.com> wrote:
>
>
> On Tue, Nov 24, 2009 at 7:19 PM, Yiliang Bao <yiliangb at gmail.com> wrote:
>
>> 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 <
>> florian.iragne at viewsurf.com> wrote:
>>
>>> 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.
>>>
>>
> Some fixes were pushed to qtmux/mp4mux for improving timestamps and
> durations handling yesterday. Could you retry and check if it works now?
>
>
>>
>>> > 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
>>> gstreamer-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>>
>
>
> --
> 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
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20091126/6c0d9904/attachment.htm>
More information about the gstreamer-devel
mailing list