On Sun, Mar 29, 2015 at 02:56:00PM -0600, Rodger Combs wrote: > I can see the reasoning here, but as "small enough" here means 32K,
my concern was that some app might use a single large buffer without seek function. 32k is too small i agree > 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, That can be done by adding a field to AVFormatContext or AVFormatInternal > 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). that sounds like the ideal solution if developer time is no factor > > > 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 > -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
