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

On Tue, Mar 26, 2019, 21:20 Yufei He <y...@matrox.com<mailto:y...@matrox.com>> 
On 03/26/2019 11:31 AM, Dennis Mungai wrote:
> On Tue, 26 Mar 2019 at 18:21, Yufei He 
> <y...@matrox.com<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.


Here's what you'll need to implement:

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

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.

ffmpeg-devel mailing list

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

Reply via email to