Hi On Sun, Nov 18, 2007 at 01:32:18AM -0500, Rich Felker wrote:
On Sat, Nov 17, 2007 at 04:55:00PM +0100, Michael Niedermayer wrote:
what about normal b frames? IPBBIBBBBBPPP
here if we start decoding from the 2nd I frame none of the B frames can be decoded as they need the pevious frames but they are after the I frame position wise
Yes, sorry, I left out the PTS part... :( I can fix it.
heres a different definition for keyframes, note this is not identical to what is in nut.txt
A frame in a stream is a keyframe if and only if all of the following are true * Decoding can successfully begin using any standard compliant decoder without requireing access to prior frames. * Begining decoding instead at a subsequent frame would cause fewer frames to be decoded successfully.
I'm confused what this second condition is supposed to mean. Of course if you start at a subsequent frame (e.g. the n+1 frame instead of the nth frame) you'll decode fewer frames, provided that you were able to successfully decode the nth frame to begin with. But maybe this characterization is what you're trying to get at:
"A frame N is a keyframe if the set of frames which can be successfully decoded by starting with frame N is a strict superset of the set of frames which can be successfully decoded by starting with frame N+1."
with "successful" having the meaning you described (perhaps adjusted to be more formal). I have replaced your idea of "more/fewer" with "strict superset/subset" to conform to the fact that the number of frames in stream need not be practically finite.
Note however that your definition here (and my version of it) have the (perhaps unfortunate) effect that all frames would be keyframes in a hypothetical codec where the (N%total_blocks)th block is intra-coded in the Nth frame and all other blocks in the Nth frame are residue-coded. This may be better than having no keyframes at all, but it seems sort of perverse nonetheless.
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 ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras