HW2.5 video's do not play in newer firmware releases in chrome/electron

[vronp]

Hi,

I'm on a mac running Mojave. The program seems to load correctly. I click on a date and then a "time" in the list of videos. However, the loading screen only shows 0% and never changes. Playing does nothing.

Also, when I click on a different time stamp, the USB drive does blink which I assume means the system is reading from it.

Not sure if I'm doing something wrong here??

[vronp]

By the way, thank you very much for putting this together.

[BobStrogg]

Is your car likely in HW3? Likeliest cause is the video is encoded with the H.265 / HEVC codec, which Chrome (used under the hood by the app) doesn’t support. If you click the “Browse” button it should open the app in your default browser. If your default browser is also Chrome (or Firefox) could you try copying the same URL into Safari or Edge? (both appear to support H.265).

[EpicMount]

I registered on Github just to leave this comment as I am also having the same problem. It looks like this is related to something that has changed with the latest update: 24.4. I'm using a 500GB HD and all my videos are viewable in your app up until after I received the update on Monday night. I have a few days worth of videos that can't be viewed since Monday but are viewable in Windows Media Player.

[vronp]

I don't know how to determine that. I purchased the car in May if that helps. What you describe is likely the issue and I will try your solution.

Thanks very much.

On Wed, Jul 24, 2019, 14:25 Chris Cavanagh notifications@github.com wrote:

Is your car likely in HW3? Likeliest cause is the video is encoded with the H.265 / HEVC codec, which Chrome (used under the hood by the app) doesn’t support. If you click the “Browse” button it should open the app in your default browser. If your default browser is also Chrome (or Firefox) could you try copying the same URL into Safari or Edge? (both appear to support H.265).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BobStrogg/teslacam-browser/issues/34?email_source=notifications&email_token=AGUKRXZWQ6QAENOLTZREYA3QBCNAJA5CNFSM4IGSPP4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XGKJQ#issuecomment-514745638, or mute the thread https://github.com/notifications/unsubscribe-auth/AGUKRX6B3H5M2DY5KS43AOLQBCNAJANCNFSM4IGSPP4A .

[EpicMount]

I'm definitely not HW3 (2018 build) and have the same problem. Which software version is your car? If you are on 24.4 like me then that's likely the issue.

[vronp]

2019.24.4

On Fri, Jul 26, 2019, 10:51 EpicMount notifications@github.com wrote:

I'm definitely not HW3 (2018 build) and have the same problem. Which software version is your car? If you are on 24.4 like me then that's likely the issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BobStrogg/teslacam-browser/issues/34?email_source=notifications&email_token=AGUKRX2ICIILGZQQDM5YZU3QBMFNXA5CNFSM4IGSPP4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD242VYI#issuecomment-515484385, or mute the thread https://github.com/notifications/unsubscribe-auth/AGUKRX4HYF7PTGSKTPDOZNTQBMFNXANCNFSM4IGSPP4A .

[EpicMount]

Bingo!

[vronp]

I had the same problem with the previous software.

On Fri, Jul 26, 2019, 11:12 EpicMount notifications@github.com wrote:

Bingo!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BobStrogg/teslacam-browser/issues/34?email_source=notifications&email_token=AGUKRX2YHNXY2OFVCOREGWTQBMH7JA5CNFSM4IGSPP4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD244S2A#issuecomment-515492200, or mute the thread https://github.com/notifications/unsubscribe-auth/AGUKRX6XWO5GJ2VOJ5DJDZTQBMH7JANCNFSM4IGSPP4A .

[EpicMount]

Ah, OK. In my situation, I have hundreds of videos that worked up until ~6pm Monday before the update. I now have dozens of videos, starting at 9pm Monday and onwards that don't work in the viewer but do work in Windows Media Player and another Sentry cam viewer app that I have but don't like.

[BobStrogg]

I've a hunch they've been gradually rolling out H.265 / HEVC. My understanding is HW3 includes dedicated hardware for it, but HW2.5 might do software encoding and perhaps they've been introducing it incrementally across the fleet. 2019.24.4 could be where the shit really hits the fan.

It may be possible to build the app with the HEVC codec included, but it looks pretty painful. Open to suggestions / help if anyone interested :)

The app's "Browse" button should help, but only if you have a browser that supports the codec natively; so far I think that's only Edge and Safari.

[smcasagrande]

The new (non-working) files with 2019.24.4 don't appear to be HEVC - according to VLC, it's still h.264/AVC, same resolution and frame rate.

[BobStrogg]

Do they play if you use the "Browse" button in the app? (might need to copy the URL to a non-Chrome/Firefox browser).

Can confirm shenanigans are afoot though; I'm seeing same issue with newer videos :/ They seem to work ok in Safari (on macOS anyway) for me, but Chrome is unhappy as usual.

Could also be a new Tesla bug... I seem to have a whole bunch of 0:00 duration videos in RecentFiles...

[smcasagrande]

No, they don't play when hitting Browse, but mine opens in Chrome (Win 10). The only URL that opens is localhost:8080, it doesn't do anything when copying to Edge. VLC and WMP play the files fine.

[tapr00t]

Hey Bob, this reddit comment might help you in identifying the problem: https://www.reddit.com/r/teslamotors/comments/chpbsp/2019244_dashcam_video_not_playable_in_browser/euyat30/

[BobStrogg]

Interesting!

Don't really want to have to modify the files in the app though... Maybe a batch / script file just to run ffmpeg on them outside the app? If it is a Tesla bug, I expect (hope?) they'll fix it soon...

[kadorito]

Hi, I have the same issue, recent recordings are not working on any browser or in the app. HW2.5 model 3, h264 files.

[olexs]

Same here. Weirdly enough, https://sentrycam.appspot.com/ is able to play the files fine, running in Firefox 68.0.2. Model 3, HW 2.5 (Jan '19 build), firmware 2019.24.4 when the recordings in question were made.

[emilm]

I believe electron uses Chromium as it's engine so it's definitely that. Got the same issue myself, also.

[adamncsu]

I was able to resolve this on Windows 10 by installing this Microsoft utility: HEVC Video Extensions

Videos load fine in Chrome now.

[BobStrogg]

Awesome! Maybe there’s a similar fix that’ll work on macOS too 🤔 I’ll look into it 👍🏻

[CptanPanic]

I was able to resolve this on Windows 10 by installing this Microsoft utility: HEVC Video Extensions

Videos load fine in Chrome now.

I already had this installed, and it doesn't work for me. I am using latest Windows 10 v1903. I also tried opening in Edge.

@BobStrogg even if this worked, wouldn't this just be a workaround and not a "fix" since the main app doesn't work.

[emilm]

What codecs are packaged with electron in your releases VS the ones that are in desktop browsers?

[joshwardell]

Same here. Weirdly enough, https://sentrycam.appspot.com/ is able to play the files fine, running in Firefox 68.0.2. Model 3, HW 2.5 (Jan '19 build), firmware 2019.24.4 when the recordings in question were made.

Thanks for this suggestion! TeslaCam browser had been my choice for a while but stopped working a few weeks ago with new firmware, that web site works great! (Except both don't yet support v10 rear camera files)

[mitchcapper]

Firefox doesn't use the same video engine as chrome so the corruption on 2.5 clips with the timestamp offset does not seem to effect it. Chrome/cef/ electron all based on the chrome engine use the same video rendering engine thus the 2.5 issue. For 3 the issue (at least for older clips) is the x265 HEVC codec problem which installing the microsoft store codec pack seems to fix.

You could also try using FF (or edge) with this app by clicking the launch browser option:) As that should use video engines that can handle the 2.5 issue.

Hopefully the v10 rolling out now fixes the timestamp corruption problem.

[mitchcapper]

After testing some V10 files unfortunately can say this is not resolved. Chrome (and Edge Beta) will still not play a simple

[mitchcapper]

Ok so more V10(2019.32.11) HW2.5 testing:

test methods for videos:

• DirectPlay - Playing the file directly off the computer's hd in the browser url (c:\TestClips\clip.mp4)
• URLDirectPlay - Play the file served up by our node instance directly in the browser url (http://127.0.0.1:8088/videos/.../clip.mp4)
• EmbedLocal -Simple HTML file with
• FullTeslaCam - Normal tesla cam website video playing
• SentryCam - https://sentrycam.appspot.com/ playing

As previously stated all chromium related browsers: Fail DirectPlay and all other versions, likely due to timestamp offset bug.

Firefox(69): DirectPlay works, URLDirectPlay will say transferring data (we can see in network however the request goes through) and never plays, EmbedAbsoluteLocal fails, FullTeslaCam fails, SentryCam fails.

Edge(original/native): All Methods Work

IE11: DirectPlay/UrlDirectPlay work but meaningless as not compat with modern html.

There seems to be prior discussion of FF working on SentryCam, not sure if something changed with V10 further to break this but does not seem to work for me.

The good news is I think I have found a solution to get chromium based items working together, our problem is this stupid negative offset well lets just skip past it shall we: document.getElementById('test').addEventListener('loadedmetadata', function() {this.currentTime = 0.3;}, false); works:) Will see about getting such a hack into the project for a temp fix until tesla fixes the timestamp issue.

[mitchcapper]

HW 2.5 with Edge almost perfectly works BUT you cannot seek inside an individual 1 minute segment video. When you try to do so it, it will fail. This happens even just manually setting position on a simple test

[mitchcapper]

Ok I have a semi-working hack: https://github.com/mitchcapper/teslacam-browser/tree/chrome_hw25_offset_back It allows chromium based browsers(including electron) to work with the broken offset videos (hw2.5 on current firmwares). Note: combining clips screws most of the time for me so is disabled by default with the patch. Sometimes I can get external chrome 77 to load it and they will play fully but if you try to seek it will break. Electron will normally just get a white screen with combine clips. Individual clips work perfectly as far as I can tell however.

Changes are visible: https://github.com/mitchcapper/teslacam-browser/compare/bug_38_edge_scrub_bar_growth_fix_pr...mitchcapper:chrome_hw25_offset_back

Not submitting a PR as it is not very elegant and not 100% working (no combined video support). If we fix combined clips we could potentially use a setting or browser detection to enable the fix.

[kdvlr]

I am not familiar with how sentrycam.appspot,com works. It looks like it is playing the file directly, but seems to work with the HW2.5 files as is.

[mitchcapper]

@kdvlr what browser are you using and what platform? Can you confirm what version your car is? I run into the same browser limitations with sentrycam as with teslacam.

[kdvlr]

I'll take that back. I was pretty sure it worked, but just checked and it doesn't work either. I'll chalk that up to old age.

Anyway, I am running this script on my server and then I can browse all the files no problem.

cat fix_files.sh
#!/bin/bash

for f in $(find ./ -name "*.mp4")
do
  ffmpeg -i $f -c:v copy $f.tmp.mp4
  mv $f.tmp.mp4 $f
done

[emilm]

Yeah it gets re-encoded to a format supported by the codecs that's shipped with the chromium in the electrum app. The appropiate codecs that support the new format must be present in the package with chromium in the app.

[kdvlr]

@emilm - The above command does not re-encode the files. The codec stays the same. The start time on the container is fixed.

[emilm]

@kdvlr nice! Does it rewrite the entire file, or change those few bytes? Because that would be flash friendly :)

[mitchcapper]

its just copying the stream but must fix the offset time bug that is the source of this issue. Unfortunately I don't think its a great solution for this project, we would have to look into including the ffmpeg binary and then probably need to really confirm with users before going through and fixing all the files (as it does change them).

[kdvlr]

@mitchcapper - I tried your branch on my raspberry pi. I could not still browse via the server.js file. Does your fix only work on the standalone app ?

@emilm - Unfortunately, it seems to rewrite the entire file.

[mitchcapper]

@kdvlr it should in theory work as its a client side fix with any chrome based browser afterwards. Are you using chrome? Are you sure you have the fix branch(you should notice that the clip merging is turned off by default). If you go to an event do you see the first frame of them when you expand the window for it?

[kdvlr]

I pulled the branch again and it seemed to work.

[kdvlr]

@mitchcapper - The chrome fix is working well. I also managed to get it to work on the TeslaBrowser itself - https://streamable.com/287yc

Is there a way the combine clips capability can be added as well?

[mitchcapper]

At least with 2019.36 combine clips work if I start with an offset, IE click on the progress bar (this bug still exists). This mainly means with a few minor changes should work with combined clips.

[kdvlr]

@mitchcapper - That doesnt seem to work on my chrome browser. Do you have an updated build for that ?