[FFmpeg-devel] [PATCH 4/4] lavf/matroskaenc: don't try to end the segment when the output isn't seekable

[Michael Niedermayer]

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 <michaelni at 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 at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150329/935d15f4/attachment.asc>