Hi, ----- Mail original ----- > On Fri, Oct 10, 2014 at 10:02:09AM +0200, Benoit Fouet wrote: > > 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. > > hmm, ok, please make sure droping a patcket especially if its > more than one prints a warning >
Sure, will update to do so. -- Ben _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel