[FFmpeg-devel] [PATCH 2/2] avisynth: Use av_packet_from_data instead of av_new_packet
Michael Niedermayer
michaelni at gmx.at
Wed Jan 8 20:12:36 CET 2014
On Wed, Jan 08, 2014 at 07:38:18PM +0100, wm4 wrote:
> On Wed, 8 Jan 2014 00:37:57 -0500
> Stephen Hutchinson <qyot27 at gmail.com> wrote:
>
> > If the audio changes from 9eac7c4 were merged as they were, this
> > would cause scripts with both video+audio to fail with a lot of
> > audio decoding errors (the video would be fine). Scripts with
> > only one of either video or audio were unaffected. Additionally,
> > the av_packet changes in general caused seeking to break.
> >
> > Using av_packet_from_data allows video+audio scripts to work as
> > expected, without audio decoding errors. It also fixes seeking.
> > ---
> > libavformat/avisynth.c | 20 ++++++++++++++++----
> > 1 file changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
> > index 66f85ec..99fe34c 100644
> > --- a/libavformat/avisynth.c
> > +++ b/libavformat/avisynth.c
> > @@ -421,7 +421,7 @@ static int avisynth_read_packet_video(AVFormatContext *s, AVPacket *pkt,
> > AVS_VideoFrame *frame;
> > unsigned char *dst_p;
> > const unsigned char *src_p;
> > - int n, i, plane, rowsize, planeheight, pitch, bits;
> > + int n, i, plane, rowsize, planeheight, pitch, bits, ret;
> > const char *error;
> >
> > if (avs->curr_frame >= avs->vi->num_frames)
> > @@ -460,9 +460,15 @@ static int avisynth_read_packet_video(AVFormatContext *s, AVPacket *pkt,
> > if (!pkt->size)
> > return AVERROR_UNKNOWN;
> >
> > - if (av_new_packet(pkt, pkt->size) < 0)
> > + pkt->data = av_malloc(pkt->size);
> > + if (!pkt->data)
> > return AVERROR(ENOMEM);
> >
> > + if ((ret = av_packet_from_data(pkt, pkt->data, pkt->size)) < 0) {
> > + av_packet_unref(pkt);
> > + return ret;
> > + }
> > +
>
> Oh, nevermind my previous mail. I was reading the code wrong. So, as
> said on the libav ML, apparently the problem is that av_new_packet()
> overwrites other packet fields? Then why not set the fields after this
> function, instead of using more complicated code? Anyway, nevermind me,
> since there is no actual problem.
iam fine with any solution that works, i applied these here as
Stephen posted this solution and not another variant.
though it seems theres a bug ive missed, the malloc should have a
+ FF_INPUT_BUFFER_PADDING_SIZE, because it can be used as input
to a decoder
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140108/69db1b18/attachment.asc>
More information about the ffmpeg-devel
mailing list