On 18/07/14 11:13, Martin Storsjö wrote:
> On Fri, 18 Jul 2014, Luca Barbato wrote:
>
>> Remove a warning if https support is disabled.
>> ---
>> libavformat/http.c | 76
>> ++++++++++++++++++++++++++++--------------------------
>> 1 file changed, 39 insertions(+), 37 deletions(-)
>>
>> diff --git a/libavformat/http.c b/libavformat/http.c
>> index fc5f7df..3bbe57c 100644
>> --- a/libavformat/http.c
>> +++ b/libavformat/http.c
>> @@ -88,43 +88,6 @@ typedef struct {
>> char *method;
>> } HTTPContext;
>>
>> -#define OFFSET(x) offsetof(HTTPContext, x)
>> -#define D AV_OPT_FLAG_DECODING_PARAM
>> -#define E AV_OPT_FLAG_ENCODING_PARAM
>> -#define DEFAULT_USER_AGENT "Lavf/" AV_STRINGIFY(LIBAVFORMAT_VERSION)
>> -static const AVOption options[] = {
>> -{"chunked_post", "use chunked transfer-encoding for posts",
>> OFFSET(chunked_post), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, E },
>> -{"headers", "set custom HTTP headers, can override built in default
>> headers", OFFSET(headers), AV_OPT_TYPE_STRING, { 0 }, 0, 0, D|E },
>> -{"content_type", "set a specific content type for the POST messages",
>> OFFSET(content_type), AV_OPT_TYPE_STRING, { 0 }, 0, 0, D|E },
>> -{"user_agent", "override User-Agent header", OFFSET(user_agent),
>> AV_OPT_TYPE_STRING, {.str = DEFAULT_USER_AGENT}, 0, 0, D },
>> -{"user-agent", "override User-Agent header, for compatibility with
>> ffmpeg", OFFSET(user_agent), AV_OPT_TYPE_STRING, {.str =
>> DEFAULT_USER_AGENT}, 0, 0, D },
>> -{"multiple_requests", "use persistent connections",
>> OFFSET(multiple_requests), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, D|E },
>> -{"post_data", "set custom HTTP post data", OFFSET(post_data),
>> AV_OPT_TYPE_BINARY, .flags = D|E },
>> -{"mime_type", "export the MIME type", OFFSET(mime_type),
>> AV_OPT_TYPE_STRING, {0}, 0, 0, AV_OPT_FLAG_EXPORT |
>> AV_OPT_FLAG_READONLY },
>> -{"icy", "request ICY metadata", OFFSET(icy), AV_OPT_TYPE_INT, {.i64 =
>> 0}, 0, 1, D },
>> -{"icy_metadata_headers", "return ICY metadata headers",
>> OFFSET(icy_metadata_headers), AV_OPT_TYPE_STRING, {0}, 0, 0,
>> AV_OPT_FLAG_EXPORT },
>> -{"icy_metadata_packet", "return current ICY metadata packet",
>> OFFSET(icy_metadata_packet), AV_OPT_TYPE_STRING, {0}, 0, 0,
>> AV_OPT_FLAG_EXPORT },
>> -{"auth_type", "HTTP authentication type",
>> OFFSET(auth_state.auth_type), AV_OPT_TYPE_INT, {.i64 =
>> HTTP_AUTH_NONE}, HTTP_AUTH_NONE, HTTP_AUTH_BASIC, D|E, "auth_type" },
>> -{"none", "No auth method set, autodetect", 0, AV_OPT_TYPE_CONST,
>> {.i64 = HTTP_AUTH_NONE}, 0, 0, D|E, "auth_type" },
>> -{"basic", "HTTP basic authentication", 0, AV_OPT_TYPE_CONST, {.i64 =
>> HTTP_AUTH_BASIC}, 0, 0, D|E, "auth_type" },
>> -{"send_expect_100", "Force sending an Expect: 100-continue header for
>> POST", OFFSET(send_expect_100), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, E },
>> -{"location", "The actual location of the data received",
>> OFFSET(location), AV_OPT_TYPE_STRING, { 0 }, 0, 0, D|E },
>> -{"offset", "initial byte offset", OFFSET(off), AV_OPT_TYPE_INT64,
>> {.i64 = 0}, 0, INT64_MAX, D },
>> -{"end_offset", "try to limit the request to bytes preceding this
>> offset", OFFSET(end_off), AV_OPT_TYPE_INT64, {.i64 = 0}, 0, INT64_MAX,
>> D },
>> -{"method", "Override the HTTP method", OFFSET(method),
>> AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E, },
>> -{NULL}
>> -};
>> -#define HTTP_CLASS(flavor)\
>> -static const AVClass flavor ## _context_class = {\
>> - .class_name = #flavor,\
>> - .item_name = av_default_item_name,\
>> - .option = options,\
>> - .version = LIBAVUTIL_VERSION_INT,\
>> -}
>> -
>> -HTTP_CLASS(http);
>> -HTTP_CLASS(https);
>
> Would it be enough to only move the HTTP_CLASS macro calls, but at least
> keep the options table here? I kinda prefer having the options table
> close to the context struct declaration.
We can do, currently most code tends to keep the options close to the
descriptor struct (AVCodec, etc) so I unified like that.
I'd push it your way since it changes less lines but I'm not sure which
is the best position. Personally I'd prefer having them all in the same
place.
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
