Opened 8 years ago

Closed 8 years ago

#1140 closed enhancement (wontfix)

Enabling GMC warp points in demuxing.

Reported by: chungshik Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


MPEG4 GMC warp points isn't included to AVCodecContext that it's not delivered to a client of a demuxer. But it's often needed before start decoding a video codec so that the decoder can decide if it can decode and render it or not. The following change (from v0.6.3) enables it, and I wonder if this can be included in the future release.

--- a/ffmpeg/libavcodec/avcodec.h
+++ b/ffmpeg/libavcodec/avcodec.h
@@ -2652,6 +2652,17 @@ typedef struct AVCodecContext {

  • - decoding: unused */

int rc_lookahead;

+ /
+ * MPEG-4 Warp Point
+ * - encoding: Set by user
+ * - decoding: Set by libavcodec
+ */
+ int warp_point;

} AVCodecContext;


--- a/ffmpeg/libavcodec/mpeg4video_parser.c
+++ b/ffmpeg/libavcodec/mpeg4video_parser.c
@@ -86,6 +86,15 @@ static int av_mpeg4_decode_header(AVCodecParserContext *s1,

if (s->width && (!avctx->width
!avctx->height !avctx->coded_width !avctx->coded_height)) {

avcodec_set_dimensions(avctx, s->width, s->height);


+ /* Get the warp point */
+ avctx->warp_point = s->num_sprite_warping_points;

s1->pict_type= s->pict_type;
pc->first_picture = 0;
return ret;

--- a/ffmpeg/libavformat/mov.c
+++ b/ffmpeg/libavformat/mov.c
@@ -1016,6 +1016,15 @@ static int mov_read_stsd(MOVContext *c, ByteIOContext *pb, MOVAtom atom)

int color_greyscale;

st->codec->codec_id = id;

+ if (id == CODEC_ID_MPEG4)
+ st->need_parsing = AVSTREAM_PARSE_HEADERS;

get_be16(pb); /* version */
get_be16(pb); /* revision level */
get_be32(pb); /* vendor */

Change History (2)

comment:1 Changed 8 years ago by cehoyos

  • Component changed from FFmpeg to undetermined

Please send patches (against current git head) to ffmpeg-devel, they get get more attention there.

And please note that all releases from the 0.6 series contain many regressions and many bugs that were fixed since 0.6 was released, you should not use 0.6.

comment:2 Changed 8 years ago by reimar

  • Resolution set to wontfix
  • Status changed from new to closed

Sorry, but that is not acceptable IMHO.
1) Your change only works with the mov demuxer
2) It would parse headers for no good reason except to set this one field that almost no FFmpeg user would use (and it would hinder us from changing the parser to be more efficient and not process such fields which it doesn't really need).
3) If the problem is finding out whether a decoder supports a format, the decoder should offer an interface for doing that. It is simply unreasonable to try to expose all of the (particularly in newer codecs) 10s of options that may influence if some implementation can decode it. For codecs that don't expose such an API, just trying to decode the first frame and see if there was an error should work. For codecs that can't even do those I don't have a suggestion I admit (except suggesting that maybe just never using such a bad implementation would probably be quite a good idea).

If you disagree your best chance would be to bring it up for discussion by others on the -devel mailing list.

Note: See TracTickets for help on using tickets.