Many people claim to have been using (including our SteveRhoden) for workflows with clients and not have problem. This leads me to believe that FinalCut is not the be all issue. I am leery of MAC proponents and particular MAC editors who like and confine themselves to do things within a very narrow range of activity.
The only non Apple ProRes encoder I have heard of is in libavcodec. Mirazon is likely using the ProRes and DNxHD encoders in libavcodec.
Calling the ffmpeg/libavcodec/ffmbc ProRes encoder (actually 3 of them) "hacked" is a very inappropriate use of the term. With that logic, one could say the same thing about the LAME MP3 encoder. I don't know what the state of the fraunhofer MP3 parents are as of now, so it may be in the clear these days.
EDIT: Remove the "patch" comment. My editor friend said that was old info.
As for the chunking JR mentions. This has absolutely nothing to do with the ProRes encoder and everything to do with the muxer. It is well known the libavcodec default chunk size is kinda small. Fine for many codec applications, but not for high bitrate formats like ProRes. This chunking is trivially changed. e.g. "-chunk_duration 500000".
If one is using some tool that uses libavcodec and that tool is not savvy enough to adjust the chunk size to something appropriate for ProRes, then that is a problem of that tool and not the ProRes encoder OR the libavcodec muxer.
ProRes itself is just another variant of DCT encoding. If it is not encoded properly then crap will come out on decode. In most any lossy encoding there is some wiggle room, so one can say that encoder X is "better" quality than encoder Y.
> "JohnnyRoy, I do not have access to Final Cut. I was wondering if you have used it with a PC ProRes video and if so what your experience was?"
I haven't used any because I don't have any but if you want to supply me with one I'd be happy to test it out in FCP X. I have only heard other editors complaining about them and the fact that Apple rejects them seems to imply that there is something "different" about the files otherwise no one would be able to tell the difference.
~jr
Former user
wrote on 9/19/2014, 7:51 PM
Let me see if I can create something that you could test if you don't mind. It might be this weekend sometime. I haven't created any for a while, but I would like to know if there are issues.
> "Calling the ffmpeg/libavcodec/ffmbc ProRes encoder (actually 3 of them) "hacked" is a very inappropriate use of the term."
I referred to it as a "hack" because it was created by reverse engineering the codec which I consider a hacking activity. Reverse engineering could lead to an incorrect interpretation of the format which may be why Apple can tell it's not the real thing when you submit it to iTunes. If it was a 100% identical, Apple wouldn't be able to tell the difference.
> "As for the chunking JR mentions. This has absolutely nothing to do with the ProRes encoder and everything to do with the muxer. It is well known the libavcodec default chunk size is kinda small. Fine for many codec applications, but not for high bitrate formats like ProRes. This chunking is trivially changed. e.g. "-chunk_duration 500000"."
That's good to know. Getting parameters correct for ffmpeg is a bit of a "black art" so it doesn't surprise me that this gets overlooked. Good info!
I uploaded a sample from ffmbc so you can try it in FCP. Basically it is just some avchd run through VP13, and edited to 10sec, rendered to xavc, and then put through ffmbc to Prores HQ format.
Here is how Vegas sees the stream info:
Streams
Video: 00:00:09.343, 23.976 fps, 1920x1080x24, Apple ProRes 422 (HQ)
Audio: 00:00:09.343, 48,000 Hz, 32 Bit (IEEE Float), Mono, 16-bit Little Endian
Here is how media info sees the file:
Video
ID: 1
Format: ProRes
Format version: Version 1
Format profile: High
Codec ID: apch
Writing library: ffm0 - my guess is this the reason Apple rejects, but it could be the data construction of the file too.
One thing to note is that ffmpeg was faster @53fps, vs ffmbc which topped at 32fps on an i7-870 win8.1
The file I create list fmpg as the writing library. This is using the free version of Cinec.
JR, I have a dropbox account I can load this up to. But I think I have to have your actual email to share. Where else can I upload it for you to check (if you are willing to do so)
Thanks to astar and DaveT2 for producing some Windows ProRes files. Would like to see these run through Premiere and FinalCutProX as well. Would like to know the inherent chunk size these were created with.
Link to an ~8 second link of a video from my Vixia camera (avchd) converted to Prores (not HQ) thru Cinec. If someone wants to check it on a FCP system, it might help others here.
Feedback for Astar -
conducted simple test of your uploaded file - using Quicktime ( Pro 7.3.1) and identified the file - plays back as pure black screen -QT info shows the right information - just no picture elements..
MediaInfo also identifies the file info correctly. this test on WinXpSrvPck3 32bit - no installation of VegasPro or any other NLE
Former user
wrote on 9/21/2014, 2:19 PM
videoITguy, do you have the PC Prores playback codec loaded?
The Pro Quicktime installation 7.3.1 first referred me to the Apple components page but among the non-installed components - there was no listing of ProRes as a component. So assuming I already I had it, if the option is not presented. Where do you think it should come from?
Note that I reviewed the Apple website and downloaded what was identified as a small executable ( not a component?) - this installed a so-called decode set. Now when I play Astar submitted video - it is pure greenscreen. Well it could be a point release problem - the difference between 7.3.1 and 7.5?
Former user
wrote on 9/21/2014, 3:22 PM
The do have a legitimate Prores play back only codec for Windows. It is not a part of the normal QT download. Is this the one you used? Version shouldn't matter. I have used it on various versions. I am using 7.7.2
Would like to know the inherent chunk size these were created with.
The chuck size issue seems to be all about the size of the audio chunks. Nothing to do with video. The word I can find, in the ffmpeg list, is that Apple prefers about 48000 samples per chunk. Stereo consists of two samples (L+R). There are reports from that for files without audio they do not get complaints from Apple.
Looking at some 4K Blackmagic ProRes MOV files I have downloaded, I see the audio chunks at 24000 samples and the audio is 24bit. I am using the Elecard Video format analyzer tool. Its a free tool.
So with 24000 stereo samples at 6 bytes per sample we at about 144KB for a chunk for these particular files.
In a 30p 145 Mbit Prores encode a video frame is about 600KB. The muxer deals with "samples". In video a "sample" is a full frame or a field. So we can see the video chunk, a single sample, is FAR bigger than the audio chunks.
So the mdat atom data stream would look something like
VaaaaVaaaa EDIT: Oops, got this mentally backwards. 363 V to 31 audio chunks this file. An audio chunk covers more time due to the smaller samples.
VVVVVVVVVVVa
It seems Apple wants big audio chunks to simplify their file I/O and help their performance.
I looked at an ffmpeg AVC/x264, MP3 audio encode and the chunks are very small. About 1KB or less. Given all this chunk talk, and seeing the small default, I have adjusted my ffmpeg commands to bigger chunk. I frameserve to ffmpeg for AVC/x264 encodes.
DaveT2 - per the Apple website info we are both ascribing - this decoder module has to have Quiktime 7.5 or greater - so that would make a huge difference. However when I did install 7.5, reapplied decoder, the video from astar is total greenscreen.
I tried to use a download helper to get DaveT2's video - but the download breaks everytime and I cannot get it successfully.
Former user
wrote on 9/21/2014, 7:18 PM
Hmm, I guess I have been using the newer versions of QT for a while.
I don't know about the dropbox. It took a long time to upload. I will try it again tonight and post a different link.
I am going to bump this thread, as I was hopeful of seeing more input from others.
The original goal that I held was to test the playback of Windows ProRes on as basic a system as possible. I did not want to influence it by installing any difficult codecs or any NLE installs.
Base system - WindowsXP32bit SrvcPk3 - QuicktimePro7 installed.
Findings-1) QTimePro Ver 7.3 original license - no extra components- did not play ProRes. 2) Installed ProRes decoder Ver1 add-on - did not play.
3) Upgraded to Ver 7.5 at request of Apple, kept ProLicense- installed ProRes add-on - did not work with Astar's file submission - indication that there was some jerkiness of the file play with the player controller. At this point I gave up on testing Win ProRes recorded by Astar's method. 4) Upgraded to QTimePro 7.7.5, kept ProLicense - DID NOT INSTALL any components or supplemental decoders. Tested the 4th step with original ProRes recording done with timecode in a camera to recorder device - used the proxy 35 version of the 422HQ file for expediting - worked beautifully.
> Reply by: astar "I uploaded a sample from ffmbc so you can try it in FCP. Basically it is just some avchd run through VP13, and edited to 10sec, rendered to xavc, and then put through ffmbc to Prores HQ format."
That files looks good in FCP X. It correctly reports ProRes422 HQ and FCP X has no problems with it.
> Posted by: DaveT2 "Link to an ~8 second link of a video from my Vixia camera (avchd) converted to Prores (not HQ) thru Cinec. If someone wants to check it on a FCP system, it might help others here."
This file did not fair as well. While FCP X did correctly import it, when I placed it on the timeline, I immediately got an orange line above the clip indicating that re-rendering is needed to play this file back smoothly. I'd imagine that once I start adding FX it would slow things down.
> Reply by: NormanPCN "The chuck size issue seems to be all about the size of the audio chunks. Nothing to do with video. The word I can find, in the ffmpeg list, is that Apple prefers about 48000 samples per chunk. Stereo consists of two samples (L+R). There are reports from that for files without audio they do not get complaints from Apple."
If this is the case then it may explain why the ffmbc video wasn't flagged as needing rendering... it had no audio.
A Star, if you'd like to render another with audio to see if this was the case or if DaveT2 would like to render a Cinec file without audio, I'd be happy to test again.
BTW, when I opened each file in QuickTime Player and opened the Inspector Window the format is listed as: prores (all lower case) and in a "real" ProRes file the format is listed as Apple ProRes 422 HQ so all you need to do is open the inspector in QuickTime to see that these are not real ProRes files from Apple's encoder. Perhaps that's why iTunes rejects them? Maybe it's looking for the string "Apple ProRes 422"? Of course it probably rejects the Cinec files because they are flagged as needing re-encoding.
~jr
Former user
wrote on 9/22/2014, 2:49 PM
Thanks for doing that JR. I do have a question though, the file I uploaded was not HQ. did you change your timeline in FCP to be the non-HQ or to match the video I uploaded.
It is good to know. I will probably end up buying a refurb mac and FCPX rather than deal with Windows on this type of stuff.
> "I do have a question though, the file I uploaded was not HQ. did you change your timeline in FCP to be the non-HQ or to match the video I uploaded."
Sorry if I wasn't clear. Your clip did not say HQ. It just said "Apple ProRes 422". The other clip said HQ.
> "It is good to know. I will probably end up buying a refurb mac and FCPX rather than deal with Windows on this type of stuff."
Well... you probably heard my story already but I picked up a 2008 Mac Pro 2.8Ghz 8-Core with 16GB memory, 256GB SSD, and 2 TB RAID 0 and ATI Radeon 5870 for $740 on eBay! It's now my main editing computer. If anyone wants a slightly used but brand new $2400+ 6-Core Windows PC let me know. It's collecting dust at my house. ;-)
The 2010 12-Core Mac Pro's are going for around $2400 on eBay and IMHO worth every penny over the $2400 I wasted building a 6-core Windows PC.
My test of a camera original in ProRes format shows as follows in the Movie Inspector dialogue - "Apple ProRes 422 (Proxy), 1920x180, Millions" of QTimePro Ver 7.7.5.
I could have sworn, that unlike JR states - that my earlier failures with Astar's file read in MediaInfo as well as QTimePro Ver 7.3 (which failed to file play) that the file format property read as "Apple ProRes 422" - but I did not save that info - so can't say for sure.
This might be something to look for in interrogation of files.
JohnnyRoy:If this is the case then it may explain why the ffmbc video wasn't flagged as needing rendering... it had no audio.
About ffmbc.
I have read posts in the ffmpeg list is that ffmbc was patched to use chunk sizes that Apple don't not complain about when you encode to ProRes. Maybe true, maybe not.
No such patch for ffmpeg itself. And any code using libavformat directly will have to manually control. With those, it is up to the user to setup a chunk size that Apple is happy with.
Also, ffmpeg and probably ffmbc identify themselves in the metadata as the writing library. Anything can look at that to see that the file is not an Apple file. The Blackmagic camera files I downloaded, show "Apple QuickTime 7.7.3" as the file source.