On Thu, Mar 12, 2015 at 08:10:17AM -0400, compn wrote:
> On Thu, 12 Mar 2015 11:47:55 +
> Derek Buitenhuis wrote:
> > answer to that is a *single* decoder, which works the best -
>
> just say it with less words. you dont want dual decoders like prores.
i strongly want to avoid dual decoders
On 3/12/2015 12:34 PM, Michael Niedermayer wrote:
> Its interresting what kind of bizare replies one gets by stating on
> the main FFmpeg development list that work should be based on FFmpeg
> and should be tested. And then repeating a few times that this is
> really what was meant and none of the
On Thu, Mar 12, 2015 at 11:47:55AM +, Derek Buitenhuis wrote:
> On 3/12/2015 11:25 AM, Michael Niedermayer wrote:
> > you continue to talk about something completely unrelated to what i
> > said/meant.
> >
> > you: take best code
>
> [...]
>
> > I: for code to be ever in FFmpeg it must eithe
On Thu, 12 Mar 2015 11:47:55 +
Derek Buitenhuis wrote:
> answer to that is a *single* decoder, which works the best -
just say it with less words. you dont want dual decoders like prores.
(i'm not going to make the argument that multiple users use different
prores versions because i dont wan
On Thu, 12 Mar 2015 11:47:55 +
Derek Buitenhuis wrote:
> I am looking at what is the best end result for the *user*. The answer to that
> is a *single* decoder, which works the best - regardless of the "effort" it.
> Yes,
> I don't buy that merging one from Libav causes "more bugs" than inde
On 3/12/2015 11:25 AM, Michael Niedermayer wrote:
> you continue to talk about something completely unrelated to what i
> said/meant.
>
> you: take best code
[...]
> I: for code to be ever in FFmpeg it must either be developed on top
> of FFmpeg or it must be rebased/ merged/integrated at some p
On Wed, Mar 11, 2015 at 09:44:22PM +, Derek Buitenhuis wrote:
> On 3/11/2015 9:36 PM, Michael Niedermayer wrote:
> > Thats analogous to saying "no its not important to put fuel in a
> > car, its important to drive the best car"
>
> No what I propose is to look at both and decide which is best.
On 11 March 2015 at 14:42, Marcus Johnson wrote:
> I've been working on adding XLL for the last couple months, it's still not
> quite complete, basically I have to combine the Core and XLL samples before
> it's output, and I also have to finish the latter stages of decoding the
> XLL like channel
On 3/11/2015 2:42 PM, Marcus Johnson wrote:
> I've been working on adding XLL for the last couple months, it's still not
> quite complete, basically I have to combine the Core and XLL samples before
> it's output, and I also have to finish the latter stages of decoding the
> XLL like channel decorr
On 3/11/2015 9:36 PM, Michael Niedermayer wrote:
> Thats analogous to saying "no its not important to put fuel in a
> car, its important to drive the best car"
No what I propose is to look at both and decide which is best. Simply being
submitted to FFmpeg first does not make it better.
> the 2nd
On Wed, Mar 11, 2015 at 09:04:39PM +, Derek Buitenhuis wrote:
> On 3/11/2015 8:25 PM, Michael Niedermayer wrote:
> > whats important is a patchset based on and tested on FFmpeg, at least
> > if people want a working decoder in FFmpeg
>
> No, what's important is that the best possible code is u
On 3/11/2015 8:25 PM, Michael Niedermayer wrote:
> whats important is a patchset based on and tested on FFmpeg, at least
> if people want a working decoder in FFmpeg
No, what's important is that the best possible code is used. Origin is
irrelevant.
- Derek
On Wed, Mar 11, 2015 at 04:07:00PM +0100, Hendrik Leppkes wrote:
> On Wed, Mar 11, 2015 at 4:02 PM, Marcus Johnson
> wrote:
> > I thought the patch on LibAV was completely removed?
>
> http://thread.gmane.org/gmane.comp.video.libav.devel/66825/focus=66826
>
> It'll probably be merged soon'ish. I
On Wed, Mar 11, 2015 at 4:02 PM, Marcus Johnson
wrote:
> I thought the patch on LibAV was completely removed?
http://thread.gmane.org/gmane.comp.video.libav.devel/66825/focus=66826
It'll probably be merged soon'ish. It still has some open TODOs, but
at this point its probably a much better idea
I thought the patch on LibAV was completely removed? it was purged from the
codebase like 9 months ago or something, I stumbled on that while trying to
fix some of the issues with the white paper I was having.
I haven't bothered with the Core decoder, but everything I've extracted so
far is fixed
On 3/11/2015 2:42 PM, Marcus Johnson wrote:
> I've been working on adding XLL for the last couple months, it's still not
> quite complete, basically I have to combine the Core and XLL samples before
> it's output, and I also have to finish the latter stages of decoding the
> XLL like channel decorr
16 matches
Mail list logo