Not a Happy Camper with the A139

Most of the time our fixed bitrate cameras have enough bitrate, so there is nothing to be gained from more compression, it is only when they run out of bitrate that you will see differences.

Under trees at high speed it is easy to run out of bitrate, but the extra optimizations available in h265 are of no help in that situation, they just don't do what is needed.

In parking mode it is easy to run out of bitrate if there is a lot of movement, possibly of traffic, more likely from wind blowing trees about, in this situation H265 should be able to help. But we don't see this situation very often, the parking mode bitrate is selected to be more than enough for most parking situations.

So in real life H265 is of no real advantage for current dashcams, and variable bitrate cameras don't seem to be going to appear anytime soon.


As you have already pointed out, with current dashcams there is no significant difference in power consumption, so there is nothing to gain by doing the maths on it!

Taking this into account, what you're saying is as follows:

1. We're increasing the resolution (1080p --> 2k -> 4k, etc)

2. By increasing the resolution we decrease pixel size, decreasing the amount of light, which becomes more noticeable in low light situations.

3. And to top it off, we're fixing the bitrate. Granted, Dash Cameras are Fixed and Aren't moving around, but scenery, motion, etc benefit significant;y from variable bitrate. As a fixed bitrate doesn't adjust for these situations.

There have clips posted here, where a car passes by real fast, and the license plate is unreadable. A scenario where this comes into play. Especially as resolution increases, and light decreases.

So basically, ya h.x265 is useless, because current ARM chips cannot take advantage of h.x265's full potential. In this case, power consumption, compression, don't really make much a difference. So why bother having h.x265?

@Nath, I'm fully aware that modern chips have h.x265 decoding built into the chipset. However, per the above, I was unaware that Dash Cameras used a fix bitrate. Otherwise, everything I said about CPU consumption, compression, and extra heat would be applicable.
 
Last edited:
General FYI:

I haven't had time to test my camera but the camera did the work for me. I'd parked my car outside without checking on it. Well noticed camera had turned off. Camera is set to H.x264 on firmware 1.2. Still shutdown spontaneously and corrupted the file being written. So switching from h.x265 to h.x264 made no difference

I'll try to downgrade to firmware 1.1 and do a test in h.x264. Just to rule out firmware 1.2 being at fault.

I highly doubt firmware 1.2 is to blame, but it's possible a bug got introduced.

I'm pretty certain my camera has an issue, but I don't want to leave any stone unturned.
 
they've been and gone already, they seemed to get it wrong more often than they got it right

Pleas elaborate. I would think allowing a Variable Bitrate would be far more beneficial. Say it's dusk and a car passes by quickly. Between the decreased lighting (higher resolution, worse low light performance) and a fixed bitrate, the plates may not be readable.

Whereas, a variable bitrate would help out with quicker faster motion. Maybe not so much with lighting, but at least less blur.

So what did these manufacturers get wrong?
 
Pleas elaborate. I would think allowing a Variable Bitrate would be far more beneficial. Say it's dusk and a car passes by quickly. Between the decreased lighting (higher resolution, worse low light performance) and a fixed bitrate, the plates may not be readable.

Whereas, a variable bitrate would help out with quicker faster motion. Maybe not so much with lighting, but at least less blur.

So what did these manufacturers get wrong?
I don't know that it was the camera manufacturers at fault, I think it was more the processor at fault, emphasis seemed to be more about where can we reduce bitrate to save storage space rather than where can we increase it to improve performance, the argument was often that running higher bitrates was a waste at those times when not much was happening, parked, low light etc, memory cards aren't priced like they used to be so storage space is not really a consideration like it once was
 
I don't know that it was the camera manufacturers at fault, I think it was more the processor at fault...
More down to the codec developers. For properly effective variable bitrate with H264/265 you currently need to use two pass compression, which is incompatible with real time encoding. Possibly the AV1 codec will bring a useful change, since it is being developed for use in live streaming so has the same encoding time constraints as dashcams.

For dashcam use with do have dual bitrate cameras, when you park some will drop into low bitrate mode, which makes it possible to record multiple days onto a single microSD card, works pretty well. I don't know about the others, but with Viofo, even the motion triggered parking mode is low bitrate, so it doesn't matter if you park on a busy road and get lots of triggers.
 
There have clips posted here, where a car passes by real fast, and the license plate is unreadable. A scenario where this comes into play. Especially as resolution increases, and light decreases.
Bitrate isn't connected with low light, if anything you tend to lose detail as light levels drop, so less bitrate is needed, but a really good sensor should maintain the same levels of detail until it is too dark to be worth worrying about.

If a "car passes by real fast", and the license plate is unreadable, it is normally caused by motion blur, which has nothing to do with bitrate. A really low bitrate can cause problems with low level detail and pixelation, but typically the license plate stays readable unless it is blurred by excessive exposure time.

So basically, ya h.x265 is useless, because current ARM chips cannot take advantage of h.x265's full potential. In this case, power consumption, compression, don't really make much a difference. So why bother having h.x265?
In practice, the only real advantage of H265 that I can see, is that it plays better on some devices, but worse on others, so if you happen to play your videos on a device that likes it, then use it.

I suspect there are times when the results of H265 are better, especially in parking mode, but I have never detected any of these times!

I'm waiting for the AV1 codec to appear in dashcams, hopefully it will get into the next generation of processors, since that does have a number of advantages when bitrate is running low, most noticeably pixelation in the skies and road surfaces tends to be unnoticeable at times when it is obvious on H264 and H265. Doesn't mean that it records all the original detail, just that it still looks decent when H26x has become unpleasant to look at.
 
So I've just read the full 14 pages in one go. One thing caught my attention that I'm not sure was resolved.

@kamkar noticed his unit continued at full bitrate on the front channel during parking mode in one of his tests. Was this a one-off?

@HonestReview - have you verified that your A139 is switching from full bitrate to low bitrate on all 3 channels?

I don't have a HW kit for my A139 test unit. I could leave it running off a powerbank, but I'm not sure if it will go into parking mode without a HW kit? In any case, I'm in the cooler north of the UK so I can't pretend to do any hot weather testing.
 
... I could leave it running off a powerbank, but I'm not sure if it will go into parking mode without a HW kit? ...
It should but there are also few reports that it doesn't work. Perhaps depends on what happens with ID wire in used USB cable.

Works for me.
 
Yeah i haven't even seen my own system do that again, but as nothing have changed with firmware and hardware it might happen again.
It was also just the front camera doing that the other 2 seemed to be doing low bitrate alright.
 
It was also just the front camera doing that the other 2 seemed to be doing low bitrate alright.
Wow, that's even more strange. I though you were talking about the whole set.
 
I posted a pic too of these parking files, the cabin camera and rear are both 92 MB in size, which seem normal but the front camera should have been 187 MB but was the normal just shy of 500 MB in size.

139-highbitrate-parking-jpg.57023


I also checked the bitrate on those files and it was 20 or was it 22,,,, anyway low bitrate i think should be 8 mbit.
 
Two Questions:

1. What bitrate should parking mode be? I can download a parking file and regular file from front cam and check what VLC player says.

2. Before anyone says here's a link, please don't. I downloaded the firmware listed as 1.1 from Viofo. Flashed my camera and it's saying 1.2 still. So guessing Viofo must have updated the firmware on their page.

I would like to flash to 1.1 and see if my camera is still having issue.

Can anyone share a confirmed version of firmware version 1.1 from the A139.
 
I posted a pic too of these parking files, the cabin camera and rear are both 98 MB in size, which seem normal but the front camera should have been 187 MB but was the normal just shy of 500 MB in size.

139-highbitrate-parking-jpg.57023

Just a thought / question. Maybe the camera doesn't exit out of the original file from Regular to Park Mode? And only begins a new file on front parking after reaching the designated length? 3 minutes, 5 minutes, etc?
 
1. What bitrate should parking mode be? I can download a parking file and regular file from front cam and check what VLC player says.
First question is whether the bitrate changes at all, or is it stuck on full bitrate?
 
2. Before anyone says here's a link, please don't. I downloaded the firmware listed as 1.1 from Viofo. Flashed my camera and it's saying 1.2 still. So guessing Viofo must have updated the firmware on their page.
What the heck? I thought you are delusional again but you are right. :LOL: Viofo's website still says it's v1.1 but it's actually v1.2 20210507

I would like to flash to 1.1 and see if my camera is still having issue.

Can anyone share a confirmed version of firmware version 1.1 from the A139.
Here you go (before you place it in SDcard, rename it to "FWA139A.bin"):
https://mega.nz/file/zxhBTK4S#UDfS9tRCPZFFYRQAaAnIIDps8iMZSTqwLsfbgFfTpeY
 
Last edited:
These are my usual 3 minute files, and i always use best possible bitrate for regular files, and there the front camera is the just short of 500 MB as i recall.
The files have the "P" suffix and are also in the parking folder.

It is the only time i have seen this, and i have after all used parking guard for some months now, though mainly just the 1 hour i normally use, but before i started these longer parking experiments i saw nothing wrong at all.
I am inclined to try another timer value than the 6 hours i have been used so far just to see if it is that single value that are giving me grief.

But for the next 9 days or so i will only see sporadic sun and generally below 20 deg C temperatures in the daytime and down to 10 degrees at night so i have paused my testing.
I was focuses on heat, but clearly my camera also have some issues fulfilling the parking mode timer duration when it is colder, i have tested in lower temperatures 3 - 4 times but only 1 of them did the camera go the full 6 hours.
 
These are my usual 3 minute files, and i always use best possible bitrate for regular files, and there the front camera is the just short of 500 MB as i recall.
The files have the "P" suffix and are also in the parking folder.

It is the only time i have seen this, and i have after all used parking guard for some months now, though mainly just the 1 hour i normally use, but before i started these longer parking experiments i saw nothing wrong at all.
I am inclined to try another timer value than the 6 hours i have been used so far just to see if it is that single value that are giving me grief.

But for the next 9 days or so i will only see sporadic sun and generally below 20 deg C temperatures in the daytime and down to 10 degrees at night so i have paused my testing.
I was focuses on heat, but clearly my camera also have some issues fulfilling the parking mode timer duration when it is colder, i have tested in lower temperatures 3 - 4 times but only 1 of them did the camera go the full 6 hours.

Firmware 1.2...Not sure which you're on. I'm going to downgrade to 1.1...But here are my results.

The Interior and Rear files are 158MB in parking mode. Front file is 318/319MB in parking mode. My file length is set to 5 minutes. This is the same on almost every full length parking file. My Guess, front camera is 2K and rear cameras are 1080p. So the front low bitrate is going to still be larger than the interior / rear low bitrate cameras which record at 1080p.

Someone chime in here please if I am incorrect:

1. Check your file length - Believe Loop is 3 and 5 minutes. Not sure if 10 minutes is an option
2. Front Camera is 2k and rear / interior 1080p
3. Could be a firmware bug in 1.1 if everything is set correctly.

low.jpg
 
Last edited:
Back
Top