[FFmpeg-devel] [PATCH 1/2] lavf: add AVFMT_AVFRAME flag
Michael Niedermayer
michaelni at gmx.at
Thu Dec 26 12:51:09 CET 2013
On Wed, Dec 25, 2013 at 11:43:19PM -0200, Ramiro Polla wrote:
> On Wed, Dec 25, 2013 at 11:42 PM, Ramiro Polla <ramiro.polla at gmail.com> wrote:
> > Attached patch adds another AVFMT flag that provides the muxer with a
> > referenced frame.
>
> And here is the patch =)
> ffmpeg.c | 5 +++++
> libavformat/avformat.h | 3 +++
> 2 files changed, 8 insertions(+)
> 97a834b7bd5f10f3c9ace555563bfe044d714333 0001-lavf-add-AVFMT_AVFRAME-flag.patch
> From edb3f5124f7194b60041b70def1015a34c47229a Mon Sep 17 00:00:00 2001
> From: Ramiro Polla <ramiro.polla at gmail.com>
> Date: Wed, 25 Dec 2013 23:21:30 -0200
> Subject: [PATCH 1/2] lavf: add AVFMT_AVFRAME flag
>
> The AVFMT_AVFRAME should be used by muxers that want a referenced
> AVFrame structure for raw picture data. This flag is must be used
> alongside AVFMT_RAWPICTURE. The muxer is responsible for unreferencing
> the frame.
> ---
> ffmpeg.c | 5 +++++
> libavformat/avformat.h | 3 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 5ccbf10..457e0e7 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -907,8 +907,13 @@ static void do_video_out(AVFormatContext *s,
> enc->field_order = enc->coded_frame->top_field_first ? AV_FIELD_TB:AV_FIELD_BT;
> else
> enc->field_order = AV_FIELD_PROGRESSIVE;
> + if (s->oformat->flags & AVFMT_AVFRAME) {
> + pkt.data = (uint8_t *) av_frame_clone(in_picture);
> + pkt.size = sizeof(AVFrame);
sizeof(AVFrame) is unsafe due to ABI (user updating the binary
libavutil.so / .dll which than has a diferent/larger sizeof(AVFrame))
i wonder what would fail if its set to 0. In the unlikely case that
this trick could be used it also would prevent copying of the
extended_data by mistake
also a flag for AVPacket that indicates that its content is a AVFrame
might be useful
and AVPacket.buf should probably also be set so that code that tries
to copy or free avpackets ends up unrefereencing the frame at the
right point and does not memcpy the whole frame
anyway, above comments are more random comments than exact suggestions
for the direction in which this should go. I ATM am not sure which
is the best way to pass this into avformat
> + } else {
> pkt.data = (uint8_t *)in_picture;
> pkt.size = sizeof(AVPicture);
> + }
> pkt.pts = av_rescale_q(in_picture->pts, enc->time_base, ost->st->time_base);
> pkt.flags |= AV_PKT_FLAG_KEY;
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 52eef0d..6a0dd97 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -376,6 +376,9 @@ typedef struct AVProbeData {
> The user or muxer can override this through
> AVFormatContext.avoid_negative_ts
> */
> +#define AVFMT_AVFRAME 0x80000 /**< Format wants referenced AVFrame structure for
> + raw picture data. Muxer is responsible for
> + unreferencing frame. */
a larger value should be used so as to avoid conflicting with the
fork, when a new flag is added there
>
> #define AVFMT_SEEK_TO_PTS 0x4000000 /**< Seeking is based on PTS */
>
> --
> 1.7.9.5
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- 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/20131226/1cdf8ab8/attachment.asc>
More information about the ffmpeg-devel
mailing list