On Wed, Jan 14, 2015 at 07:53:03PM +0100, Jean-Baptiste Kempf wrote:
> On 14 Jan, Ronald S. Bultje wrote :
> > He specifically mentioned that yami supports (in addition to things ffmpeg
> > already does) hardware h264 encoding, hardware vp8 decoding/decoding,
> > hardware vp9 decoding and hardware
Hi,
On Wed, Jan 14, 2015 at 1:53 PM, Jean-Baptiste Kempf
wrote:
> On 14 Jan, Ronald S. Bultje wrote :
> > He specifically mentioned that yami supports (in addition to things
> ffmpeg
> > already does) hardware h264 encoding, hardware vp8 decoding/decoding,
> > hardware vp9 decoding and hardware
On 14 Jan, Ronald S. Bultje wrote :
> He specifically mentioned that yami supports (in addition to things ffmpeg
> already does) hardware h264 encoding, hardware vp8 decoding/decoding,
> hardware vp9 decoding and hardware jpeg encoding/decoding (all based on
> vaapi as underlying api).
Well, first
On Mon, 12 Jan 2015 10:30:34 -0500
"Ronald S. Bultje" wrote:
> Hi,
>
> On Mon, Jan 12, 2015 at 10:07 AM, compn wrote:
>
> > On Mon, 12 Jan 2015 08:24:35 -0500
> > "Ronald S. Bultje" wrote:
> >
> > > Anything else? Why not just implement these in ffmpeg directly?
> >
> > because (i'm guessing)
Hi,
On Tue, Jan 13, 2015 at 10:35 PM, Jean-Baptiste Kempf
wrote:
> On 12 Jan, Ronald S. Bultje wrote :
> > - how long will it take us to implement these features ourselves?
>
> What features?
You know, J-B, you're one of the very few that can see over this
salesperson talk of "rich" and "very"
On Wed, 14 Jan 2015 06:53:18 +
"Zhao, Halley" wrote:
> Thanks for your valued comments, I followed them in updated patch set.
>
> >> +config_buffer.profile = VAProfileNone;
> >> +status = s->decoder->start(&config_buffer);
> >> +if (status != DECODE_SUCCESS) {
> >> +av_lo
On Wed, 14 Jan 2015 04:35:26 +0100
Jean-Baptiste Kempf wrote:
> On 12 Jan, Ronald S. Bultje wrote :
> > - how long will it take us to implement these features ourselves?
>
> What features?
>
Most importantly, it requires less boilerplate by the user. (Somewhat
similar to "hwaccel 2.0" Libav is
well, Which function do you mean to?
> Also, for this frame no pixel format is set.
Add it, thanks.
>> +frame->buf[0] = av_buffer_create((uint8_t*)yami_frame,
>> + sizeof(VideoFrameRawData), yami_recycle_frame, avctx, 0);
> Breaks refcounting of the YUV420P frame?
Sorry, not catch
On 12 Jan, Zhao, Halley wrote :
> to be honest, libyami is core codec library for vaapi (especially on Intel
> platform).
FFmpeg already accesses vaapi directly. Adding a library in the middle
is just making everything slower...
With my kindest regards,
--
Jean-Baptiste Kempf
http://www.jbkempf
On 12 Jan, Zhao, Halley wrote :
> > Maintaining decoders is the point of this project.
> Yes, I agree the core of ffmpeg is codec;
> But, from the user, ffmpeg is usually treated as a light-weight media
> framework. Being a media framework, it is good to leverage hw codec in many
> cases.
FFmpeg
On 12 Jan, Ronald S. Bultje wrote :
> - how long will it take us to implement these features ourselves?
What features?
--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-
On 14 Jan, Zhao, Halley wrote :
> 1. I know our team/Intel plan to maintain this lib for the following years.
> I'm a developer, I can't promise more.
Many people have made such claims and backtracked in the end.
> 2. as to libxyz, it is some way like investment: Nobody is sure of the
> future,
On Wed, Jan 14, 2015 at 01:35:14AM +, Zhao, Halley wrote:
> Thanks your explanation.
> 1. I know our team/Intel plan to maintain this lib for the following years.
> I'm a developer, I can't promise more.
will someone also maintain the libyami wraper code from this
patch ?
If so the patch shou
, 2015 10:35 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by
libyami
Hi,
On Mon, Jan 12, 2015 at 9:04 AM, wm4 wrote:
> On Mon, 12 Jan 2015 08:24:35 -0500
> "Ronald S. Bultje" wrote:
>
> > H
On 09.01.2015, at 09:15, "Zhao, Halley" wrote:
> From: "Zhao, Halley"
>
> - do not support multi-thread decoding, it is unnecessary for hw
While it might not be possible to support in a proper way, and the FFmpeg
multithreading is probably useless in the context of this library, but I think
t
Hi,
On Mon, Jan 12, 2015 at 10:07 AM, compn wrote:
> On Mon, 12 Jan 2015 08:24:35 -0500
> "Ronald S. Bultje" wrote:
>
> > Anything else? Why not just implement these in ffmpeg directly?
>
> because (i'm guessing) they are developing libyami with other projects,
> not ffmpeg.
>
> i know everyone
On Mon, 12 Jan 2015 10:07:56 -0500
compn wrote:
> On Mon, 12 Jan 2015 08:24:35 -0500
> "Ronald S. Bultje" wrote:
>
> > Anything else? Why not just implement these in ffmpeg directly?
>
> because (i'm guessing) they are developing libyami with other projects,
> not ffmpeg.
>
> i know everyone
On Mon, 12 Jan 2015 08:24:35 -0500
"Ronald S. Bultje" wrote:
> Anything else? Why not just implement these in ffmpeg directly?
because (i'm guessing) they are developing libyami with other projects,
not ffmpeg.
i know everyone wants to reinvent the wheels here, but also that may
have a detrimen
On Mon, 12 Jan 2015 00:46:26 +
"Zhao, Halley" wrote:
> > Maintaining decoders is the point of this project.
> Yes, I agree the core of ffmpeg is codec;
> But, from the user, ffmpeg is usually treated as a light-weight media
> framework. Being a media framework, it is good to leverage hw codec
Hi,
On Mon, Jan 12, 2015 at 9:04 AM, wm4 wrote:
> On Mon, 12 Jan 2015 08:24:35 -0500
> "Ronald S. Bultje" wrote:
>
> > Hi,
> >
> > On Mon, Jan 12, 2015 at 12:59 AM, Zhao, Halley
> > wrote:
> >
> > > I understand you concern.
> > > The wrapper doesn't help much to ffmpeg itself, however, it ben
On Mon, 12 Jan 2015 08:24:35 -0500
"Ronald S. Bultje" wrote:
> Hi,
>
> On Mon, Jan 12, 2015 at 12:59 AM, Zhao, Halley
> wrote:
>
> > I understand you concern.
> > The wrapper doesn't help much to ffmpeg itself, however, it benefits much
> > to the apps uses ffmpeg, to pick up hw capability for
Hi,
On Mon, Jan 12, 2015 at 12:59 AM, Zhao, Halley
wrote:
> I understand you concern.
> The wrapper doesn't help much to ffmpeg itself, however, it benefits much
> to the apps uses ffmpeg, to pick up hw capability for codec.
So specifically, what are the features that you get with yaml that ff
ald S. Bultje
Sent: Saturday, January 10, 2015 9:49 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by
libyami
Hi,
On Fri, Jan 9, 2015 at 5:30 PM, wm4 wrote:
> On Fri, 9 Jan 2015 17:17:00 -0500
> compn wrote:
>
>
m.
> -Original Message-
> From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-
> boun...@ffmpeg.org] On Behalf Of wm4
> Sent: Monday, January 12, 2015 9:35 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264
> decoding by
On Mon, 12 Jan 2015 00:46:26 +
"Zhao, Halley" wrote:
> > Maintaining decoders is the point of this project.
> Yes, I agree the core of ffmpeg is codec;
> But, from the user, ffmpeg is usually treated as a light-weight media
> framework. Being a media framework, it is good to leverage hw code
g-yami
-Original Message-
From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org]
On Behalf Of wm4
Sent: Saturday, January 10, 2015 6:30 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by
libyami
On Fri, 9
Hi,
On Fri, Jan 9, 2015 at 5:30 PM, wm4 wrote:
> On Fri, 9 Jan 2015 17:17:00 -0500
> compn wrote:
>
> > On Fri, 9 Jan 2015 14:44:32 +0100
> > wm4 wrote:
> >
> > > What's the point of using this library, if ffmpeg already has
> > > most of the hw decoding infrastructure itself?
> >
> > probably
On Fri, 9 Jan 2015 17:17:00 -0500
compn wrote:
> On Fri, 9 Jan 2015 14:44:32 +0100
> wm4 wrote:
>
> > What's the point of using this library, if ffmpeg already has
> > most of the hw decoding infrastructure itself?
>
> probably so we dont have to maintain every single little hw decoding
> and
On Fri, 9 Jan 2015 14:44:32 +0100
wm4 wrote:
> What's the point of using this library, if ffmpeg already has
> most of the hw decoding infrastructure itself?
probably so we dont have to maintain every single little hw decoding
and encoding feature , and libyami will do this for us.
same thing l
On Fri, 9 Jan 2015 16:15:13 +0800
"Zhao, Halley" wrote:
> From: "Zhao, Halley"
>
> - do not support multi-thread decoding, it is unnecessary for hw
> - create a decode thread to interface with yami decoding, decouple
> frame in and out
> - the output frame type (raw data | drm handle | dmabu
From: "Zhao, Halley"
- do not support multi-thread decoding, it is unnecessary for hw
- create a decode thread to interface with yami decoding, decouple
frame in and out
- the output frame type (raw data | drm handle | dmabuf) are specified
in avctx->coder during init
- yami frame is assigned
31 matches
Mail list logo
