GNOME Bugzilla – Bug 613866
Failed to configure latency warning on N900
Last modified: 2010-04-01 22:54:21 UTC
I want record a mp4 video with GStreamer,using this gst-launch command: "gst-launch v4l2camsrc device=/dev/video0 ! video/x-raw-yuv,width=320,height=240 ! ffmpegcolorspace ! dspmp4venc ! hantromp4mux ! filesink location=blah.mp4 " on the N900. but a error occured: ------------------------------------------------------------------- New clock: GstSystemClock WARNING: from element /GstPipeline:pipeline0: Internal GStreamer error: clock problem. please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. Additional debug info: gstbin.c(2224): gst_bin_do_latency_func (): /GstPipeline:pipeline0: Failed to configure latency of 0:00:00.000000000 ------------------------------------------------------------------- In the file gst-plugins-bad-0.10.15/tests/examples/gst-camera-perf.c,there is a introduction how to record video and picture on maemo, but "dspmpeg4enc" can not be found, so I use "dspmp4venc" instead, and the muxer is hantromp4mux or ffmux_mp4, but the error appeared. and the recorded video file can not be played in N900. so I want to know how this happened. only this way can record video efficient, how can I record a mp4 vidoe correctly with dspmp4venc and hantromp4mux (or ffmux_mp4). thank you very much.
This looks much like a bug in the Maemo specific plugins. Could you attach a debug log with GST_DEBUG=5 GST_DEBUG_NO_COLOR=1 gst-launch v4l2camsrc device=/dev/video0 ! video/x-raw-yuv,width=320,height=240 ! ffmpegcolorspace ! dspmp4venc ! hantromp4mux ! filesink location=blah.mp4 &> log
The Meamo specific plugins don't forward the LATENCY event and need to be fixed.
Right, that's what I thought too. You should probably file a bug in the maemo bug tracker.
I just tested this. While I agree that hantromp4mux should be fixed (well you can use qtmux which maemo will use in maemo6), this is not fatal. You can probably not play the video as you seem to terminate recordign with Ctrl-c. If you record with gst-launch, you need to use the -e option to ensure that the file is properly terminated.
(In reply to comment #1) > This looks much like a bug in the Maemo specific plugins. > Could you attach a debug log with > GST_DEBUG=5 GST_DEBUG_NO_COLOR=1 gst-launch v4l2camsrc device=/dev/video0 ! > video/x-raw-yuv,width=320,height=240 ! ffmpegcolorspace ! dspmp4venc ! > hantromp4mux ! filesink location=blah.mp4 &> log hi, Sebastian Dröge, I can't get the right log, because the log is empty.
(In reply to comment #2) > The Meamo specific plugins don't forward the LATENCY event and need to be > fixed. Hi,Wim Taymans, firstly thank you. you means the meamo plugin hantromp4mux has bugs itself? but the N900's camera is OK, it can record MP4 video correctly.
Hello, all. as your means the plugin hantromp4mux is not a correct plugin, so what can I do with MP4, I want record it more efficient, other method with ffenc_mpeg4 and ffmux_mp4 ( or ffenc_mpeg2video & ffmux_mpeg2video) is inefficient.
(In reply to comment #5) > (In reply to comment #1) > > This looks much like a bug in the Maemo specific plugins. > > Could you attach a debug log with > > GST_DEBUG=5 GST_DEBUG_NO_COLOR=1 gst-launch v4l2camsrc device=/dev/video0 ! > > video/x-raw-yuv,width=320,height=240 ! ffmpegcolorspace ! dspmp4venc ! > > hantromp4mux ! filesink location=blah.mp4 &> log > > hi, Sebastian Dröge, I can't get the right log, because the log is empty. you can't becasue on a released device the logging is disabled. You would need to build gstreamer yourself. (In reply to comment #6) > (In reply to comment #2) > > The Meamo specific plugins don't forward the LATENCY event and need to be > > fixed. > > Hi,Wim Taymans, firstly thank you. you means the meamo plugin hantromp4mux > has bugs itself? but the N900's camera is OK, it can record MP4 video > correctly. yes, hantromp4mux should be fixed to forward the latency event. File a bug on bugzilla.maemo.org if you want. Please read the info I gave to you in comment #4 again. The camera pplication uses the same elements you use. There is no fatal issue that would block you on recording clips with the software you have right now.
Actually both hantromp4mux and the dspencoders have only event functions on the sink pads and both have a default: ret = gst_pad_event_default (pad, event); statement. v4l2camsrc is identical to v4l2src intems of event handling. It answers the LATENCY query.
(In reply to comment #9) > Actually both hantromp4mux and the dspencoders have only event functions on the > sink pads and both have a > default: > ret = gst_pad_event_default (pad, event); > statement. v4l2camsrc is identical to v4l2src intems of event handling. It > answers the LATENCY query. Be that as it may, it still looks like the problem is in hantromp4mux: gstpad.c:4937:gst_pad_send_event:<mp4mux0:src> have event type latency gstpad.c:3430:gst_pad_event_default:<mp4mux0:src> default event handler gstpad.c:3335:gst_pad_event_default_dispatch:<mp4mux0:src> Sending event 0xac860 (latency) to all internally linked pads gstpad.c:3131:gst_pad_iterate_internal_links_default:<mp4mux0:src> Making iterator gstpad.c:3366:gst_pad_event_default_dispatch:<mp4mux0:src> sending event 0xac860 (latency) to one sink pad mp4mux0:audio gstpad.c:4760:gst_pad_push_event:<mp4mux0:audio> event: latency gstpad.c:4834:gst_pad_push_event:<mp4mux0:audio> Dropping event because pad is not linked gstpad.c:4965:gst_pad_send_event:<mp4mux0:src> sent event, result 0 gstpad.c:4820:gst_pad_push_event:<filesink0:sink> sent event to peerpad <mp4mux0:src>, result 0 So it tries to forward the event on the unlinked audio pad, and that fails and so it returns FALSE. So something either needs to accumulate properly and/or forward the event properly. Or it should use request pads so there aren't input pads that aren't used hanging around. (And btw, it also should register itself with GType "GstMp4Mux" btw). @xiaohui: as Stefan said, it's only a warning, you can ignore it. If it bothers you, you can feed some audio into hantromp4mux (e.g. ... ! hantromp4mux name=mux ! filesink location=foo.mp4 audiotestsrc ! audioconvert ! nokiaaacenc ! mux. ), then it will go away.
(In reply to comment #10) > So it tries to forward the event on the unlinked audio pad, and that fails and > so it returns FALSE. So something either needs to accumulate properly and/or > forward the event properly. Or it should use request pads so there aren't input > pads that aren't used hanging around. (And btw, it also should register itself > with GType "GstMp4Mux" btw). > You mean it should *not*. I guess you meant that it would be better to register it as "HantroMp4Mux" or something like it, which it true.
> > And btw, it also should register itself with GType "GstMp4Mux" (...) > > > You mean it should *not*. I guess you meant that it would be better to register > it as "HantroMp4Mux" or something like it, which it true. Yes, sorry :)