Hi,
----- Mail original -----
> On Tue, Oct 07, 2014 at 03:02:38PM +0200, Benoit Fouet wrote:
> > Support only one independent substream right now, and only
> > syncframes
> > containing 6 blocks.
> >
> > Fixes part of ticket #3074
> > ---
> >
> > Right now, this produces the same output as the previous patch for
> > supported
> > streams, and rejects the unsupported ones.
> > Support for syncframes concatenation will come afterwards.
> >
> > libavformat/isom.c | 1 +
> > libavformat/movenc.c | 184
> > +++++++++++++++++++++++++++++++++++++++++++++++++++
> > libavformat/movenc.h | 2 +
> > 3 files changed, 187 insertions(+)
> >
[...]
> > diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> > index bfee866..18c5955 100644
> > --- a/libavformat/movenc.c
> > +++ b/libavformat/movenc.c
[...]
> > @@ -292,6 +293,178 @@ static int mov_write_ac3_tag(AVIOContext *pb,
> > MOVTrack *track)
[...]
> > +static int handle_eac3(AVPacket *pkt, MOVTrack *track)
> > +{
> > + GetBitContext gbc;
> > + AC3HeaderInfo tmp, *hdr = &tmp;
> > + struct eac3_info *info;
> > + int ret, num_blocks;
> > +
> > + if (!track->eac3_priv && !(track->eac3_priv =
> > av_mallocz(sizeof(*info))))
> > + return AVERROR(ENOMEM);
> > + info = track->eac3_priv;
> > +
>
> > + init_get_bits(&gbc, pkt->data, pkt->size * 8);
> > + if ((ret = avpriv_ac3_parse_header2(&gbc, &hdr)) < 0)
> > + return ret;
>
> [...]
> > + if ((ret = avpriv_ac3_parse_header2(&gbc, &hdr)) <
> > 0)
> > + return ret;
>
> these forward internal error codes like
> AAC_AC3_PARSE_ERROR_FRAME_TYPE
> to the lib user
> av_strerror() for example will not be able to interpret these
>
True.
> also this would prevent remuxing a stream that contains a
> single damaged packet if i understand correctly, this may be
> annoying for sources recoded over somewhat noisy channels
>
Also true, though I'm not sure how to handle this. Dropping the packet would
presumably be a way of dealing with this.
Please note that the E-AC-3 stream passes through the E-AC-3 parser before
muxing, so these errors shouldn't really happen in practice, except for the
first frame (or maybe I missed something in the way the parser works?).
A solution here could be to drop the packet if it is the first one, and error
out if not (with an AV_ error code), what do you think?
> also how can this patch be tested ?
> carls testcase from the ticket does not seem to work
>
If we drop the erroneous packet instead of erroring out, the testcase works
fine.
Thanks,
--
Ben
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
