[FFmpeg-devel] [PATCH] WebM mux/demux

James Zern jzern
Thu May 20 22:36:17 CEST 2010


On Thu, May 20, 2010 at 05:24, David Conrad <lessen42 at gmail.com> wrote:
>>>> + ? ?MatroskaMuxContext *mkv = s->priv_data;
>>>> + ? ?ByteIOContext *pb = s->pb;
>>>> + ? ?AVCodecContext *codec = s->streams[pkt->stream_index]->codec;
>>>> + ? ?int keyframe = !!(pkt->flags & PKT_FLAG_KEY);
>>>> + ? ?int ret = 0;
>>>> +
>>>> + ? ?if (codec->codec_type == AVMEDIA_TYPE_VIDEO && keyframe && mkv->cluster_pos) {
>>>> + ? ? ? ?// Start a new cluster when we get a key frame
>>>> + ? ? ? ?int64_t ts = mkv->tracks[pkt->stream_index].write_dts ? pkt->dts : pkt->pts;
>>>>
>>>> + ? ? ? ?av_log(s, AV_LOG_DEBUG, "Starting new cluster at offset %" PRIu64
>>>> + ? ? ? ? ?" bytes, pts %" PRIu64 "\n", url_ftell(pb), ts);
>>>> +
>>>> + ? ? ? ?end_ebml_master(pb, mkv->cluster);
>>>> + ? ? ? ?mkv->cluster_pos = 0;
>>>> + ? ? ? ?if (mkv->dyn_bc)
>>>> + ? ? ? ? ? ?mkv_flush_dynbuf(s);
>>>> + ? ?}
>>>
>>> There should be a minimum cluster size in addition to starting on keyframes.
>> With the current setup it would pass back through the initial write
>> and hit the worst case 30s.
>
> You mean the first keyframe after reaching the min size wouldn't trigger this condition? At any rate, the idea is that if you have several keyframes to avoid starting a new cluster for each of them. The min size only has to be like 1-4k or so to avoid the worst of it.
>
I understand, I think I was confused in my initial response. As far
size goes this can of course vary depending on the stream. Might a
minimum time be appropriate as well?



More information about the ffmpeg-devel mailing list