[FFmpeg-devel] [PATCH] avformat: add limit_transfer_len option
Clément Bœsch
u at pkh.me
Sun Mar 30 17:05:56 CEST 2014
On Sun, Mar 30, 2014 at 03:07:50PM +0200, Michael Niedermayer wrote:
> This allows forcing smaller chunks to be read for debuging demuxers
> and the avformat core
>
What's the use case? Is this in order to make networking code faster in
later commits?
> Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> ---
> libavformat/avio.c | 14 +++++++++++++-
> libavformat/url.h | 1 +
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/avio.c b/libavformat/avio.c
> index 4edaaa6..185ab1c 100644
> --- a/libavformat/avio.c
> +++ b/libavformat/avio.c
> @@ -72,7 +72,16 @@ static const AVClass *urlcontext_child_class_next(const AVClass *prev)
> return NULL;
> }
>
> -static const AVOption options[] = { { NULL } };
> +#define OFFSET(x) offsetof(URLContext, x)
> +//these names are too long to be readable
> +#define E AV_OPT_FLAG_ENCODING_PARAM
> +#define D AV_OPT_FLAG_DECODING_PARAM
> +
Does it make sense to have these flags at this level?
> +static const AVOption options[] = {
> + {"limit_transfer_len", "maximum number of bytes tranfered with a single read/write call", OFFSET(limit_transfer_len), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, INT_MAX, D|E},
> + { NULL }
> +};
> +
> const AVClass ffurl_context_class = {
> .class_name = "URLContext",
> .item_name = urlcontext_to_name,
> @@ -296,6 +305,9 @@ static inline int retry_transfer_wrapper(URLContext *h, uint8_t *buf,
> int fast_retries = 5;
> int64_t wait_since = 0;
>
> + if (h->limit_transfer_len && h->limit_transfer_len<size)
nitstyle: " < "
[...]
--
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140330/d2364f50/attachment.asc>
More information about the ffmpeg-devel
mailing list