Dashcam Viewer for Mac and Windows

[traveler]

@traveler

Question 1:
The file order is not sorted according to the exif information or file name,
which leads to the confusion of the file order
(because the file is airdropped to the computer, the creation time and modification time on the system are incorrect),
but the time and file name in the exif information are correct.

So I hope to be able to sort by file name, or get exif information to sort.

Question 2:
The reverse function does not reverse the list of files,
but reverses the selection or selects the last file in the case of select all.
This is not the right way to do it, in my opinion.
The reverse function has been changed to reverse the file list order.

Question 3:
Allows drag and drop of files to modify file order

Question 4:
Provides select all and deselect all functions

@LOVECHEN

Thanks for the questions. Here are some answers:

1. By default, Dashcam Viewer sequences files by file modification date. However, you can force Dashcam Viewer to sequence by filename in the Preferences (as shown below).
2. There is no "reverse" function. Do you mean "Invert"? Invert inverts the selection of files in the Control Center.
3. This would violate the native sequencing produced by the dashcam.
4. This is a good suggestion. I'll add it to my ToDo list!

 

[LOVECHEN]

thanks @traveler

 

[traveler]

Dashcam Viewer v3.8.7 Released​

Hello, Everyone. Dashcam Viewer v3.8.7 was released today for both Mac and Windows with the following new improvements. Version 3.8.7 is a free upgrade for all Dashcam Viewer users:

New Camera Supports:

• Added support for Thinkware X1000 and U1000
• Reported compatible with VANTRUE Element 1 (E1)

New Features:

• [Free, Plus versions] Added new red motorcycle compass pointer icon. User can toggle between the automobile icon and the motorcycle icon by clicking the compass. The choice is remembered between Dashcam Viewer runs.
• [PRO version] Added the new red motorcycle compass pointer icon plus 17 additional icons. See list below:

Bug Fixes:

• Improved heuristic that detects time-lapse mode in videos.

New compass pointer icons in v3.8.7. Click on the compass to toggle among the various icons.


Dashcam Viewer and Dashcam Viewer PRO are PC/Mac applications that allow you to play your dashcam’s videos while simultaneously viewing your vehicle’s location on a map. There are many other features in the software which are detailed on our website (http://dashcamviewer.com). The free version is fully-functional and allows the loading of up to 2 videos at a time.

 

[jyunte]

Reference version 3.8.7 of DashCam Viewer

I have a VIOFO 119V3. It uses a GPS to log position, bearing and speed. However, like most GPS systems, it takes some time after boot-up for the GPS to acquire a GPS lock. This causes problems with DashCam Viewer.

After starting the car, the 119V3 turns on a few seconds later. The video begins to record as soon as the dashcam boots.
Meanwhile, the GPS is still searching for a satellite lock.
About 40 seconds after the video starts recording, the GPS obtains valid LAT/LON coordinates, which are written to the video file.

When the video is loaded into DashCam Viewer, it is parsed by the program and the GPS coordinates are collected.
When the video is played, DashCam Viewer immediately uses the first LAT/LON coordinates it got from the video and updates the moving map.
The problem is the video and the moving map are not synchronized because the first valid LAT/LON coordinates from the GPS were not received until 40 seconds after the start of the video, but the moving map is updated as if they were received at the very beginning of the video. This means the position of the moving map is 40 seconds ahead of the position in the video.

The video and the moving map will remain out of sync (moving map ahead of the video by several seconds or minutes) until the next video in the loop is started - by which time the GPS has a good satellite lock and will be sending valid LAT/LON coordinates when the new video begins recording.

I believe the solution to this problem is the following:
1) Parse the video, looking for the first valid LAT/LON indication.
2) Record how far into the video the first valid LAT/LON coordinates are found (EG. in seconds or frames).
3) DashCam Viewer should delay updating the moving map for the number of seconds/frames determined in step #2, above.

This would ensure that the moving map begins updating at the correct point in the video.


Video Frame: Just about to get on the freeway...





Moving Map: Map is 20+ seconds ahead of the video....

 

[jyunte]

Reference version 3.8.7 of DashCam Viewer

I recorded a video on my VIOFO 119 V3.
GPS showed I was in San Diego on El Cajon Blvd at 8:41 PM, Tuesday, September 6.
The video shows that it's video #63 in the batch, it's nighttime and I'm on El Cajon Blvd.

I loaded all the clips on my V119 V3 into DashCam Viewer.
When I click the track on the moving map, to jump the video to the next block down the road, DashCam Viewer jumps me to video #21, which shows me in Mission Viejo, at 10:18 AM on September 6, some 80 miles away and 10+ hours earlier. It happens reliably when I click on any point on the track. This video is the first video after the dashcam was booted, so I believe it's related to the previous issue I posted above: Post 944

 

[DT MI]

Reference version 3.8.7 of DashCam Viewer

I have a VIOFO 119V3. It uses a GPS to log position, bearing and speed. However, like most GPS systems, it takes some time after boot-up for the GPS to acquire a GPS lock. This causes problems with DashCam Viewer.

After starting the car, the 119V3 turns on a few seconds later. The video begins to record as soon as the dashcam boots.
Meanwhile, the GPS is still searching for a satellite lock.
About 40 seconds after the video starts recording, the GPS obtains valid LAT/LON coordinates, which are written to the video file.

When the video is loaded into DashCam Viewer, it is parsed by the program and the GPS coordinates are collected.
When the video is played, DashCam Viewer immediately uses the first LAT/LON coordinates it got from the video and updates the moving map.
The problem is the video and the moving map are not synchronized because the first valid LAT/LON coordinates from the GPS were not received until 40 seconds after the start of the video, but the moving map is updated as if they were received at the very beginning of the video. This means the position of the moving map is 40 seconds ahead of the position in the video.

The video and the moving map will remain out of sync (moving map ahead of the video by several seconds or minutes) until the next video in the loop is started - by which time the GPS has a good satellite lock and will be sending valid LAT/LON coordinates when the new video begins recording.

I believe the solution to this problem is the following:
1) Parse the video, looking for the first valid LAT/LON indication.
2) Record how far into the video the first valid LAT/LON coordinates are found (EG. in seconds or frames).
3) DashCam Viewer should delay updating the moving map for the number of seconds/frames determined in step #2, above.

This would ensure that the moving map begins updating at the correct point in the video.


Video Frame: Just about to get on the freeway...

View attachment 61749



Moving Map: Map is 20+ seconds ahead of the video....

View attachment 61750

I get the same behavior with SGGCX2Pro+ and SG9663DC cameras.

 

[traveler]

@jyunte I apologize for not responding sooner and thank you for the detailed bug report.

Your solution to the "incomplete GPS data record issue" makes perfect sense. However, the issue is more complicated than you might think. Unlike the video industry with its precise timecodes, standardized formats, and well-known protocols, there is no such sanity in the dashcam video world. As someone who's worked with embedded dashcam video data for 8 years, I can safely say that it's like the Wild West out there. Different vendors use different techniques, often proprietary, for encoding their navigation data into the video stream. There is very little standardization, even across the same manufacturer's model line. Some intersperse the GPS data with the video frames, some write the data in subtitle tracks, some write all the data at the end of the file. Some put the data in an external file. Some backfill dead time with null points, some just skip the points altogether. When supporting 100+ different models, handling these corner cases is a challenge. To help deal with missing data I use a post-processing step that attempts to backfill or frontfill the empty pockets of data. This routine makes a guess as to what to do with the blank areas, and occasionally it's incorrect (at least for some dashcam models but maybe not for others). Sounds like this is the issue in your case.

With that said, I'd like to examine your case in more detail. Can you send me two consecutive raw dashcam videos?-- the first one in which the GPS did not achieve lock until midway through, and the 2nd one where the GPS did achieve lock throughout. That way I can investigate the issue more closely. You can send me large files using https://wetransfer.com

Thanks,
John

 

[jyunte]

Hi John,

Thanks for the reply. I get what you're saying... Cheap cameras using cheap sensors, with (probably) pretty poor coding!

I've uploaded a couple of videos to OneDrive here. I know you said to use "wetransfer" but I'm not a subscriber to that service and probably won't ever use it again! The videos are in a zipped archive (1.30GB).

 

[traveler]

Hi John,

Thanks for the reply. I get what you're saying... Cheap cameras using cheap sensors, with (probably) pretty poor coding!

I've uploaded a couple of videos to OneDrive here. I know you said to use "wetransfer" but I'm not a subscriber to that service and probably won't ever use it again! The videos are in a zipped archive (1.30GB).

@jyunte Videos downloaded. Thanks!

 

[traveler]

@jyunte I was able to find and fix the problem you reported. It was an interesting case.

Your first video had a mix of null, valid, and invalid GPS points in the data stream. For the first 11 seconds, your dashcam was reporting null date/time, latitude and longitude. For the next 10 seconds, your dashcam then partially locked on to GPS and reported a valid but INCORRECT date/time. Latitude and longitude were still invalid. At 22 seconds and beyond, suddenly valid and correct date/time, latitude and longitude show up in the stream.

To fix the issue I post process the data by walking through it backwards and remembering the last 'good' point. The idea being that 'good' points are more likely at the end of the data stream. When I come across a point that doesn't look valid, I substitute it with the last valid point.

The result looks something like this below. Notice in the speed graph that there's a constant speed at the beginning and then suddenly, after 22 seconds, the curve starts varying. Those first 22 seconds have been backfilled with 'corrected' data.

Also notice the "wrench" icon in the bottom-right list view. The wrench indicates a problem was found in the data stream. If you hover your mouse on the wrench a pop-up window will appear that explains the problem and the measures taken to mitigate it.

Expect this fix in the next release, v3.8.8. Thanks for your help!

John

 

[jyunte]

@jyunte I was able to find and fix the problem you reported. It was an interesting case.

Wow! Thanks for checking it out and fixing it so quickly. I wonder if my 119V3 is defective if it's getting bad data from the GPS? It's still in its return window from Amazon. Maybe it's the GPS unit? Or maybe they're all like that! I can understand the first 11 seconds of null data and even the next 10 seconds of a partial lock, as this would be the GPS warm start. The incorrect date/time is weird - I don't think that should happen after a partial lock is achieved. Very strange.

Anyway, I look forward to trying out the next release.

Thanks again, neighbor, from AV, OC, SoCal.

 

[jyunte]

Reference version 3.8.7 of DashCam Viewer

Using the 119 V3 from VIOFO, I notice that all the videos imported into DashCam Viewer have a duration of "-0.01s".

The FAQ says ffmpeg can't find the files, or there's a unicode character in the path/filename. I copy the files directly from the SD card to a folder in the Documents folder that's dedicated to the 119 V3 video files ("C:\Users\xxxx\Documents\000 DashCam Footage") and the files are named "20220917170933_000338.TS" and so on.

The latest K-Lite CODEC pack is installed and I downloaded the FFmpeg GPL version, which is what I've been using since I installed DashCam Viewer - If I remember correctly, I couldn't export clips using the default ffmeg that came with the DachCam Viewer install file, but can with the GPL version).

I've tried moving the video files to a folder without a space in it (C:\test) and I still get durations of -0.01s.

 

[Kremmen]

I'm guessing that this would have only affected the first video whilst the V3 gets a GPS lock. When I've played my footage I've never noticed any issues apart from the first 20 secs or so not having a GPS lock, as expected, but I've never noticed a time issue. I've also never noticed any issue with the route overlay in that first video.

Must look closer next time.

 

[jyunte]

I'm guessing that this would have only affected the first video whilst the V3 gets a GPS lock. When I've played my footage I've never noticed any issues apart from the first 20 secs or so not having a GPS lock, as expected, but I've never noticed a time issue. I've also never noticed any issue with the route overlay in that first video.

Must look closer next time.

I'm glad the author of the software was able to find a workaround, but I'm not convinced the V3 I have isn't broken.

I drove 150 miles today, in two 75-mile journeys. The V3 was set to record in 3-minute clips. The very first clip had all the problems discussed above... bad date/time, no LAT/LON, invalid LAT/LON, and GPS data out-of-sync errors. Other seemingly random clips, from after the V3 got a good GPS fix contained other errors - GPS data out-of-sync and bad LAT or bad LON data, mostly. I could see no pattern to which clips had errors. After the initial start-up video with its usual errors, I might have 20 clips without any errors, and then one clip with several different errors, followed by another bunch of error-free clips.

In a test tonight, I booted the V3, drove around for a few miles, then parked for 4 minutes with the car and V3 turned off. When I started the car and V3 again, there were no errors on the first new video. I don't know if the supercapacitor in the V3 is able to keep the GPS running for 4 minutes, but, if it can, that could explain why I got no errors in that file.

I might return it and see if the replacement is any better.

 

[traveler]

@jyunte My guess is that your V3 is working normally. 20 clips with no errors (totaling 60 mins of video) is not bad at all.

Also, the way GPS establishes a fix (known as, TTFF or time to first fix), cycling the V3's power for 4 minutes would still produce a Warm Start. This would explain why you can park with the power off for a few minutes and still get valid GPS data almost immediately after powering on.

 

[Kremmen]

I've just checked my first video of a day.

As expected the first 20 secs has no GPS display 'in the Viofo video window' then it cuts in. The time in the video window is correct from the start.

Looking at the map, my starting position is correct with the default, red in my case, dot and the end of my first 3 minute clip is correct with the black/white dot.

What I don't display though is the 'Speed Distance Bearing' or the 'Dashboard' as all I need is the video window, map and file list which is where I suspect your problem occurred.

 

[jyunte]

I recorded a video on my VIOFO 119 V3.
GPS showed I was in San Diego on El Cajon Blvd at 8:41 PM, Tuesday, September 6.
The video shows that it's video #63 in the batch, it's nighttime and I'm on El Cajon Blvd.

I loaded all the clips on my V119 V3 into DashCam Viewer.
When I click the track on the moving map, to jump the video to the next block down the road, DashCam Viewer jumps me to video #21, which shows me in Mission Viejo, at 10:18 AM on September 6, some 80 miles away and 10+ hours earlier. It happens reliably when I click on any point on the track.

I have now confirmed that this issue is not restricted to the first video after a 119 V3 restart.

Regardless of the video that's currently playing, when I click on a location on the track in the map window, the DashCam Viewer Map location jumps to a totally different location, sometimes several hours and many miles away from the position on the map. Its behavior is inconsistent. I have seen the following results:

1. Play video #1 and pause it. Click on the track ahead of the car's current location: Map display goes back to the current location of the car; video jumps to the last frame of video #1 and will not continue to video #2 unless you click the "Next" button.

2. Play video #1 and pause it. Click on the track ahead of the car's current location: Map display goes back to the current location of the car; video jumps to the last frame of video #1, which is a black frame, and will not continue to video #2 unless you click the "Next" button.

3. Play video #1 and pause it. Click on the track ahead of the car's current location: Map display goes to a (seemingly) random clip (EG. #15); video continues to play from this random location which is not the location I clicked on, but is the location the Map is displaying.

4. Play video #10 of a long trip and pause it. Click on the track ahead of the car's current location: Map display goes back to a random clip.

5. Play video #10 of a long trip and pause it. Click on the track ahead of the car's current location: Map display goes back to the beginning of the trip.

I cannot click on any part of the track in the Map window and reliably know that it will go to that location and play the video from there.

 

[Kremmen]

My first job would be to install a new firmware version after a reset, the pinhole on the side, yours may be corrupt.

If you still have issues then post back and I'll link a download from one of mine that definately works. That'll help decide whether it's a file or PC issue.

Alternatively, link a download to one of your files for me to test on my PC.

 

[jyunte]

My first job would be to install a new firmware version after a reset, the pinhole on the side, yours may be corrupt.

I don't think resetting the 119 V3 would affect how DCV updates its moving map display for valid data (files with no reported errors).

I've removed all old 119V3 video files from my computer, cleared the DCV cache, and will format the SD card in the dashcam so that everything is fresh for the next long trip tomorrow. I'll be able to upload clips that behave incorrectly at that time.

 

[jyunte]

I don't think resetting the 119 V3 would affect how DCV updates its moving map display for valid data (files with no reported errors).

I've removed all old 119V3 video files from my computer, cleared the DCV cache, and will format the SD card in the dashcam so that everything is fresh for the next long trip tomorrow. I'll be able to upload clips that behave incorrectly at that time.

I purchased another 119V3, reset it to factory defaults, and formatted the SD card in the camera. It was already on the latest firmware.
I ran it for a 75-mile journey. There are 50 videos on the SD card.
There were no errors on any clip, not even the first one, which was the cold start.

If I zoom in to just before the end-point of the journey, where the car was stationary for a time, and click on it in the map viewer, the map jumps to 49 seconds into video 4, which is about 2.6 miles from my starting point and 2 hours earlier in the trip.

This confirms that it is not the dashcam that is causing this error.

I will be doing some more tests with both cameras, as the original camera had numerous errors on the first clip after boot-up, but the second camera did not. I still have time before my return window closes.