[gst-devel] window too big with resolution greater than 352 × 288
Aurelien Grimaud
gstelzz at yahoo.fr
Sun Sep 14 19:29:12 CEST 2008
Hi,
Francesco Argese a écrit :
>> Probably the higher resolution means your encoded frames are larger,
>> perhaps exceeding the MTU on the network, or just being dropped since
>> you're using UDP.
>>
>
> Yes, probably this is the problem. I can confirm it because now I have
> tried with a version of gstreamer including debug (the same posted in
> this mailing and compiled with OABuild) and the application give me
> the following error:
>
> ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Could
> not read from resource.
> Additional debug info:
> ..\..\gst\udp\gstudpsrc.c(563): gst_udpsrc_create ():
> /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
> receive error -1 (WSA error: 10040)
>
> Capturing udp packets toward the network analyzer Wireshark, I have
> understand that the packet exceeding a size near to 1500 are discarded
> by Windows (then return that error reported on this site
> (http://www.ultrabac.com/kb/ubq000192.htm) as message too long). With
> low resolution the packet are always under this limit so it works
> well.
>
> The error WSA error: 10040 is the following: A message sent on a
> datagram socket was larger than the
> internal message buffer or some other network limit, or the
> buffer used to receive a datagram into was smaller than
> the datagram itself.
>
>
>> Use a TCP transport, or a network protocol designed to handle lossy transports.
>>
>
> I haven't tcp plugins in my gstreamer distribution on windows (i have
> checked it with a gst-inspect-0.10 | grep tcp). I have tried to use a
> different payloader also with codec h263 or mpeg4 but i have the
> following error at the receiver (it seems that the udpsrc problem is
> resolved in this manner):
>
> $ gst-launch-0.10 -v udpsrc port=5000 ! application/x-rtp,media=video,payload=9
> 6,encoding-name=MP4V-ES ! rtpmp4vdepay ! video/mpeg,mpegversion=4,systemstream=
> false ! ffdec_mpeg4 ! ffmpegcolorspace ! directdrawsink
> New clock: GstSystemClock
> Setting pipeline to PAUSED ...
> Pipeline is live and does not need PREROLL ...
> Setting pipeline to PLAYING ...
> **
> ** ERROR:(..\..\libs\gst\base\gstbasetransform.c:1141):gst_base_transform_prepare_output_buffer:
> assertion failed: (*out_buf != NULL)
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
>
>
Check out
http://bugzilla.gnome.org/show_bug.cgi?id=545853
http://bugzilla.gnome.org/show_bug.cgi?id=551509
the assertion failed problem is due to capsfilter.
Specify full caps after udpsrc to get it working.
clock-rate is missing.
> The pipeline to send this flow is the following:
>
> gst-launch-0.10 videotestsrc ! video/x-raw-rgb,width=640,height=480 ! ffmpegc
> olorspace ! video/x-raw-yuv ! ffenc_mpeg4 ! video/mpeg,width=640,height=480,mpe
> gversion=4,systemstream=false ! rtpmp4vpay ! application/x-rtp,media=video,payl
> oad=96,encoding-name=MP4V-ES ! udpsink host=10.10.0.1 port=5000
> New clock: GstSystemClock
>
> It seems that the buffer is not initialized. What could be the
> problem? Probably the rtp payloader? I have tried also with other
> encoders (h263, h263p) and their relative payloaders and depayloaders
> with the same result. These does not work also with lower resolution
> (the problem is different).
>
>
Is first colorspace really necessary ?
videotestsrc may produce x-raw-yuv.
Try videotestsrc ! video/x-raw-yuv,width=640,height=480 ! ffenc_mpeg4 ...
> Another question: is there a manner to specify the size of the sending
> udp packet? It probably could resolve my problems with gdppay that
> work well with small resolution (on Linux also with greater
> resolution).
>
> Thanks
> Francesco
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
More information about the gstreamer-devel
mailing list