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

[Michael Niedermayer]

On Sun, Jul 21, 2013 at 11:51:53AM +0200, Nicolas George wrote:
> Le tridi 3 thermidor, an CCXXI, Bernie Habermeier a écrit :
> > But I explicitly WANT to have an option that doesn't "take it under
> > advisement".  
> > 
> > Specifically, I want to control exact placement of my I-frames, and
> > therefore CuePoints, and I want to a 100% guarantee that I have a new
> > Cluster start for each such CuePoint.  What you're proposing does not do
> > that at all, and has a completely different feel to it.  We can certainly
> > add this kind of control, and I'm fine implementing that, but that is
> > specifically not what I want.
> 
> I am not sure the direction of your requirement, but I believe the current
> logic with configurable limits would work for both:
> 
> * Positive: if you WANT a new cluster for each key frame, irregardless of
>   the size/duration/age/whatever of the current cluster, -min_cluster_size 0
>   (instead of 4k) should do that.
> 
> * Negative: if you WANT NO new cluster except at key frames, then
>   -max_cluster_size \infty -max_cluster_duration \infty (instead of 5M/5000,
>   or 32k/1000 for streams) should do that.
> 
>   (lavf does not have \infty, but INT64_MAX should do the trick unless you
>   intend to produce a eight etaoctets file longer than the history of
>   mankind.)

above will only work with video streams, if theres no video stream
then making cue points and clusters match will i think not work
with these values but i didnt double check the source

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- 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/63be0668/attachment.asc>