2017.1.0p1 video meta import bug, differences between users that triggers reimports

Hi there, since we upgraded to 2017.1.0p1 every time a user updates they're repo, Unity modifies the meta files for all of our video assets that have been switched over to use the video player introduced in 5.6. They commit the meta files and this triggers a reimport of all video assets for all users and the cycle repeats. We have dozens of large video files and it chews up 20 minutes every time we update from the repo. Making it worse is that the cache server doesn't cache the new video assets. I've reported this weeks ago but still no response, but now this change has made it even worse ie. we only had to deal with reimports for switching platforms, but now every time we update our repo from any user. Something is clearly wrong.

Our videos do use the transcode override per platform feature which I'm sure must be playing a part in this. But the meta should not be changing per user surely?! Looking at the changes in the meta files it seems that different machines are calculating the video size and amount of frames differently which just can't be right. The two machines that the meta files are bouncing between are both clones of the same mac hardware and both running the same version of macOS.

What would account for unity thinking the video file size and total frames being different depending on different computers importing the assets?

 

Just bumping because I've edited my original post to make it a little clearer. Is anyone else having this issue or have ideas on how to solve this?

 

having the same issue in 5.6.2p4

 

Having the same issue in 5.6.1f1

The only meta properties that are changing are encodedEndFrame and streamedResource size, which vary by a small amount.

 

Having the same issue in 2017.1.0p5

It's driving me crazy. This is the git diff output (only encodedEndFrame and size change per user):


encodedStartFrame: 0
- encodedEndFrame: 115
+ encodedEndFrame: 116
streamedResource:
source: library/metadata/46/4644fb1d7c32b4944bd381147c90f6bc.resource
offset: 0
- size: 623981
+ size: 633605
userData:

 

Is the video not in streaming assets?

 

No, it is somewhere in Resources.
Is that wrong? why?

 

My team is encountering this issue; it also appears to cause strange problems with the Cache Server the machines share, and causes builds to fail.

It sounds like what's happening is that each machine generates a slightly different version of the file - in fact I've seen different "encodedEndFrame" values produced for the same file *by the same machine*! So even for the same machine it doesn't seem to be deterministic.

The first machine then uploads its file to the cache server, but either the file is invalid, or it's invalid once it's downloaded by another machine (the cache server appears to return a 0-byte file for this video file).

The last posts in this thread reference the StreamingAssets folder. However we were previously using custom videos in the StreamingAssets folder - the point of using this feature was to move away from those and let Unity handle the video import specifics per-platform, saving us from having large files for each platform in the StreamingAssets folder, etc.

Is this only seen to happen with certain videos? My team is using Unity 5.6.3p4 - has this problem been fixed in a newer version? We have tried many things to understand what's going on here, and it seems like we'll have to drop using VideoPlayer entirely - we can't even diagnose what's happening well, and it's been disrupting our workflow for days.

 

This doesn't make sense, what's it matter where the file is stored? The 'large file' still needs to exist somewhere.

However videos should be put in streaming assets in general so that it can be streamed properly, as well Unity treats streaming assets differently and will not do a full import on files placed there.