slow encoding from raw rgb

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

slow encoding from raw rgb

Daniel Oberhoff-3
Hello,


So we are trying to encode raw rgb data from a pipe with ffmpeg. We
found that ffmpeg implicitly converts the data to tv range bt601, which
is suboptimal. Especially tv range loses more information than
neccessary, also bt709 seems to be the better color space.


We know we can fix this by adding -vf
scale=out_color_matrix=bt709:out_range=pc. Unfortuntately thi makes
encoding a lot slower (40 vs 60 fps) which effectively makes this
approach too slow for us. Do yiz have any idea why this is the case?


Best


Daniel


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

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

pEpkey.asc (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: slow encoding from raw rgb

Paul B Mahol
On 10/18/18, Daniel Oberhoff <[hidden email]> wrote:

> Hello,
>
>
> So we are trying to encode raw rgb data from a pipe with ffmpeg. We
> found that ffmpeg implicitly converts the data to tv range bt601, which
> is suboptimal. Especially tv range loses more information than
> neccessary, also bt709 seems to be the better color space.
>
>
> We know we can fix this by adding -vf
> scale=out_color_matrix=bt709:out_range=pc. Unfortuntately thi makes
> encoding a lot slower (40 vs 60 fps) which effectively makes this
> approach too slow for us. Do yiz have any idea why this is the case?

That approach does not use slice threading.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://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: slow encoding from raw rgb

Daniel Oberhoff-3
Am 18.10.18 um 12:13 schrieb Paul B Mahol:

> On 10/18/18, Daniel Oberhoff <[hidden email]> wrote:
>> Hello,
>>
>>
>> So we are trying to encode raw rgb data from a pipe with ffmpeg. We
>> found that ffmpeg implicitly converts the data to tv range bt601, which
>> is suboptimal. Especially tv range loses more information than
>> neccessary, also bt709 seems to be the better color space.
>>
>>
>> We know we can fix this by adding -vf
>> scale=out_color_matrix=bt709:out_range=pc. Unfortuntately thi makes
>> encoding a lot slower (40 vs 60 fps) which effectively makes this
>> approach too slow for us. Do yiz have any idea why this is the case?
> That approach does not use slice threading.
So what is the suggested way to do this? Or should we just accept that
rgb encoding is either slow or suboptimal? Is this such a rare use-case?

Best


Daniel



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

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

pEpkey.asc (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: slow encoding from raw rgb

Paul B Mahol
On 11/2/18, Daniel Oberhoff <[hidden email]> wrote:

> Am 18.10.18 um 12:13 schrieb Paul B Mahol:
>> On 10/18/18, Daniel Oberhoff <[hidden email]> wrote:
>>> Hello,
>>>
>>>
>>> So we are trying to encode raw rgb data from a pipe with ffmpeg. We
>>> found that ffmpeg implicitly converts the data to tv range bt601, which
>>> is suboptimal. Especially tv range loses more information than
>>> neccessary, also bt709 seems to be the better color space.
>>>
>>>
>>> We know we can fix this by adding -vf
>>> scale=out_color_matrix=bt709:out_range=pc. Unfortuntately thi makes
>>> encoding a lot slower (40 vs 60 fps) which effectively makes this
>>> approach too slow for us. Do yiz have any idea why this is the case?
>> That approach does not use slice threading.
>
> So what is the suggested way to do this? Or should we just accept that
> rgb encoding is either slow or suboptimal? Is this such a rare use-case?

I suggest to raise bounty to further improve swscale library.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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