rodizio
Posts: 43
Joined: Sat May 07, 2016 2:40 am

Artifacts, "blocky" video stream

Tue Apr 11, 2017 2:11 pm

I found something where I'm not sure if this is correct behavior of the camera (or the h264 encoder). When walking through the woods, sometimes parts of the images are heavily "blocky".

At first, I attributed this to the complex light conditions in a forest and the fact that in wintertime there is not that much light there because it seems to happen more in dark areas of the image. And of course also the fact that all the leaves and "stuff" in a forest doesn't compress very well compared to a uniform blue sky or whatever less complex objects.

However, today I did some more tests in an area with lots of trees, leaves, bushes etc, but on a bright day. Same issue. Sometimes the image gets really blocky. I have checked the resulting h264 file with VLC, it shows around 6mbit bitrate throughout the video, I'd assume 6mbit is enough to not have "blockiness"?

Raspivid commandline used was:

Code: Select all

 raspivid -w 1280 -h 720 -fps 48 -b 6000000 -g 5 -t 0 -cd H264 -n -fl -ih -pf high -hf -vf -ex sports -mm matrix -awb horizon -o -

Edit: Just realized the forum resized the pic. Here are two pictures in original size:
http://imgur.com/a/dVJKU

More pics from the above area:
http://imgur.com/a/nZ1nr

More pics from another (more dark) forest, where the problem is more apparent:
http://imgur.com/a/fO4ST

Here is a sample on how it looks:
screenshot16.jpg
blocky image
screenshot16.jpg (63.52 KiB) Viewed 1931 times

User avatar
topguy
Posts: 6466
Joined: Tue Oct 09, 2012 11:46 am
Location: Trondheim, Norway

Re: Artifacts, "blocky" video stream

Tue Apr 11, 2017 2:26 pm

You are either hitting the limit on the bitrate or on the processing power. I believe that walking through a forest probably is the h264-codecs worst nightmare. Lots of smaller details, lots of (shaky possible) movement and in very large areas of the picture. Something gotta give...

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26442
Joined: Sat Jul 30, 2011 7:41 pm

Re: Artifacts, "blocky" video stream

Tue Apr 11, 2017 2:28 pm

Bitrate is too low I suspect. Try 8 to 10Mbits/s.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 8739
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Artifacts, "blocky" video stream

Tue Apr 11, 2017 2:35 pm

Normally 6Mbit/s would be reasonable for 720P30. However you're running at 48fps, and -g 5 is forcing it to return an I-frame every 5th frame (the default is 60 IIRC).

6Mbit/s = 750kbytes/s = 15kB/frame if equally encoded. How good a 1280x720 JPEG can you get in 15kB? That is what you are forcing with every I-frame (not quite true as I-frames are assigned more bits than P-frames, but the worse an I-frame is the bigger the residuals in the next P-frame).


There is the alternate acronym for MPEG - Motion Pictures Except Grass.
Lots of moving stuff is very bad for motion based compression, so waving grass and running water do very badly. Waving tree branches will have the same effect.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

rodizio
Posts: 43
Joined: Sat May 07, 2016 2:40 am

Re: Artifacts, "blocky" video stream

Tue Apr 11, 2017 3:04 pm

There is the alternate acronym for MPEG - Motion Pictures Except Grass.
LOL. Yeah, I know similar effects from watching DVB-T (mpeg-2 I think) around new years eve, when it shows fireworks, it gets really blocky, seems to be something the codec cannot deal with very good. I just wouldn't have thought it's that bad with h264 and 6mbit, but after thinking about it, 15kbyte per image is really not much.

Thanks, I'll play with the settings some more. Thing is, I can't go lower on the FPS or use higher "-g" values, because I use it for flying model planes and copters, high frame-rate and fast glitch-recovery is crucial. Higher bitrate would be possible, but the problem is, that I have to use about 50% more wifi-bitrate than the camera produces because sometimes the datarate of the cam goes a lot higher than set.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 8739
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Artifacts, "blocky" video stream

Tue Apr 11, 2017 3:33 pm

rodizio wrote:Thanks, I'll play with the settings some more. Thing is, I can't go lower on the FPS or use higher "-g" values, because I use it for flying model planes and copters, high frame-rate and fast glitch-recovery is crucial. Higher bitrate would be possible, but the problem is, that I have to use about 50% more wifi-bitrate than the camera produces because sometimes the datarate of the cam goes a lot higher than set.
Even an increase up to -g 10 would be a significant saving in bitrate and still be a key frame every 208ms.

The sad reality is that something has to give - compression can't work total magic and be artifact free under all conditions in zero bitrate. Although I do have a nice video of a black cat on a dark night that compresses pretty well ;)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26442
Joined: Sat Jul 30, 2011 7:41 pm

Re: Artifacts, "blocky" video stream

Wed Apr 12, 2017 9:32 am

rodizio wrote:
There is the alternate acronym for MPEG - Motion Pictures Except Grass.
LOL. Yeah, I know similar effects from watching DVB-T (mpeg-2 I think) around new years eve, when it shows fireworks, it gets really blocky, seems to be something the codec cannot deal with very good. I just wouldn't have thought it's that bad with h264 and 6mbit, but after thinking about it, 15kbyte per image is really not much.
The codec can deal with it fine, if it is given enough bits to do it in. Which given the cost of TV transmission bandwidth, is usually not enough. It's a tradeoff between bitrate and quality, and always will be.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

Return to “Camera board”