? About ffmpeg's prores implemention
’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
On 8/28/20, Gary Yost <gary@yostopia.com> 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?
There is no Apple specification for ProRes. At least not official one as open standard.
2. Has anything changed in the Prores code transcoding of ffmpeg in the lat 4 months?
If ffplay playback is also very slow, than yes.
Thanks!
-g _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Thanks Paul. I’ll do more testing tomorrow and will get back to you with further data.
On Aug 27, 2020, at 5:14 PM, Paul B Mahol <onemda@gmail.com> wrote:
On 8/28/20, Gary Yost <gary@yostopia.com <mailto:gary@yostopia.com>> 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?
There is no Apple specification for ProRes. At least not official one as open standard.
2. Has anything changed in the Prores code transcoding of ffmpeg in the lat 4 months?
If ffplay playback is also very slow, than yes.
Thanks!
-g _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org <mailto:ffmpeg-user@ffmpeg.org> https://ffmpeg.org/mailman/listinfo/ffmpeg-user <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org <mailto:ffmpeg-user-request@ffmpeg.org> with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org <mailto:ffmpeg-user@ffmpeg.org> https://ffmpeg.org/mailman/listinfo/ffmpeg-user <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org <mailto:ffmpeg-user-request@ffmpeg.org> with subject "unsubscribe".
Hi, ProRes is proprietary, Apple actually calls FFmpeg out on having an unlicensed implementation:
Using any unauthorized implementation (like the FFmpeg and derivative implementations) may lead to decoding errors, performance degradation, incompatibility, and instability.
But you said it worked fine until fairly recently, did you install the pro video formats update that released recently? Regards, Ted Park
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 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 <gary@yostopia.com> 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 ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 8/28/20, Phil Rhodes via ffmpeg-user <ffmpeg-user@ffmpeg.org> 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... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdata.c;hb... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdec.h;hb=... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdsp.h;hb=... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdsp.c;hb=... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdec2.c;hb... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresenc_anato... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresenc_kosty...
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 <gary@yostopia.com> 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 ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On Friday, 28 August 2020, 09:34:48 BST, Paul B Mahol <onemda@gmail.com> wrote:
http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdata.h;hb... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdata.c;hb... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdec.h;hb=... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdsp.h;hb=... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdsp.c;hb=... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdec2.c;hb... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresenc_anato... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresenc_kosty... Do any of those things actually have effects that are likely to affect users? I don't think there is any way to tell without being an expert on the low-level implementation. If they do, that should be written up in a public-facing manner so that it can be understood by users. This is not public-facing documentation; these are internal notes for developers. Users cannot be expected to comprehend the real-world results of "infer array length," for instance. (Well, you can expect people to understand it, but you will be disappointed.) P
After more research, I’ve found that the two other encoders that I have which write Prores create files that Afterburner recognizes as Prores and plays them in real time. Unfortunately ffmpeg’s Prores isn’t recognized as such by the Mac and I’ll have to switch to AME for this going forward. Too bad because ffmpeg is so beautifully multithreaded and fast… I’ll miss it! Thanks all.
On Aug 28, 2020, at 6:49 AM, Phil Rhodes via ffmpeg-user <ffmpeg-user@ffmpeg.org> wrote:
On Friday, 28 August 2020, 09:34:48 BST, Paul B Mahol <onemda@gmail.com> wrote:
http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdata.h;hb... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdata.c;hb... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdec.h;hb=... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdsp.h;hb=... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdsp.c;hb=... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdec2.c;hb... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresenc_anato... http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresenc_kosty... Do any of those things actually have effects that are likely to affect users? I don't think there is any way to tell without being an expert on the low-level implementation. If they do, that should be written up in a public-facing manner so that it can be understood by users. This is not public-facing documentation; these are internal notes for developers. Users cannot be expected to comprehend the real-world results of "infer array length," for instance. (Well, you can expect people to understand it, but you will be disappointed.) P
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Hi,
After more research, I’ve found that the two other encoders that I have which write Prores create files that Afterburner recognizes as Prores and plays them in real time. Unfortunately ffmpeg’s Prores isn’t recognized as such by the Mac and I’ll have to switch to AME for this going forward. Too bad because ffmpeg is so beautifully multithreaded and fast… I’ll miss it!
Well, Adobe pays Apple to use their ProRes codec in AME, so that should be a foolproof option. Basically, authorized partners have access to a lot more comprehensive and definitive specifications and architectural directives from the original authors when they develop their codecs, and they go through the pass/fail tests that all but guarantees that their output works with any and all other official implementation. Th On the other hand, and I might be wrong about this, but the ProRes implementation in FFmpeg was pretty much reverse engineered by a couple (extremely talented) people, and it was done a long time ago. As talented as the authors are, obviously it is impossible to replicate the codec perfectly without the "blueprints." Nevertheless, it worked fine (until now), and it is definitely maintained, but some significant updates were made by Apple that I don't think have been fully realized by the changes in FFmpeg, especially in the last few minor versions of motion. Since you are on a Mac, implementing the ProRes encoder through videotoolbox would be your solution. I tried to tackle that a few weeks ago actually, but I think I may have been in way over my head, haha. Since it's a feature that would only benefit macos builds, priority might be low, I don't know how much you want ProRes+FFmpeg, but I'm thinking you could hire whoever does the heavy lifting in macos videotoolbox to implement the prores encoder as well.
Unfortunately ffmpeg’s Prores isn’t recognized as such by the Mac and I’ll have to switch to AME for this going forward. Too bad because ffmpeg is so beautifully multithreaded and fast… I’ll miss it!
I'm a bit confused this comment though... How beneficial additional threads are to performance is firstly dependent on the actual codec, FFmpeg, and AME more like orchestrates the multi-threading, and I can't see AME falling behind very much in this specific case... Do you mean ProRes rendering doesn't rev up the CPU usage over 300% or 600% if you use AME?? (Depending on source) Ultimately it's the same as all the other "Apple authorized" ProRes apps, videotoolbox. Regards, Ted Park
On 8/30/20, Edward Park <kumowoon1025@gmail.com> wrote:
Hi,
After more research, I’ve found that the two other encoders that I have which write Prores create files that Afterburner recognizes as Prores and plays them in real time. Unfortunately ffmpeg’s Prores isn’t recognized as such by the Mac and I’ll have to switch to AME for this going forward. Too bad because ffmpeg is so beautifully multithreaded and fast… I’ll miss it!
Well, Adobe pays Apple to use their ProRes codec in AME, so that should be a foolproof option.
Basically, authorized partners have access to a lot more comprehensive and definitive specifications and architectural directives from the original authors when they develop their codecs, and they go through the pass/fail tests that all but guarantees that their output works with any and all other official implementation. Th
On the other hand, and I might be wrong about this, but the ProRes implementation in FFmpeg was pretty much reverse engineered by a couple (extremely talented) people, and it was done a long time ago. As talented as the authors are, obviously it is impossible to replicate the codec perfectly without the "blueprints." Nevertheless, it worked fine (until now), and it is definitely maintained, but some significant updates were made by Apple that I don't think have been fully realized by the changes in FFmpeg, especially in the last few minor versions of motion.
Since you are on a Mac, implementing the ProRes encoder through videotoolbox would be your solution. I tried to tackle that a few weeks ago actually, but I think I may have been in way over my head, haha. Since it's a feature that would only benefit macos builds, priority might be low, I don't know how much you want ProRes+FFmpeg, but I'm thinking you could hire whoever does the heavy lifting in macos videotoolbox to implement the prores encoder as well.
Again just typical FUD from same person.
Unfortunately ffmpeg’s Prores isn’t recognized as such by the Mac and I’ll have to switch to AME for this going forward. Too bad because ffmpeg is so beautifully multithreaded and fast… I’ll miss it!
I'm a bit confused this comment though... How beneficial additional threads are to performance is firstly dependent on the actual codec, FFmpeg, and AME more like orchestrates the multi-threading, and I can't see AME falling behind very much in this specific case... Do you mean ProRes rendering doesn't rev up the CPU usage over 300% or 600% if you use AME?? (Depending on source) Ultimately it's the same as all the other "Apple authorized" ProRes apps, videotoolbox.
It is obviously slower, hahaha.
Regards, Ted Park
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Hi,
Again just typical FUD from same person.
I'm not sure what you are referring to, what's there to spread fud about??
It is obviously slower, hahaha.
What is, AME or one of the prores encoders included in FFmpeg? I mean obviously it'd depend on the job and hardware but for what it's worth I compared prores_ks with 4444xq and it took around twice the wallclock time. It did indeed take way more than twice the cpu time though, but if its output has problems then the whole point is moot :/ Regards, Ted Park
On Sunday, 30 August 2020, 23:21:16 BST, Edward Park <kumowoon1025@gmail.com> wrote:
I'm not sure what you are referring to, what's there to spread fud about?? I'm not sure what he's referring to, either, but just be aware you're talking mainly to software engineers here and they have a well-deserved reputation for being very difficult with, well, more or less anyone who isn't a software engineer. Don't be concerned, you haven't done anything wrong. They're like this with everyone. It's normal in the world of open source (it's comically bad behaviour, but it's normal). For what it's worth I've noticed problems playing back ffmpeg's prores on hardware devices, but it usually seems to work OK in software decoders. If your environment has changed in that regard, perhaps by handing off prores decoding to a hardware device, that might be an issue that's hard to solve with ffmpeg-generated files. I never tried that hard to fix the hardware playback issues, but if you really need to, you might try fiddling around with some of the commandline parameters you're using, if that's something you have the option to do. This may all be old news to you, but the command I use is something like this: ffmpeg -probesize 5000000 -i %INFILE% -c:v prores_ks -profile:v 4 -qscale:v 11 -vendor ap10 -chunk_duration 500000 -c:a pcm_s16le %OUTFILE%
I honestly can't remember most of what that does but the number after "-qscale:v" controls overall bitrate from 1 to 31. Reducing it increases bitrate (obviously!) and if you set it very low, it may create files that are wildly out of specification that Apple decoders may not like. I have not had problems with 11 (again, on software decoders). The "-profile:v" controls what sort of prores you're creating, from 0 to 4 or perhaps 1 to 4. I can't remember what number means what. The "-chunk_duration" as I recall stops Final Cut complaining about unoptimised media, or at least it certainly used to. Apparently you don't actually need "-vendor ap10" but it doesn't hurt. I'm not sure what other command line options might have relevance for ProRes but I suspect this might be quite a complicated problem to solve. P
On Mon, Aug 31, 2020 at 08:41:27AM +0000, Phil Rhodes via ffmpeg-user wrote:
On Sunday, 30 August 2020, 23:21:16 BST, Edward Park <kumowoon1025@gmail.com> wrote:
I'm not sure what you are referring to, what's there to spread fud about?? I'm not sure what he's referring to, either, but just be aware you're talking mainly to software engineers here and they have a well-deserved reputation for being very difficult with, well, more or less anyone who isn't a software engineer. Don't be concerned, you haven't done anything wrong. They're like this with everyone. It's normal in the world of open source (it's comically bad behaviour, but it's normal).
I'm fairly new to this list (though not to ffmpeg), but for what it's worth I've been involved with lots of open source projects over the last ~10 years and the "being very difficult" of some messages on this list has been quite surprising to me. My own experience with open source has been that overall, "comically bad behavior" definitely exists but is far from normal. As I say, I'm new here, and there's a difference between being blunt (which is often good) and being a jerk (which is generally bad). These are my first impressions. Tom
On 31/08/2020 10:41, Phil Rhodes via ffmpeg-user wrote:
I honestly can't remember most of what that does but the number after "-qscale:v" controls overall bitrate from 1 to 31. Reducing it increases bitrate (obviously!) and if you set it very low, it may create files that are wildly out of specification that Apple decoders may not like.
Hi, I think i may be able to clear up the behavior of qscale a little. According to https://trac.ffmpeg.org/wiki/Encode/MPEG-4 qscale behaves similar to the quantization parameter in h264. That parameter is pretty well explained here: https://www.pixeltools.com/rate_control_paper.html but in short: The quantization parameter basically tells an encoder how much detail can be "thrown away" during encoding. So if the parameter is lower, more detail is preserved, if it's higher, more is thrown away, which leads to a higher or lower bitrate respectively. This is not the most detailed explanation, but I hope it helps to clear up why a lower number leads to a higher bitrate. Hope that helps, Valentin
Hi Valentin, I made some tests very recently with several qcsale value, but never reached exactly the bit rate specs announced by Apple. Did anyone has already success to get those specs? BR. Philippe -----Message d'origine----- De : ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] De la part de Valentin Schweitzer Envoyé : mercredi 2 septembre 2020 17:29 À : ffmpeg-user@ffmpeg.org Objet : Re: [FFmpeg-user] ? About ffmpeg's prores implemention On 31/08/2020 10:41, Phil Rhodes via ffmpeg-user wrote:
I honestly can't remember most of what that does but the number after "-qscale:v" controls overall bitrate from 1 to 31. Reducing it increases bitrate (obviously!) and if you set it very low, it may create files that are wildly out of specification that Apple decoders may not like.
Hi, I think i may be able to clear up the behavior of qscale a little. According to https://trac.ffmpeg.org/wiki/Encode/MPEG-4 qscale behaves similar to the quantization parameter in h264. That parameter is pretty well explained here: https://www.pixeltools.com/rate_control_paper.html but in short: The quantization parameter basically tells an encoder how much detail can be "thrown away" during encoding. So if the parameter is lower, more detail is preserved, if it's higher, more is thrown away, which leads to a higher or lower bitrate respectively. This is not the most detailed explanation, but I hope it helps to clear up why a lower number leads to a higher bitrate. Hope that helps, Valentin _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 9/2/20, Philippe Laterrade <laterradep@vectracom.fr> wrote:
Hi Valentin,
I made some tests very recently with several qcsale value, but never reached exactly the bit rate specs announced by Apple. Did anyone has already success to get those specs?
Next time specify what you actually tried. qscale is not for reaching specific bitrate. It solely purpose is to give you best quality under variable bitrate, whatever that means.
Hi Paul, You're right. It's just, I didn't find anything relevant to really adjust the output bit rate. Perhap's I missed something...somewhere. Thank's for your help. BR Pilippe -----Message d'origine----- De : ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] De la part de Paul B Mahol Envoyé : mercredi 2 septembre 2020 18:08 À : FFmpeg user questions Objet : Re: [FFmpeg-user] ? About ffmpeg's prores implemention On 9/2/20, Philippe Laterrade <laterradep@vectracom.fr> wrote:
Hi Valentin,
I made some tests very recently with several qcsale value, but never reached exactly the bit rate specs announced by Apple. Did anyone has already success to get those specs?
Next time specify what you actually tried. qscale is not for reaching specific bitrate. It solely purpose is to give you best quality under variable bitrate, whatever that means. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 9/2/20, Philippe Laterrade <laterradep@vectracom.fr> wrote:
Hi Paul,
You're right. It's just, I didn't find anything relevant to really adjust the output bit rate. Perhap's I missed something...somewhere.
http://ffmpeg.org/ffmpeg-codecs.html#ProRes See bits_per_mb option. This is only for prores_ks encoder. If you use another, the default prores (prores_aw) encoder, in that case there is no any options to set, and encoder happily writes files that may be a lot bellow or above desired bitrate.
Thank's for your help. BR Pilippe
-----Message d'origine----- De : ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] De la part de Paul B Mahol Envoyé : mercredi 2 septembre 2020 18:08 À : FFmpeg user questions Objet : Re: [FFmpeg-user] ? About ffmpeg's prores implemention
On 9/2/20, Philippe Laterrade <laterradep@vectracom.fr> wrote:
Hi Valentin,
I made some tests very recently with several qcsale value, but never reached exactly the bit rate specs announced by Apple. Did anyone has already success to get those specs?
Next time specify what you actually tried.
qscale is not for reaching specific bitrate. It solely purpose is to give you best quality under variable bitrate, whatever that means. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Hi Paul, Thank's very much for your help. I'll make avtry. Have a nice day. Philippe. Philippe LATERRADE Directeur Technique / CTO Tel : +33 1 55 93 42 51 Mob : +33 6 33 63 01 69 laterradep@vectracom.fr -----Message d'origine----- De : ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] De la part de Paul B Mahol Envoyé : mercredi 2 septembre 2020 18:54 À : FFmpeg user questions Objet : Re: [FFmpeg-user] ? About ffmpeg's prores implemention On 9/2/20, Philippe Laterrade <laterradep@vectracom.fr> wrote:
Hi Paul,
You're right. It's just, I didn't find anything relevant to really adjust the output bit rate. Perhap's I missed something...somewhere.
http://ffmpeg.org/ffmpeg-codecs.html#ProRes See bits_per_mb option. This is only for prores_ks encoder. If you use another, the default prores (prores_aw) encoder, in that case there is no any options to set, and encoder happily writes files that may be a lot bellow or above desired bitrate.
Thank's for your help. BR Pilippe
-----Message d'origine----- De : ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] De la part de Paul B Mahol Envoyé : mercredi 2 septembre 2020 18:08 À : FFmpeg user questions Objet : Re: [FFmpeg-user] ? About ffmpeg's prores implemention
On 9/2/20, Philippe Laterrade <laterradep@vectracom.fr> wrote:
Hi Valentin,
I made some tests very recently with several qcsale value, but never reached exactly the bit rate specs announced by Apple. Did anyone has already success to get those specs?
Next time specify what you actually tried.
qscale is not for reaching specific bitrate. It solely purpose is to give you best quality under variable bitrate, whatever that means. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 8/31/20, Edward Park <kumowoon1025@gmail.com> wrote:
Hi,
Again just typical FUD from same person.
I'm not sure what you are referring to, what's there to spread fud about??
Closely read your text that you removed out.
It is obviously slower, hahaha.
What is, AME or one of the prores encoders included in FFmpeg? I mean obviously it'd depend on the job and hardware but for what it's worth I compared prores_ks with 4444xq and it took around twice the wallclock time. It did indeed take way more than twice the cpu time though, but if its output has problems then the whole point is moot :/
Your comparison is not scientifically proven and thus is highly personally biased.
Hi,
I'm not sure what you are referring to, what's there to spread fud about??
Closely read your text that you removed out.
You're reading into it too much if it provoked fear or uncertainty in your mind, wasn't my intention.
What is, AME or one of the prores encoders included in FFmpeg? I mean obviously it'd depend on the job and hardware but for what it's worth I compared prores_ks with 4444xq and it took around twice the wallclock time. It did indeed take way more than twice the cpu time though, but if its output has problems then the whole point is moot :/
Your comparison is not scientifically proven and thus is highly personally biased.
Yes it was an observation of a single test case. I did say it was pointless. And I think being biased towards fairness is something to be avoided, at least personally, that is. Regards, Ted Park
Am Fr., 28. Aug. 2020 um 02:01 Uhr schrieb Gary Yost <gary@yostopia.com>:
’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…
Command line and complete, uncut console output missing, but see below...
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
Which commit broke the behaviour? This is the most important question, continuing the discussion without the answer makes very little sense. Carl Eugen
On 8/30/20, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
Am Fr., 28. Aug. 2020 um 02:01 Uhr schrieb Gary Yost <gary@yostopia.com>:
’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…
Command line and complete, uncut console output missing, but see below...
I think he uses one of ffmpeg prores encoders, but yes currently provided information is far from helpful.
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
Which commit broke the behaviour?
This is the most important question, continuing the discussion without the answer makes very little sense.
No ffmpeg commit caused it, he uses different decoder for playback, probably hardware accelerated.
Carl Eugen _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
participants (8)
-
amindfv＠mailbox.org -
Carl Eugen Hoyos -
Edward Park -
Gary Yost -
Paul B Mahol -
Phil Rhodes -
Philippe Laterrade -
Valentin Schweitzer