> I have a HD webcam connected to my pandaboard, and I want to do
> streaming with vlc. The streaming works, but according to "top", it
> consumes 115% cpu (I wonder how that's even possible?), and it seems
> the stream drops some frames now and then.

> This is the vlm.conf file I use:

> --
> new camNumber2 broadcast enabled
> setup camNumber2 input v4l2:///dev/video2:width=640:height=480
> setup camNumber2 output
> #transcode{vcodec=mp2v,acodec=none,vb=5000}:standard{access=http,mux=ogg,ds t=0.0.0.0:8080}
> control camNumber2 play
> --

> I reduced the resolution which seems to solve some issues, but cpu
> usage is still very high. My webcam is a logitech c525 with native
> resolution of 1280x720 (720).

> Since the stream is only used on my own network, I want to settle for
> higher bandwith use, if I just can get decent image quality without
> overloading my cpu all the time.

> I'm using the Ubuntu pandaboard image (without the omap-multimedia
> extensions). I doubt that those extensions will help me, since they
> are for video-decoding, not encoding (right?).

> I also used mp4v encoding, but that also occupies a lot of cpu power.

> Thanks,

> Jeroen.

> > I have a HD webcam connected to my pandaboard, and I want to do
> > streaming with vlc. The streaming works, but according to "top", it
> > consumes 115% cpu (I wonder how that's even possible?), and it seems
> > the stream drops some frames now and then.

> without doing anything special, you would be using ARM CPU for
> encoding and image processing, so nothing surprising really ;-)

> > This is the vlm.conf file I use:

> > --
> > new camNumber2 broadcast enabled
> > setup camNumber2 input v4l2:///dev/video2:width=640:height=480
> > setup camNumber2 output

> #transcode{vcodec=mp2v,acodec=none,vb=5000}:standard{access=http,mux=ogg,ds t=
> 0.0.0.0:8080}
> > control camNumber2 play
> > --

> > I reduced the resolution which seems to solve some issues, but cpu
> > usage is still very high. My webcam is a logitech c525 with native
> > resolution of 1280x720 (720).

> > Since the stream is only used on my own network, I want to settle for
> > higher bandwith use, if I just can get decent image quality without
> > overloading my cpu all the time.

> > I'm using the Ubuntu pandaboard image (without the omap-multimedia
> > extensions). I doubt that those extensions will help me, since they
> > are for video-decoding, not encoding (right?).

> no, there is encoder support as well. at least in 11.10, we haven't
> pushed encoders in 12.04 yet.

> we provide low level user space API (libDCE) to access the codecs, and
> we provide Gstreamer plugins that work with these codecs. If you use
> an application that is not using Gstreamer (such as VLC), you will
> have to plug in libDCE.

> however, if you use a USB webcam it is likely that the image format
> won't be compatible with what OMAP h/w accelerated codecs need (NV12)
> and you will need to make a YUV->NV12 on ARM, before you can use the
> codecs, but at least you can get read of the encoding on ARM, get a
> high quality stream..

> Gstreamer can do that like this:

> http://omappedia.org/index.php?title=Gstreamer_overview#Display_webca...

> > I also used mp4v encoding, but that also occupies a lot of cpu power.

> > Thanks,

> > Jeroen.

> I used some Gstreamer pipelines with ducati codecs to test video-streaming

> ------------
> server (Pandaboard):
> gst-launch -v gstrtpbin name=rtpbin  \
> v4l2src device=/dev/video3  num-buffers=200000 ! "video/x-raw-yuv,
> width=640, height=480,framerate=30/1" ! queue !  ffmpegcolorspace ! tee
> name=tee tee.src1 ! queue ! autovideosink \
> tee.src2 ! queue ! ducatimpeg4enc ! mpeg4videoparse !  rtpmp4vpay !
> rtpbin.send_rtp_sink_0 \
> rtpbin.send_rtp_src_0 ! udpsink port=5000 host=192.168.0.179 ts-offset=0
> name=vrtpsink \
> rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=192.168.0.179 sync=false
> async=false name=vrtcpsink \
> udpsrc port=5005 name=vrtpsrc ! rtpbin.recv_rtcp_sink_0

> client (Desktop):
> gst-launch -v gstrtpbin name=rtpbin latency=200 \
> udpsrc caps="application/x-rtp, media=(string)video,
> clock-rate=(int)90000, encoding-name=(string)MP4V-ES,
> profile-level-id=(string)0,
> config=(string)00000100000001200086e00025006007ec00d355c801e514043c1463,
> ssrc=(uint)1941061319, payload=(int)96, clock-base=(uint)1446705187,
> seqnum-base=(uint)64474" port=5000 ! rtpbin.recv_rtp_sink_0 \
> rtpbin. ! rtpmp4vdepay ! "video/mpeg" ! ffdec_mpeg4  ! ffmpegcolorspace
> ! ximagesink \
> udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
> rtpbin.send_rtcp_src_0 ! udpsink port=5005 host=192.168.0.179 sync=false
> async=false

> ------------

> Unfortunately, as Nicolas said, the performance is not the best because
> ffmpegcolorspace is required between webcam stream (v4l2src) and
> ducatimpeg4enc to convert to the right video format.   (ffmpegcolorspace
> runs on the arm side)

> Hi

> I used some Gstreamer pipelines with ducati codecs to test video-streaming

> ------------
> server (Pandaboard):
> gst-launch -v gstrtpbin name=rtpbin  \
> v4l2src device=/dev/video3  num-buffers=200000 ! "video/x-raw-yuv,
> width=640, height=480,framerate=30/1" ! queue !  ffmpegcolorspace ! tee
> name=tee tee.src1 ! queue ! autovideosink \
> tee.src2 ! queue ! ducatimpeg4enc ! mpeg4videoparse !  rtpmp4vpay !
> rtpbin.send_rtp_sink_0 \
> rtpbin.send_rtp_src_0 ! udpsink port=5000 host=192.168.0.179 ts-offset=0
> name=vrtpsink \
> rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=192.168.0.179 sync=false
> async=false name=vrtcpsink \
> udpsrc port=5005 name=vrtpsrc ! rtpbin.recv_rtcp_sink_0

> client (Desktop):
> gst-launch -v gstrtpbin name=rtpbin latency=200 \
> udpsrc caps="application/x-rtp, media=(string)video,
> clock-rate=(int)90000, encoding-name=(string)MP4V-ES,
> profile-level-id=(string)0,
> config=(string)00000100000001200086e00025006007ec00d355c801e514043c1463,
> ssrc=(uint)1941061319, payload=(int)96, clock-base=(uint)1446705187,
> seqnum-base=(uint)64474" port=5000 ! rtpbin.recv_rtp_sink_0 \
> rtpbin. ! rtpmp4vdepay ! "video/mpeg" ! ffdec_mpeg4  ! ffmpegcolorspace !
> ximagesink \
> udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
> rtpbin.send_rtcp_src_0 ! udpsink port=5005 host=192.168.0.179 sync=false
> async=false

> ------------

> Unfortunately, as Nicolas said, the performance is not the best because
> ffmpegcolorspace is required between webcam stream (v4l2src) and
> ducatimpeg4enc to convert to the right video format.   (ffmpegcolorspace
> runs on the arm side)

> Regards
> Joaquin Castellanos

> PS: Check in your client pipeline that the udpsrc caps=" ... " string
> match the caps of the server pipeline. See the output log in your terminal.

> On Sun, May 27, 2012 at 7:19 PM, Nicolas Dechesne <nde...@gmail.com>wrote:

>> On Sun, May 27, 2012 at 1:04 PM, Jeroen <jeroenjacobs1...@gmail.com>
>> wrote:
>> > Hi,

>> > I have a HD webcam connected to my pandaboard, and I want to do
>> > streaming with vlc. The streaming works, but according to "top", it
>> > consumes 115% cpu (I wonder how that's even possible?), and it seems
>> > the stream drops some frames now and then.

>> without doing anything special, you would be using ARM CPU for
>> encoding and image processing, so nothing surprising really ;-)

>> > This is the vlm.conf file I use:

>> > --
>> > new camNumber2 broadcast enabled
>> > setup camNumber2 input v4l2:///dev/video2:width=640:height=480
>> > setup camNumber2 output

>> #transcode{vcodec=mp2v,acodec=none,vb=5000}:standard{access=http,mux=ogg,ds t=
>> 0.0.0.0:8080}
>> > control camNumber2 play
>> > --

>> > I reduced the resolution which seems to solve some issues, but cpu
>> > usage is still very high. My webcam is a logitech c525 with native
>> > resolution of 1280x720 (720).

>> > Since the stream is only used on my own network, I want to settle for
>> > higher bandwith use, if I just can get decent image quality without
>> > overloading my cpu all the time.

>> > I'm using the Ubuntu pandaboard image (without the omap-multimedia
>> > extensions). I doubt that those extensions will help me, since they
>> > are for video-decoding, not encoding (right?).

>> no, there is encoder support as well. at least in 11.10, we haven't
>> pushed encoders in 12.04 yet.

>> we provide low level user space API (libDCE) to access the codecs, and
>> we provide Gstreamer plugins that work with these codecs. If you use
>> an application that is not using Gstreamer (such as VLC), you will
>> have to plug in libDCE.

>> however, if you use a USB webcam it is likely that the image format
>> won't be compatible with what OMAP h/w accelerated codecs need (NV12)
>> and you will need to make a YUV->NV12 on ARM, before you can use the
>> codecs, but at least you can get read of the encoding on ARM, get a
>> high quality stream..

>> Gstreamer can do that like this:

>> http://omappedia.org/index.php?title=Gstreamer_overview#Display_webca...

>> > I also used mp4v encoding, but that also occupies a lot of cpu power.

>> > Thanks,

>> > Jeroen.

> I never messed with GStreamer before, and from the looks of it, it seems to have the most counter-intuitive syntax I've
> ever seen. I'll think I'll stick for VLC a bit longer (even if that means higher cpu use).

> Are there any plans to integrate Ducati with VLC too?

> Hi

> I used some Gstreamer pipelines with ducati codecs to test video-streaming

> ------------
> server (Pandaboard):
> gst-launch -v gstrtpbin name=rtpbin  \
> v4l2src device=/dev/video3  num-buffers=200000 ! "video/x-raw-yuv,
> width=640, height=480,framerate=30/1" ! queue !  ffmpegcolorspace ! tee
> name=tee tee.src1 ! queue ! autovideosink \
> tee.src2 ! queue ! ducatimpeg4enc ! mpeg4videoparse !  rtpmp4vpay !
> rtpbin.send_rtp_sink_0 \
> rtpbin.send_rtp_src_0 ! udpsink port=5000 host=192.168.0.179 ts-offset=0
> name=vrtpsink \
> rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=192.168.0.179 sync=false
> async=false name=vrtcpsink \
> udpsrc port=5005 name=vrtpsrc ! rtpbin.recv_rtcp_sink_0

> client (Desktop):
> gst-launch -v gstrtpbin name=rtpbin latency=200 \
> udpsrc caps="application/x-rtp, media=(string)video,
> clock-rate=(int)90000, encoding-name=(string)MP4V-ES,
> profile-level-id=(string)0,
> config=(string)00000100000001200086e00025006007ec00d355c801e514043c1463,
> ssrc=(uint)1941061319, payload=(int)96, clock-base=(uint)1446705187,
> seqnum-base=(uint)64474" port=5000 ! rtpbin.recv_rtp_sink_0 \
> rtpbin. ! rtpmp4vdepay ! "video/mpeg" ! ffdec_mpeg4  ! ffmpegcolorspace !
> ximagesink \
> udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
> rtpbin.send_rtcp_src_0 ! udpsink port=5005 host=192.168.0.179 sync=false
> async=false

> ------------

> Unfortunately, as Nicolas said, the performance is not the best because
> ffmpegcolorspace is required between webcam stream (v4l2src) and
> ducatimpeg4enc to convert to the right video format.   (ffmpegcolorspace
> runs on the arm side)

> Regards
> Joaquin Castellanos

> PS: Check in your client pipeline that the udpsrc caps=" ... " string
> match the caps of the server pipeline. See the output log in your terminal.

> On Sun, May 27, 2012 at 7:19 PM, Nicolas Dechesne  wrote:

>> On Sun, May 27, 2012 at 1:04 PM, Jeroen  wrote:
>> > Hi,

>> > I have a HD webcam connected to my pandaboard, and I want to do
>> > streaming with vlc. The streaming works, but according to "top", it
>> > consumes 115% cpu (I wonder how that's even possible?), and it seems
>> > the stream drops some frames now and then.

>> without doing anything special, you would be using ARM CPU for
>> encoding and image processing, so nothing surprising really ;-)

>> > This is the vlm.conf file I use:

>> > --
>> > new camNumber2 broadcast enabled
>> > setup camNumber2 input v4l2:///dev/video2:width=640:height=480
>> > setup camNumber2 output

>> #transcode{vcodec=mp2v,acodec=none,vb=5000}:standard{access=http,mux=ogg,ds t=
>> 0.0.0.0:8080}
>> > control camNumber2 play
>> > --

>> > I reduced the resolution which seems to solve some issues, but cpu
>> > usage is still very high. My webcam is a logitech c525 with native
>> > resolution of 1280x720 (720).

>> > Since the stream is only used on my own network, I want to settle for
>> > higher bandwith use, if I just can get decent image quality without
>> > overloading my cpu all the time.

>> > I'm using the Ubuntu pandaboard image (without the omap-multimedia
>> > extensions). I doubt that those extensions will help me, since they
>> > are for video-decoding, not encoding (right?).

>> no, there is encoder support as well. at least in 11.10, we haven't
>> pushed encoders in 12.04 yet.

>> we provide low level user space API (libDCE) to access the codecs, and
>> we provide Gstreamer plugins that work with these codecs. If you use
>> an application that is not using Gstreamer (such as VLC), you will
>> have to plug in libDCE.

>> however, if you use a USB webcam it is likely that the image format
>> won't be compatible with what OMAP h/w accelerated codecs need (NV12)
>> and you will need to make a YUV->NV12 on ARM, before you can use the
>> codecs, but at least you can get read of the encoding on ARM, get a
>> high quality stream..

>> Gstreamer can do that like this:

>> http://omappedia.org/index.php?title=Gstreamer_overview#Display_webca...

>> > I also used mp4v encoding, but that also occupies a lot of cpu power.

>> > Thanks,

>> > Jeroen.

> I don't get it... why do you need so many ports, and encode the server's
> ip address in the server-setup? Can't I just use 0.0.0.0 to make it work?

> Also, how do I view this on a windows computer with VLC. VLC seems unable
> to open the stream, no matter which port I use...

> This seems also to put the video on the screen. Isn't it possible tojust
> do the streaming, without putting it on the pandaboard screen output?

> Greetz,

> J.

> On Monday, May 28, 2012 7:22:33 PM UTC+2, Joaquin Castellanos wrote:

>> Hi

>> I used some Gstreamer pipelines with ducati codecs to test video-streaming

>> ------------
>> server (Pandaboard):
>> gst-launch -v gstrtpbin name=rtpbin  \
>> v4l2src device=/dev/video3  num-buffers=200000 ! "video/x-raw-yuv,
>> width=640, height=480,framerate=30/1" ! queue !  ffmpegcolorspace ! tee
>> name=tee tee.src1 ! queue ! autovideosink \
>> tee.src2 ! queue ! ducatimpeg4enc ! mpeg4videoparse !  rtpmp4vpay !
>> rtpbin.send_rtp_sink_0 \
>> rtpbin.send_rtp_src_0 ! udpsink port=5000 host=192.168.0.179 ts-offset=0
>> name=vrtpsink \
>> rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=192.168.0.179 sync=false
>> async=false name=vrtcpsink \
>> udpsrc port=5005 name=vrtpsrc ! rtpbin.recv_rtcp_sink_0

>> client (Desktop):
>> gst-launch -v gstrtpbin name=rtpbin latency=200 \
>> udpsrc caps="application/x-rtp, media=(string)video,
>> clock-rate=(int)90000, encoding-name=(string)MP4V-ES,
>> profile-level-id=(string)0, config=(string)**
>> 00000100000001200086e000250060**07ec00d355c801e514043c1463,
>> ssrc=(uint)1941061319, payload=(int)96, clock-base=(uint)1446705187,
>> seqnum-base=(uint)64474" port=5000 ! rtpbin.recv_rtp_sink_0 \
>> rtpbin. ! rtpmp4vdepay ! "video/mpeg" ! ffdec_mpeg4  ! ffmpegcolorspace !
>> ximagesink \
>> udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \
>> rtpbin.send_rtcp_src_0 ! udpsink port=5005 host=192.168.0.179 sync=false
>> async=false

>> ------------

>> Unfortunately, as Nicolas said, the performance is not the best because
>> ffmpegcolorspace is required between webcam stream (v4l2src) and
>> ducatimpeg4enc to convert to the right video format.   (ffmpegcolorspace
>> runs on the arm side)

>> Regards
>> Joaquin Castellanos

>> PS: Check in your client pipeline that the udpsrc caps=" ... " string
>> match the caps of the server pipeline. See the output log in your terminal.

>> On Sun, May 27, 2012 at 7:19 PM, Nicolas Dechesne  wrote:

>> On Sun, May 27, 2012 at 1:04 PM, Jeroen  wrote:
>>> > Hi,

>>> > I have a HD webcam connected to my pandaboard, and I want to do
>>> > streaming with vlc. The streaming works, but according to "top", it
>>> > consumes 115% cpu (I wonder how that's even possible?), and it seems
>>> > the stream drops some frames now and then.

>>> without doing anything special, you would be using ARM CPU for
>>> encoding and image processing, so nothing surprising really ;-)

>>> > This is the vlm.conf file I use:

>>> > --
>>> > new camNumber2 broadcast enabled
>>> > setup camNumber2 input v4l2:///dev/video2:width=640:**height=480
>>> > setup camNumber2 output
>>> > #transcode{vcodec=mp2v,acodec=**none,vb=5000}:standard{access=**
>>> http,mux=ogg,dst=0.0.0.0:8080}
>>> > control camNumber2 play
>>> > --

>>> > I reduced the resolution which seems to solve some issues, but cpu
>>> > usage is still very high. My webcam is a logitech c525 with native
>>> > resolution of 1280x720 (720).

>>> > Since the stream is only used on my own network, I want to settle for
>>> > higher bandwith use, if I just can get decent image quality without
>>> > overloading my cpu all the time.

>>> > I'm using the Ubuntu pandaboard image (without the omap-multimedia
>>> > extensions). I doubt that those extensions will help me, since they
>>> > are for video-decoding, not encoding (right?).

>>> no, there is encoder support as well. at least in 11.10, we haven't
>>> pushed encoders in 12.04 yet.

>>> we provide low level user space API (libDCE) to access the codecs, and
>>> we provide Gstreamer plugins that work with these codecs. If you use
>>> an application that is not using Gstreamer (such as VLC), you will
>>> have to plug in libDCE.

>>> however, if you use a USB webcam it is likely that the image format
>>> won't be compatible with what OMAP h/w accelerated codecs need (NV12)
>>> and you will need to make a YUV->NV12 on ARM, before you can use the
>>> codecs, but at least you can get read of the encoding on ARM, get a
>>> high quality stream..

>>> Gstreamer can do that like this:

>>> http://omappedia.org/index.**php?title=Gstreamer_overview#**
>>> Display_webcam_video<http://omappedia.org/index.php?title=Gstreamer_overview#Display_webca...>

>>> > I also used mp4v encoding, but that also occupies a lot of cpu power.

>>> > Thanks,

>>> > Jeroen.

> Hi,

> I have a HD webcam connected to my pandaboard, and I want to do
> streaming with vlc. The streaming works, but according to "top", it
> consumes 115% cpu (I wonder how that's even possible?), and it seems
> the stream drops some frames now and then.

> This is the vlm.conf file I use:

> --
> new camNumber2 broadcast enabled
> setup camNumber2 input v4l2:///dev/video2:width=640:height=480
> setup camNumber2 output

> #transcode{vcodec=mp2v,acodec=none,vb=5000}:standard{access=http,mux=ogg,ds t=
> 0.0.0.0:8080}
> control camNumber2 play
> ---

> I reduced the resolution which seems to solve some issues, but cpu
> usage is still very high. My webcam is a logitech c525 with native
> resolution of 1280x720 (720).

> Since the stream is only used on my own network, I want to settle for
> higher bandwith use, if I just can get decent image quality without
> overloading my cpu all the time.

> I'm using the Ubuntu pandaboard image (without the omap-multimedia
> extensions). I doubt that those extensions will help me, since they
> are for video-decoding, not encoding (right?).

> I also used mp4v encoding, but that also occupies a lot of cpu power.

> Thanks,

> Jeroen.

> Thanks,
> John

> On Sunday, May 27, 2012 1:04:34 PM UTC+2, Jeroen wrote:

>> Hi,

>> I have a HD webcam connected to my pandaboard, and I want to do
>> streaming with vlc. The streaming works, but according to "top", it
>> consumes 115% cpu (I wonder how that's even possible?), and it seems
>> the stream drops some frames now and then.

>> This is the vlm.conf file I use:

>> --
>> new camNumber2 broadcast enabled
>> setup camNumber2 input v4l2:///dev/video2:width=640:**height=480
>> setup camNumber2 output
>> #transcode{vcodec=mp2v,acodec=**none,vb=5000}:standard{access=**
>> http,mux=ogg,dst=0.0.0.0:8080}
>> control camNumber2 play
>> ---

>> I reduced the resolution which seems to solve some issues, but cpu
>> usage is still very high. My webcam is a logitech c525 with native
>> resolution of 1280x720 (720).

>> Since the stream is only used on my own network, I want to settle for
>> higher bandwith use, if I just can get decent image quality without
>> overloading my cpu all the time.

>> I'm using the Ubuntu pandaboard image (without the omap-multimedia
>> extensions). I doubt that those extensions will help me, since they
>> are for video-decoding, not encoding (right?).

>> I also used mp4v encoding, but that also occupies a lot of cpu power.

>> Thanks,

>> Jeroen.