? About ffmpeg's prores implemention

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

? About ffmpeg's prores implemention

Gary Yost
’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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Paul B Mahol
On 8/28/20, Gary Yost <[hidden email]> 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
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Gary Yost
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 <[hidden email]> wrote:
>
> On 8/28/20, Gary Yost <[hidden email] <mailto:[hidden email]>> 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
>> [hidden email] <mailto:[hidden email]>
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>>
>> To unsubscribe, visit link above, or email
>> [hidden email] <mailto:[hidden email]> with subject "unsubscribe".
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email] <mailto:[hidden email]>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user <https://ffmpeg.org/mailman/listinfo/ffmpeg-user>
>
> To unsubscribe, visit link above, or email
> [hidden email] <mailto:[hidden email]> with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

kumowoon1025
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
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

FFmpeg-users mailing list
In reply to this post by Gary Yost
 
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 <[hidden email]> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".  
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Paul B Mahol
On 8/28/20, Phil Rhodes via ffmpeg-user <[hidden email]> 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 <[hidden email]>
> 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
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

FFmpeg-users mailing list
 On Friday, 28 August 2020, 09:34:48 BST, Paul B Mahol <[hidden email]> wrote:
 
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
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Gary Yost
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 <[hidden email]> wrote:
>
> On Friday, 28 August 2020, 09:34:48 BST, Paul B Mahol <[hidden email]> wrote:
>
>>  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
> 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
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

kumowoon1025
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

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Paul B Mahol
On 8/30/20, Edward Park <[hidden email]> 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
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Carl Eugen Hoyos-2
In reply to this post by Gary Yost
Am Fr., 28. Aug. 2020 um 02:01 Uhr schrieb Gary Yost <[hidden email]>:
>
> ’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
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Paul B Mahol
On 8/30/20, Carl Eugen Hoyos <[hidden email]> wrote:

> Am Fr., 28. Aug. 2020 um 02:01 Uhr schrieb Gary Yost <[hidden email]>:
>>
>> ’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
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

kumowoon1025
In reply to this post by Paul B Mahol
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

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

FFmpeg-users mailing list
 

    On Sunday, 30 August 2020, 23:21:16 BST, Edward Park <[hidden email]> 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  
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

amindfv@mailbox.org
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 <[hidden email]> 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

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Valentin Schweitzer
In reply to this post by FFmpeg-users mailing list
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Phillipe Laterrade
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:[hidden email]] De la part de Valentin Schweitzer
Envoyé : mercredi 2 septembre 2020 17:29
À : [hidden email]
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Paul B Mahol
In reply to this post by kumowoon1025
On 8/31/20, Edward Park <[hidden email]> 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.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Paul B Mahol
In reply to this post by Phillipe Laterrade
On 9/2/20, Philippe Laterrade <[hidden email]> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: ? About ffmpeg's prores implemention

Phillipe Laterrade
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:[hidden email]] 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 <[hidden email]> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
12