[Craig Seeman]

Noticing that source is HDV, which was mostly recorded to tape until the tail end of the camera development where some were recorded to card. I don’t know of any camera that recorded HDV to Compact Flash. I think the few that recorded to card were SD cards. Perhaps they need something like an HDV .mts file. HDV was recorded to SD card as a Transport Stream if I recall correctly. I’m not sure why they’d want HDV over ProRes or DNxHD unless they have a very old NLE. Even if the have “no budget” for a paid NLE, the FREE DaVInci Resolve can handle ProRes or DNxHD on a computer with a decent GPU.

[Craig Seeman]

Perhaps Will hasn’t seen my Library. Would you send me his contact info?
I’ve been in contact with Josh.

[Craig Seeman]

I sent them a library. One clip short clip in the Library. 10 seconds or so in the project (timeline). No other effects at all. Newly created library under FCPX 10.3.1. The problem is obvious.

[Craig Seeman]

If the full duration fails but short sections encode, it could be memory related. The Studio suite was only 32 bit. Using a reference movie might compound the problem. Do a full ProRes export first.

[Craig Seeman]

The request doesn’t make sense from a technical perspective. There’s also virtually no logistical reason to do it.
What “camera?” Even within the same brand they record differently. My Sony EX1 recorded differently than my Sony X70 which records differently then my consumer Canon Vixia which is different than a Canon D80 which is different than Canon 7D and so on. Isn’t the absurdity of the request obvious to you?

[Craig Seeman]

I suspect instagram assumes users have no control what their mobile devices will deliver and they just re-encode to whatever they need on their end.

I don’t doubt, just like YouTube, the better you send, the better the delivery within reason (and what that is, is subject to debate). YouTube has recommended H.264 specs for example but that doesn’t stop people from uploading ProRes which they swear they can see a difference in the final YouTube encode.

Perhaps if you examine an Instagram video externally you can see how they’re encoding. You can examine a good mobile video (from a current iPhone or high end Android) and see what those specs look like. That’s not to say doing better than that might give you even better quality.

[Craig Seeman]

Up front applying a lossy codec is not really “archival.”
Loss is permanent.
Storage is relatively inexpensive.
The time it takes to transcode is an expense since, if you’re professional, time is money.

[Tom Dempsey] “absolutely the best quality i can get outside of the original pro res hq”

There’s no such “absolute” technically speaking.

Generally the best H.264 encoding is with x264, High Profile, CABAC entropy, multi-pass variable bit rate. Higher data rates and higher key frame frequency can help but there are diminishing returns on that.

Generally It makes much more economic sense to just buy more storage.

If you insist on lossy compression, what’s acceptable is subjective and what you think looks great today may subjectively look bad a few years from now… even compared to H265 or maybe VP10 as it becomes more widely implemented.

[Craig Seeman]

[Ricardo Marty] “Destination codec_ (to compact flash)”
Compact Flash isn’t a codec. It’s a storage medium.

[Ricardo Marty] “like if it was recording from a camera”
I don’t see the logic to this which may be one reason for the lack of response.
Generally it ranges from difficult to impossible to replicate the file structure of most cameras with valid metadata.
Generally there’s no reason to do this unless one is forced to playback from the camera and that’s rarely needed.

[Craig Seeman]

They’ve acknowledged receipt of my “project” (Library with source media and project with clip and filter applied).

[Craig Seeman]

Sorry but why would there be latency in De-click for example?
There’s no issue with De-verb.

Also if it were processing latency that the file would be rendered correctly even if it can’t process in real time.