Hi attached patch would change nut.txt to the alternative keyframe definition this would allow files with no classic keyframes but instead things like P frames where each would have 10% intra blocks to be muxed in nut and still allow seeking without this seeking is not possible, the seek to non keyframe hack would only work if all streams would allow seeking to any frame as back ptrs would not be meaningfull in such a file it would also fix cases where B frames with a PTS after the previous I frame would use frames prior to the I frame for prediction and it could be used to allow decoding B frames with a PTS prior to the last I frame, that is IPBBIBB ^^ if they dont use previous frames for prediction this would fix a missing feature relative to mpeg1/2/4 which allow that and provide enough information to make this odd case easily detectable Compatibility effects: new demuxers can always demux old files old demuxers can demux new files as long as they only contain normal keyframes otherwise they fail to demux the specific keyframes Effects on optimal seeking: unknown -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
Michael Niedermayer wrote:
Hi
attached patch would change nut.txt to the alternative keyframe definition
how that would change in code (ffnut and libnut) ? lu - still wondering if the subtitle muxing is just underspecified or just broken on ffnut -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Tue, Nov 20, 2007 at 01:38:51PM +0100, Luca Barbato wrote:
Michael Niedermayer wrote:
Hi
attached patch would change nut.txt to the alternative keyframe definition
how that would change in code (ffnut and libnut) ?
Not at all. The caller is responsible for flagging whether a frame is a keyframe. The only practical difference in definitions is what happens in pathological codecs; for "normal" codecs it's the same as the definition has always been. Rich
On Tue, Nov 20, 2007 at 12:18:09PM +0100, Michael Niedermayer wrote:
Hi
attached patch would change nut.txt to the alternative keyframe definition
i will apply this in a few days if there are no objections [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein
On Wed, Jan 16, 2008 at 02:22:31PM +0100, Michael Niedermayer wrote:
On Tue, Nov 20, 2007 at 12:18:09PM +0100, Michael Niedermayer wrote:
Hi
attached patch would change nut.txt to the alternative keyframe definition
i will apply this in a few days if there are no objections
I'm not opposed to any of this in principle, but I think the wording could be clearer (more formal, less discussion of rationale which belongs in a separate section imo). The one actual technical issue I'd like to consider is the whole convergence thing. For instantly-convergent things like mp3 it doesn't matter so much, but if we're going to use this definition of keyframes I would like a way to know how far back one has to begin decoding to get 'virtually identical' results. Otherwise a good deal of the seeking power of nut is lost for applications that need error-free decoding, when the file uses such a codec. But I don't have any easy answer and since such codecs aren't really in widespread use I'll let the issue slide if no one has any easy answers. Rich
On Wed, Jan 16, 2008 at 11:14:40AM -0500, Rich Felker wrote:
On Wed, Jan 16, 2008 at 02:22:31PM +0100, Michael Niedermayer wrote:
On Tue, Nov 20, 2007 at 12:18:09PM +0100, Michael Niedermayer wrote:
Hi
attached patch would change nut.txt to the alternative keyframe definition
i will apply this in a few days if there are no objections
I'm not opposed to any of this in principle, but I think the wording could be clearer (more formal, less discussion of rationale which belongs in a separate section imo).
Iam not in favor of (re)moving explanations and discussions. Its more understandable if explanations are close to where they are needed. This reminds me of the h.264 spec where early versions where quite understandable. And which then where changed to be exact and precisse with no explanations to the point that it was not understandable anymore. anyway a seperate much bigger explanations and rationale section is of course very important anyway. But IMO removing explanations from all other sections is not a good idea. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
participants (3)
-
Luca Barbato -
Michael Niedermayer -
Rich Felker