Locking file might not lock the file you want?

[onceuponadashcam]

Locking file might not lock the file you want?

For example, if an incident on the road happens near the end of a file, and then starts a new file during the incident (it creates a new file every xx minutes), and then you lock it, it will lock the current file, not the previous file where the incident started. So, you have locked a partial incident (the 2nd file and not the 1st file). It might be good if it would lock the current file, and the previous file, and maybe even the next file as well.

Also, during an incident, it might be hard to find a chance to hit lock as you are concentrating on whatever is happening around you. Then, after the incident, you hit lock, but by that time, you are on the next file and the incident is on the previous file, and has not been locked. So again, locking the current + previous + next file would be good here as well.

 

[estore009]

So again, locking the current + previous + next file would be good here as well.

Thanks for the suggestion, and will ask my team to have a check then!

 

[kamkar]

Many newer cameras i think have begun to look at file segments instead of a little buffer in regard to event recordings.

in the old days if you wanted to save something you saw, you would have to press the event button within seconds of it happening, and if you was too slow all you could do was use the event file as a date/time marker and then go looking for the event in among the regular files.

On the other hand going by segments, that will take up more room in the event folder, but again if that folder is managed intelligent and old files there also getting written over when the event folder are full, then that should not really be a problem.
The B1W have a min of 30% of the memory card set off for events, so if you use that feature it should be fine, me on the other hand that dont really use events, well then 30% are a bit much to do without.

So a code sounding something like this should be fine:

If current video segment < then 50% lock previous segment too
If current video segnemt > than 50% lock following segment too

This mean that if you are less than 1.5 minute into a 3 minute segment and you press the button then the previous file will be write protected too as well as the current session, and so you will have 2 X 3 minutes protected.
on the other hand if you are past 1.5 minutes of a 3 minute segment, then the current segment and the following will be protected and again you have 2 X 3 minutes secure in the read only folder.

And you have a little time to press the button instead of maybe a 10 second prebuffer.

 

[jokiin]

If current video segment < then 50% lock previous segment too
If current video segnemt > than 50% lock following segment too

that's exactly how we do it

 

[DidYouSeeThat?]

Thanks for the suggestion, and will ask my team to have a check then!

Thanks for this! This change would be beneficial to all of us using the B1W cameras.

 

[DidYouSeeThat?]

Also, during an incident, it might be hard to find a chance to hit lock as you are concentrating on whatever is happening around you. Then, after the incident, you hit lock, but by that time, you are on the next file and the incident is on the previous file, and has not been locked. So again, locking the current + previous + next file would be good here as well.

So a code sounding something like this should be fine:
If current video segment < then 50% lock previous segment too
If current video segnemt > than 50% lock following segment too

that's exactly how we do it

There are many approaches here, but as long as the camera logic focuses on "segments" like this, the user experience will be varied, and perhaps not always satisfactory.

For example: B1W configured to 1 minute segments:
If the event happens say 1 second into the file, you could have as few as 30 seconds to hit the button, or the file containing the event will be missed (not locked). A button press at 31 seconds would lock the current file (missing the event) and the 1 minute file after it. For something like a road rage incident, 30 seconds is likely not enough lead-in, and two minutes total of locked files is likely not enough for the overall "encounter".

Alternate example: B1W configured to 5 minute segments:
Your reaction time and the associated locked file duration is now greatly expanded. If using some of the logic proposed above, you will guaranteed get at least 2 1/2 minutes on both sides of the button press, which is much more reasonable. But it's not perfect - A press at 2:31 into a file will preserve 2 1/2 minutes of prior footage, but 7 1/2 minutes after... In many cases, this time after is likely to be a waste, and preserving more footage prior to the press would have been more beneficial to the camera user.


A different way of coding the logic might focus on time durations instead of segments, and then lock sets of segments however is necessary to match that time criteria.
For example, logic like this:
If button is pressed, lock the prior 3 minutes of video as well as the future 2 minutes.

To satisfy this, when the B1W is configured to 5 minute segments, it would only lock at most two files regardless of the timing.
When it is configured to 3 minute segments, it would lock either two or three depending on where the press falls between segments.
When configured to 1 minute segments, the camera would likely lock six separate segments.


It would be more efficient with storage space, would have more predictable saving of prior time events, would be less likely to greatly over-run the event, and would have more consistent behavior to the user regardless of their selection of segment sizes.

(That -3 minute / +2 minute timing could be alternate values, or configurable... that was just an example.)

 

[jokiin]

trying to save segments of video that are different to the loop video size is a lot more involved than you might think, they need to work within the capabilities of the SDK

 

[DidYouSeeThat?]

trying to save segments of video that are different to the loop video size is a lot more involved than you might think, they need to work within the capabilities of the SDK

Sorry about that, perhaps I wasn't clear - the logic wouldn't split any segments. Any segment within or overlapping the specified timeframe would be saved/locked in it's entirety. So if you need to go back 3 minutes and you have a 5-minute segment size, you would save the entire 5 minute segment as-is to ensure that that last 3 minutes of it was preserved.

If you think of it as a moving timeline of segments, all that the time-based logic would do is flag existing segments to be saved. No additional processing of the video.

 

[jokiin]

If you think of it as a moving timeline of segments, all that the time-based logic would do is flag existing segments to be saved. No additional processing of the video.

no different to what we do already, we just make decision on which files to save based on when the event is triggered (automatically or manually triggered)

If current video segment < than 50% lock previous segment too
If current video segment > than 50% lock following segment too

 

[DidYouSeeThat?]

no different to what we do already, we just make decision on which files to save based on when the event is triggered (automatically or manually triggered)

If current video segment < than 50% lock previous segment too
If current video segment > than 50% lock following segment too

It's not at all the same, because that logic doesn't compensate for the duration of the segments, which is user-configurable.

As I described in my prior post, setting the camera to 1, 3, or 5 minute segments will have a significant impact on how much video is locked (between 2 and 10 minutes), as well as how quickly they need to react and press the button to capture a prior event, as well as how much time prior to the button press is guaranteed to be locked.

 

[jokiin]

the method you're proposing is overly complex, too many variables to have to code for

 

[kamkar]

K.I.S.S is good in dashcams.
Maybe if it was possible for nerds to run amok in some form of linux things would be different, but i cant see us being other than bound by SDK of the 2 major players in dashcam chip sets for a while.

Believe me for years i have been asking for one after the other features or functions i would like in dashcams, but it seem things are not as simple as i would expect.

 

[DidYouSeeThat?]

the method you're proposing is overly complex, too many variables to have to code for

In the big picture, it's absolutely trivial compared to the other logic and calculations involved in video processing.

If the firmware can remember what the prior video file was, you already have the method to keep track of the one before that as well.
And if you can set a flag to save the next video file which hasn't happened yet, you already have the method to trigger the one after that as well.
If you've implemented your logic as you've described, all of the key pieces are already there.

I write software for a living. It's too bad the B1W firmware isn't open source, otherwise I'd just add this feature myself.

 

[kamkar]

I couldn't code, anything if my life depended on it, not even a simple program for a CNC machine which i really should be able to do as a skilled machine worker.
I wiish i could though, there are some nice things one could contribute in if one could, but aside for dabbeling very little with Basic in the early 80ties i know nothing, even of that cuz i drugged it all out in the 90ties.

 

[DidYouSeeThat?]

I bet you could! I started on Basic as well, each step of the way just builds on the last.