RTP causes webrtc to have delay

[robert.corolea...@gmail.com]

Hello.
I ran into a problem where a RtpEndpoint connected to a WebRtc endpoint causes it to have delay when its connected to other WebRtc endpoints.
The scenario is this:
-One streamer has an WebRtc endpoint ready for one or more viewers;
-When viewers come they connect to the WebRtc endpoint of the broadcaster;
-Parallel with the creation of the WebRtc endpoint I also create two Rtp endpoints that I use for something else(one for Wowza and one for periodic screenshots) and connect them to the WebRtc endpoint of the streamer;
-The WebRtc endpoints of the viewers don't have anything to do with the Rtp endpoint(they don't connect to them);

If I skip the rpt part it works great and the webrtc has a small delay(aroud 0.3 sec), but if I create and connect the rtp to the streamer the following problems occur:
-If the streamer is on Chrome the viewers get an initial small delay that increases linearly(around 6 sec delay in 5 min of stream and 20 seconds in a couple of minutes);
-If the streamer is on Firefox the viewers get a pretty big delay from the start that increases and the video is also in slow motion;

I know that a webrtc-->rtp bridge eats more resources and I can see it in the server(20 or 30% more from a core per stream), but I didn't expect it to affect the webrtc-->webrtc bridge since that is independent from it.
I am using KMS 6.2 on Ubuntu 14 witch is installed on a remote dedicated server.

Should I expect this behavior to be normal for every stream that has a WebRtc to Rtp connection besides the WebRtc to WebRtc ones or can I do something about it without affecting the structure of the project(I would like to keep the rtp endpoints)?
Thank you in advance!
Corolea Robert

[Ivan Gracia]

No, I think you should see close to no delay. Could you explain a bit of your architecture? Where are your Wowza and KMS? What’s the CPU load when you connect the RTP endpoint?

It would be great if you could send us (as an attachment) the output of getGstreamerDot. That way we can have a look at your pipeline, and see if there are any extra transcodifications taking place.

Ivan Gracia

​

--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[robert.corolea...@gmail.com]

The architecture is rather basic. Its a one to many structure , which I explained it in my first post. There is a WebRtc endpoint of the streamer that connects to multiple viewers, the difference being that wen I create the WebRtc Endpoint of the broadcaster I also create two Rtp endpoints and proceed to connect the webrtc to them. One of them I use for Wowza and the other is for ffmpeg to create screenshots. Wowza and Kurento are on the same server and when I start a stream(no viewers, only the broadcaster which will have the 2 rtp endpoints) the cpu is around 100%(that's 1 from 12 xeon cores). I will atach the GStreamerDot info I gathered when I started the streame with no viewers.

[Ivan Gracia]

Those delays are due to the high load in your CPU. Now let's see why is that. Could you post the output of htop and top? 

Ivan Gracia

On Tue, Dec 8, 2015 at 1:22 PM, <robert.corolea...@gmail.com> wrote:

The architecture is rather basic. Its a one to many structure , which I explained it in my first post. There is a WebRtc endpoint of the streamer that connects to multiple viewers, the difference being that wen I create the WebRtc Endpoint of the broadcaster I also create two Rtp endpoints and proceed to connect the webrtc to them. One of them I use for Wowza and the other is for ffmpeg to create screenshots. Wowza and Kurento are on the same server and when I start a stream(no viewers, only the broadcaster which will have the 2 rtp endpoints) the cpu is around 100%(that's 1 from 12 xeon cores). I will atach the GStreamerDot info I gathered when I started the streame with no viewers.

--

[robert.corolea...@gmail.com]

htop:

  1  [||         2.5%]   4  [|          3.2%]     7  [||||      15.0%]   10 [||         6.3%]
  2  [|          0.6%]   5  [||         1.2%]     8  [||         1.9%]   11 [||||||    37.1%]
  3  [||         5.6%]   6  [|          1.2%]     9  [           0.0%]   12 [|||||||   36.3%]
  Mem[|||||||||||||||||||       3716/16047MB]     Tasks: 66, 1211 thr; 2 running
  Swp[                             0/16381MB]     Load average: 1.00 0.58 0.31
                                                  Uptime: 37 days, 21:35:07

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
14528 nobody     20   0 6765M  768M 22152 S 93.6  4.8  3h18:35 /usr/bin/kurento-media-server
20513 nobody     20   0 6765M  768M 22152 R 85.4  4.8  2:32.14 /usr/bin/kurento-media-server
26423 root       20   0 18.6G 1756M 17936 S 10.1 10.9  9h47:39 /usr/local/WowzaStreamingEngine/j
20348 root       20   0 27004  4796  2912 R  6.3  0.0  0:18.19 htop
 4042 root       20   0 25128  3176  2580 S  3.8  0.0  6h30:35 top
20496 nobody     20   0 6765M  768M 22152 S  5.0  4.8  0:08.14 /usr/bin/kurento-media-server
20515 nobody     20   0 6765M  768M 22152 S  1.3  4.8  0:01.50 /usr/bin/kurento-media-server
27490 root       20   0 18.6G 1756M 17936 S  0.6 10.9  0:08.34 /usr/local/WowzaStreamingEngine/j
20510 nobody     20   0 6765M  768M 22152 S  0.6  4.8  0:02.51 /usr/bin/kurento-media-server
20511 nobody     20   0 6765M  768M 22152 S  0.6  4.8  0:01.36 /usr/bin/kurento-media-server
20514 nobody     20   0 6765M  768M 22152 S  0.6  4.8  0:01.51 /usr/bin/kurento-media-server
27444 root       20   0 18.6G 1756M 17936 S  0.0 10.9  0:49.56 /usr/local/WowzaStreamingEngine/j
17693 user       20   0  103M  4884  3884 S  0.0  0.0 18:17.65 sshd: user@pts/4
26508 root       20   0 18.6G 1756M 17936 S  0.6 10.9 12:49.12 /usr/local/WowzaStreamingEngine/j
 2269 root       20   0 8744M  479M 18376 S  0.6  3.0 55:31.90 /usr/local/WowzaStreamingEngine/j
26507 root       20   0 18.6G 1756M 17936 S  0.0 10.9 12:52.88 /usr/local/WowzaStreamingEngine/j
26493 root       20   0 18.6G 1756M 17936 S  0.0 10.9 12:53.49 /usr/local/WowzaStreamingEngine/j
26491 root       20   0 18.6G 1756M 17936 S  0.0 10.9 12:56.55 /usr/local/WowzaStreamingEngine/j
26487 root       20   0 18.6G 1756M 17936 S  0.0 10.9 14:29.95 /usr/local/WowzaStreamingEngine/j
F1Help  F2Setup F3SearchF4FilterF5Tree  F6SortByF7Nice -F8Nice +F9Kill  F10Quit

top:

top - 15:28:54 up 37 days, 21:33,  4 users,  load average: 0.85, 0.36, 0.21
Tasks: 229 total,   1 running, 228 sleeping,   0 stopped,   0 zombie
%Cpu0  : 21.1 us,  5.3 sy,  0.0 ni, 73.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  4.5 us,  0.0 sy,  0.0 ni, 95.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  : 75.0 us,  0.0 sy,  0.0 ni, 25.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :  4.8 us,  0.0 sy,  0.0 ni, 95.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :  4.8 us,  0.0 sy,  0.0 ni, 95.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu8  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu9  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu10 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu11 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  16432480 total,  7697972 used,  8734508 free,   244392 buffers
KiB Swap: 16775164 total,        0 used, 16775164 free.  3648524 cached Mem
  scroll coordinates: y = 1/229 (tasks), x = 1/12 (fields)
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
14528 nobody    20   0 6927744 786824  22152 S  95.4  4.8 196:46.77 /usr/bin/kurento-media-server
20348 root      20   0   27004   4796   2912 R  19.1  0.0   0:11.23 htop
26423 root      20   0 18.609g 1.715g  17936 S  19.1 10.9 587:28.57 /usr/local/WowzaStreamingEngine/jav+
 4042 root      20   0   25128   3176   2580 R   4.8  0.0 390:30.12 top

This is with 1 stream open and no viewers.
I also tested with 10 streams open (and a couple of users connected to some of the streams) and there were around 2 cores used.

[robert.corolea...@gmail.com]

top:

top - 15:28:54 up 37 days, 21:33,  4 users,  load average: 0.85, 0.36, 0.21
Tasks: 229 total,   1 running, 228 sleeping,   0 stopped,   0 zombie
%Cpu0  : 21.1 us,  5.3 sy,  0.0 ni, 73.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  4.5 us,  0.0 sy,  0.0 ni, 95.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  : 75.0 us,  0.0 sy,  0.0 ni, 25.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :  4.8 us,  0.0 sy,  0.0 ni, 95.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :  4.8 us,  0.0 sy,  0.0 ni, 95.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu8  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu9  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu10 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu11 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  16432480 total,  7697972 used,  8734508 free,   244392 buffers
KiB Swap: 16775164 total,        0 used, 16775164 free.  3648524 cached Mem
  scroll coordinates: y = 1/229 (tasks), x = 1/12 (fields)
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
14528 nobody    20   0 6927744 786824  22152 S  95.4  4.8 196:46.77 /usr/bin/kurento-media-server
20348 root      20   0   27004   4796   2912 R  19.1  0.0   0:11.23 htop
26423 root      20   0 18.609g 1.715g  17936 S  19.1 10.9 587:28.57 /usr/local/WowzaStreamingEngine/jav+
 4042 root      20   0   25128   3176   2580 R   4.8  0.0 390:30.12 top

This is with 1 stream and no viewers.
I also tested with 10 stream(and a a a couple of viewers connected to some of the stream) and there were around 2 cores used.

[robert.corolea...@gmail.com]

Sorry for the triple post but it seems google groups deletes everything after the first code syntax.

These were with 1 stream and no viewers.

[Ivan Gracia]

Ok, so now we now it’s the media server :-) Could you share the logs? Please raise the log level to 5. In /etc/default/kurento-media-server-6.0, edit the key export GST_DEBUG=1,Kurento*:5, and change that 1 for a 5. Send us the logs of a session, please.

​

Ivan Gracia

--

[robert.corolea...@gmail.com]

I attached the log file. It is compressed because the original one was too big to upload.
I also had a similar problem on another project where I used kurento. The idea of that project was to get a RTSP stream, set an overlay image over it and server it to N viewers through WebRtc and Wowza(HLS). The problem was that when I made the player endpoint with the rtsp uri and connected it to the overlayfilter with an image the memory usage of the server would increase until the it froze, and I mean the whole server. I inspected my Node js code and I can't find anything that would make that happen. Its weird since that project is simpler than thus one all I do is connect the endpoint with an image overlay so I don't see where the code would be at fault.

[Ivan Gracia]

Thanks for those log. We'll have a look at them! We'll see what's going on there.

It's normal that when you use any computer vision algorithm, the CPU ramps up like crazy if you don't limit the framerate. Keep in mind that the algorithm will be applied to each frame, so having 30-60 fps going through such a filter is a resource-hungry thing.

Ivan Gracia

On Thu, Dec 10, 2015 at 8:41 AM, <robert.corolea...@gmail.com> wrote:

I attached the log file. It is compressed because the original one was too big to upload.
I also had a similar problem on another project where I used kurento. The idea of that project was to get a RTSP stream, set an overlay image over it and server it to N viewers through WebRtc and Wowza(HLS). The problem was that when I made the player endpoint with the rtsp uri and connected it to the overlayfilter with an image the memory usage of the server would increase until the it froze, and I mean the whole server. I inspected my Node js code and I can't find anything that would make that happen. Its weird since that project is simpler than thus one all I do is connect the endpoint with an image overlay so I don't see where the code would be at fault.

--

[Ivan Gracia]

Didn't find anything strange in the logs. Things you should/can try:

• Test each RTP endpoint separately, and see which one is consuming all resources. Make a test connecting one, disconnect it, and then make another test with the only the other one connected. You need to isolate which RTP is eating up your CPU.
• Test with different clients and resolutions. See if that makes a difference.

Please tell us the result of those tests.

Cheers,

Ivan Gracia

[robert.corolea...@gmail.com]

Ok. I did a fresh instalation of KMS and some testing. All tests were done with one viewer and one streamer at 1080p. I only mainly tested with that resolution because lower ones rarely caused delay and the CPU values were lower.
I also had some problems were just WebRtc Endpoints  raised the CPU usage to 200%, but that was solved after the fresh installation. Maybe the apt-get update/upgrade is not that good for getting a newer version.
The results of the tests are:
-The delay don't always happen because like I said it isn't big from the start. The stream usually starts with a small delay and then it escalates. That increase in delay is caused by the stream coming to the viewer in slow motion with leaves it behind the broadcaster. Sometimes that slow just appears occasionally and its hard to detect so you need to keep the stream open for several minutes to spot it, while other times it starts from the beginning or after some time but is just persists and doesn't go away so the lag will be easy to observer from the beginning. The delay always stay. Once a stream is left behind it never recovers.
-When the delay kicks in I can see that a core is always at 100%.
-Both RTP endpoints cause delay but the the one for ffmpeg is more likely to provoke it. Its weird since that Rtp has only video in the sdp that it processes and I only use it once in a while for the ffmpeg to create a screenshot out of it.
-Without the RtpEndpoints the CPU is at 20-30% and with them its around 200%(2 cores).
-Most of the CPU consumption is done by 2 kms proceses(one uses 60% of the total while the other 40%);
-The CPU consumption is higher when the streamer is on Firefox.
-With one 1080p stream open the Load average is around 1.8 and with 2 1080 streams its around 3.0;

The conclusion that I got is that high resolution streams cause a very high CPU consumption(around 150% per stream) and that creates the delay. I presume this is normal but the consumption seems really high for me.
The server on wich KMS is installed has an Intel Xeon X5650, 2,67GHz, 6 physical core with 2 logical cores per physical. If I want the server to be able to keep a reasonable number of streams they all would need to be at 640x480, since that resolution consumes almost as much CPU as a 1080p one without the RTP(around 20%).

Also, about the other project. I agree that an image filter would consume allot of resources, but a single rtsp with a image overlay filter to freeze the server doesn't seem right to me.

[Ivan Gracia]

Well, as we have always stated, transcoding FullHD certainly is resource hungry, and you are doing it twice (once per RTP) if you are negotiating different SDPs for your RTP endpoints. The thing is that there is only one thread for transcodifications, and if that thread is extremely busy, as with your case, everrything will have delays, even if there is no transcoding needed. What you could try is have two different KMS processes, one for webrtc and the other for the RTPs. Send media va webrtc from one instance to another, and that way your webrtc EPs will be isolated from your transcoding RTPs.

Also, about the other project. I agree that an image filter would consume allot of resources, but a single rtsp with a image overlay filter to freeze the server doesn't seem right to me.

Not much we can do there. The high resource consumption in the filter is because of the libraries used to analyse and transform the images. There's nothing we can do there, except advise you to lower the framerate (this really helps) and the resolution.

Ivan Gracia

--

[robert.corolea...@gmail.com]

I see. Could you explain what you mean by two KMS processes? Do I need 2 servers with KMS on each and then send the WebRtc from one to another by negotiating 2 WebRtc endpoints and make the second do the transcoding(because a second server is not a option now), or can I do it with 1 server? If its the later, how can I do it and wouldn't it consume more resources if there would be 2 KMS instances on the same server?

[Ivan Gracia]

You can use one server. Just create two different KMS process, each one listening on a different WS port. You will need to create two different kurento.conf.json files, and start the media server using the command /usr/bin/kurento-media-server -f <path-to-conf-file>. In order to create endpoints in the different instances, you will need to have two different KurentoClient instances.

​

Ivan Gracia

On Mon, Dec 14, 2015 at 9:04 AM, <robert.corolea...@gmail.com> wrote:

I see. Could you explain what you mean by two KMS processes? Do I need 2 servers with KMS on each and then send the WebRtc from one to another by negotiating 2 WebRtc endpoints and make the second do the transcoding(because a second server is not a option now), or can I do it with 1 server? If its the later, how can I do it and wouldn't it consume more resources if there would be 2 KMS instances on the same server?

--

[robert.corolea...@gmail.com]

I understand thank you.
The server got a better cpu and I did some more testing. It seems the delay is still present. With 1080p at 30fps I noticed that KMS has a parent process that creates a child with over 100% CPU and many other that are sleeping. and this was with only one stream.
Also, in order to connect two WebRtc endpoint from different instances do I need to negotiate the sdp and exchange ICE between them, or is there a better way?

[robert.corolea...@gmail.com]

It seems like the second instance of KMS doesn't work. I copied the .conf file and changed the ws port. After that I ran the command and started the second KMS with the new .conf file. In my code I changed the port to the new one and started a stream. I get no errors but the viewer doesn't get any video. Is there something more that I must do?

[Ivan Gracia]

Without seeing the code, can't tell. Basically, you need to create two different pipelines: one where you will instantiate all webrtc endpoints for viewers and presenter (+1 for sending media to the second KMS), and another one for one webrtc and two RTP endpoints. Try to get that working fist, and after that, negotiating the two webrtc endpoints that will exchange media between KMSs. Tell me if I explained this too lightly, or I should go more into detail.

Ivan Gracia

On Mon, Dec 14, 2015 at 1:20 PM, <robert.corolea...@gmail.com> wrote:

It seems like the second instance of KMS doesn't work. I copied the .conf file and changed the ws port. After that I ran the command and started the second KMS with the new .conf file. In my code I changed the port to the new one and started a stream. I get no errors but the viewer doesn't get any video. Is there something more that I must do?

--

[robert.corolea...@gmail.com]

Ok I managed to make it work. I should've just cloned the .conf file in the same dir with another name and not move it. My mistake(like always).
I also managed to make the 2 instances work and got WebRtc on one and Rtp on the other and the delay is gone on the WebRtcm. Thank you very much for your help.
One more question: is there a way to find out how much resources would I need to stream high resolution streams without the CPU going crazy, because right now on 1 stream ups 1 logical core to 100% and the server is pretty powerful?

[Ivan Gracia]

That should consume 1 CPU. Do you have there the two RTP endpoints, or just one? Could you check if just one eats up all the CPU? It could be that you are doing two different transcodifications for each RTP endpoint.

Ivan Gracia

--

[robert.corolea...@gmail.com]

After a short time with a stream open (with both rtp endpoints connected) htop shows me one of the cores at 100% and it stays until stream is closed. I kinda need two RtpEndpoint because if I tried making ffmpeg read from the one for Wowza it won't work. I guess a a sdp can't be read by two things at the same time. I'll try testing which one eats more.

[Ivan Gracia]

Try testing which one eats more, and also try using the same SDP template for both. You just need to change the IP and port.

Reducing the framerate will greatly improve. For that, you can add a capsfilter after the receiving webrtc in your "rtp KMS".

String command = "capsfilter caps=video/x-raw,framerate=10/1";
GStreamerFilter capsFilter = new GStreamerFilter.Builder(pipeline, command).withFilterType(FilterType.VIDEO).build();
webrtc.connect(capsFilter);
capsFilter.connect(rtp1);
capsFilter.connect(rtp2);

​

Ivan Gracia

On Mon, Dec 14, 2015 at 4:51 PM, <robert.corolea...@gmail.com> wrote:

After a short time with a stream open (with both rtp endpoints connected) htop shows me one of the cores at 100% and it stays until stream is closed. I kinda need two RtpEndpoint because if I tried making ffmpeg read from the one for Wowza it won't work. I guess a a sdp can't be read by two things at the same time. I'll try testing which one eats more.

--

[robert.corolea...@gmail.com]

Thanks but, can you give me an Node js example for creating a capsfilter?

[Ivan Gracia]

It´s the same as with any other endpoint.

var options = { command : "capsfilter caps=video/x-raw,framerate=10/1" }
pipeline.create('GStreamerFilter', options, function(error, filter){});

​

Ivan Gracia

On Tue, Dec 15, 2015 at 8:02 AM, <robert.corolea...@gmail.com> wrote:

Thanks but, can you give me an Node js example for creating a capsfilter?

--

[robert.corolea...@gmail.com]

I tried the capsfilter for the webrtc that connect to the rtp for screenshot. The fps limit I set was 1/1 since I don't need a much higher one since I'm only using that RtpEndpoint to create screenshot with ffmpeg from time to time. Can I also limit the resolution with that?
P.S. Unrelated question: if I release an enpoint, do I still need to disconnect it from whatever it was connected to, or does it disconnect automatically (or disconnect another endpoint that was connected to it)?

[Ivan Gracia]

Yes, you can also limit the size. Use this to keep the aspect ratio.

var command = "capsfilter caps=video/x-raw,pixel-aspect-ratio=1/1,width=[" + width + ",30], framerate=" + framerate + "/1"

Releasing an endpoint will disconnect everything, don’t worry!

​

Ivan Gracia

On Wed, Dec 16, 2015 at 4:25 PM, <robert.corolea...@gmail.com> wrote:

I tried the capsfilter for the webrtc that connect to the rtp for screenshot. The fps limit I set was 1/1 since I don't need a much higher one since I'm only using that RtpEndpoint to create screenshot with ffmpeg from time to time. Can I also limit the resolution with that?
P.S. Unrelated question: if I release an enpoint, do I still need to disconnect it from whatever it was connected to, or does it disconnect automatically (or disconnect another endpoint that was connected to it)?

--

[robert.corolea...@gmail.com]

I see. Thanks!
I managed to make it work somwhow, but its seems the '30' value must be bigger than width, so why does the width option take 2 arguments(as an array) and how should I approach this?
For now I made something like this: width=[640, 641], so that the second value is bigger than the first one.

[Ivan Gracia]

Sorry, the interval is inverted. Should be var command = "capsfilter caps=video/x-raw,pixel-aspect-ratio=1/1,width=[30, " + width + "], framerate=" + framerate + "/1"

Ivan Gracia

--