[FFmpeg-devel] [PATCH] libvpx: alt reference frame / lag
Thu Jul 22 15:21:13 CEST 2010
On Thu, Jun 17, 2010 at 05:47:32PM -0400, John Koleszar wrote:
> On Thu, Jun 17, 2010 at 2:10 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Thu, Jun 17, 2010 at 11:42:28AM -0400, John Koleszar wrote:
> >> On Thu, Jun 17, 2010 at 12:24 AM, Reimar D?ffinger
> >> <Reimar.Doeffinger at gmx.de> wrote:
> >> >> I've been through a lot of the advantages of keeping the data
> >> >> separate, but it mostly boils down to staying out of the way of
> >> >> applications that know what they're doing
> >> >
> >> > I think you are arguing that we should make things more complex for
> >> > everyone for the sake of simplifying things for a use-case that
> >> > currently does not exist and you don't specify well enough so we
> >> > could suggest and alternative.
> >> I don't want to be in the business of saying what people can and can't
> >> do with the codec, so I'm looking to provide flexibility. Yes, ARFs
> >> are a new feature that other codecs don't have. No, I don't know all
> >> the ways that people will find to use them yet.
> > But we expect that ARFs will cause problems to some players.
> > Now if you showed that they where usefull and did improve quality relative
> > to B frames alone then iam sure people would not be so much opposed but
> > simply arguing that they might be usefull is kinda weak to argue that
> > many applicaions would have to be changed to deal with the new special
> > cases.
> They are useful, they do improve quality relative to not having them
but do they improve quality relative to having B frames or on top of
I see your great interrest in all this, but i dont see the technical
justification behind this compared to what everyone else is doing.
> (that blog post showed about 1dB, it's obviously material and ARF mode
> (noise reduced vs b-frame-like lookahead) dependant). They're being
> used today. I'm just trying to say they have wider application than
> what they're being used for today.
> > For example if you implemented ARFs in a codec that supported B frames
> > like x264 and our h264 decoder and that led to a non trivial quality gain
> > iam sure there would be very little opposition.
> > Also, who would fix all the issues caused by seperately coded ARFs /non
> > displayed frames? thats changes to the nut spec and our implementation
> > changes to the libavformat core probably, maybe changes in mplayer,
> > maybe other players ...
> > ?
> Obviously we have a vested interest in making sure this works well as
> broadly as possible, particularly ffmpeg, mplayer, mencoder,
> gstreamer, etc, and the goal is to get clean support.. if that means
> changing the lavf core, we can do that. Maybe what we need to do is
> create a pathological file to test what apps out there are affected..
> Create an ARF every other packet or something and see if the av sync
> drifts. I'm still inclined to think that as long as you're keeping
more pathological would be to create arfs with probability changing
from 100% to 0% over the course of the file so any player trying to
apply some constant correction would be thrown off as well
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: Digital signature
More information about the ffmpeg-devel