[FFmpeg-devel] [PATCH 11/17] avformat/assenc: mux all extradata at once
Clément Bœsch
u at pkh.me
Sun Sep 21 18:58:19 CEST 2014
On Sun, Sep 21, 2014 at 08:32:15AM +0200, wm4 wrote:
> On Sat, 20 Sep 2014 22:27:51 +0200
> Clément Bœsch <u at pkh.me> wrote:
>
> > Before this commit, the code was muxing up to the 2nd line after
> > "[Events]" (assuming it to be the "Format:" line). The remaining are
> > generally "Comment:" directives which can stay in that place. mkvextract
> > behaves that way so it seems there is no reason for that extra
> > complexity.
> > ---
>
> Still LGTM generally, but...
>
> > libavformat/assenc.c | 26 ++++----------------------
> > 1 file changed, 4 insertions(+), 22 deletions(-)
> >
> > diff --git a/libavformat/assenc.c b/libavformat/assenc.c
> > index 2afeef7..236d021 100644
> > --- a/libavformat/assenc.c
> > +++ b/libavformat/assenc.c
> > @@ -30,7 +30,6 @@ typedef struct DialogueLine {
> > } DialogueLine;
> >
> > typedef struct ASSContext{
> > - unsigned int extra_index;
> > int write_ts; // 0: ssa (timing in payload), 1: ass (matroska like)
> > int expected_readorder;
> > DialogueLine *dialogue_cache;
> > @@ -42,7 +41,6 @@ static int write_header(AVFormatContext *s)
> > {
> > ASSContext *ass = s->priv_data;
> > AVCodecContext *avctx= s->streams[0]->codec;
> > - uint8_t *last= NULL;
> >
> > if (s->nb_streams != 1 || (avctx->codec_id != AV_CODEC_ID_SSA &&
> > avctx->codec_id != AV_CODEC_ID_ASS)) {
> > @@ -51,21 +49,11 @@ static int write_header(AVFormatContext *s)
> > }
> > ass->write_ts = avctx->codec_id == AV_CODEC_ID_ASS;
> > avpriv_set_pts_info(s->streams[0], 64, 1, 100);
> > -
> > - while(ass->extra_index < avctx->extradata_size){
> > - uint8_t *p = avctx->extradata + ass->extra_index;
> > - uint8_t *end= strchr(p, '\n');
> > - if(!end) end= avctx->extradata + avctx->extradata_size;
> > - else end++;
> > -
> > - avio_write(s->pb, p, end-p);
> > - ass->extra_index += end-p;
> > -
> > - if(last && !memcmp(last, "[Events]", 8))
> > - break;
> > - last=p;
> > + if (avctx->extradata_size > 0) {
> > + avio_write(s->pb, avctx->extradata, avctx->extradata_size);
> > + if (avctx->extradata[avctx->extradata_size - 1] != '\n')
> > + avio_write(s->pb, "\r\n", 2);
>
> Wouldn't that add a \r\n even if \n is used in this file? Or does
> Aegisub write \r\n even on Unix?
>
That's right, that's something we need to fix somehow: in some
circumstances we indeed generate inconsistent files in that regard. I'll
leave that to a later patch, because we already use \r\n in that
muxer for the tail of the Dialogue lines.
Patch applied, thank you
[...]
--
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140921/c54e9902/attachment.asc>
More information about the ffmpeg-devel
mailing list