[NUT-devel] rfc drafting

[Michael Niedermayer]

On Sun, Nov 18, 2007 at 09:42:14PM -0500, Rich Felker wrote:
> On Sun, Nov 18, 2007 at 02:48:51PM +0100, Michael Niedermayer wrote:
> > that was the reason why i wrote it like that :)
> > such streams exist and it even makes sense for them to exist ...
> > just think of realtime communication over a low bandwidth channel
> > (portable phones or something like that would be an example)
> > i frames are many times bigger than p frames at the same quality
> > so having p frames with lets say 10% intra coded blocks leads to
> > lower delay than i frame would. and i frames at lower quality would lead
> > to unacceptable flickering every time a low quality blocky I frame would
> > be received
> > so yes, i think all frames should be key frames in that case ...
> > also the encoder can optimize the decission of which blocks to code as
> > intra ...
> 
> I agree such codecs should exist, I just wonder whether considering
> all frames to be keyframes is an appropriate solution. After all,
> imagine a program using a file with such a codec as a source for
> editing. "This frame is a keyframe" does not mean much if it doesn't
> guarantee you can decode all frames with pts >= this_frame.pts without
> significant error. You might as well just ignore the keyframe flag for
> seeking then..

it shouldnt be hard to consider the frames with significant error in
the back ptrs and index (its pretty much just replacing pts[x] by
pts[x]+delay_until_no_error[x])
i of course havnt considered what effects that would have on "optimal
seeking" but as long as delay_until_no_error[x]=0 it shouldnt be affected

and if you dont set them as keyframes you cant seek or how should the
demuxer know it should ignore keyframe flags for a specific file?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20071119/0ceeb6ac/attachment.pgp>