On 8/28/20, Phil Rhodes via ffmpeg-user <[email protected]> wrote: > > The ProRes implementation is not likely to be perfect in terms of Apple's > internal spec. They do not publish the spec so we don't know. In general, it > has been shown to be reasonably reliable when used with most software > decoders. It has had problems in the past (I haven't checked for years) in > playback on hardware devices such as Atomos and AJA recorders. It is > possible to set ffmpeg up to create ProRes-like files that are wildly out of > spec and are unlikely to play back satisfactorily on anything, but with > sensible setup it's generally fine. "It's generally fine" is all you're > getting, sadly. I use it freely in situations where I will have an > opportunity to fix problems as they occur (they never have) but I would > hesitate to use it, for instance, for submission of a final master to > someone. > In general it's very difficult to figure out exactly when something has > changed in a particular part of ffmpeg as no change log is published, at > least nothing which calls out "we have changed something which affects > prores," but the behaviour of the ProRes implementation has not changed in a
Unlike Apple, everything about ProRes implementation in FFmpeg is open [1]. Your comment that there is not changelog for ProRes in FFmpeg is very unhelpful and even with unclear intentions. [1] list of changes: http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdata.h;hb=HEAD http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdata.c;hb=HEAD http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdec.h;hb=HEAD http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdsp.h;hb=HEAD http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdsp.c;hb=HEAD http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdec2.c;hb=HEAD http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresenc_anatoliy.c;hb=HEAD http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresenc_kostya.c;hb=HEAD > way that's visible to me. Prores is a reasonably simple format, as these > things go. It's technologically similar to MJPEG or DV. > > P > > On Friday, 28 August 2020, 01:01:19 BST, Gary Yost <[email protected]> > wrote: > > ’ve got a question about the Prores implementation in ffmpeg because I’ve > seen some odd behavior here with FCPX (running on a very beefy 16-core Mac > Pro with 192Gram and an Afterburner card). > > When I output files from ffmpeg in ProresLT format and bring them into FCPX, > they stutter badly… playback is ~5fps. But when I transcode/optimize them > in FCPX, which creates Prores422 versions of those files, they play back in > FCPX seamlessly. > > The ffmpeg files _used_ to play back seamlessly on this machine when I was > doing this Jan-March, but I haven’t been using this workflow since March. > My questions are: > > 1. Is the Prores implementation in ffmpeg a 100% accurate implementation as > per the Apple spec? > > 2. Has anything changed in the Prores code transcoding of ffmpeg in the lat > 4 months? > > Thanks! > > -g > _______________________________________________ > ffmpeg-user mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". > _______________________________________________ > ffmpeg-user mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
