On Tue, Sep 16, 2014 at 10:44:32PM +0200, wm4 wrote: > On Tue, 16 Sep 2014 21:37:08 +0200 > Clément Bœsch <u...@pkh.me> wrote: > > > On Sun, Sep 14, 2014 at 10:01:55AM +0200, Clément Bœsch wrote: > > > After this the order from the original file is stored through readorder > > > when doing ffmpeg -i input.ass -c copy output.mkv. > > > > > > And now that the ASS muxer honors the ReadOrder, extracting the ass back > > > (without transcoding) restores the original order. > > > > > > TODO: micro bump? > > > --- > > > libavformat/assdec.c | 37 +++++++++++++++++++++++++++++++++---- > > > 1 file changed, 33 insertions(+), 4 deletions(-) > > > > > > > ping > > I can just say that it looks reasonable to me. > > One problem was whether ReadOrder starts with 0 or 1. The "spec" seems > to imply it's 1 (never clearly stated, but an example uses 1), but all > real world files use 0, and we concluded that it must be 0. >
Indeed I confirm that, every samples I looked at started at 0; I believe it's a better choice that 1. But I actually made the "mistake" to follow the specifications in the ass encoder; I'll probably need to change that at some point. > One minor detail: could it be that the layer field has whitespace > between the number and the ','? AFAIK strtol() doesn't skip trailing > whitespace. Mmh. Yeah I'll adjust the code just in case. > It's also a bit annoying that the code looks at the event > lines twice (read_ts and reformat_line). Ah, didn't even thought of merging them. Alright, I'll send a new version in the next days. Thanks -- Clément B.
pgptKD9pCK7JE.pgp
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
