POST
|
ArcGIS Pro can play several non-spatially aware formats, but .ts is the only container format that can contain a spatial data stream. The .ts container format is not limited to MPEG-2; it can also contain MPEG-4, H.264 and H.265, all of which Pro can play.
... View more
02-29-2024
07:52 AM
|
0
|
0
|
50
|
POST
|
Hello, I'm happy to help you with this. Are you able to share your data?
... View more
02-29-2024
07:44 AM
|
0
|
0
|
49
|
POST
|
Hello, A few questions for you. Is the camera pointing up above the horizon at the beginning a video? We will be fixing a bug related to footprint computation in 3.0.2, which may or may not be related to your issue. Are you setting a DEM, or using constant elevation? (if you're using constant elevation it will give a warning) Does the Video Multiplexer tool work if you don't set a DEM or elevation? Thanks. Any additional info you can give would be super helpful.
... View more
08-30-2022
05:18 PM
|
0
|
0
|
174
|
POST
|
As a further follow up, the bug has been fixed for 3.0.2, currently scheduled to be released late September. Thanks again for reporting this issue.
... View more
08-30-2022
04:47 PM
|
0
|
0
|
644
|
POST
|
Ooof. Yup, that's a bug. We have a fix for 3.1. We've missed the window for 3.0.1, but I'll try to get the fix in 3.0.2. Unfortunately there's no workaround.
... View more
07-25-2022
08:05 AM
|
1
|
2
|
707
|
POST
|
`Sensor True Altitude` is height above the MSL/geoid. `Sensor Ellipsoid Height` is height above the WGS84 ellipsoid. We do not have a mechanism to input height above ground. If the scaling is off, that could indicate a few things. The first things to check are that the altitude is correct and that the field of view is correct. The Phantom 3 and 4 we use for testing tend to have systematic altitude errors; for any given flight, the altitude reported by the drone is off by a fixed amount for the whole flight. It's so bad we're not necessarily able to tell if the altitude it's reporting is HAE or MSL -- we take the ground elevation of the takeoff point and the reported altitude when takeoff occurred, and apply the difference between the known ground elevation and the reported takeoff altitude, and apply that difference to the reported altitude for the flight. This seems to work well enough. Unfortunately I don't have a good workflow for determining what the field of view is. I do know that the FoV that works best for our Phantom 4 is not the FoV reported by the Phantom 4 spec sheet. Which is not ideal.
... View more
11-29-2021
09:25 AM
|
0
|
1
|
445
|
POST
|
We managed to squeak a better error message for this situation into 2.9, just under the wire. So keep an eye out for that. Determining what the "right" way to determine how much terrain to index is something I've struggled with a lot. There are always edge cases that seem to crop up. It's true that if you're 20m above ground level, the curvature of the Earth would indicate the horizon is 15km away. But it's also true that at Esri's main campus in Redlands, if you're standing at ground level, you can see Mt San Jacinto 55km east of here, and you can see Mt San Antonio 50km to the northwest. We need to expect to be able to put a telescopic lens on our camera and draw a footprint on those mountains. Similarly, we should expect to be able to fly a drone 20m above ground level on the tops of those mountains, point the camera down a few degrees from the horizon, and draw a footprint in Redlands. So we have this situation where the algorithm needs to know what terrain the camera is looking at before it can calculate what terrain the camera is looking at. The algorithm we're using now is fairly robust in terms of if there's terrain where the camera is looking, the terrain will be indexed and the correct footprints will be calculated. Unfortunately this comes at the expense of handling smallish DEMs less than optimally, as you've seen. I think for 3.0 we can enable the processing extent environment variable for the video multiplexer. And then load and index terrain from the DEM for that extent only if it's set, but by default use the current logic. But unfortunately that will have to wait for 3.0; we're already in feature freeze for 2.9. Stay tuned.
... View more
09-09-2021
09:56 AM
|
3
|
2
|
2325
|
POST
|
The video multiplexer is meant to be able to use custom DEMs as input. Can you supply your DEM? And ideally, the metadata .csv file? One thing worth checking is that the extent of the DEM is at least as large as the extent of the metadata. The multiplexer expects to be able to get elevation data of the full extent of all the data in the metadata file. This includes the platform location, even if the target area is smaller. For instance, if the target area is a football field and a small amount of area around it, say a 200m x 200m area, but the platform is flying in a 10km radius loop around the football field, the multiplexer will expect to be able to read the data of the full 20km x 20km area that the platform is flying in. If the DEM only covers a 500m x 500m area centered on the football field, the video multiplexer tool will fail. If the sensor ever points above the horizon, it will project a point out some distance (50km I believe) and will include that in the extent it requires. If this extent mismatch is your problem, there are workflows to construct a DEM composed of a larger raster downloaded from Terrain3D with your DEM overlaid on top of it, but I'm afraid this is outside the area of expertise. For the other issue, the Video Multiplexer does not allow the user to specify which data product from the Terrain 3D service is used. You would need to use another tool to extract just that data product and save it as a DEM. But unfortunately, again, this is outside my area of expertise.
... View more
09-07-2021
01:47 PM
|
3
|
0
|
2343
|
POST
|
Hi Tony, Are you able to share the video with us? Unfortunately, due to limitations beyond our control, we're unable to give more helpful error messages when a video fails to open.
... View more
03-25-2021
01:19 PM
|
1
|
0
|
897
|
POST
|
Edward, What data is in the flight record? Can you attach your data? Note that it's ok to fill the missing fields in with zeros if the field is missing. For instance, MISB expects the sensor relative angles to be relative to the platform, but I seem to recall DJI might give absolute angles for the sensor. In that case, it's fine to give whatever angles you're given in one column, and leave the angles all zero for the other columns. -Nick
... View more
07-20-2020
03:39 PM
|
0
|
1
|
2048
|
POST
|
Hi Graham, This is indeed broken in 2.5. It will be fixed in 2.6. Unfortunately, we don't have a fix in time for 2.5.1. However, there's a workaround. If your map has an elevation source, it will calculate the footprint based on the elevation source in real time, and the incorrect value in the metadata will be ignored. Scene views always have elevation sources. To add an elevation source to a 2D map view, Ribbon -> Map tab -> Layer group -> Add Data dropdown -> Elevation Source. I typically use the Terrain 3D service from Living Atlas. Let me know how that works for you, -Nick
... View more
04-14-2020
11:01 AM
|
2
|
1
|
846
|
POST
|
Ok, so it looks like the metadata itself is sorted out. Now you need to add an elevation source. You can add an elevation source to the map, using Map->Add Data dropdown->Elevation source. Alternatively, you can run the multiplexer with a data source, by adding an elevation source into the Digital Elevation Model box. Since your video takes place mostly over the ocean, you could also just type 0 meters into that box. Note that we don't really have a way to deal with tides at the moment, so that's something to keep in mind. -Nick
... View more
12-03-2019
01:45 PM
|
0
|
0
|
613
|
POST
|
Hi James, The problem is that all of your timestamps has the same value. They're all 1571940000000000. The problem is that since they're all the same, there's no way to sequence them. This is usually because Excel will convert all the values to scientific notation and only a few significant digits, so it will save it as 1.57194e15 or something similar. You'll have to gather up your original data and make sure Excel never eats your last digits. The way to make sure it never eats them is to change the formatting to "Number" with 0 decimal places. There's a screenshot in the tips and tricks page about how it should look. Note that since Excel has already eaten that data, you'll have to grab your data from an earlier stage. Video Multiplexer Tips and Tricks to format your metadata Good luck, -Nick
... View more
12-03-2019
10:43 AM
|
1
|
3
|
613
|
POST
|
Lucas, Yes, if you could send me your data I'd be happy to take a look at it. -Nick
... View more
06-11-2019
09:53 AM
|
0
|
1
|
367
|
POST
|
Lucas, I have attached two datasets for use with the video multiplexer. The metadata_465 set does not require a mapping file. Additionally, I would recommend you update to 2.3.2 as quickly as possible, and to 2.4 when it comes out. (should be 1-2 months away) 2.3 fixed two important bugs in the video multiplexer, (one of which I mentioned in my July 6th 2018 post, and it might be the same problem you're having) and 2.4 will make the error messages significantly more clear. It will give you the specific values it won't accept. Best of luck, -Nick
... View more
05-22-2019
11:08 AM
|
1
|
3
|
1462
|
Title | Kudos | Posted |
---|---|---|
1 | 07-25-2022 08:05 AM | |
3 | 09-09-2021 09:56 AM | |
3 | 09-07-2021 01:47 PM | |
1 | 03-25-2021 01:19 PM | |
1 | 12-05-2018 01:00 PM |
Online Status |
Online
|
Date Last Visited |
5 hours ago
|