Raspberry Pi Forums

Posted: **Wed Aug 09, 2017 9:27 am**

The updated firmware was released yesterday - https://github.com/Hexxeh/rpi-firmware/ ... baf8626eeb
If you use rpi-update it will pick up the new firmware. The usual warnings about the use of rpi-update apply - it gets the absolute latest firmware and kernel, and there is a chance of regressions. Don't use it on a critical SD card without backing up first.
It is only a firmware change, so you could use "sudo SKIP_KERNEL=1 rpi-update" to pick up only the firmware and leave the kernel alone.

Posted: **Wed Aug 09, 2017 11:01 am**

Thank you, will test it this evening. :) If I can cut Gstreamer entirely out of the game and refactor the drone's entire video feedback subsystem to broadcast RGB scanlines in packet injection mode (ground station listening in monitor mode), I should have an rather low latency and highly robust video downlink. :) And it would save CPU cycles otherwise wasted in Gstreamer. :)

(At the moment, though, I'm simulating packet injection/monitor with ordinary (but NIO, so a bit faster than standard Java sockets) UDP broadcast on top of ordinary (associated) WiFi.)

Posted: **Wed Aug 09, 2017 7:12 pm**

Tested. :) Works beautifully. Thank you! :)

Posted: **Fri Aug 25, 2017 2:39 pm**

jwatte wrote: ↑
Tue Aug 08, 2017 7:07 pm
That sounds good!

Another option: I don't need the on-screen preview, but I'm running it so that the auto-level-magic can do its work.
Can I connect a memory buffer pool to the preview output?
If so, can that output have RGB format when the main video encoder uses YUV? Or can the encoder use YUV?
If so, I don't need the splitter at all!

Sorry, I seemed to miss this question.
Indeed you can link the preview port to a buffer pool and application callback - the components themselves have no notion of what they are connected to as that is all handled by the framework.
Yes, preview output can be RGB whilst video output is YUV (or preferrably MMAL_ENCODING_OPAQUE) for the video encoder. The H264 codec needs YUV, so presenting it with such saves a load of format conversions.

Posted: **Thu Feb 21, 2019 9:28 am**

I am trying to decode raw rgb data from raspistill STDOUT by java language, I encountered the same issue that images are dislocated, see my snapshot(camera is shooting at my roof in static, picture should be same as test0.png) ,

PI 3B
raspivid Camera App v1.3.12
camera rev 1.3 hardware

since rgb output bytes are byte[width*height*3], so I read though the stream one by one as,

Code: Select all

raspivid --width 320 --height 240 --flush --framerate 10 --timeout 0 --segment 1024 --nopreview --raw-format rgb --raw - --output /dev/null

Code: Select all

while (stream not close) {
  byte[] bytes = new byte[width * height * 3];
  in.read(bytes);//read from InputStream
  ...
  //then decode to java BufferedImage
  ...
}

You can see, images are first correct then dislocated some frames, then back to correct, again and again. mean while, the frames is more then expected. for 5 seconds of running, there should be 5*10fps=50 images, but there are much more in byte length. I inserted some code around converting images to mock fps, it is almost up to 50, that means I decoded 50 images per seconds.

what is in raw rgb content, anyone can help me on this? really appreciate

Posted: **Thu Feb 21, 2019 1:30 pm**

maoanping wrote: ↑
Thu Feb 21, 2019 9:28 am
I am trying to decode raw rgb data from raspistill STDOUT by java language, I encountered the same issue that images are dislocated, see my snapshot(camera is shooting at my roof in static, picture should be same as test0.png) ,

PI 3B
raspivid Camera App v1.3.12
camera rev 1.3 hardware

since rgb output bytes are byte[width*height*3], so I read though the stream one by one as,
Code: Select all
raspivid --width 320 --height 240 --flush --framerate 10 --timeout 0 --segment 1024 --nopreview --raw-format rgb --raw - --output /dev/null
Code: Select all
while (stream not close) {
  byte[] bytes = new byte[width * height * 3];
  in.read(bytes);//read from InputStream
  ...
  //then decode to java BufferedImage
  ...
}
You can see, images are first correct then dislocated some frames, then back to correct, again and again. mean while, the frames is more then expected. for 5 seconds of running, there should be 5*10fps=50 images, but there are much more in byte length. I inserted some code around converting images to mock fps, it is almost up to 50, that means I decoded 50 images per seconds.

what is in raw rgb content, anyone can help me on this? really appreciate

Please don't double post - https://www.raspberrypi.org/forums/view ... 8#p1432498

Your images appear not to have attached, however adding -v (verbose)to your raspivid command shows up the issue very rapidly.

Code: Select all

bitrate 17000000, framerate 10, time delay 1000
H264 Profile high
H264 Level 4
H264 Quantisation level 0, Inline headers Yes
H264 Fill SPS Timings No
H264 Intra refresh type (null), period -1
H264 Slices 1
Segment size 1024, segment wrap value 0, initial segment number 1
Raw output enabled, format yuv  <<<<<<<<<<<<<<
Wait method : Simple capture
Initial state 'record'

It's saving as YUV.
The reason is that the -raw option enables raw capture and selects yuv mode, so because that has come after your --raw-format parameter it has reset the format. That should really be fixed up raspivid as that is a horrible side effect.
For now, just use

Code: Select all

raspivid --width 320 --height 240 --flush --framerate 10 --timeout 0 --segment 1024 --nopreview --raw - --raw-format rgb --output /dev/null

and you should get the result you want.

Raspberry Pi Forums

raspivid raw RGB data is incorrect?

Re: raspivid raw RGB data is incorrect?

Re: raspivid raw RGB data is incorrect?

Re: raspivid raw RGB data is incorrect?

Re: raspivid raw RGB data is incorrect?

Re: raspivid raw RGB data is incorrect?

Re: raspivid raw RGB data is incorrect?