window too big with resolution greater than 352 × 288

[Francesco Argese]

I have this problem: i'm trying to send towards udp a stream encoded
with theora from Linux and to receive it on a windows machine (always
with gstreamer) in a ARToolKit application (it do only a
gst_parse_launch (pipeline_string, &error) to recover the video). The
version of gstreamer used on Windows was cross-compiled by me (version
0.10.20 for core and base and 0.10.9 good, 0.10.8 bad, 0.10.9 ugly,
ffmpeg lacks because i think it could require more time to
cross-compile it). The two pipeline (reported below) works well if i
use a low resolution (max 352 × 288). If i try with a greater
resolution, Gstreamer recognize a big window (1835099506 x 1327526501
) but don't show me errors and don't open the window. The problem is
that i have no debug informations on windows so i don't know how to
find the possible error. I have built the same configuration with two
Linux machine and it works well with all known resolution, higher than
320x240. I use the client with ARToolKit but the ARToolKit code
doesn't give any error, too. The only signal seems to be the big
dimension of the window.

My two pipeline are the following:

1)gst-launch-0.10-0 videotestsrc !
video/x-raw-yuv,format=\(fourcc\)I420,width=640,height=480 ! theoraenc
! video/x-theora ! gdppay ! application/x-gdp ! udpsink host=127.0.0.1
port=5000

2)udpsrc port=5000 ! application/x-gdp ! gdpdepay ! video/x-theora !
theoradec ! video/x-raw-yuv,format=\(fourcc\)I420,width=640,height=480
! ffmpegcolorspace ! capsfilter
caps=video/x-raw-rgb,bpp=32,endianness=4321,red_mask=65280,green_mask=16711680,blue_mask=-16777216
! identity name=artoolkit sync=false ! fakesink

I'm trying it on localhost (both on Windows so) launching first 2), then 1)
What could be the problem? Any suggestion?

Thanks
Francesco Argese

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[michael smith-6-3]

On Thu, Sep 11, 2008 at 1:46 AM, Francesco Argese <[hidden email]> wrote:

>
> My two pipeline are the following:
>
> 1)gst-launch-0.10-0 videotestsrc !
> video/x-raw-yuv,format=\(fourcc\)I420,width=640,height=480 ! theoraenc
> ! video/x-theora ! gdppay ! application/x-gdp ! udpsink host=127.0.0.1
> port=5000
>
> 2)udpsrc port=5000 ! application/x-gdp ! gdpdepay ! video/x-theora !
> theoradec ! video/x-raw-yuv,format=\(fourcc\)I420,width=640,height=480
> ! ffmpegcolorspace ! capsfilter
> caps=video/x-raw-rgb,bpp=32,endianness=4321,red_mask=65280,green_mask=16711680,blue_mask=-16777216
> ! identity name=artoolkit sync=false ! fakesink

GDP (which is what you're using, with gdppay and gdpdepay) is not
designed for lossy transports.

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.

Use a TCP transport, or a network protocol designed to handle lossy transports.

Mike

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Francesco Argese]

> 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.

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).

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Aurelien Grimaud (elzz)]

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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>  

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Francesco Argese]

Ok. I have resolved my problem with these two pipelines:

Receiver:
gst-launch-0.10 -v udpsrc port=5000 ! capsfilter
caps="application/x-rtp,media=(string)video,clock-rate=90000,encoding-name=(string)MP4V-ES,profile-level-id=(string)1,payload=(int)96"
! rtpmp4vdepay ! capsfilter
caps="video/mpeg,width=(int)640,height=(int)480,framerate=(fraction)30/1,mpegversion=4,systemstream=(boolean)false"
!!ffdec_mpeg4! ffmpegcolorspace ! directdrawsink

Sender:
gst-launch-0.10 -v videotestsrc  is-live=true !
video/x-raw-rgb,width=640,height=480 ! ffmpegcolorspace ! ffenc_mpeg4
! rtppmp4vpay ! udpsink host=127.0.0.1 port=5000

Thanks all
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel