GET ?act=info response returns incorrect values

[audionerd]

According to HTTP.md, ?act=info can be used to get the duration and size of the video file. From the docs:

GET /DCIM/110ZCAME/ZCAM0100_0000_201811121522.MOV?act=info

{
  "code": 0,
  "desc": "",
  "msg": "",
  "w": 2880,   // video width
  "h": 2880,   // video height
  "vts": 30000, // video timescale
  "vcnt": 107,   // video packet count
  "dur": 107107 // video duration.
}

But the values actually returned in the response are incorrect.

• w/h do not match the primary video stream in the downloaded file. They appear to be set from the proxy stream #0:1, instead of the primary stream #0:0. Where do these values actually come from?
• vts is described only as the "video timescale". What does that mean? The definition is unclear. It appears to actually be the audio sample rate of stream #0:2 (48000)? What is this value actually returning?
• dur is described as the "video duration" but it did not match the actual video stream #0:0 duration. It appears to be the number of audio samples? What is this value actually returning?
• vcnt is described as the "video packet count". What does that mean? It appears to be approximately the number of frames in the video + 1. What is this value actually returning?

For reference, in our testing, once we downloaded the actual .MOV file we used ffprobe to view its actual values to compare to the ?act=info JSON response. We were recording to ProRes (stream #0:0), and the file also has an HEVC proxy (stream #0:1), and audio (stream #0:2), as well as a timecode stream.

For our use case, we want to know the actual video duration and actual frame count of the video for verification purposes, to make sure that it has downloaded correctly. But currently, we cannot rely on ?act=info to provide these values accurately.

Please fix ?act=info to provide more accurate information about the video, and update the documentation to accurately describe how ?act=info works.

[QuinnyPig]

Can also confirm that ?act=md5 returns an md5 checksum that bears no discernible relation to the actual file being queried. That seems... less than ideal?