[FFmpeg-devel] matroska encoder option -- force new Cluster on keyframe

[Michael Niedermayer]

On Sun, Jul 21, 2013 at 12:51:29AM -0700, Bernie Habermeier wrote:
> 
> On Jul 20, 2013, at 1:54 PM, Michael Niedermayer wrote:
> 
> > On Fri, Jul 19, 2013 at 05:11:54PM -0700, Bernie Habermeier wrote:
> >> I'm working on implementing a video player that would benefit from a tiny optional change to the matroska encoder in ffmpeg.   I propose to add a command line option that generates a valid matroska file with the added constraint that each keyframe gets a new cluster.   I'm writing to ask if folks think that adding this option to ffmpeg is acceptable before I submit such a patch.
> > 
> > this could cause problems (significant overhead) with intra only
> > streams
> > It possibly should thus be limited to keyframes not preceded by
> > another keyfrane
> > 
> > But in principle the feature sounds like a good idea
> 
> Agree that this would be really kind of bad for intra only streams, but to be honest the current implementation in matroskaenc.c creates a CuePoint for each video key frame, and arguably, it's a little bit insane to have a CuePoint entry for every single video frame in a movie.  If you're coming from the point of view that this would impact overhead, you've already lost the battle on that front.  Though I concede that you don't HAVE to read the CuePoint table to play a movie, whereas you DO have to seek through Clusters.
> 
> However, I'd argue that given this flag is entirely optional -- something that you have to turn on, I would allow the user to make their choice to turn it or or not without protecting them from themselves regarding the additional overhead.  That would be preferable in my mind than writing logic that violates the stipulation of the argument in question.  If the user expects a new Cluster to start for every CuePoint, then by golly -- let it be so.  As an end-user I'd rather know that it's doing what I asked it to, regardless if I'm asking it to do something questionable.  
> 

> Even if we decided to add some kind of protection against "excessive overhead", I'm not sure where exactly I'd hardcode the line of protection.  A GOP of size 1 is the most extreme, but what about 2, 3 or 5?  

2,3,5 -> ive never seen such in reality so i wouldt give that case
too much weight in a design decission, though of course it shouldnt
be ignored either


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130721/6503c86c/attachment.asc>