Re: [FFmpeg-devel] scaling option

[Dennis Mungai]

On Wed, 27 Mar 2019 at 17:51, Yufei He  wrote:

> On 03/26/2019 02:36 PM, Dennis Mungai wrote:
>
>
>
> On Tue, Mar 26, 2019, 21:20 Yufei He  wrote:
>
>> On 03/26/2019 11:31 AM, Dennis Mungai wrote:
>> > On Tue, 26 Mar 2019 at 18:21, Yufei He  wrote:
>> >
>> >> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
>> >> On 26/03/2019 13:47, Yufei He wrote:
>> >> Hi
>> >>
>> >> Is there option for scaling on transcoding ?
>> >>
>> >> e.g. transcoding from a quadhd file to 640 * 480.
>> >>
>> >> Thanks.
>> >>
>> >> Yufei.
>> >>
>> >>
>> >> Yes there is, but this is ffmpeg-devel, so not the place to ask user
>> >> questions.
>> >>
>> >> Yes, I see the option of -vf scale=width:height
>> >> We can do scaling on decoding or encoding, my question was to check if
>> >> there is scaling option for codec.
>> >> I'll add special scaling option to our codec.
>> >>
>> >>
>> > Hello there,
>> >
>> > Scaling comes in two forms (correct me if I'm wrong):
>> >
>> > 1. Specific video filters, such as the scale filters, and other
>> > hardware-accelerated implementations, such as scale_npp, scale_cuda,
>> > scale_vaapi, etc.
>> > 2. Decoders (Not too sure if equating the private -resize option
>> provided
>> > by these decoders is equivalent to "scaling"):
>> >
>> > See the example provided by the likes of the cuvid implementations,
>> such as
>> > h264_cuvid, etc:
>> >
>> > ffmpeg -h decoder=h264_cuvid
>> >
>> > The -resize option therein acts as a scaler.
>> >
>> > Are you planning to implement a codec-specific hardware (or
>> software-based)
>> > scaler (implemented as a video filter or a decoder), with similar
>> > functionality?
>> Hi Dennis
>> Our hardware m264 supports scaling and encoding or decoding at the same
>> time, this saves memory copy time between host and card if it's scaled
>> in host or in other separate filter.
>> I'm trying to make it work in FFmpeg.
>>
>> Yufei.
>>
>
>
> Here's what you'll need to implement:
>
> 1. A hwaccel of the type equivalent to the accelerator backend you're
> creating, and
>
> 2. The actual hwaccel implementation. This will be an encoder (or set of
> encoders) targeting the codecs you're after.
>
> 3. Based on the two above, create video filters that can take advantage of
> hwupload, hwdownload, etc to create filter chains that will allow to move
> (and map) textures, etc from system to device memory . Take a look at how
> CUDA based hwaccels are implemented. That's a good crash course on what
> needs to be done.
>
> 4. Understand how the FFmpeg development process works. Patches are
> welcome, but the review process and adherence to coding standards matters
> even more. See the wikis on what's expected regarding the development
> process. I'd suggest being aware of the subsystem maintainers and the roles
> they play.
>
> 5. On vendor specific libraries: I'd suggest releasing this as an open
> implementation such that it can be hosted in a manner similar to how the
> ffnvcodec headers are handled. Trust me, you'll greatly lower the
> maintainance overhead on time.
>
> Hope that helps.
>
> Hi Dennis
>
> We will talk about your suggestion and schedule it later.
>
> Thanks for your help.
>
> Yufei.
>

And I'll issue a warning, before it blocks this patch from going anywhere:
Do *NOT* link to a library bundled within the device driver.
There's no (justifiable) reason for that. Also see the note on maintainer
overhead above.
Avail the shim (intermediate library) as recommended above such that it can
be enabled at ./configure as an option.
The end user should be able to compile and install the aforementioned
library to a pre-configured prefix, such that when building FFmpeg, the
same facility can pick up that library and enable the requested
component(s) as per the directive(s) in ./configure.
What your (now rejected) patch in the mailing list does shifts the burden
of maintaining ABI compatibility to a *device driver component* and until
that's resolved, it will go nowhere.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] scaling option

[Yufei He]

On 03/26/2019 02:36 PM, Dennis Mungai wrote:


On Tue, Mar 26, 2019, 21:20 Yufei He mailto:y...@matrox.com>> 
wrote:
On 03/26/2019 11:31 AM, Dennis Mungai wrote:
> On Tue, 26 Mar 2019 at 18:21, Yufei He 
> mailto:y...@matrox.com>> wrote:
>
>> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
>> On 26/03/2019 13:47, Yufei He wrote:
>> Hi
>>
>> Is there option for scaling on transcoding ?
>>
>> e.g. transcoding from a quadhd file to 640 * 480.
>>
>> Thanks.
>>
>> Yufei.
>>
>>
>> Yes there is, but this is ffmpeg-devel, so not the place to ask user
>> questions.
>>
>> Yes, I see the option of -vf scale=width:height
>> We can do scaling on decoding or encoding, my question was to check if
>> there is scaling option for codec.
>> I'll add special scaling option to our codec.
>>
>>
> Hello there,
>
> Scaling comes in two forms (correct me if I'm wrong):
>
> 1. Specific video filters, such as the scale filters, and other
> hardware-accelerated implementations, such as scale_npp, scale_cuda,
> scale_vaapi, etc.
> 2. Decoders (Not too sure if equating the private -resize option provided
> by these decoders is equivalent to "scaling"):
>
> See the example provided by the likes of the cuvid implementations, such as
> h264_cuvid, etc:
>
> ffmpeg -h decoder=h264_cuvid
>
> The -resize option therein acts as a scaler.
>
> Are you planning to implement a codec-specific hardware (or software-based)
> scaler (implemented as a video filter or a decoder), with similar
> functionality?
Hi Dennis
Our hardware m264 supports scaling and encoding or decoding at the same
time, this saves memory copy time between host and card if it's scaled
in host or in other separate filter.
I'm trying to make it work in FFmpeg.

Yufei.


Here's what you'll need to implement:

1. A hwaccel of the type equivalent to the accelerator backend you're creating, 
and

2. The actual hwaccel implementation. This will be an encoder (or set of 
encoders) targeting the codecs you're after.

3. Based on the two above, create video filters that can take advantage of 
hwupload, hwdownload, etc to create filter chains that will allow to move (and 
map) textures, etc from system to device memory . Take a look at how CUDA based 
hwaccels are implemented. That's a good crash course on what needs to be done.

4. Understand how the FFmpeg development process works. Patches are welcome, 
but the review process and adherence to coding standards matters even more. See 
the wikis on what's expected regarding the development process. I'd suggest 
being aware of the subsystem maintainers and the roles they play.

5. On vendor specific libraries: I'd suggest releasing this as an open 
implementation such that it can be hosted in a manner similar to how the 
ffnvcodec headers are handled. Trust me, you'll greatly lower the maintainance 
overhead on time.

Hope that helps.
Hi Dennis

We will talk about your suggestion and schedule it later.

Thanks for your help.

Yufei.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] scaling option

[Dennis Mungai]

On Tue, Mar 26, 2019, 21:20 Yufei He  wrote:

> On 03/26/2019 11:31 AM, Dennis Mungai wrote:
> > On Tue, 26 Mar 2019 at 18:21, Yufei He  wrote:
> >
> >> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
> >> On 26/03/2019 13:47, Yufei He wrote:
> >> Hi
> >>
> >> Is there option for scaling on transcoding ?
> >>
> >> e.g. transcoding from a quadhd file to 640 * 480.
> >>
> >> Thanks.
> >>
> >> Yufei.
> >>
> >>
> >> Yes there is, but this is ffmpeg-devel, so not the place to ask user
> >> questions.
> >>
> >> Yes, I see the option of -vf scale=width:height
> >> We can do scaling on decoding or encoding, my question was to check if
> >> there is scaling option for codec.
> >> I'll add special scaling option to our codec.
> >>
> >>
> > Hello there,
> >
> > Scaling comes in two forms (correct me if I'm wrong):
> >
> > 1. Specific video filters, such as the scale filters, and other
> > hardware-accelerated implementations, such as scale_npp, scale_cuda,
> > scale_vaapi, etc.
> > 2. Decoders (Not too sure if equating the private -resize option provided
> > by these decoders is equivalent to "scaling"):
> >
> > See the example provided by the likes of the cuvid implementations, such
> as
> > h264_cuvid, etc:
> >
> > ffmpeg -h decoder=h264_cuvid
> >
> > The -resize option therein acts as a scaler.
> >
> > Are you planning to implement a codec-specific hardware (or
> software-based)
> > scaler (implemented as a video filter or a decoder), with similar
> > functionality?
> Hi Dennis
> Our hardware m264 supports scaling and encoding or decoding at the same
> time, this saves memory copy time between host and card if it's scaled
> in host or in other separate filter.
> I'm trying to make it work in FFmpeg.
>
> Yufei.
>


Here's what you'll need to implement:

1. A hwaccel of the type equivalent to the accelerator backend you're
creating, and

2. The actual hwaccel implementation. This will be an encoder (or set of
encoders) targeting the codecs you're after.

3. Based on the two above, create video filters that can take advantage of
hwupload, hwdownload, etc to create filter chains that will allow to move
(and map) textures, etc from system to device memory . Take a look at how
CUDA based hwaccels are implemented. That's a good crash course on what
needs to be done.

4. Understand how the FFmpeg development process works. Patches are
welcome, but the review process and adherence to coding standards matters
even more. See the wikis on what's expected regarding the development
process. I'd suggest being aware of the subsystem maintainers and the roles
they play.

5. On vendor specific libraries: I'd suggest releasing this as an open
implementation such that it can be hosted in a manner similar to how the
ffnvcodec headers are handled. Trust me, you'll greatly lower the
maintainance overhead on time.

Hope that helps.

>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] scaling option

[Yufei He]

On 03/26/2019 11:31 AM, Dennis Mungai wrote:
> On Tue, 26 Mar 2019 at 18:21, Yufei He  wrote:
>
>> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
>> On 26/03/2019 13:47, Yufei He wrote:
>> Hi
>>
>> Is there option for scaling on transcoding ?
>>
>> e.g. transcoding from a quadhd file to 640 * 480.
>>
>> Thanks.
>>
>> Yufei.
>>
>>
>> Yes there is, but this is ffmpeg-devel, so not the place to ask user
>> questions.
>>
>> Yes, I see the option of -vf scale=width:height
>> We can do scaling on decoding or encoding, my question was to check if
>> there is scaling option for codec.
>> I'll add special scaling option to our codec.
>>
>>
> Hello there,
>
> Scaling comes in two forms (correct me if I'm wrong):
>
> 1. Specific video filters, such as the scale filters, and other
> hardware-accelerated implementations, such as scale_npp, scale_cuda,
> scale_vaapi, etc.
> 2. Decoders (Not too sure if equating the private -resize option provided
> by these decoders is equivalent to "scaling"):
>
> See the example provided by the likes of the cuvid implementations, such as
> h264_cuvid, etc:
>
> ffmpeg -h decoder=h264_cuvid
>
> The -resize option therein acts as a scaler.
>
> Are you planning to implement a codec-specific hardware (or software-based)
> scaler (implemented as a video filter or a decoder), with similar
> functionality?
Hi Dennis
Our hardware m264 supports scaling and encoding or decoding at the same 
time, this saves memory copy time between host and card if it's scaled 
in host or in other separate filter.
I'm trying to make it work in FFmpeg.

Yufei.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] scaling option

[Dennis Mungai]

On Tue, 26 Mar 2019 at 18:21, Yufei He  wrote:

> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
> On 26/03/2019 13:47, Yufei He wrote:
> Hi
>
> Is there option for scaling on transcoding ?
>
> e.g. transcoding from a quadhd file to 640 * 480.
>
> Thanks.
>
> Yufei.
>
>
> Yes there is, but this is ffmpeg-devel, so not the place to ask user
> questions.
>
> Yes, I see the option of -vf scale=width:height
> We can do scaling on decoding or encoding, my question was to check if
> there is scaling option for codec.
> I'll add special scaling option to our codec.
>
>
Hello there,

Scaling comes in two forms (correct me if I'm wrong):

1. Specific video filters, such as the scale filters, and other
hardware-accelerated implementations, such as scale_npp, scale_cuda,
scale_vaapi, etc.
2. Decoders (Not too sure if equating the private -resize option provided
by these decoders is equivalent to "scaling"):

See the example provided by the likes of the cuvid implementations, such as
h264_cuvid, etc:

ffmpeg -h decoder=h264_cuvid

The -resize option therein acts as a scaler.

Are you planning to implement a codec-specific hardware (or software-based)
scaler (implemented as a video filter or a decoder), with similar
functionality?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] scaling option

[Yufei He]

On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
On 26/03/2019 13:47, Yufei He wrote:
Hi

Is there option for scaling on transcoding ?

e.g. transcoding from a quadhd file to 640 * 480.

Thanks.

Yufei.


Yes there is, but this is ffmpeg-devel, so not the place to ask user questions.

Yes, I see the option of -vf scale=width:height
We can do scaling on decoding or encoding, my question was to check if there is 
scaling option for codec.
I'll add special scaling option to our codec.




___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with 
subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] scaling option

[Timo Rothenpieler]

On 26/03/2019 13:47, Yufei He wrote:

Hi

Is there option for scaling on transcoding ?

e.g. transcoding from a quadhd file to 640 * 480.

Thanks.

Yufei.



Yes there is, but this is ffmpeg-devel, so not the place to ask user 
questions.





smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".