I can see the reasoning here, but as "small enough" here means 32K, I don't 
think this would be worth doing on a per-muxer basis. Maybe if we had a more 
general way to tell the muxer about segment boundaries, or if segment.c 
provided a single AVIOContext, with a write() function that passes through to a 
sub-context and a seek() function that reopened (and seeked within) previous 
segments if necessary? (Though we'd need an option to disable seeks into 
previous files to avoid inter-process read/write races).

> On Mar 29, 2015, at 14:04, Michael Niedermayer <michae...@gmx.at> wrote:
> 
> On Sun, Mar 29, 2015 at 11:54:59AM -0600, Rodger Combs wrote:
>> In the case of most calls to end_ebml_master, the target is within the 
>> current segment, but in this case, it's in the first segment or header file, 
>> so if the context was marked as non-seekable manually (as in segment.c), 
>> avio_seek will ignore that and execute it anyway. This is fine in other uses 
>> of end_ebml_master, since both the current and target position are within 
>> the current segment, but breaks when ending mkv->segment, since `master.pos` 
>> refers to an offset in the first segment. So instead of failing the seek and 
>> returning, we end up seeking to an early point in the last segment, 
>> overwriting 8 unrelated bytes, and jumping back.
> 
> maybe it would be better to add a private option to the matroska
> muxer that keeps it from messing with past "segments"
> and set this from the segment muxer
> 
> a non seekable file thats small enough could before this patch
> be written with mkv->segment properly closed but i think the patch
> would break this.
> 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> If a bugfix only changes things apparently unrelated to the bug with no
> further explanation, that is a good sign that the bugfix is wrong.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to