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