Re: [FFmpeg-devel] [PATCH 5/5] apng: Add a basic APNG muxer
On 29 March 2015 at 14:02, Carl Eugen Hoyos wrote:
> Donny Yang kota.moe> writes:
>
> > +{ "final_delay_num", "Force delay numerator after the last frame",
> > OFFSET(last_delay_num),
> > + AV_OPT_TYPE_INT, { .i64 = 0 }, 0, USHRT_MAX, ENC },
> > +{ "final_delay_den", "Force delay denominator after the last frame",
> > OFFSET(last_delay_den),
> > + AV_OPT_TYPE_INT, { .i64 = 0 }, 0, USHRT_MAX, ENC },
>
> Wouldn't AV_OPT_TYPE_RATIONAL help here?
>
Yes
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tiff: Return more meaningful error codes
On 29/03/15 1:18 AM, Himangi Saraogi wrote:
> ---
> libavcodec/tiffenc.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/tiffenc.c b/libavcodec/tiffenc.c
> index 44cd956..a94b700 100644
> --- a/libavcodec/tiffenc.c
> +++ b/libavcodec/tiffenc.c
> @@ -164,7 +164,8 @@ static int add_entry1(TiffEncoderContext *s,
> * @param dst output buffer
> * @param n size of input buffer
> * @param compr compression method
> - * @return number of output bytes. If an output error is encountered, -1 is
> returned
> + * @return number of output bytes. If an output error is encountered, a
> negative
> + * value corresponding to an AVERROR error code is returned.
> */
> static int encode_strip(TiffEncoderContext *s, const int8_t *src,
> uint8_t *dst, int n, int compr)
> @@ -177,14 +178,14 @@ static int encode_strip(TiffEncoderContext *s, const
> int8_t *src,
> unsigned long zlen = s->buf_size - (*s->buf - s->buf_start);
> if (compress(dst, &zlen, src, n) != Z_OK) {
> av_log(s->avctx, AV_LOG_ERROR, "Compressing failed\n");
> -return -1;
> +return AVERROR_EXTERNAL;
> }
> return zlen;
> }
> #endif
> case TIFF_RAW:
> if (check_size(s, n))
> -return -1;
> +return AVERROR(EINVAL);
I'm not sure this qualifies as "Invalid argument", so I'll let someone else
comment.
> memcpy(dst, src, n);
> return n;
> case TIFF_PACKBITS:
> @@ -193,7 +194,7 @@ static int encode_strip(TiffEncoderContext *s, const
> int8_t *src,
> case TIFF_LZW:
> return ff_lzw_encode(s->lzws, src, n);
> default:
> -return -1;
> +return AVERROR_BUG;
AVERROR(EINVAL) here.
If i do "ffmpeg -i INPUT -compression_algo 2 OUTPUT.tiff" I'm not triggering a
bug, I'm
passing an invalid/unsupported argument to the encoder.
> }
> }
>
> @@ -304,7 +305,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
> *pkt,
> default:
> av_log(s->avctx, AV_LOG_ERROR,
> "This colors format is not supported\n");
> -return -1;
> +return AVERROR(EINVAL);
> }
>
> for (i = 0; i < s->bpp_tab_size; i++)
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: GSoC: APNG
On 29 March 2015 at 03:15, Michael Niedermayer wrote: > you can try AVCodecContext->frame_number, if that doesnt work > you need to keep track of if you already had received a frame > I've tried both, but it turns out that AVCodecContext->frame_number seems to be thread-specific. That is, it starts with 0 for each thread rather than the actual frame number. One possible option is to disable threading support though... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tiff: Return more meaningful error codes
---
libavcodec/tiffenc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/tiffenc.c b/libavcodec/tiffenc.c
index 44cd956..a94b700 100644
--- a/libavcodec/tiffenc.c
+++ b/libavcodec/tiffenc.c
@@ -164,7 +164,8 @@ static int add_entry1(TiffEncoderContext *s,
* @param dst output buffer
* @param n size of input buffer
* @param compr compression method
- * @return number of output bytes. If an output error is encountered, -1 is
returned
+ * @return number of output bytes. If an output error is encountered, a
negative
+ * value corresponding to an AVERROR error code is returned.
*/
static int encode_strip(TiffEncoderContext *s, const int8_t *src,
uint8_t *dst, int n, int compr)
@@ -177,14 +178,14 @@ static int encode_strip(TiffEncoderContext *s, const
int8_t *src,
unsigned long zlen = s->buf_size - (*s->buf - s->buf_start);
if (compress(dst, &zlen, src, n) != Z_OK) {
av_log(s->avctx, AV_LOG_ERROR, "Compressing failed\n");
-return -1;
+return AVERROR_EXTERNAL;
}
return zlen;
}
#endif
case TIFF_RAW:
if (check_size(s, n))
-return -1;
+return AVERROR(EINVAL);
memcpy(dst, src, n);
return n;
case TIFF_PACKBITS:
@@ -193,7 +194,7 @@ static int encode_strip(TiffEncoderContext *s, const int8_t
*src,
case TIFF_LZW:
return ff_lzw_encode(s->lzws, src, n);
default:
-return -1;
+return AVERROR_BUG;
}
}
@@ -304,7 +305,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
default:
av_log(s->avctx, AV_LOG_ERROR,
"This colors format is not supported\n");
-return -1;
+return AVERROR(EINVAL);
}
for (i = 0; i < s->bpp_tab_size; i++)
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fix dnxhd pix_fmt change
Michael Niedermayer gmx.at> writes: > > dnxhddec.c |9 + > > 1 file changed, 5 insertions(+), 4 deletions(-) > > faf7809dc5b971e27c493e25e8f56a41e7743bd7 patchdnxhd.diff > > diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c > > LGTM The change was merged. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] apng: Add a basic APNG muxer
Donny Yang kota.moe> writes:
> +{ "final_delay_num", "Force delay numerator after the last frame",
> OFFSET(last_delay_num),
> + AV_OPT_TYPE_INT, { .i64 = 0 }, 0, USHRT_MAX, ENC },
> +{ "final_delay_den", "Force delay denominator after the last frame",
> OFFSET(last_delay_den),
> + AV_OPT_TYPE_INT, { .i64 = 0 }, 0, USHRT_MAX, ENC },
Wouldn't AV_OPT_TYPE_RATIONAL help here?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add "split" mode to tinterlace filter.
>> This mode is the opposite of the "merge" mode. >> --- >> This patch adds a new mode to tinterlace which performs the opposite operation >> as the "merge" mode. >> >> My primary motivation is that I have been working with Derek Buitenhuis to see >> about adding interlace support to the libx265 encoder. It turns out that this is >> a complex situation since libx265 requires each field to be encoded separately >> but ffmpeg stores fields together as an interlaced frame. tinterlace can be used >> with this new mode to provide each field as a separate frame to libx265 - and >> therefore perform valid interlaced h.265 encoding. >> >> At first I considered this patch a hack and planned on keeping it to myself. But >> now I think that it must be generally useful since it can produce the exact >> format of data that would be the input to the tinterlace "merge" mode. >> As a test, I have checked: >> ffmpeg -i input.file -vf "tinterlace=split,tinterlace=merge" output.file >> And the image makes a successful round trip. > >What about separatefields filter? Yes. That would appear to do the same thing. I will go test it and see if it works for my scenario. I tentatively withdrawl my patch. ~Brian ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add "split" mode to tinterlace filter.
Dana 28. 3. 2015. 23:35 osoba "Brian Matherly"
napisala je:
>
> From: Brian Matherly
>
> This mode is the opposite of the "merge" mode.
> ---
> This patch adds a new mode to tinterlace which performs the opposite
operation
> as the "merge" mode.
>
> My primary motivation is that I have been working with Derek Buitenhuis
to see
> about adding interlace support to the libx265 encoder. It turns out that
this is
> a complex situation since libx265 requires each field to be encoded
separately
> but ffmpeg stores fields together as an interlaced frame. tinterlace can
be used
> with this new mode to provide each field as a separate frame to libx265 -
and
> therefore perform valid interlaced h.265 encoding.
>
> At first I considered this patch a hack and planned on keeping it to
myself. But
> now I think that it must be generally useful since it can produce the
exact
> format of data that would be the input to the tinterlace "merge" mode.
> As a test, I have checked:
> ffmpeg -i input.file -vf "tinterlace=split,tinterlace=merge"
output.file
> And the image makes a successful round trip.
What about separatefields filter?
> doc/filters.texi| 24
> libavfilter/tinterlace.h| 1 +
> libavfilter/vf_tinterlace.c | 43
+--
> 3 files changed, 66 insertions(+), 2 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 15f8ed5..9b3fd02 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -9197,6 +9197,30 @@ Output:
> 1 1 2 2 3 3 4
> @end example
>
> +@item split, 7
> +Perform the inverse operation as merge. Move upper field to odd frames,
lower
> +field to even frames, generating a half height frame at double frame
rate.
> +@example
> + --> time
> +Input:
> +Frame 1 Frame 2
> +1 3
> +2 4
> +1 3
> +2 4
> +1 3
> +2 4
> +1 3
> +2 4
> +
> +Output:
> +Frame 1 Frame 2 Frame 3 Frame 4
> +1 2 3 4
> +1 2 3 4
> +1 2 3 4
> +1 2 3 4
> +@end example
> +
>
> @end table
>
> diff --git a/libavfilter/tinterlace.h b/libavfilter/tinterlace.h
> index fa0a83a..ece8ce4 100644
> --- a/libavfilter/tinterlace.h
> +++ b/libavfilter/tinterlace.h
> @@ -38,6 +38,7 @@ enum TInterlaceMode {
> MODE_INTERLEAVE_TOP,
> MODE_INTERLEAVE_BOTTOM,
> MODE_INTERLACEX2,
> +MODE_SPLIT,
> MODE_NB,
> };
>
> diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
> index f3411f9..2c9047b 100644
> --- a/libavfilter/vf_tinterlace.c
> +++ b/libavfilter/vf_tinterlace.c
> @@ -46,6 +46,7 @@ static const AVOption tinterlace_options[] = {
> {"interleave_top","interleave top and bottom fields",
0, AV_OPT_TYPE_CONST, {.i64=MODE_INTERLEAVE_TOP},INT_MIN, INT_MAX,
FLAGS, "mode"},
> {"interleave_bottom", "interleave bottom and top fields",
0, AV_OPT_TYPE_CONST, {.i64=MODE_INTERLEAVE_BOTTOM}, INT_MIN, INT_MAX,
FLAGS, "mode"},
> {"interlacex2", "interlace fields from two consecutive
frames", 0, AV_OPT_TYPE_CONST, {.i64=MODE_INTERLACEX2}, INT_MIN,
INT_MAX, FLAGS, "mode"},
> +{"split", "split fields",
0, AV_OPT_TYPE_CONST, {.i64=MODE_SPLIT}, INT_MIN, INT_MAX,
FLAGS, "mode"},
>
> {"flags", "set flags", OFFSET(flags), AV_OPT_TYPE_FLAGS,
{.i64 = 0}, 0, INT_MAX, 0, "flags" },
> {"low_pass_filter", "enable vertical low-pass filter",
0, AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_VLPF}, INT_MIN, INT_MAX,
FLAGS, "flags" },
> @@ -118,7 +119,8 @@ static int config_out_props(AVFilterLink *outlink)
> outlink->flags |= FF_LINK_FLAG_REQUEST_LOOP;
> outlink->w = inlink->w;
> outlink->h = tinterlace->mode == MODE_MERGE || tinterlace->mode ==
MODE_PAD ?
> -inlink->h*2 : inlink->h;
> +inlink->h*2 : tinterlace->mode == MODE_SPLIT ?
> +inlink->h/2 : inlink->h;
>
> if (tinterlace->mode == MODE_PAD) {
> uint8_t black[4] = { 16, 128, 128, 16 };
> @@ -145,7 +147,7 @@ static int config_out_props(AVFilterLink *outlink)
> tinterlace->flags &= ~TINTERLACE_FLAG_VLPF;
> }
> tinterlace->preout_time_base = inlink->time_base;
> -if (tinterlace->mode == MODE_INTERLACEX2) {
> +if (tinterlace->mode == MODE_INTERLACEX2 || tinterlace->mode ==
MODE_SPLIT) {
> tinterlace->preout_time_base.den *= 2;
> outlink->frame_rate = av_mul_q(inlink->frame_rate,
(AVRational){2,1});
> outlink->time_base = av_mul_q(inlink->time_base ,
(AVRat
Re: [FFmpeg-devel] [GSoC] Proof-of-concept HTTP Server
I hope this addresses the issues mentioned.
I added a new label in case of failure in http_open() in favor of
duplicated code (i.e. calling av_dict_free() multiple times). I copied
the style from the other functions.
Signed-off-by: Stephan Holljes
---
doc/protocols.texi | 3 +++
libavformat/http.c | 26 +-
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 2a19b41..5b7b6cf 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -277,6 +277,9 @@ Set initial byte offset.
@item end_offset
Try to limit the request to bytes preceding this offset.
+
+@item listen
+If set to 1 enables experimental HTTP server.
@end table
@subsection HTTP Cookies
diff --git a/libavformat/http.c b/libavformat/http.c
index da3c9be..c769918 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -96,6 +96,7 @@ typedef struct HTTPContext {
int send_expect_100;
char *method;
int reconnect;
+int listen;
} HTTPContext;
#define OFFSET(x) offsetof(HTTPContext, x)
@@ -127,6 +128,7 @@ static const AVOption options[] = {
{ "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 },
{ "reconnect", "auto reconnect after disconnect before EOF",
OFFSET(reconnect), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
+{ "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 0
}, 0, 1, E },
{ NULL }
};
@@ -321,9 +323,31 @@ static int http_open(URLContext *h, const char *uri, int
flags,
"No trailing CRLF found in HTTP header.\n");
}
+if (s->listen) {
+static const char header[] = "HTTP/1.1 200 OK\r\nContent-Type:
application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n";
+char hostname[1024];
+char lower_url[100];
+int port;
+av_url_split(NULL, 0, NULL, 0, hostname, sizeof(hostname), &port,
+ NULL, 0, uri);
+ff_url_join(lower_url, sizeof(lower_url), "tcp", NULL, hostname, port,
+NULL);
+av_dict_set(options, "listen", "1", 0);
+ret = ffurl_open(&s->hd, lower_url, AVIO_FLAG_READ_WRITE,
+ &h->interrupt_callback, options);
+if (ret < 0)
+goto fail;
+if (ret = ffurl_write(s->hd, header, strlen(header)) < 0)
+goto fail;
+return 0;
+}
ret = http_open_cnx(h, options);
if (ret < 0)
-av_dict_free(&s->chained_options);
+goto fail;
+return ret;
+
+fail:
+av_dict_free(&s->chained_options);
return ret;
}
--
2.3.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] libavdevice/avfoundation: add capture_screen_mouse_clicks option
On Sun, Mar 29, 2015 at 12:25:27AM +0100, Thilo Borgmann wrote: > Am 27.03.15 um 14:37 schrieb Matthieu Bouron: > > On Sat, Mar 21, 2015 at 6:47 PM, Thilo Borgmann > > wrote: > > [...] > > > >> > >> Please rename to "capture_mouse_clicks". > >> > > > > Updated in attached patch. > > Ok, please apply. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] libavdevice/avfoundation: use pts/dts provided by the CMSampleBuffer API
On Sun, Mar 29, 2015 at 12:26:31AM +0100, Thilo Borgmann wrote:
> Am 21.03.15 um 18:45 schrieb Thilo Borgmann:
> > Am 18.03.15 um 09:37 schrieb Matthieu Bouron:
> >> On Fri, Mar 13, 2015 at 8:16 PM, wrote:
> >>
> >>> From: Matthieu Bouron
> >>>
> >>> ---
> >>> libavdevice/avfoundation.m | 21 +++--
> >>> 1 file changed, 15 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> >>> index 8112229..5bcd6a4 100644
> >>> --- a/libavdevice/avfoundation.m
> >>> +++ b/libavdevice/avfoundation.m
> >>> @@ -881,9 +881,14 @@ static int avf_read_packet(AVFormatContext *s,
> >>> AVPacket *pkt)
> >>> return AVERROR(EIO);
> >>> }
> >>>
> >>> -pkt->pts = pkt->dts = av_rescale_q(av_gettime() -
> >>> ctx->first_pts,
> >>> - AV_TIME_BASE_Q,
> >>> - avf_time_base_q);
> >>> +CMItemCount count;
> >>> +CMSampleTimingInfo timing_info;
> >>> +
> >>> +if
> >>> (CMSampleBufferGetOutputSampleTimingInfoArray(ctx->current_frame, 1,
> >>> &timing_info, &count) == noErr) {
> >>> +AVRational timebase_q = av_make_q(1,
> >>> timing_info.presentationTimeStamp.timescale);
> >>> +pkt->pts = pkt->dts =
> >>> av_rescale_q(timing_info.presentationTimeStamp.value, timebase_q,
> >>> avf_time_base_q);
> >>> +}
> >>> +
> >>> pkt->stream_index = ctx->video_stream_index;
> >>> pkt->flags|= AV_PKT_FLAG_KEY;
> >>>
> >>> @@ -911,9 +916,13 @@ static int avf_read_packet(AVFormatContext *s,
> >>> AVPacket *pkt)
> >>> return AVERROR(EIO);
> >>> }
> >>>
> >>> -pkt->pts = pkt->dts = av_rescale_q(av_gettime() -
> >>> ctx->first_audio_pts,
> >>> - AV_TIME_BASE_Q,
> >>> - avf_time_base_q);
> >>> +CMItemCount count;
> >>> +CMSampleTimingInfo timing_info;
> >>> +
> >>> +if
> >>> (CMSampleBufferGetOutputSampleTimingInfoArray(ctx->current_audio_frame, 1,
> >>> &timing_info, &count) == noErr) {
> >>> +AVRational timebase_q = av_make_q(1,
> >>> timing_info.presentationTimeStamp.timescale);
> >>> +pkt->pts = pkt->dts =
> >>> av_rescale_q(timing_info.presentationTimeStamp.value, timebase_q,
> >>> avf_time_base_q);
> >>> +}
> >>>
> >>> pkt->stream_index = ctx->audio_stream_index;
> >>> pkt->flags|= AV_PKT_FLAG_KEY;
> >>> --
> >>> 2.3.2
> >>>
> >>>
> >> ping
> >
> > Ok if tested.
>
> Please apply.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavdevice/avfoundation: add framerate and video size options
On Sun, Mar 29, 2015 at 12:27:54AM +0100, Thilo Borgmann wrote: > Am 27.03.15 um 14:34 schrieb Matthieu Bouron: > > On Sat, Mar 21, 2015 at 4:51 PM, Thilo Borgmann > > wrote: > > [...] > >> +[video_device setValue:selected_format forKey:@"activeFormat"]; > >> +[video_device setValue:min_frame_duration > >> forKey:@"activeVideoMinFrameDuration"]; > >> +[video_device setValue:min_frame_duration > >> forKey:@"activeVideoMaxFrameDuration"]; > >> ^^^ > >> Should be max_frame_duration in the third line. > >> IIRC there is functionality in the API to check if setting > >> min/max_frame_duration is available for the device, isn't it? Please > >> check, in > >> case there it is not, there is an alternative way to set the framerate > >> (IIRC). > >> > > > > It is purely intentionnal to use the min_frame_duration for the > > activeVideoMaxFrameDuration to acheive a better consistant framerate. > > There is no way to check if the range is accepted by the device but as > > stated by the documentation, applied range values that does not come from > > ranges returned by the API will throw an exception. > > There is an alternative way to set the framerate using > > AVCaptureConnection.setVideo(Min|Max)FrameDuration but it has been > > deprecated in iOS 7 and I do not intend to support it. > > I misunderstood your these lines. > > Patch ok, please apply. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] libavdevice/avfoundation: add capture_screen_cursor option
On Sun, Mar 29, 2015 at 12:25:13AM +0100, Thilo Borgmann wrote: > Am 27.03.15 um 14:36 schrieb Matthieu Bouron: > > On Sat, Mar 21, 2015 at 5:35 PM, Thilo Borgmann > > wrote: > > [...] > > > >> I suggest to rename the option to "capture_cursor"... _screen_ in it seems > >> to be > >> redundant. > >> > > > > Updated in attached patch. > > Ok, please apply. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] lavf/matroskaenc: don't try to end the segment when the output isn't seekable
--- libavformat/matroskaenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index 6b2e390..c242a0e 100644 --- a/libavformat/matroskaenc.c +++ b/libavformat/matroskaenc.c @@ -1948,9 +1948,9 @@ static int mkv_write_trailer(AVFormatContext *s) put_ebml_float(pb, MATROSKA_ID_DURATION, mkv->duration); avio_seek(pb, currentpos, SEEK_SET); +end_ebml_master(pb, mkv->segment); } -end_ebml_master(pb, mkv->segment); av_freep(&mkv->tracks); av_freep(&mkv->cues->entries); av_freep(&mkv->cues); -- 2.3.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] libavformat/segment: add an option to write the header to a separate file
This permits some interesting segmenting techniques with formats like Matroska,
where you can concatenate the header and segments [N, nb_segments) and get
a working file that starts at segment N's start time.
---
libavformat/segment.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index b623bb6..b84b2df 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -105,6 +105,7 @@ typedef struct SegmentContext {
int64_t time_delta;
int individual_header_trailer; /**< Set by a private option. */
int write_header_trailer; /**< Set by a private option. */
+char *header_filename; ///< filename to write the output header to
int reset_timestamps; ///< reset timestamps at the begin of each segment
int64_t initial_offset;///< initial timestamps offset, expressed in
microseconds
@@ -594,6 +595,11 @@ static int seg_write_header(AVFormatContext *s)
if (!seg->write_header_trailer)
seg->individual_header_trailer = 0;
+if (seg->header_filename) {
+seg->write_header_trailer = 1;
+seg->individual_header_trailer = 0;
+}
+
if (!!seg->time_str + !!seg->times_str + !!seg->frames_str > 1) {
av_log(s, AV_LOG_ERROR,
"segment_time, segment_times, and segment_frames options "
@@ -670,7 +676,7 @@ static int seg_write_header(AVFormatContext *s)
goto fail;
if (seg->write_header_trailer) {
-if ((ret = avio_open2(&oc->pb, oc->filename, AVIO_FLAG_WRITE,
+if ((ret = avio_open2(&oc->pb, seg->header_filename ?
seg->header_filename : oc->filename, AVIO_FLAG_WRITE,
&s->interrupt_callback, NULL)) < 0) {
av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n",
oc->filename);
goto fail;
@@ -706,8 +712,13 @@ static int seg_write_header(AVFormatContext *s)
if (oc->avoid_negative_ts > 0 && s->avoid_negative_ts < 0)
s->avoid_negative_ts = 1;
-if (!seg->write_header_trailer) {
-close_null_ctxp(&oc->pb);
+if (!seg->write_header_trailer || seg->header_filename) {
+if (seg->header_filename) {
+av_write_frame(oc, NULL);
+avio_closep(&oc->pb);
+} else {
+close_null_ctxp(&oc->pb);
+}
if ((ret = avio_open2(&oc->pb, oc->filename, AVIO_FLAG_WRITE,
&s->interrupt_callback, NULL)) < 0)
goto fail;
@@ -880,6 +891,7 @@ static const AVOption options[] = {
{ "segment_format","set container format used for the segments",
OFFSET(format), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E },
{ "segment_format_options", "set list of options for the container format
used for the segments", OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str =
NULL}, 0, 0, E },
{ "segment_list", "set the segment list filename",
OFFSET(list),AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E },
+{ "segment_header_filename", "write a single file containing the header",
OFFSET(header_filename), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E },
{ "segment_list_flags","set flags affecting segment list generation",
OFFSET(list_flags), AV_OPT_TYPE_FLAGS, {.i64 = SEGMENT_LIST_FLAG_CACHE }, 0,
UINT_MAX, E, "list_flags"},
{ "cache", "allow list caching",
0, AV_OPT_TYPE_CONST, {.i64 = SEGMENT_LIST_FLAG_CACHE }, INT_MIN, INT_MAX,
E, "list_flags"},
--
2.3.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] libavformat/segment: don't leave the list pb open when not in use
---
libavformat/segment.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index b65a2eb..06bc459 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -357,17 +357,17 @@ static int segment_end(AVFormatContext *s, int
write_trailer, int is_last)
av_freep(&entry);
}
-avio_closep(&seg->list_pb);
if ((ret = segment_list_open(s)) < 0)
goto end;
for (entry = seg->segment_list_entries; entry; entry = entry->next)
segment_list_print_entry(seg->list_pb, seg->list_type, entry,
s);
if (seg->list_type == LIST_TYPE_M3U8 && is_last)
avio_printf(seg->list_pb, "#EXT-X-ENDLIST\n");
+avio_closep(&seg->list_pb);
} else {
segment_list_print_entry(seg->list_pb, seg->list_type,
&seg->cur_entry, s);
+avio_flush(seg->list_pb);
}
-avio_flush(seg->list_pb);
}
av_log(s, AV_LOG_VERBOSE, "segment:'%s' count:%d ended\n",
@@ -635,8 +635,9 @@ static int seg_write_header(AVFormatContext *s)
else if (av_match_ext(seg->list, "ffcat,ffconcat")) seg->list_type
= LIST_TYPE_FFCONCAT;
else seg->list_type =
LIST_TYPE_FLAT;
}
-if ((ret = segment_list_open(s)) < 0)
-goto fail;
+if (!seg->list_size && seg->list_type != LIST_TYPE_M3U8)
+if ((ret = segment_list_open(s)) < 0)
+goto fail;
}
if (seg->list_type == LIST_TYPE_EXT)
av_log(s, AV_LOG_WARNING, "'ext' list type option is deprecated in
favor of 'csv'\n");
--
2.3.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] lavf/segment: Mark output contexts as non-seekable
This prevents sub-muxers from trying to seek back to the beginning of the
whole stream, only to find themselves overwriting some video data in the
current (often last) segment.
---
libavformat/segment.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 06bc459..b623bb6 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -236,6 +236,7 @@ static int segment_start(AVFormatContext *s, int
write_header)
av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n", oc->filename);
return err;
}
+oc->pb->seekable = 0;
if (oc->oformat->priv_class && oc->priv_data)
av_opt_set(oc->priv_data, "mpegts_flags", "+resend_headers", 0);
@@ -674,6 +675,7 @@ static int seg_write_header(AVFormatContext *s)
av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n",
oc->filename);
goto fail;
}
+oc->pb->seekable = 0;
} else {
if ((ret = open_null_ctx(&oc->pb)) < 0)
goto fail;
@@ -709,6 +711,7 @@ static int seg_write_header(AVFormatContext *s)
if ((ret = avio_open2(&oc->pb, oc->filename, AVIO_FLAG_WRITE,
&s->interrupt_callback, NULL)) < 0)
goto fail;
+oc->pb->seekable = 0;
}
fail:
--
2.3.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/hls: add an option to start from a given segment in a live stream
---
libavformat/hls.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index af890bd..4a7d003 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -165,6 +165,7 @@ struct variant {
};
typedef struct HLSContext {
+AVClass *class;
int n_variants;
struct variant **variants;
int n_playlists;
@@ -173,6 +174,7 @@ typedef struct HLSContext {
struct rendition **renditions;
int cur_seq_no;
+int live_start_index;
int first_packet;
int64_t first_timestamp;
int64_t cur_timestamp;
@@ -1237,10 +1239,12 @@ static int select_cur_seq_no(HLSContext *c, struct
playlist *pls)
* require us to download a segment to inspect its timestamps. */
return c->cur_seq_no;
-/* If this is a live stream with more than 3 segments, start at the
- * third last segment. */
-if (pls->n_segments > 3)
-return pls->start_seq_no + pls->n_segments - 3;
+/* If this is a live stream, start live_start_index segments from the
+ * start or end */
+if (c->live_start_index < 0)
+return pls->start_seq_no + FFMAX(pls->n_segments +
c->live_start_index, 0);
+else
+return pls->start_seq_no + FFMIN(c->live_start_index,
pls->n_segments - 1);
}
/* Otherwise just start on the first segment. */
@@ -1714,9 +1718,25 @@ static int hls_probe(AVProbeData *p)
return 0;
}
+#define OFFSET(x) offsetof(HLSContext, x)
+#define FLAGS AV_OPT_FLAG_DECODING_PARAM
+static const AVOption hls_options[] = {
+{"live_start_index", "segment index to start live streams at (negative
values are from the end)",
+OFFSET(live_start_index), FF_OPT_TYPE_INT, {.i64 = -3}, INT_MIN,
INT_MAX, FLAGS},
+{NULL}
+};
+
+static const AVClass hls_class = {
+.class_name = "hls,applehttp",
+.item_name = av_default_item_name,
+.option = hls_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
AVInputFormat ff_hls_demuxer = {
.name = "hls,applehttp",
.long_name = NULL_IF_CONFIG_SMALL("Apple HTTP Live Streaming"),
+.priv_class = &hls_class,
.priv_data_size = sizeof(HLSContext),
.read_probe = hls_probe,
.read_header= hls_read_header,
--
2.3.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] lavf: add directory listing API
On Fri, Mar 27, 2015 at 6:52 PM, Michael Niedermayer
wrote:
> On Thu, Mar 26, 2015 at 03:31:27PM +0100, Mariusz Szczepańczyk wrote:
> > On Thu, Mar 26, 2015 at 2:31 PM, Michael Niedermayer
> > wrote:
> >
> > > On Thu, Mar 26, 2015 at 01:25:17AM +0100, Mariusz Szczepańczyk wrote:
> > > > From: Lukasz Marek
> > > >
> > > > API allows protocol implementations to provide API that
> > > > allows to list directory content.
> > > > API is similar to POSIX opendir/readdir/closedir.
> > > > ---
> > > > libavformat/avio.c | 74
> +++
> > > > libavformat/avio.h | 84
> > > +-
> > > > libavformat/url.c | 16 +++
> > > > libavformat/url.h | 10 +++
> > > > 4 files changed, 183 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavformat/avio.c b/libavformat/avio.c
> > > > index 4896782..51419cc 100644
> > > > --- a/libavformat/avio.c
> > > > +++ b/libavformat/avio.c
> > > > @@ -23,6 +23,7 @@
> > > > #include "libavutil/dict.h"
> > > > #include "libavutil/opt.h"
> > > > #include "libavutil/time.h"
> > > > +#include "libavutil/avassert.h"
> > > > #include "os_support.h"
> > > > #include "avformat.h"
> > > > #if CONFIG_NETWORK
> > > > @@ -418,6 +419,79 @@ int avio_check(const char *url, int flags)
> > > > return ret;
> > > > }
> > > >
> > > > +int avio_open_dir(AVIODirContext **s, const char *url, AVDictionary
> > > **options)
> > > > +{
> > > > +URLContext *h = NULL;
> > > > +AVIODirContext *ctx = NULL;
> > > > +int ret;
> > > > +av_assert0(s);
> > > > +
> > > > +ctx = av_mallocz(sizeof(*ctx));
> > > > +if (!ctx) {
> > > > +ret = AVERROR(ENOMEM);
> > > > +goto fail;
> > > > +}
> > > > +
> > > > +if ((ret = ffurl_alloc(&h, url, AVIO_FLAG_READ, NULL)) < 0)
> > > > +goto fail;
> > > > +
> > > > +if (h->prot->url_open_dir && h->prot->url_read_dir &&
> > > h->prot->url_close_dir) {
> > > > +if (options && h->prot->priv_data_class &&
> > > > +(ret = av_opt_set_dict(h->priv_data, options)) < 0)
> > > > +goto fail;
> > > > +ret = h->prot->url_open_dir(h);
> > > > +} else
> > > > +ret = AVERROR(ENOSYS);
> > > > +if (ret < 0)
> > > > +goto fail;
> > > > +
> > > > +ctx->url_context = h;
> > > > +*s = ctx;
> > > > +return 0;
> > > > +
> > > > + fail:
> > > > +av_free(ctx);
> > > > +*s = NULL;
> > > > +ffurl_close(h);
> > > > +return ret;
> > > > +}
> > > > +
> > >
> > > > +int avio_read_dir(AVIODirContext *s, AVIODirEntry **next)
> > > > +{
> > > > +URLContext *h;
> > > > +int ret;
> > > > +
> > > > +if (!s || !s->url_context)
> > > > +return EINVAL;
> > >
> > > i assume this is intended to be AVERROR(EINVAL)
> > >
> >
> > Yes, of course! Fixed.
> >
> >
> > >
> > >
> > > > +h = s->url_context;
> > > > +if ((ret = h->prot->url_read_dir(h, next)) < 0)
> > > > +avio_free_directory_entry(next);
> > > > +return ret;
> > > > +}
> > > > +
> > > > +int avio_close_dir(AVIODirContext **s)
> > > > +{
> > > > +URLContext *h;
> > > > +
> > > > +av_assert0(s);
> > > > +if (!(*s) || !(*s)->url_context)
> > > > +return EINVAL;
> > >
> > > same as previous
> > >
> >
> > ditto
> >
> >
> > >
> > > [...]
> > >
> >
> >
> > Mariusz
>
> > avio.c | 74 +
> > avio.h | 84
> -
> > url.c | 16
> > url.h | 10 +++
> > 4 files changed, 183 insertions(+), 1 deletion(-)
> > 0289391026b4d7c3d698b7b47bd18045e9f14460
> 0001-lavf-add-directory-listing-API.patch
> > From 628fa295d2710da56ba672ac0cb8502cafc27f82 Mon Sep 17 00:00:00 2001
> > From: Lukasz Marek
> > Date: Sat, 5 Jul 2014 18:11:59 +0200
> > Subject: [PATCH 1/4] lavf: add directory listing API
> >
> > API allows protocol implementations to provide API that
> > allows to list directory content.
> > API is similar to POSIX opendir/readdir/closedir.
> > ---
> > libavformat/avio.c | 74 +++
> > libavformat/avio.h | 84
> +-
> > libavformat/url.c | 16 +++
> > libavformat/url.h | 10 +++
> > 4 files changed, 183 insertions(+), 1 deletion(-)
>
> theres no update to version.h and APIChanges but i think its
> actually good to wait with these a few days so if more comments
> come in we could still change the API
> but please add a patch that updates them
>
I'm attaching the patch but I'm not completely sure whether it's correct.
Please check it.
>
> applied this one
>
> thanks
>
>
Regards,
Mariusz
From 04da63e473b181d72dba909968ce28671ee5e5ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mariusz=20Szczepa=C5=84czyk?=
Date: Sun, 29 Mar 2015 00:54:46 +0100
Subject: [PATCH] lavf: Bump minor version and document directory l
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On 2015-03-29 00:32 +0100, Timo Rothenpieler wrote: > > Le nonidi 9 germinal, an CCXXIII, wm4 a écrit : > >> amovie1.zip, and then "/tmp/amovie1.zip//amovie.srt" is a perfectly > >> valid unix path. Multiple slashes are coalesced into 1. > > > > Just as you say it without realizing it, it is valid but useless. > > While it is useless, for example scripts frequently generate such paths. > Changing the behaviour on valid paths is a bad idea, however useless > they might seem. +1 Alexander pgp8MfGOUjZmv.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sun, 29 Mar 2015 00:20:53 +0100 Nicolas George wrote: > Le nonidi 9 germinal, an CCXXIII, wm4 a écrit : > > amovie1.zip, and then "/tmp/amovie1.zip//amovie.srt" is a perfectly > > valid unix path. Multiple slashes are coalesced into 1. > > Just as you say it without realizing it, it is valid but useless. Just because it's useless you can't randomly change its semantics. Or do you want API users being forced to "normalize" paths just so libavformat doesn't mess it up for them? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/http: Return an error in case of prematurely ending data
Fixes Ticket 4039
Signed-off-by: Michael Niedermayer
---
libavformat/http.c |8
1 file changed, 8 insertions(+)
diff --git a/libavformat/http.c b/libavformat/http.c
index da3c9be..a1d3763 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -907,6 +907,14 @@ static int http_buf_read(URLContext *h, uint8_t *buf, int
size)
s->filesize >= 0 && s->off >= s->filesize)
return AVERROR_EOF;
len = ffurl_read(s->hd, buf, size);
+if (!len && (!s->willclose || s->chunksize < 0) &&
+s->filesize >= 0 && s->off < s->filesize) {
+av_log(h, AV_LOG_ERROR,
+ "Streams ends prematurly at %"PRId64", should be
%"PRId64"\n",
+ s->off, s->filesize
+ );
+return AVERROR(EIO);
+}
}
if (len > 0) {
s->off += len;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
> Le nonidi 9 germinal, an CCXXIII, wm4 a écrit : >> amovie1.zip, and then "/tmp/amovie1.zip//amovie.srt" is a perfectly >> valid unix path. Multiple slashes are coalesced into 1. > > Just as you say it without realizing it, it is valid but useless. While it is useless, for example scripts frequently generate such paths. Changing the behaviour on valid paths is a bad idea, however useless they might seem. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavdevice/avfoundation: add framerate and video size options
Am 27.03.15 um 14:34 schrieb Matthieu Bouron: > On Sat, Mar 21, 2015 at 4:51 PM, Thilo Borgmann > wrote: > [...] >> +[video_device setValue:selected_format forKey:@"activeFormat"]; >> +[video_device setValue:min_frame_duration >> forKey:@"activeVideoMinFrameDuration"]; >> +[video_device setValue:min_frame_duration >> forKey:@"activeVideoMaxFrameDuration"]; >> ^^^ >> Should be max_frame_duration in the third line. >> IIRC there is functionality in the API to check if setting >> min/max_frame_duration is available for the device, isn't it? Please >> check, in >> case there it is not, there is an alternative way to set the framerate >> (IIRC). >> > > It is purely intentionnal to use the min_frame_duration for the > activeVideoMaxFrameDuration to acheive a better consistant framerate. > There is no way to check if the range is accepted by the device but as > stated by the documentation, applied range values that does not come from > ranges returned by the API will throw an exception. > There is an alternative way to set the framerate using > AVCaptureConnection.setVideo(Min|Max)FrameDuration but it has been > deprecated in iOS 7 and I do not intend to support it. I misunderstood your these lines. Patch ok, please apply. Thanks, Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] libavdevice/avfoundation: use pts/dts provided by the CMSampleBuffer API
Am 21.03.15 um 18:45 schrieb Thilo Borgmann:
> Am 18.03.15 um 09:37 schrieb Matthieu Bouron:
>> On Fri, Mar 13, 2015 at 8:16 PM, wrote:
>>
>>> From: Matthieu Bouron
>>>
>>> ---
>>> libavdevice/avfoundation.m | 21 +++--
>>> 1 file changed, 15 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
>>> index 8112229..5bcd6a4 100644
>>> --- a/libavdevice/avfoundation.m
>>> +++ b/libavdevice/avfoundation.m
>>> @@ -881,9 +881,14 @@ static int avf_read_packet(AVFormatContext *s,
>>> AVPacket *pkt)
>>> return AVERROR(EIO);
>>> }
>>>
>>> -pkt->pts = pkt->dts = av_rescale_q(av_gettime() -
>>> ctx->first_pts,
>>> - AV_TIME_BASE_Q,
>>> - avf_time_base_q);
>>> +CMItemCount count;
>>> +CMSampleTimingInfo timing_info;
>>> +
>>> +if
>>> (CMSampleBufferGetOutputSampleTimingInfoArray(ctx->current_frame, 1,
>>> &timing_info, &count) == noErr) {
>>> +AVRational timebase_q = av_make_q(1,
>>> timing_info.presentationTimeStamp.timescale);
>>> +pkt->pts = pkt->dts =
>>> av_rescale_q(timing_info.presentationTimeStamp.value, timebase_q,
>>> avf_time_base_q);
>>> +}
>>> +
>>> pkt->stream_index = ctx->video_stream_index;
>>> pkt->flags|= AV_PKT_FLAG_KEY;
>>>
>>> @@ -911,9 +916,13 @@ static int avf_read_packet(AVFormatContext *s,
>>> AVPacket *pkt)
>>> return AVERROR(EIO);
>>> }
>>>
>>> -pkt->pts = pkt->dts = av_rescale_q(av_gettime() -
>>> ctx->first_audio_pts,
>>> - AV_TIME_BASE_Q,
>>> - avf_time_base_q);
>>> +CMItemCount count;
>>> +CMSampleTimingInfo timing_info;
>>> +
>>> +if
>>> (CMSampleBufferGetOutputSampleTimingInfoArray(ctx->current_audio_frame, 1,
>>> &timing_info, &count) == noErr) {
>>> +AVRational timebase_q = av_make_q(1,
>>> timing_info.presentationTimeStamp.timescale);
>>> +pkt->pts = pkt->dts =
>>> av_rescale_q(timing_info.presentationTimeStamp.value, timebase_q,
>>> avf_time_base_q);
>>> +}
>>>
>>> pkt->stream_index = ctx->audio_stream_index;
>>> pkt->flags|= AV_PKT_FLAG_KEY;
>>> --
>>> 2.3.2
>>>
>>>
>> ping
>
> Ok if tested.
Please apply.
Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] libavdevice/avfoundation: add capture_screen_mouse_clicks option
Am 27.03.15 um 14:37 schrieb Matthieu Bouron: > On Sat, Mar 21, 2015 at 6:47 PM, Thilo Borgmann > wrote: > [...] > >> >> Please rename to "capture_mouse_clicks". >> > > Updated in attached patch. Ok, please apply. Thanks, Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] libavdevice/avfoundation: add capture_screen_cursor option
Am 27.03.15 um 14:36 schrieb Matthieu Bouron: > On Sat, Mar 21, 2015 at 5:35 PM, Thilo Borgmann > wrote: > [...] > >> I suggest to rename the option to "capture_cursor"... _screen_ in it seems >> to be >> redundant. >> > > Updated in attached patch. Ok, please apply. Thanks, Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
Le nonidi 9 germinal, an CCXXIII, wm4 a écrit : > amovie1.zip, and then "/tmp/amovie1.zip//amovie.srt" is a perfectly > valid unix path. Multiple slashes are coalesced into 1. Just as you say it without realizing it, it is valid but useless. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sun, 29 Mar 2015 01:12:32 +0200 Ivan Kalvachev wrote: > On 3/28/15, Peter Ross wrote: > > On Sat, Mar 28, 2015 at 10:24:55PM +0100, wm4 wrote: > >> On Sun, 29 Mar 2015 08:10:29 +1100 > >> Peter Ross wrote: > >> > >> > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > >> > > On 28.03.2015 20:13, Nicolas George wrote: > >> > > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > >> > > >>I will try to use this libarchive first and do some tests. Your > >> > > >> approach may > >> > > >>collapse in case compression libraries doesn't support parallel > >> > > >>compression/decompression (I mean that you write or read several > >> > > >> files from > >> > > >>single archive file) I would be much surprised if at least writing > >> > > >> will not > >> > > >>work. > >> > > > > >> > > >This is a likely issue, but fortunately it would not prevent all use > >> > > > cases. > >> > > > > >> > > >>I wonder if there is other solution: zip could be protocol as it is > >> > > >> now, it > >> > > >>allows to benefit from list API and gives flexibility other demuxers > >> > > >> to > >> > > >>benefit from it. There could also be a "directory" demuxer which > >> > > >> would also > >> > > >>use that API and possibly could serve streams in your way. That > >> > > >> demuxer > >> > > >>could also handle directories over any protocol that supports that > >> > > >> API. > >> > > > > >> > > >That was the kind of idea that I had. But I believe that to get that > >> > > > working > >> > > >a bit reliably, we will need to extend the directory listing > >> > > > callbacks to > >> > > >allow a URL context to create new URL contexts, to open remote files > >> > > > without > >> > > >establishing a new connection (and it will also be necessary for > >> > > > network > >> > > >servers). Some kind of VFS API, then. > >> > > >> > Agree. > >> > > >> > > This can be even harder as opening archive file require stat or other > >> > > smart > >> > > way to check some candidates that ought to be a archive file. See > >> > > below. > >> > > >> > > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > >> > > >>libzip can't handle it (the same way it cannot handle files via > >> > > >> protocols), > >> > > >>maybe libarchive will be better > >> > > > > >> > > >I think you misunderstood the question. I was not asking whether it > >> > > > would be > >> > > >able to decode nested files, but how your code did split nested > >> > > > paths: would > >> > > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or > >> > > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone > >> > > > was > >> > > >stupid enough to name a directory dot-zip)? > >> > > > >> > > I assumed it is local file (no other option so far). So I stat full > >> > > path > >> > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so > >> > > then I > >> > > opened it as zip file and used fallback to open first file. > >> > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so > >> > > on... > >> > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a > >> > > path > >> > > inside zip. > >> > > >> > walking the path means that the archive protocol must know about the > >> > syntax of the underlying protocol (file, http, ftp, etc.). that seems > >> > messy. > >> > also inefficient if you have got to walk a long ftp path. > >> > > >> > wouldn't we be better off defining a special character that seperates > >> > the zip > >> > path from the inner path. obviously we'd need some way of escaping the > >> > character > >> > if it is legitimately part of either path. > >> > > >> > ffplay /tmp/amovie.zip > >> > ffplay http://subtitles.org/amovie.zip#amovie.srt > >> > > >> > the syntax should support nested archives (even if the libzip/archive > >> > cannot handle > >> > that yet). e.g. > >> > > >> > ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt > >> > > >> > -- Peter > >> > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) > >> > >> No. '#' is perfectly allowed in URLs and local filenames. > > > > of course it is, hence my qualification above: > >>> obviously we'd need some way of escaping the character > > > > so if '##' reduces to '#', then: > > ffplay /tmp/amovie##1.zip#amovie##1.srt would open 'amovie#1.srt' inside > > '/tmp/amovie#1.zip' > > > > '#' was only given as an example. > > pick a character (or character sequence) that is easy to type, but > > infrequently used in > > uris/filenames, such to avoid having to escape to often. > > How about: > ffplay /tmp/amovie1.zip//amovie.srt > > Aka, using double directory separator to indicate diving into an archive. > This way "ffplay /tmp/amovie1.zip/amovie" would imply amovie1.zip is > directory. You forgot // in your second example? Anyway, you can name a directory amovie1.zip, and then "/tmp/amovie1.zip//amovie.srt" is a perfectly valid unix path. Multiple slashes are coalesced into 1. ___
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On 3/28/15, Peter Ross wrote: > On Sat, Mar 28, 2015 at 10:24:55PM +0100, wm4 wrote: >> On Sun, 29 Mar 2015 08:10:29 +1100 >> Peter Ross wrote: >> >> > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: >> > > On 28.03.2015 20:13, Nicolas George wrote: >> > > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : >> > > >>I will try to use this libarchive first and do some tests. Your >> > > >> approach may >> > > >>collapse in case compression libraries doesn't support parallel >> > > >>compression/decompression (I mean that you write or read several >> > > >> files from >> > > >>single archive file) I would be much surprised if at least writing >> > > >> will not >> > > >>work. >> > > > >> > > >This is a likely issue, but fortunately it would not prevent all use >> > > > cases. >> > > > >> > > >>I wonder if there is other solution: zip could be protocol as it is >> > > >> now, it >> > > >>allows to benefit from list API and gives flexibility other demuxers >> > > >> to >> > > >>benefit from it. There could also be a "directory" demuxer which >> > > >> would also >> > > >>use that API and possibly could serve streams in your way. That >> > > >> demuxer >> > > >>could also handle directories over any protocol that supports that >> > > >> API. >> > > > >> > > >That was the kind of idea that I had. But I believe that to get that >> > > > working >> > > >a bit reliably, we will need to extend the directory listing >> > > > callbacks to >> > > >allow a URL context to create new URL contexts, to open remote files >> > > > without >> > > >establishing a new connection (and it will also be necessary for >> > > > network >> > > >servers). Some kind of VFS API, then. >> > >> > Agree. >> > >> > > This can be even harder as opening archive file require stat or other >> > > smart >> > > way to check some candidates that ought to be a archive file. See >> > > below. >> > >> > > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin >> > > >>libzip can't handle it (the same way it cannot handle files via >> > > >> protocols), >> > > >>maybe libarchive will be better >> > > > >> > > >I think you misunderstood the question. I was not asking whether it >> > > > would be >> > > >able to decode nested files, but how your code did split nested >> > > > paths: would >> > > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or >> > > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone >> > > > was >> > > >stupid enough to name a directory dot-zip)? >> > > >> > > I assumed it is local file (no other option so far). So I stat full >> > > path >> > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so >> > > then I >> > > opened it as zip file and used fallback to open first file. >> > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so >> > > on... >> > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a >> > > path >> > > inside zip. >> > >> > walking the path means that the archive protocol must know about the >> > syntax of the underlying protocol (file, http, ftp, etc.). that seems >> > messy. >> > also inefficient if you have got to walk a long ftp path. >> > >> > wouldn't we be better off defining a special character that seperates >> > the zip >> > path from the inner path. obviously we'd need some way of escaping the >> > character >> > if it is legitimately part of either path. >> > >> > ffplay /tmp/amovie.zip >> > ffplay http://subtitles.org/amovie.zip#amovie.srt >> > >> > the syntax should support nested archives (even if the libzip/archive >> > cannot handle >> > that yet). e.g. >> > >> > ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt >> > >> > -- Peter >> > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) >> >> No. '#' is perfectly allowed in URLs and local filenames. > > of course it is, hence my qualification above: >>> obviously we'd need some way of escaping the character > > so if '##' reduces to '#', then: > ffplay /tmp/amovie##1.zip#amovie##1.srt would open 'amovie#1.srt' inside > '/tmp/amovie#1.zip' > > '#' was only given as an example. > pick a character (or character sequence) that is easy to type, but > infrequently used in > uris/filenames, such to avoid having to escape to often. How about: ffplay /tmp/amovie1.zip//amovie.srt Aka, using double directory separator to indicate diving into an archive. This way "ffplay /tmp/amovie1.zip/amovie" would imply amovie1.zip is directory. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add "split" mode to tinterlace filter.
From: Brian Matherly
This mode is the opposite of the "merge" mode.
---
This patch adds a new mode to tinterlace which performs the opposite operation
as the "merge" mode.
My primary motivation is that I have been working with Derek Buitenhuis to see
about adding interlace support to the libx265 encoder. It turns out that this is
a complex situation since libx265 requires each field to be encoded separately
but ffmpeg stores fields together as an interlaced frame. tinterlace can be used
with this new mode to provide each field as a separate frame to libx265 - and
therefore perform valid interlaced h.265 encoding.
At first I considered this patch a hack and planned on keeping it to myself. But
now I think that it must be generally useful since it can produce the exact
format of data that would be the input to the tinterlace "merge" mode.
As a test, I have checked:
ffmpeg -i input.file -vf "tinterlace=split,tinterlace=merge" output.file
And the image makes a successful round trip.
doc/filters.texi| 24
libavfilter/tinterlace.h| 1 +
libavfilter/vf_tinterlace.c | 43 +--
3 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 15f8ed5..9b3fd02 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9197,6 +9197,30 @@ Output:
1 1 2 2 3 3 4
@end example
+@item split, 7
+Perform the inverse operation as merge. Move upper field to odd frames, lower
+field to even frames, generating a half height frame at double frame rate.
+@example
+ --> time
+Input:
+Frame 1 Frame 2
+1 3
+2 4
+1 3
+2 4
+1 3
+2 4
+1 3
+2 4
+
+Output:
+Frame 1 Frame 2 Frame 3 Frame 4
+1 2 3 4
+1 2 3 4
+1 2 3 4
+1 2 3 4
+@end example
+
@end table
diff --git a/libavfilter/tinterlace.h b/libavfilter/tinterlace.h
index fa0a83a..ece8ce4 100644
--- a/libavfilter/tinterlace.h
+++ b/libavfilter/tinterlace.h
@@ -38,6 +38,7 @@ enum TInterlaceMode {
MODE_INTERLEAVE_TOP,
MODE_INTERLEAVE_BOTTOM,
MODE_INTERLACEX2,
+MODE_SPLIT,
MODE_NB,
};
diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
index f3411f9..2c9047b 100644
--- a/libavfilter/vf_tinterlace.c
+++ b/libavfilter/vf_tinterlace.c
@@ -46,6 +46,7 @@ static const AVOption tinterlace_options[] = {
{"interleave_top","interleave top and bottom fields", 0,
AV_OPT_TYPE_CONST, {.i64=MODE_INTERLEAVE_TOP},INT_MIN, INT_MAX, FLAGS,
"mode"},
{"interleave_bottom", "interleave bottom and top fields", 0,
AV_OPT_TYPE_CONST, {.i64=MODE_INTERLEAVE_BOTTOM}, INT_MIN, INT_MAX, FLAGS,
"mode"},
{"interlacex2", "interlace fields from two consecutive frames", 0,
AV_OPT_TYPE_CONST, {.i64=MODE_INTERLACEX2}, INT_MIN, INT_MAX, FLAGS,
"mode"},
+{"split", "split fields", 0,
AV_OPT_TYPE_CONST, {.i64=MODE_SPLIT}, INT_MIN, INT_MAX, FLAGS,
"mode"},
{"flags", "set flags", OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64
= 0}, 0, INT_MAX, 0, "flags" },
{"low_pass_filter", "enable vertical low-pass filter", 0,
AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_VLPF}, INT_MIN, INT_MAX, FLAGS,
"flags" },
@@ -118,7 +119,8 @@ static int config_out_props(AVFilterLink *outlink)
outlink->flags |= FF_LINK_FLAG_REQUEST_LOOP;
outlink->w = inlink->w;
outlink->h = tinterlace->mode == MODE_MERGE || tinterlace->mode ==
MODE_PAD ?
-inlink->h*2 : inlink->h;
+inlink->h*2 : tinterlace->mode == MODE_SPLIT ?
+inlink->h/2 : inlink->h;
if (tinterlace->mode == MODE_PAD) {
uint8_t black[4] = { 16, 128, 128, 16 };
@@ -145,7 +147,7 @@ static int config_out_props(AVFilterLink *outlink)
tinterlace->flags &= ~TINTERLACE_FLAG_VLPF;
}
tinterlace->preout_time_base = inlink->time_base;
-if (tinterlace->mode == MODE_INTERLACEX2) {
+if (tinterlace->mode == MODE_INTERLACEX2 || tinterlace->mode ==
MODE_SPLIT) {
tinterlace->preout_time_base.den *= 2;
outlink->frame_rate = av_mul_q(inlink->frame_rate, (AVRational){2,1});
outlink->time_base = av_mul_q(inlink->time_base , (AVRational){1,2});
@@ -372,6 +374,43 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*picref)
tff ? FIELD_UPPER : FIELD_LOWER, 1, tff ?
FIELD_UPPER : FIELD_LOWER,
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
W dniu sobota, 28 marca 2015 Peter Ross napisał(a): > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > > I assumed it is local file (no other option so far). So I stat full path > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so then > I > > opened it as zip file and used fallback to open first file. > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so > on... > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a path > > inside zip. > > walking the path means that the archive protocol must know about the > syntax of the underlying protocol (file, http, ftp, etc.). that seems > messy. > also inefficient if you have got to walk a long ftp path. I think filesystem looks the same on every server, no matter it is http, ftp or any other server. wouldn't we be better off defining a special character that seperates the > zip > path from the inner path. obviously we'd need some way of escaping the > character > if it is legitimately part of either path. In real life you might assume that archive has extension zip, rar, 7z,... and try to open according to it in first try, if user has archive with "ass" extension in directory called "data.zip" then they have to wait. i really would avoid to escape anything. this is just annoying. i remember i used to escape urls with so many ifs, if file then dont escape, if http then escape, and so on. handling archives with its own escapes is kinda stupid. it would be easier just to add an option to pass inner file. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sun, 29 Mar 2015 08:55:42 +1100 Peter Ross wrote: > On Sat, Mar 28, 2015 at 10:24:55PM +0100, wm4 wrote: > > On Sun, 29 Mar 2015 08:10:29 +1100 > > Peter Ross wrote: > > > > > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > > > > On 28.03.2015 20:13, Nicolas George wrote: > > > > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > > > > >>I will try to use this libarchive first and do some tests. Your > > > > >>approach may > > > > >>collapse in case compression libraries doesn't support parallel > > > > >>compression/decompression (I mean that you write or read several > > > > >>files from > > > > >>single archive file) I would be much surprised if at least writing > > > > >>will not > > > > >>work. > > > > > > > > > >This is a likely issue, but fortunately it would not prevent all use > > > > >cases. > > > > > > > > > >>I wonder if there is other solution: zip could be protocol as it is > > > > >>now, it > > > > >>allows to benefit from list API and gives flexibility other demuxers > > > > >>to > > > > >>benefit from it. There could also be a "directory" demuxer which > > > > >>would also > > > > >>use that API and possibly could serve streams in your way. That > > > > >>demuxer > > > > >>could also handle directories over any protocol that supports that > > > > >>API. > > > > > > > > > >That was the kind of idea that I had. But I believe that to get that > > > > >working > > > > >a bit reliably, we will need to extend the directory listing callbacks > > > > >to > > > > >allow a URL context to create new URL contexts, to open remote files > > > > >without > > > > >establishing a new connection (and it will also be necessary for > > > > >network > > > > >servers). Some kind of VFS API, then. > > > > > > Agree. > > > > > > > This can be even harder as opening archive file require stat or other > > > > smart > > > > way to check some candidates that ought to be a archive file. See below. > > > > > > > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > > > > >>libzip can't handle it (the same way it cannot handle files via > > > > >>protocols), > > > > >>maybe libarchive will be better > > > > > > > > > >I think you misunderstood the question. I was not asking whether it > > > > >would be > > > > >able to decode nested files, but how your code did split nested paths: > > > > >would > > > > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or > > > > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was > > > > >stupid enough to name a directory dot-zip)? > > > > > > > > I assumed it is local file (no other option so far). So I stat full path > > > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so > > > > then I > > > > opened it as zip file and used fallback to open first file. > > > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so > > > > on... > > > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a > > > > path > > > > inside zip. > > > > > > walking the path means that the archive protocol must know about the > > > syntax of the underlying protocol (file, http, ftp, etc.). that seems > > > messy. > > > also inefficient if you have got to walk a long ftp path. > > > > > > wouldn't we be better off defining a special character that seperates the > > > zip > > > path from the inner path. obviously we'd need some way of escaping the > > > character > > > if it is legitimately part of either path. > > > > > > ffplay /tmp/amovie.zip > > > ffplay http://subtitles.org/amovie.zip#amovie.srt > > > > > > the syntax should support nested archives (even if the libzip/archive > > > cannot handle > > > that yet). e.g. > > > > > > ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt > > > > > > -- Peter > > > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) > > > > No. '#' is perfectly allowed in URLs and local filenames. > > of course it is, hence my qualification above: > >> obviously we'd need some way of escaping the character > > so if '##' reduces to '#', then: > ffplay /tmp/amovie##1.zip#amovie##1.srt would open 'amovie#1.srt' inside > '/tmp/amovie#1.zip' > > '#' was only given as an example. > pick a character (or character sequence) that is easy to type, but > infrequently used in > uris/filenames, such to avoid having to escape to often. > > -- Peter > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) There's no such character - you can _always_ clash with unix filenames. The only way to disambiguate this is using a protocol prefix. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sat, Mar 28, 2015 at 10:24:55PM +0100, wm4 wrote: > On Sun, 29 Mar 2015 08:10:29 +1100 > Peter Ross wrote: > > > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > > > On 28.03.2015 20:13, Nicolas George wrote: > > > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > > > >>I will try to use this libarchive first and do some tests. Your > > > >>approach may > > > >>collapse in case compression libraries doesn't support parallel > > > >>compression/decompression (I mean that you write or read several files > > > >>from > > > >>single archive file) I would be much surprised if at least writing will > > > >>not > > > >>work. > > > > > > > >This is a likely issue, but fortunately it would not prevent all use > > > >cases. > > > > > > > >>I wonder if there is other solution: zip could be protocol as it is > > > >>now, it > > > >>allows to benefit from list API and gives flexibility other demuxers to > > > >>benefit from it. There could also be a "directory" demuxer which would > > > >>also > > > >>use that API and possibly could serve streams in your way. That demuxer > > > >>could also handle directories over any protocol that supports that API. > > > > > > > >That was the kind of idea that I had. But I believe that to get that > > > >working > > > >a bit reliably, we will need to extend the directory listing callbacks to > > > >allow a URL context to create new URL contexts, to open remote files > > > >without > > > >establishing a new connection (and it will also be necessary for network > > > >servers). Some kind of VFS API, then. > > > > Agree. > > > > > This can be even harder as opening archive file require stat or other > > > smart > > > way to check some candidates that ought to be a archive file. See below. > > > > > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > > > >>libzip can't handle it (the same way it cannot handle files via > > > >>protocols), > > > >>maybe libarchive will be better > > > > > > > >I think you misunderstood the question. I was not asking whether it > > > >would be > > > >able to decode nested files, but how your code did split nested paths: > > > >would > > > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or > > > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was > > > >stupid enough to name a directory dot-zip)? > > > > > > I assumed it is local file (no other option so far). So I stat full path > > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so then I > > > opened it as zip file and used fallback to open first file. > > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so on... > > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a path > > > inside zip. > > > > walking the path means that the archive protocol must know about the > > syntax of the underlying protocol (file, http, ftp, etc.). that seems messy. > > also inefficient if you have got to walk a long ftp path. > > > > wouldn't we be better off defining a special character that seperates the > > zip > > path from the inner path. obviously we'd need some way of escaping the > > character > > if it is legitimately part of either path. > > > > ffplay /tmp/amovie.zip > > ffplay http://subtitles.org/amovie.zip#amovie.srt > > > > the syntax should support nested archives (even if the libzip/archive > > cannot handle > > that yet). e.g. > > > > ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt > > > > -- Peter > > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) > > No. '#' is perfectly allowed in URLs and local filenames. of course it is, hence my qualification above: >> obviously we'd need some way of escaping the character so if '##' reduces to '#', then: ffplay /tmp/amovie##1.zip#amovie##1.srt would open 'amovie#1.srt' inside '/tmp/amovie#1.zip' '#' was only given as an example. pick a character (or character sequence) that is easy to type, but infrequently used in uris/filenames, such to avoid having to escape to often. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: Do not overwrite output if there is no input
On Sat, Mar 28, 2015 at 11:03:22AM +0100, Nicolas George wrote: > Le septidi 7 germinal, an CCXXIII, Michael Niedermayer a écrit : > > yes, theres a test that does this in fate > > Oh, I realize I did not look at your patch closely enough. Sorry. No > objection from me. ok patch applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] png: Clearly separate init, encoding headers and encoding frame
On Sat, Mar 28, 2015 at 03:14:23PM +, Donny Yang wrote: > Signed-off-by: Donny Yang [...] > -enc_row_size= deflateBound(&s->zstream, row_size); > -max_packet_size = avctx->height * (int64_t)(enc_row_size + > - ((enc_row_size + IOBUF_SIZE - 1) / > IOBUF_SIZE) * 12) > - + FF_MIN_BUFFER_SIZE; > -if (max_packet_size > INT_MAX) > -return AVERROR(ENOMEM); > -if ((ret = ff_alloc_packet2(avctx, pkt, max_packet_size)) < 0) > -return ret; [...] > +size_t max_packet_size; > + > +enc_row_size = deflateBound(&s->zstream, (avctx->width * > s->bits_per_pixel + 7) >> 3); > +max_packet_size = > +8 + // PNGSIG > +13 + 12 + // IHDR > +9 + 12 +// pHYs > +1 + 12 +// sRGB > +32 + 12 + // cHRM > +4 + 12 +// gAMA > +256 * 3 + 12 + // PLTE > +256 + 12 + // tRNS > +avctx->height * ( > +enc_row_size + > +12 * ((enc_row_size + IOBUF_SIZE - 1) / IOBUF_SIZE) // 12 * > ceil(enc_row_size / IOBUF_SIZE) > +); > + > +ret = ff_alloc_packet2(avctx, pkt, max_packet_size < FF_MIN_BUFFER_SIZE > ? FF_MIN_BUFFER_SIZE : max_packet_size); changes to how the packet size is calculated should be in a seperate patch also all other functional changes should be seperate from a patch that primarely moves code between init/header and frame encode [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] avformat/img2: Change enum to int, which is accessed via AVOption as int
This fixes depending on implementation defined behavior
Signed-off-by: Michael Niedermayer
---
libavformat/img2.h |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/img2.h b/libavformat/img2.h
index 67bd7a3..e4bcb26 100644
--- a/libavformat/img2.h
+++ b/libavformat/img2.h
@@ -30,6 +30,12 @@
#include
#endif
+enum PatternType {
+PT_GLOB_SEQUENCE,
+PT_GLOB,
+PT_SEQUENCE
+};
+
typedef struct VideoDemuxData {
const AVClass *class; /**< Class for private options. */
int img_first;
@@ -44,7 +50,7 @@ typedef struct VideoDemuxData {
int width, height; /**< Set by a private option. */
AVRational framerate; /**< Set by a private option. */
int loop;
-enum { PT_GLOB_SEQUENCE, PT_GLOB, PT_SEQUENCE } pattern_type;
+int pattern_type; /**< PatternType */
int use_glob;
#if HAVE_GLOB
glob_t globstate;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avformat/wavenc: Change enum to int, which is accessed via AVOption as int
This fixes depending on implementation defined behavior
Signed-off-by: Michael Niedermayer
---
libavformat/wavenc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index 2345fc5..0333622 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -82,7 +82,7 @@ typedef struct WAVMuxContext {
int write_peak;
int rf64;
int peak_block_size;
-PeakFormat peak_format;
+int peak_format;
int peak_block_pos;
int peak_ppv;
int peak_bps;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avfilter/vf_transpose: Change enums to int, which are accessed via AVOption as int
This fixes depending on implementation defined behavior
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_transpose.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_transpose.c b/libavfilter/vf_transpose.c
index d9b165c..dd570e6 100644
--- a/libavfilter/vf_transpose.c
+++ b/libavfilter/vf_transpose.c
@@ -56,8 +56,8 @@ typedef struct TransContext {
int hsub, vsub;
int pixsteps[4];
-PassthroughType passthrough; ///< landscape passthrough mode enabled
-enum TransposeDir dir;
+int passthrough;///< PassthroughType, landscape passthrough mode
enabled
+int dir;///< TransposeDir
} TransContext;
static int query_formats(AVFilterContext *ctx)
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] avfilter/tinterlace: Change enum to int, which is accessed via AVOption as int
This fixes depending on implementation defined behavior
Signed-off-by: Michael Niedermayer
---
libavfilter/tinterlace.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/tinterlace.h b/libavfilter/tinterlace.h
index fa0a83a..d80a6e2 100644
--- a/libavfilter/tinterlace.h
+++ b/libavfilter/tinterlace.h
@@ -43,7 +43,7 @@ enum TInterlaceMode {
typedef struct {
const AVClass *class;
-enum TInterlaceMode mode; ///< interlace mode selected
+int mode; ///< TInterlaceMode, interlace mode selected
AVRational preout_time_base;
int flags; ///< flags affecting interlacing algorithm
int frame; ///< number of the output frame
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sun, 29 Mar 2015 08:10:29 +1100 Peter Ross wrote: > On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > > On 28.03.2015 20:13, Nicolas George wrote: > > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > > >>I will try to use this libarchive first and do some tests. Your approach > > >>may > > >>collapse in case compression libraries doesn't support parallel > > >>compression/decompression (I mean that you write or read several files > > >>from > > >>single archive file) I would be much surprised if at least writing will > > >>not > > >>work. > > > > > >This is a likely issue, but fortunately it would not prevent all use cases. > > > > > >>I wonder if there is other solution: zip could be protocol as it is now, > > >>it > > >>allows to benefit from list API and gives flexibility other demuxers to > > >>benefit from it. There could also be a "directory" demuxer which would > > >>also > > >>use that API and possibly could serve streams in your way. That demuxer > > >>could also handle directories over any protocol that supports that API. > > > > > >That was the kind of idea that I had. But I believe that to get that > > >working > > >a bit reliably, we will need to extend the directory listing callbacks to > > >allow a URL context to create new URL contexts, to open remote files > > >without > > >establishing a new connection (and it will also be necessary for network > > >servers). Some kind of VFS API, then. > > Agree. > > > This can be even harder as opening archive file require stat or other smart > > way to check some candidates that ought to be a archive file. See below. > > > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > > >>libzip can't handle it (the same way it cannot handle files via > > >>protocols), > > >>maybe libarchive will be better > > > > > >I think you misunderstood the question. I was not asking whether it would > > >be > > >able to decode nested files, but how your code did split nested paths: > > >would > > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or > > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was > > >stupid enough to name a directory dot-zip)? > > > > I assumed it is local file (no other option so far). So I stat full path > > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so then I > > opened it as zip file and used fallback to open first file. > > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so on... > > /tmp/outer.zip is a file so I open it and treat rest of the uri as a path > > inside zip. > > walking the path means that the archive protocol must know about the > syntax of the underlying protocol (file, http, ftp, etc.). that seems messy. > also inefficient if you have got to walk a long ftp path. > > wouldn't we be better off defining a special character that seperates the zip > path from the inner path. obviously we'd need some way of escaping the > character > if it is legitimately part of either path. > > ffplay /tmp/amovie.zip > ffplay http://subtitles.org/amovie.zip#amovie.srt > > the syntax should support nested archives (even if the libzip/archive cannot > handle > that yet). e.g. > > ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt > > -- Peter > (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) No. '#' is perfectly allowed in URLs and local filenames. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On Sat, Mar 28, 2015 at 08:38:40PM +0100, Lukasz Marek wrote: > On 28.03.2015 20:13, Nicolas George wrote: > >L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > >>I will try to use this libarchive first and do some tests. Your approach may > >>collapse in case compression libraries doesn't support parallel > >>compression/decompression (I mean that you write or read several files from > >>single archive file) I would be much surprised if at least writing will not > >>work. > > > >This is a likely issue, but fortunately it would not prevent all use cases. > > > >>I wonder if there is other solution: zip could be protocol as it is now, it > >>allows to benefit from list API and gives flexibility other demuxers to > >>benefit from it. There could also be a "directory" demuxer which would also > >>use that API and possibly could serve streams in your way. That demuxer > >>could also handle directories over any protocol that supports that API. > > > >That was the kind of idea that I had. But I believe that to get that working > >a bit reliably, we will need to extend the directory listing callbacks to > >allow a URL context to create new URL contexts, to open remote files without > >establishing a new connection (and it will also be necessary for network > >servers). Some kind of VFS API, then. Agree. > This can be even harder as opening archive file require stat or other smart > way to check some candidates that ought to be a archive file. See below. > >>>ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > >>libzip can't handle it (the same way it cannot handle files via protocols), > >>maybe libarchive will be better > > > >I think you misunderstood the question. I was not asking whether it would be > >able to decode nested files, but how your code did split nested paths: would > >it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or > >/tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was > >stupid enough to name a directory dot-zip)? > > I assumed it is local file (no other option so far). So I stat full path > (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so then I > opened it as zip file and used fallback to open first file. > If not then I stat by path components: /tmp/, /tmp/outer.zip, and so on... > /tmp/outer.zip is a file so I open it and treat rest of the uri as a path > inside zip. walking the path means that the archive protocol must know about the syntax of the underlying protocol (file, http, ftp, etc.). that seems messy. also inefficient if you have got to walk a long ftp path. wouldn't we be better off defining a special character that seperates the zip path from the inner path. obviously we'd need some way of escaping the character if it is legitimately part of either path. ffplay /tmp/amovie.zip ffplay http://subtitles.org/amovie.zip#amovie.srt the syntax should support nested archives (even if the libzip/archive cannot handle that yet). e.g. ffplay /tmp/amovie.rar#/tmp/amovie.zip#amovie.srt -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add an ignore_delay option to the gif demuxer
On Sat, Mar 28, 2015 at 05:54:49PM +, Carl Eugen Hoyos wrote: > Michael Niedermayer gmx.at> writes: > > > was this the intent of the creator of the sample file we have ? > > i mean that the frames display more then 10 minutes > > There is no indication that anything else was intended. > To the best of my knowledge, the file is not invalid > (and there is no bug except that our mov muxer has > deficiencies which are unrelated to gif). if the goal is to transcode this file while maintaining the huge frame delay then "-vsync vfr" could be used otoh if you really want to limit the max delay the patch sure is ok i thought the file was not supposed to have such huge delays [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On 28.03.2015 20:13, Nicolas George wrote: L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : I will try to use this libarchive first and do some tests. Your approach may collapse in case compression libraries doesn't support parallel compression/decompression (I mean that you write or read several files from single archive file) I would be much surprised if at least writing will not work. This is a likely issue, but fortunately it would not prevent all use cases. I wonder if there is other solution: zip could be protocol as it is now, it allows to benefit from list API and gives flexibility other demuxers to benefit from it. There could also be a "directory" demuxer which would also use that API and possibly could serve streams in your way. That demuxer could also handle directories over any protocol that supports that API. That was the kind of idea that I had. But I believe that to get that working a bit reliably, we will need to extend the directory listing callbacks to allow a URL context to create new URL contexts, to open remote files without establishing a new connection (and it will also be necessary for network servers). Some kind of VFS API, then. This can be even harder as opening archive file require stat or other smart way to check some candidates that ought to be a archive file. See below. ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin libzip can't handle it (the same way it cannot handle files via protocols), maybe libarchive will be better I think you misunderstood the question. I was not asking whether it would be able to decode nested files, but how your code did split nested paths: would it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or /tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was stupid enough to name a directory dot-zip)? I assumed it is local file (no other option so far). So I stat full path (/tmp/outer.zip/tmp/inner.zip/tmp/data.bin) for being a file, if so then I opened it as zip file and used fallback to open first file. If not then I stat by path components: /tmp/, /tmp/outer.zip, and so on... /tmp/outer.zip is a file so I open it and treat rest of the uri as a path inside zip. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
L'octidi 8 germinal, an CCXXIII, Lukasz Marek a écrit : > I will try to use this libarchive first and do some tests. Your approach may > collapse in case compression libraries doesn't support parallel > compression/decompression (I mean that you write or read several files from > single archive file) I would be much surprised if at least writing will not > work. This is a likely issue, but fortunately it would not prevent all use cases. > I wonder if there is other solution: zip could be protocol as it is now, it > allows to benefit from list API and gives flexibility other demuxers to > benefit from it. There could also be a "directory" demuxer which would also > use that API and possibly could serve streams in your way. That demuxer > could also handle directories over any protocol that supports that API. That was the kind of idea that I had. But I believe that to get that working a bit reliably, we will need to extend the directory listing callbacks to allow a URL context to create new URL contexts, to open remote files without establishing a new connection (and it will also be necessary for network servers). Some kind of VFS API, then. > >ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin > libzip can't handle it (the same way it cannot handle files via protocols), > maybe libarchive will be better I think you misunderstood the question. I was not asking whether it would be able to decode nested files, but how your code did split nested paths: would it try to find /tmp/inner.zip/tmp/data.bin inside /tmp/outer.zip, or /tmp/data.bin inside /tmp/outer.zip/tmp/inner.zip (assuming someone was stupid enough to name a directory dot-zip)? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tiff: Return more meaningful error codes
L'octidi 8 germinal, an CCXXIII, Carl Eugen Hoyos a écrit : > -1 seems more correct to me. -1 is never correct. On Linux (and apparently BSD too), -1 is AVERROR(EPERM), definitely not what you want. One libav guy suggested AVERROR_UNKNOWN; in FFmpeg we have AVERROR_EXTERNAL "Generic error in an external library". libz has a small list of error codes that can be mapped in a helper function: #define Z_STREAM_END1 -> is this an error? #define Z_NEED_DICT 2 -> is this an error? #define Z_ERRNO(-1) -> AVERROR(errno) #define Z_STREAM_ERROR (-2) -> AVERROR_INVALIDDATA? #define Z_DATA_ERROR (-3) -> AVERROR_INVALIDDATA? #define Z_MEM_ERROR(-4) -> AVERROR(ENOMEM)? #define Z_BUF_ERROR(-5) -> AVERROR_BUFFER_TOO_SMALL? #define Z_VERSION_ERROR (-6) -> AVERROR_BUG? > Can this be reached? > If yes, please print an error, if not, replace the > return with an assert. I second that. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
On 28.03.2015 11:53, Nicolas George wrote: Le septidi 7 germinal, an CCXXIII, Lukasz Marek a écrit : But, this time I dont understand you comments, could you elaborate it? What's wrong, what can I do? What I am saying is that there are a lot of different cases where we want to read archives (not only zip, see my previous mail, but that does not matter for now) on the fly with FFmpeg, and I am not sure your proposal is convenient for all these use cases. You implement it as a protocol, to access a single file in the archive. If it was gzip, that would be fine, because it is a stream compression format. In fact, I now realize we should have stackable protocols for all common stream compression tools. But a zip file is not just a compressed stream: it contains structure, several files. In FFmpeg architecture, that may map better to a demuxer: each file as a stream or as an attachment. This is yet another case where the distinction between protocols and formats is not entirely clear. If you think about it, an input protocol is just a demuxer that outputs a single stream of AVMEDIA_TYPE_DATA packets. Of course, for "normal" protocols and formats, like reading a Matroska file from a plain file, the separation makes sense. But with more complex and tied-in protocols and formats, it makes things actually harder. See the RTP issues for example. I have not yet looked closely enough at it, but I suspect the directory listing API that you have just landed may start a bridge between the two: a protocol may no longer be just an API for accessing a single stream but a whole filesystem. Then we can have demuxers that use it. I suppose one of the most pressing tasks would be to have the image2 demuxer use the directory listing API, is it not? I know that line between protocol and format is very thin. I will try to use this libarchive first and do some tests. Your approach may collapse in case compression libraries doesn't support parallel compression/decompression (I mean that you write or read several files from single archive file) I would be much surprised if at least writing will not work. But I will test it, there is no point in guessing here. Of course making it protocol doesn't solve that potential issue, but it may be less confusing for the user. I wonder if there is other solution: zip could be protocol as it is now, it allows to benefit from list API and gives flexibility other demuxers to benefit from it. There could also be a "directory" demuxer which would also use that API and possibly could serve streams in your way. That demuxer could also handle directories over any protocol that supports that API. Personally I don't favor any of the approaches, but if I had to decide then probably a protocol. So my actual proposal about this patch is: keep it near at hand, but not apply it; rather, use it as a work case to see the most we can do with new APIs. (Well, I do not oppose actually applying it. But if so, let us make us very clear that this is something really experimental. Not experimental "it probably works poorly" but experimental "we may change it completely tomorrow because we had another idea, we will not bother AT ALL with compatibility for now".) I have no pressure to merge asap. At least this libarchive is worth to try. I think you misunderstood this. There is no doc, but reading files by index is a fallback when user doesn't specify file explicitly. For example: Thanks for correcting me, I really missed that. ./ffplay zip://zipfile.zip/aaa.avi Ok, but that leads me to another question: what does this do: ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin libzip can't handle it (the same way it cannot handle files via protocols), maybe libarchive will be better ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tiff: Return more meaningful error codes
Himangi Saraogi gmail.com> writes:
> if (compress(dst, &zlen, src, n) != Z_OK) {
> av_log(s->avctx, AV_LOG_ERROR, "Compressing failed\n");
> -return -1;
> +return AVERROR_INVALIDDATA;
-1 seems more correct to me.
> case TIFF_LZW:
> return ff_lzw_encode(s->lzws, src, n);
> default:
> -return -1;
> +return AVERROR_UNKNOWN;
Can this be reached?
If yes, please print an error, if not, replace the
return with an assert.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add an ignore_delay option to the gif demuxer
Michael Niedermayer gmx.at> writes: > was this the intent of the creator of the sample file we have ? > i mean that the frames display more then 10 minutes There is no indication that anything else was intended. To the best of my knowledge, the file is not invalid (and there is no bug except that our mov muxer has deficiencies which are unrelated to gif). Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tiff: Return more meaningful error codes
---
libavcodec/tiffenc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/tiffenc.c b/libavcodec/tiffenc.c
index 44cd956..fc9b78e 100644
--- a/libavcodec/tiffenc.c
+++ b/libavcodec/tiffenc.c
@@ -164,7 +164,8 @@ static int add_entry1(TiffEncoderContext *s,
* @param dst output buffer
* @param n size of input buffer
* @param compr compression method
- * @return number of output bytes. If an output error is encountered, -1 is
returned
+ * @return number of output bytes. If an output error is encountered, a
negative
+ * value corresponding to an AVERROR error code is returned.
*/
static int encode_strip(TiffEncoderContext *s, const int8_t *src,
uint8_t *dst, int n, int compr)
@@ -177,14 +178,14 @@ static int encode_strip(TiffEncoderContext *s, const
int8_t *src,
unsigned long zlen = s->buf_size - (*s->buf - s->buf_start);
if (compress(dst, &zlen, src, n) != Z_OK) {
av_log(s->avctx, AV_LOG_ERROR, "Compressing failed\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
return zlen;
}
#endif
case TIFF_RAW:
if (check_size(s, n))
-return -1;
+return AVERROR(EINVAL);
memcpy(dst, src, n);
return n;
case TIFF_PACKBITS:
@@ -193,7 +194,7 @@ static int encode_strip(TiffEncoderContext *s, const int8_t
*src,
case TIFF_LZW:
return ff_lzw_encode(s->lzws, src, n);
default:
-return -1;
+return AVERROR_UNKNOWN;
}
}
@@ -304,7 +305,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
default:
av_log(s->avctx, AV_LOG_ERROR,
"This colors format is not supported\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
for (i = 0; i < s->bpp_tab_size; i++)
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add an ignore_delay option to the gif demuxer
On Sat, Mar 28, 2015 at 05:47:52PM +0100, Carl Eugen Hoyos wrote: > On Friday 27 March 2015 02:45:22 pm Michael Niedermayer wrote: > > On Fri, Mar 27, 2015 at 08:07:23AM +, Carl Eugen Hoyos wrote: > > > Michael Niedermayer gmx.at> writes: > > > > On Fri, Mar 27, 2015 at 12:21:00AM +, Carl Eugen Hoyos wrote: > > > > > Michael Niedermayer gmx.at> writes: > > > > > > iam not sure the default of 6 seconds is safe > > > > > > > > > > What would be a sensible default max_delay? > > > > > > > > for this file simply considering 0x as 0 would work > > > > and would so i think only replacing that would be the > > > > least change needed > > > > > > I did not find any specification that suggests to do this > > > (but many pages were 0x is explicitely mentioned as > > > allowing for maximum delay). > > > > one could add a option like max_delay which is then used in place > > of 0x, conforming to the spec if taken litterally > > I attached a new version of the patch that does not change the > current behaviour but gives users a chance to play long gifs in > real-time. > > > The only reason i can imagine a file would be using the "max delay" > > would be to wait for user input before displaying the next frame > > i thought thats not the reason for this file though but i might be > > wrong > > Imo, the main reason to use "max delay" is if the creator wants a > frame to be shown for more than ten minutes. was this the intent of the creator of the sample file we have ? i mean that the frames display more then 10 minutes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add an ignore_delay option to the gif demuxer
On Friday 27 March 2015 02:45:22 pm Michael Niedermayer wrote:
> On Fri, Mar 27, 2015 at 08:07:23AM +, Carl Eugen Hoyos wrote:
> > Michael Niedermayer gmx.at> writes:
> > > On Fri, Mar 27, 2015 at 12:21:00AM +, Carl Eugen Hoyos wrote:
> > > > Michael Niedermayer gmx.at> writes:
> > > > > iam not sure the default of 6 seconds is safe
> > > >
> > > > What would be a sensible default max_delay?
> > >
> > > for this file simply considering 0x as 0 would work
> > > and would so i think only replacing that would be the
> > > least change needed
> >
> > I did not find any specification that suggests to do this
> > (but many pages were 0x is explicitely mentioned as
> > allowing for maximum delay).
>
> one could add a option like max_delay which is then used in place
> of 0x, conforming to the spec if taken litterally
I attached a new version of the patch that does not change the
current behaviour but gives users a chance to play long gifs in
real-time.
> The only reason i can imagine a file would be using the "max delay"
> would be to wait for user input before displaying the next frame
> i thought thats not the reason for this file though but i might be
> wrong
Imo, the main reason to use "max delay" is if the creator wants a
frame to be shown for more than ten minutes.
Carl Eugen
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 11dfe1b..289787d 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -205,6 +205,11 @@ It accepts the following options:
Set the minimum valid delay between frames in hundredths of seconds.
Range is 0 to 6000. Default value is 2.
+@item max_gif_delay
+Set the maximum valid delay between frames in hundredth of seconds.
+Range is 0 to 65535. Default value is 65535, the maximum value
+allowed by the specification.
+
@item default_delay
Set the default delay between frames in hundredths of seconds.
Range is 0 to 6000. Default value is 10.
diff --git a/libavformat/gifdec.c b/libavformat/gifdec.c
index 7db5a27..bb4c6ec 100644
--- a/libavformat/gifdec.c
+++ b/libavformat/gifdec.c
@@ -43,6 +43,7 @@ typedef struct GIFDemuxContext {
* invalid and set to value of default_delay.
*/
int min_delay;
+int max_delay;
int default_delay;
/**
@@ -159,6 +160,7 @@ static int gif_read_ext(AVFormatContext *s)
if (gdc->delay < gdc->min_delay)
gdc->delay = gdc->default_delay;
+gdc->delay = FFMIN(gdc->delay, gdc->max_delay);
/* skip the rest of the Graphic Control Extension block */
if ((ret = avio_skip(pb, sb_size - 3)) < 0 )
@@ -309,6 +311,7 @@ resync:
static const AVOption options[] = {
{ "min_delay", "minimum valid delay between frames (in hundredths of
second)", offsetof(GIFDemuxContext, min_delay), AV_OPT_TYPE_INT, {.i64 =
GIF_MIN_DELAY}, 0, 100 * 60, AV_OPT_FLAG_DECODING_PARAM },
+{ "max_gif_delay", "maximum valid delay between frames (in hundredths of
seconds)", offsetof(GIFDemuxContext, max_delay) , AV_OPT_TYPE_INT, {.i64 =
65535}, 0, 65535 , AV_OPT_FLAG_DECODING_PARAM },
{ "default_delay", "default delay between frames (in hundredths of
second)" , offsetof(GIFDemuxContext, default_delay), AV_OPT_TYPE_INT,
{.i64 = GIF_DEFAULT_DELAY}, 0, 100 * 60, AV_OPT_FLAG_DECODING_PARAM },
{ "ignore_loop" , "ignore loop setting (netscape extension)"
, offsetof(GIFDemuxContext, ignore_loop) , AV_OPT_TYPE_INT, {.i64 = 1}
, 0,1, AV_OPT_FLAG_DECODING_PARAM },
{ NULL },
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] png: Minor whitespace change and added missing comment
On Sat, Mar 28, 2015 at 03:14:22PM +, Donny Yang wrote: > Signed-off-by: Donny Yang > --- > libavcodec/pngenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] png: Use av_freep() instead of av_free()
On Sat, Mar 28, 2015 at 03:14:21PM +, Donny Yang wrote: > Signed-off-by: Donny Yang > --- > libavcodec/pngenc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: GSoC: APNG
On Sat, Mar 28, 2015 at 03:14:20PM +, Donny Yang wrote: > > On 29 March 2015 at 00:08, Michael Niedermayer wrote: > > git send-email should send one patch per mail > Okay, here's my try with that > > > pts == 0 is not a reliable way to detect the first picture > What would be the recommended way, then? you can try AVCodecContext->frame_number, if that doesnt work you need to keep track of if you already had received a frame > > > this patchset also breaks PAL8 > Yes, I know. > The only reason is because I'm unsure of whether or not ffmpeg ever passes > frame-specific palettes, since APNG only supports a single palette for the > entire movie. > If not, it's trivial to add back. Otherwise, I'm not sure what to do, other > than warn when extra palettes are detected that they will be ignored. ffmpeg can change the palette, yes, if apng cant handle it you can just fail at tat point [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fix dnxhd pix_fmt change
On Sat, Mar 28, 2015 at 09:38:12AM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #4400 for me, please comment. > > Carl Eugen > dnxhddec.c |9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > faf7809dc5b971e27c493e25e8f56a41e7743bd7 patchdnxhd.diff > diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] apng: Add a basic APNG muxer
Additionally, update some documentation with support for APNG
Signed-off-by: Donny Yang
---
Changelog| 1 +
doc/general.texi | 2 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 2 +-
libavformat/apngenc.c| 249 +++
libavformat/version.h| 4 +-
6 files changed, 256 insertions(+), 3 deletions(-)
create mode 100644 libavformat/apngenc.c
diff --git a/Changelog b/Changelog
index 109a1b8..a2d4974 100644
--- a/Changelog
+++ b/Changelog
@@ -11,6 +11,7 @@ version :
- nvenc H265 encoder
- Detelecine filter
- Intel QSV-accelerated H.264 encoding
+- basic APNG encoder and muxer
version 2.6:
diff --git a/doc/general.texi b/doc/general.texi
index 85ee219..589b423 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -222,6 +222,7 @@ library:
@tab Audio format used on the Nintendo Gamecube.
@item AFC @tab @tab X
@tab Audio format used on the Nintendo Gamecube.
+@item APNG @tab X @tab X
@item ASF @tab X @tab X
@item AST @tab X @tab X
@tab Audio format used on the Nintendo Wii.
@@ -508,6 +509,7 @@ following image formats are supported:
@item Alias PIX@tab X @tab X
@tab Alias/Wavefront PIX image format
@item animated GIF @tab X @tab X
+@item APNG @tab X @tab X
@item BMP @tab X @tab X
@tab Microsoft BMP image
@item BRender PIX @tab @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2118ff2..5082101 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -80,6 +80,7 @@ OBJS-$(CONFIG_ANM_DEMUXER) += anm.o
OBJS-$(CONFIG_APC_DEMUXER) += apc.o
OBJS-$(CONFIG_APE_DEMUXER) += ape.o apetag.o img2.o
OBJS-$(CONFIG_APNG_DEMUXER) += apngdec.o
+OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
OBJS-$(CONFIG_AQTITLE_DEMUXER) += aqtitledec.o subtitles.o
OBJS-$(CONFIG_ASF_DEMUXER) += asfdec.o asf.o asfcrypt.o \
avlanguage.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 26ccc27..ca45db8 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -74,7 +74,7 @@ void av_register_all(void)
REGISTER_DEMUXER (ANM, anm);
REGISTER_DEMUXER (APC, apc);
REGISTER_DEMUXER (APE, ape);
-REGISTER_DEMUXER (APNG, apng);
+REGISTER_MUXDEMUX(APNG, apng);
REGISTER_DEMUXER (AQTITLE, aqtitle);
REGISTER_MUXDEMUX(ASF, asf);
REGISTER_MUXDEMUX(ASS, ass);
diff --git a/libavformat/apngenc.c b/libavformat/apngenc.c
new file mode 100644
index 000..7e3ea87
--- /dev/null
+++ b/libavformat/apngenc.c
@@ -0,0 +1,249 @@
+/*
+ * APNG muxer
+ * Copyright (c) 2015 Donny Yang
+ *
+ * first version by Donny Yang
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+
+#include "avformat.h"
+#include "internal.h"
+#include "libavutil/avassert.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/log.h"
+#include "libavutil/opt.h"
+#include "libavcodec/png.h"
+#include "libavcodec/apng.h"
+
+static void apng_write_chunk(AVIOContext *io_context, uint32_t tag,
+ uint8_t* buf, size_t length)
+{
+uint32_t crc;
+uint8_t tagbuf[4];
+
+avio_wb32(io_context, length);
+crc = crc32(0, Z_NULL, 0);
+AV_WB32(tagbuf, tag);
+crc = crc32(crc, tagbuf, 4);
+avio_wb32(io_context, tag);
+if (length > 0) {
+crc = crc32(crc, buf, length);
+avio_write(io_context, buf, length);
+}
+avio_wb32(io_context, crc);
+}
+
+typedef struct APNGMuxContext {
+AVClass *class;
+uint32_t plays;
+uint16_t last_delay_num;
+uint16_t last_delay_den;
+
+uint64_t acTL_offset;
+uint32_t sequence_number;
+uint32_t frame_number;
+
+AVPacket *prev_packet;
+uint16_t prev_delay_num;
+uint16_t prev_delay_den;
+} APNGMuxContext;
+
+static int apng_write_header(AVFormatContext *format_context)
+{
+AVStream *codec_stream;
+
+if (format_context->nb_streams != 1 ||
+format_c
[FFmpeg-devel] [PATCH 4/5] apng: Make PNG encoder only write headers once in APNG mode
Signed-off-by: Donny Yang
---
configure | 1 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 2 +-
libavcodec/pngenc.c| 40
libavcodec/version.h | 2 +-
5 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/configure b/configure
index 017a9d2..8a30549 100755
--- a/configure
+++ b/configure
@@ -2096,6 +2096,7 @@ amv_decoder_select="sp5x_decoder exif"
amv_encoder_select="aandcttables mpegvideoenc"
ape_decoder_select="bswapdsp llauddsp"
apng_decoder_select="zlib"
+apng_encoder_select="huffyuvencdsp zlib"
asv1_decoder_select="blockdsp bswapdsp idctdsp"
asv1_encoder_select="bswapdsp fdctdsp pixblockdsp"
asv2_decoder_select="blockdsp bswapdsp idctdsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b2d9c71..9a145d3 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -144,6 +144,7 @@ OBJS-$(CONFIG_ANM_DECODER) += anm.o
OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
OBJS-$(CONFIG_APE_DECODER) += apedec.o
OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
+OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o ass_split.o
OBJS-$(CONFIG_SSA_ENCODER) += assenc.o ass.o
OBJS-$(CONFIG_ASS_DECODER) += assdec.o ass.o ass_split.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 10aad4c..2e5d558 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -107,7 +107,7 @@ void avcodec_register_all(void)
REGISTER_ENCDEC (AMV, amv);
REGISTER_DECODER(ANM, anm);
REGISTER_DECODER(ANSI, ansi);
-REGISTER_DECODER(APNG, apng);
+REGISTER_ENCDEC (APNG, apng);
REGISTER_ENCDEC (ASV1, asv1);
REGISTER_ENCDEC (ASV2, asv2);
REGISTER_DECODER(AURA, aura);
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 0264575..6959435 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -485,15 +485,19 @@ static int encode(AVCodecContext *avctx, AVPacket *pkt,
s->bytestream = pkt->data;
s->bytestream_end = pkt->data + pkt->size;
-ret = encode_headers(avctx, pict);
-if (ret)
-return ret;
+if (avctx->codec_id == AV_CODEC_ID_PNG || pict->pts == 0) {
+ret = encode_headers(avctx, pict);
+if (ret)
+return ret;
+}
ret = encode_frame(avctx, pict);
if (ret)
return ret;
-png_write_chunk(&s->bytestream, MKTAG('I', 'E', 'N', 'D'), NULL, 0);
+if (avctx->codec_id == AV_CODEC_ID_PNG) {
+png_write_chunk(&s->bytestream, MKTAG('I', 'E', 'N', 'D'), NULL, 0);
+}
pkt->size = s->bytestream - s->bytestream_start;
pkt->flags |= AV_PKT_FLAG_KEY;
@@ -629,6 +633,13 @@ static const AVClass pngenc_class = {
.version= LIBAVUTIL_VERSION_INT,
};
+static const AVClass apngenc_class = {
+.class_name = "APNG encoder",
+.item_name = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
AVCodec ff_png_encoder = {
.name = "png",
.long_name = NULL_IF_CONFIG_SMALL("PNG (Portable Network Graphics)
image"),
@@ -649,3 +660,24 @@ AVCodec ff_png_encoder = {
},
.priv_class = &pngenc_class,
};
+
+AVCodec ff_apng_encoder = {
+.name = "apng",
+.long_name = NULL_IF_CONFIG_SMALL("APNG (Animated Portable Network
Graphics) image"),
+.type = AVMEDIA_TYPE_VIDEO,
+.id = AV_CODEC_ID_APNG,
+.priv_data_size = sizeof(PNGEncContext),
+.init = png_enc_init,
+.close = png_enc_close,
+.encode2= encode,
+.capabilities = CODEC_CAP_FRAME_THREADS | CODEC_CAP_INTRA_ONLY,
+.pix_fmts = (const enum AVPixelFormat[]) {
+AV_PIX_FMT_RGB24, AV_PIX_FMT_RGBA,
+AV_PIX_FMT_RGB48BE, AV_PIX_FMT_RGBA64BE,
+// TODO: AV_PIX_FMT_PAL8,
+AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY8A,
+AV_PIX_FMT_GRAY16BE, AV_PIX_FMT_YA16BE,
+AV_PIX_FMT_MONOBLACK, AV_PIX_FMT_NONE
+},
+.priv_class = &apngenc_class,
+};
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 5a93c68..a351b08 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include "libavutil/version.h"
#define LIBAVCODEC_VERSION_MAJOR 56
-#define LIBAVCODEC_VERSION_MINOR 31
+#define LIBAVCODEC_VERSION_MINOR 32
#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
2.3.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/5] png: Clearly separate init, encoding headers and encoding frame
Signed-off-by: Donny Yang
---
libavcodec/pngenc.c | 286 ++--
1 file changed, 163 insertions(+), 123 deletions(-)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index d6233d0..0264575 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -48,6 +48,11 @@ typedef struct PNGEncContext {
uint8_t buf[IOBUF_SIZE];
int dpi; ///< Physical pixel density, in dots per
inch, if set
int dpm; ///< Physical pixel density, in dots per
meter, if set
+
+int is_progressive;
+int bit_depth;
+int color_type;
+int bits_per_pixel;
} PNGEncContext;
static void png_get_interlaced_row(uint8_t *dst, int row_size,
@@ -286,107 +291,9 @@ static int png_get_gama(enum
AVColorTransferCharacteristic trc, uint8_t *buf)
return 1;
}
-static int encode_frame(AVCodecContext *avctx, AVPacket *pkt,
-const AVFrame *pict, int *got_packet)
+static int encode_headers(AVCodecContext *avctx, const AVFrame *pict)
{
-PNGEncContext *s = avctx->priv_data;
-const AVFrame *const p = pict;
-int bit_depth, color_type, y, len, row_size, ret, is_progressive;
-int bits_per_pixel, pass_row_size, enc_row_size;
-int64_t max_packet_size;
-int compression_level;
-uint8_t *ptr, *top, *crow_buf, *crow;
-uint8_t *crow_base = NULL;
-uint8_t *progressive_buf = NULL;
-uint8_t *top_buf = NULL;
-
-is_progressive = !!(avctx->flags & CODEC_FLAG_INTERLACED_DCT);
-switch (avctx->pix_fmt) {
-case AV_PIX_FMT_RGBA64BE:
-bit_depth = 16;
-color_type = PNG_COLOR_TYPE_RGB_ALPHA;
-break;
-case AV_PIX_FMT_RGB48BE:
-bit_depth = 16;
-color_type = PNG_COLOR_TYPE_RGB;
-break;
-case AV_PIX_FMT_RGBA:
-bit_depth = 8;
-color_type = PNG_COLOR_TYPE_RGB_ALPHA;
-break;
-case AV_PIX_FMT_RGB24:
-bit_depth = 8;
-color_type = PNG_COLOR_TYPE_RGB;
-break;
-case AV_PIX_FMT_GRAY16BE:
-bit_depth = 16;
-color_type = PNG_COLOR_TYPE_GRAY;
-break;
-case AV_PIX_FMT_GRAY8:
-bit_depth = 8;
-color_type = PNG_COLOR_TYPE_GRAY;
-break;
-case AV_PIX_FMT_GRAY8A:
-bit_depth = 8;
-color_type = PNG_COLOR_TYPE_GRAY_ALPHA;
-break;
-case AV_PIX_FMT_YA16BE:
-bit_depth = 16;
-color_type = PNG_COLOR_TYPE_GRAY_ALPHA;
-break;
-case AV_PIX_FMT_MONOBLACK:
-bit_depth = 1;
-color_type = PNG_COLOR_TYPE_GRAY;
-break;
-case AV_PIX_FMT_PAL8:
-bit_depth = 8;
-color_type = PNG_COLOR_TYPE_PALETTE;
-break;
-default:
-return -1;
-}
-bits_per_pixel = ff_png_get_nb_channels(color_type) * bit_depth;
-row_size = (avctx->width * bits_per_pixel + 7) >> 3;
-
-s->zstream.zalloc = ff_png_zalloc;
-s->zstream.zfree = ff_png_zfree;
-s->zstream.opaque = NULL;
-compression_level = avctx->compression_level == FF_COMPRESSION_DEFAULT
- ? Z_DEFAULT_COMPRESSION
- : av_clip(avctx->compression_level, 0, 9);
-ret = deflateInit2(&s->zstream, compression_level,
- Z_DEFLATED, 15, 8, Z_DEFAULT_STRATEGY);
-if (ret != Z_OK)
-return -1;
-
-enc_row_size= deflateBound(&s->zstream, row_size);
-max_packet_size = avctx->height * (int64_t)(enc_row_size +
- ((enc_row_size + IOBUF_SIZE - 1) /
IOBUF_SIZE) * 12)
- + FF_MIN_BUFFER_SIZE;
-if (max_packet_size > INT_MAX)
-return AVERROR(ENOMEM);
-if ((ret = ff_alloc_packet2(avctx, pkt, max_packet_size)) < 0)
-return ret;
-
-s->bytestream_start =
-s->bytestream = pkt->data;
-s->bytestream_end = pkt->data + pkt->size;
-
-crow_base = av_malloc((row_size + 32) << (s->filter_type ==
PNG_FILTER_VALUE_MIXED));
-if (!crow_base)
-goto fail;
-// pixel data should be aligned, but there's a control byte before it
-crow_buf = crow_base + 15;
-if (is_progressive) {
-progressive_buf = av_malloc(row_size + 1);
-if (!progressive_buf)
-goto fail;
-}
-if (is_progressive) {
-top_buf = av_malloc(row_size + 1);
-if (!top_buf)
-goto fail;
-}
+PNGEncContext *s = avctx->priv_data;
/* write png header */
AV_WB64(s->bytestream, PNGSIG);
@@ -394,11 +301,11 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
AV_WB32(s->buf, avctx->width);
AV_WB32(s->buf + 4, avctx->height);
-s->buf[8] = bit_depth;
-s->buf[9] = color_type;
+s->buf[8] = s->bit_depth;
+s->buf[9] = s->color_type;
s->buf[10] = 0; /* compression type */
s->buf[11] = 0; /* filter type */
-s->buf[12] = is_progressive; /* interlace type */
+s->buf[12] = s->is_progressive; /*
[FFmpeg-devel] [PATCH 2/5] png: Minor whitespace change and added missing comment
Signed-off-by: Donny Yang
---
libavcodec/pngenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 0231bf7..d6233d0 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -399,9 +399,9 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
s->buf[10] = 0; /* compression type */
s->buf[11] = 0; /* filter type */
s->buf[12] = is_progressive; /* interlace type */
-
png_write_chunk(&s->bytestream, MKTAG('I', 'H', 'D', 'R'), s->buf, 13);
+/* write physical information */
if (s->dpm) {
AV_WB32(s->buf, s->dpm);
AV_WB32(s->buf + 4, s->dpm);
--
2.3.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: GSoC: APNG
On 29 March 2015 at 00:08, Michael Niedermayer wrote: > git send-email should send one patch per mail Okay, here's my try with that > pts == 0 is not a reliable way to detect the first picture What would be the recommended way, then? > this patchset also breaks PAL8 Yes, I know. The only reason is because I'm unsure of whether or not ffmpeg ever passes frame-specific palettes, since APNG only supports a single palette for the entire movie. If not, it's trivial to add back. Otherwise, I'm not sure what to do, other than warn when extra palettes are detected that they will be ignored. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] png: Use av_freep() instead of av_free()
Signed-off-by: Donny Yang --- libavcodec/pngenc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c index 9bdefc4..0231bf7 100644 --- a/libavcodec/pngenc.c +++ b/libavcodec/pngenc.c @@ -512,9 +512,9 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt, ret = 0; the_end: -av_free(crow_base); -av_free(progressive_buf); -av_free(top_buf); +av_freep(&crow_base); +av_freep(&progressive_buf); +av_freep(&top_buf); deflateEnd(&s->zstream); return ret; fail: -- 2.3.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: GSoC: APNG
On Sat, Mar 28, 2015 at 09:12:10AM +, Donny Yang wrote:
> Sorry for the delay. I was a bit busy this week.
>
> On 25 March 2015 at 09:59, Michael Niedermayer wrote:
>
> > is there any advantage for multiple small IDATs ?
> > if not i suggest to make the IDAT change to png as well in a seperate
> > patch so that a single frame APNG and PNG produce identical data
> > and especially so that the introduction of APNG does not change PNG
> > files
>
>
> Having multiple small IDAT sections is simply to make the encoder easier to
> write.
> For now, I've left it how it is, but now the APNG encoder and muxer
> produces identical output to PNG before.
>
> I've also changed my edits to libavcodec a fair bit as well after thinking
> more carefully about the next steps in implementing a full APNG encoder.
> The APNG encoder currently just outputs normal PNG headers and IDAT chunks,
> while the muxer adds the necessary headers for APNG and converts the IDAT
> chunks to fdAT where needed.
>
> On 28 March 2015 at 18:24, Paul B Mahol wrote:
>
> > Dana 28. 3. 2015. 04:56 osoba "Donny Yang" napisala je:
> > > On 28 March 2015 at 04:36, Paul B Mahol wrote:
> > >>
> > >> The style of code inside patch do not match other files in codebase,
> > >> look at style of other files inside codebase.
> > >
> > > I assume you're referring to the opening brace style on functions?
> > >
> > Yes.
> >
> Okay, I've fixed them.
>
> Also, I just realised I'm not supposed to be sending more than one patch
> per email.
> I've put them again for this email, but what should I do instead next time?
git send-email should send one patch per mail
>
> configure |1
> libavcodec/Makefile|1
> libavcodec/allcodecs.c |2
> libavcodec/pngenc.c| 326
> +
> libavcodec/version.h |2
> 5 files changed, 203 insertions(+), 129 deletions(-)
> 2724818cf358ca284e59add36b1a28e410bc28da
> 0001-apng-Make-PNG-encoder-only-write-headers-once-in-APN.patch
> From cdc40aa212d3c8a34b2895213f6bc63efe881df5 Mon Sep 17 00:00:00 2001
> From: Donny Yang
> Date: Sat, 28 Mar 2015 19:09:11 +1100
> Subject: [PATCH 1/2] apng: Make PNG encoder only write headers once in APNG
> mode
>
> Signed-off-by: Donny Yang
> ---
> configure | 1 +
> libavcodec/Makefile| 1 +
> libavcodec/allcodecs.c | 2 +-
> libavcodec/pngenc.c| 326
> ++---
> libavcodec/version.h | 2 +-
> 5 files changed, 203 insertions(+), 129 deletions(-)
>
> diff --git a/configure b/configure
> index 017a9d2..8a30549 100755
> --- a/configure
> +++ b/configure
> @@ -2096,6 +2096,7 @@ amv_decoder_select="sp5x_decoder exif"
> amv_encoder_select="aandcttables mpegvideoenc"
> ape_decoder_select="bswapdsp llauddsp"
> apng_decoder_select="zlib"
> +apng_encoder_select="huffyuvencdsp zlib"
> asv1_decoder_select="blockdsp bswapdsp idctdsp"
> asv1_encoder_select="bswapdsp fdctdsp pixblockdsp"
> asv2_decoder_select="blockdsp bswapdsp idctdsp"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index b2d9c71..9a145d3 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -144,6 +144,7 @@ OBJS-$(CONFIG_ANM_DECODER) += anm.o
> OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
> OBJS-$(CONFIG_APE_DECODER) += apedec.o
> OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
> +OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
> OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o ass_split.o
> OBJS-$(CONFIG_SSA_ENCODER) += assenc.o ass.o
> OBJS-$(CONFIG_ASS_DECODER) += assdec.o ass.o ass_split.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 10aad4c..2e5d558 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -107,7 +107,7 @@ void avcodec_register_all(void)
> REGISTER_ENCDEC (AMV, amv);
> REGISTER_DECODER(ANM, anm);
> REGISTER_DECODER(ANSI, ansi);
> -REGISTER_DECODER(APNG, apng);
> +REGISTER_ENCDEC (APNG, apng);
> REGISTER_ENCDEC (ASV1, asv1);
> REGISTER_ENCDEC (ASV2, asv2);
> REGISTER_DECODER(AURA, aura);
> diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
> index 9bdefc4..6959435 100644
> --- a/libavcodec/pngenc.c
> +++ b/libavcodec/pngenc.c
> @@ -48,6 +48,11 @@ typedef struct PNGEncContext {
> uint8_t buf[IOBUF_SIZE];
> int dpi; ///< Physical pixel density, in dots per
> inch, if set
> int dpm; ///< Physical pixel density, in dots per
> meter, if set
> +
> +int is_progressive;
> +int bit_depth;
> +int color_type;
> +int bits_per_pixel;
> } PNGEncContext;
>
> static void png_get_interlaced_row(uint8_t *dst, int row_size,
> @@ -286,107 +291,9 @@ static int png_get_gama
Re: [FFmpeg-devel] [PATCH] replace cookies with updated values instead of appending forever (backport to 2.6)
On Sat, Mar 28, 2015 at 04:18:39PM +1100, Micah Galizia wrote: > Hi, > > One more -- backport code to replace cookie values instead appending > to the header forever. > > -- > "The mark of an immature man is that he wants to die nobly for a > cause, while the mark of the mature man is that he wants to live > humbly for one." --W. Stekel > http.c | 65 > - > 1 file changed, 52 insertions(+), 13 deletions(-) > 4f491fac74e643edc485ca7c324d18a56503ac2c > 0003-avformat-http-replace-cookies-with-updated-values-in.patch > From 629e9028f40cbf6f54c4b481a274aea5219d7c10 Mon Sep 17 00:00:00 2001 > From: Micah Galizia > Date: Tue, 17 Mar 2015 20:22:59 +1100 > Subject: [PATCH 3/3] avformat/http: replace cookies with updated values > instead of appending forever applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Store cookies returned in HLS key (Backport to 2.6)
On Sat, Mar 28, 2015 at 04:15:34PM +1100, Micah Galizia wrote: > Hi, > > Backport code to store cookies stored by HLS key. > > -- > "The mark of an immature man is that he wants to die nobly for a > cause, while the mark of the mature man is that he wants to live > humbly for one." --W. Stekel > hls.c |5 + > 1 file changed, 5 insertions(+) > 442d6cec501c08d5c3d3a96ae3103c1ce5c52528 > 0001-avformat-hls-store-cookies-returned-in-HLS-key-respo.patch > From faf8f1c6c1efb87caf50fd054809769b1c5040f2 Mon Sep 17 00:00:00 2001 > From: Micah Galizia > Date: Sun, 15 Mar 2015 09:31:59 +1100 > Subject: [PATCH 1/3] avformat/hls: store cookies returned in HLS key response applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Refactor repeated HLS option updates (Backport to 2.6)
On Sat, Mar 28, 2015 at 04:16:49PM +1100, Micah Galizia wrote: > Hi, > > Backport code to refactor HLS option updates. > > TIA > -- > "The mark of an immature man is that he wants to die nobly for a > cause, while the mark of the mature man is that he wants to live > humbly for one." --W. Stekel > hls.c | 28 > 1 file changed, 12 insertions(+), 16 deletions(-) > f74dc2210649b093cc0d65065157d51b82b8222e > 0002-avformat-hls-refactor-repeated-HLS-option-updates.patch > From cd2beeadf124c495497e665e6b95265ca9fcb3a8 Mon Sep 17 00:00:00 2001 > From: Micah Galizia > Date: Mon, 16 Mar 2015 20:26:29 +1100 > Subject: [PATCH 2/3] avformat/hls: refactor repeated HLS option updates applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add zip protocol
Le septidi 7 germinal, an CCXXIII, Lukasz Marek a écrit : > But, this time I dont understand you comments, could you elaborate it? > What's wrong, what can I do? What I am saying is that there are a lot of different cases where we want to read archives (not only zip, see my previous mail, but that does not matter for now) on the fly with FFmpeg, and I am not sure your proposal is convenient for all these use cases. You implement it as a protocol, to access a single file in the archive. If it was gzip, that would be fine, because it is a stream compression format. In fact, I now realize we should have stackable protocols for all common stream compression tools. But a zip file is not just a compressed stream: it contains structure, several files. In FFmpeg architecture, that may map better to a demuxer: each file as a stream or as an attachment. This is yet another case where the distinction between protocols and formats is not entirely clear. If you think about it, an input protocol is just a demuxer that outputs a single stream of AVMEDIA_TYPE_DATA packets. Of course, for "normal" protocols and formats, like reading a Matroska file from a plain file, the separation makes sense. But with more complex and tied-in protocols and formats, it makes things actually harder. See the RTP issues for example. I have not yet looked closely enough at it, but I suspect the directory listing API that you have just landed may start a bridge between the two: a protocol may no longer be just an API for accessing a single stream but a whole filesystem. Then we can have demuxers that use it. I suppose one of the most pressing tasks would be to have the image2 demuxer use the directory listing API, is it not? So my actual proposal about this patch is: keep it near at hand, but not apply it; rather, use it as a work case to see the most we can do with new APIs. (Well, I do not oppose actually applying it. But if so, let us make us very clear that this is something really experimental. Not experimental "it probably works poorly" but experimental "we may change it completely tomorrow because we had another idea, we will not bother AT ALL with compatibility for now".) > I think you misunderstood this. There is no doc, but reading files by index > is a fallback when user doesn't specify file explicitly. For example: Thanks for correcting me, I really missed that. > ./ffplay zip://zipfile.zip/aaa.avi Ok, but that leads me to another question: what does this do: ffplay zip:///tmp/outer.zip/tmp/inner.zip/tmp/data.bin ? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] af_channelmap: fix number of channels
On Sat, Mar 28, 2015 at 10:12:48AM +0100, Nicolas George wrote: > L'octidi 8 germinal, an CCXXIII, Marton Balint a écrit : > > Fixes segfaults with the following command: > > > > ffmpeg -f lavfi -i aevalsrc=0:c=stereo:n=1920 -af 'channelmap=0' test.ac3 > > I find strange that "=0" works at all, but the change itself seems > absolutely right. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH/TOY] zip files
L'octidi 8 germinal, an CCXXIII, Peter Ross a écrit : > Did a cursory search before selecting libzip... had hoped to find a general > purpose > library for reading popular archive formats. Alas, none seem to exist. What about libarchive? http://www.libarchive.org/ It is packaged in Debian since a long time but has still active development, so I guess this is a serious project. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] Proof-of-concept HTTP Server
Le septidi 7 germinal, an CCXXIII, Stephan Holljes a écrit :
> I just copied that from the line above, I was not aware of the meaning
> of the letter at all. Changed to "E".
D and E are short-cuts for AV_OPT_FLAG_DECODING_PARAM and
AV_OPT_FLAG_ENCODING_PARAM, that allows front-ends to filter options that
are not useful in a particular situation.
> > > +av_dict_set(options, "listen", "1", AV_DICT_APPEND);
> > Are you sure about AV_DICT_APPEND?
> Not at all, it seemed like the flag I needed, but it also works with 0
> passed as a flag.
If the option was already present in the table as, maybe, "0", it would have
become "01". That would probably have worked, but just by happenstance.
> What do you mean with the full-duplex connection? Does
> AVIO_FLAG_READ_WRITE not create a read- and writeable socket?
I did not read carefully enough, sorry.
> This patch only adds the variables and options needed and only changes
> http_open().
>
> I hope this time the use of an alternative mail-client does not corrupt
> it. Regardless, I attached it in case it does anyway.
It seems it was not mangled this time. Feel free to use any one of the
methods.
> Regards,
> Stephan Holljes
>
> ---
> doc/protocols.texi | 3 +++
> libavformat/http.c | 21 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index 2a19b41..5b7b6cf 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -277,6 +277,9 @@ Set initial byte offset.
>
> @item end_offset
> Try to limit the request to bytes preceding this offset.
> +
> +@item listen
> +If set to 1 enables experimental HTTP server.
> @end table
>
> @subsection HTTP Cookies
> diff --git a/libavformat/http.c b/libavformat/http.c
> index da3c9be..989dc95 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -96,6 +96,7 @@ typedef struct HTTPContext {
> int send_expect_100;
> char *method;
> int reconnect;
> +int listen;
> } HTTPContext;
>
> #define OFFSET(x) offsetof(HTTPContext, x)
> @@ -127,6 +128,7 @@ static const AVOption options[] = {
> { "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 },
> { "reconnect", "auto reconnect after disconnect before EOF",
> OFFSET(reconnect), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
> +{ "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 =
> 0 }, 0, 1, E },
> { NULL }
> };
>
> @@ -321,6 +323,25 @@ static int http_open(URLContext *h, const char *uri, int
> flags,
> "No trailing CRLF found in HTTP header.\n");
> }
>
> +if (s->listen) {
> +char header[] = "HTTP/1.1 200 OK\r\nContent-Type:
> application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n";
"static const char header" -> you avoid copying the string to the stack at
each call.
> +char hostname[1024];
> +char lower_url[100];
> +int port;
> +av_url_split(NULL, 0, NULL, 0, hostname, sizeof(hostname), &port,
> + NULL, 0, uri);
> +ff_url_join(lower_url, sizeof(lower_url), "tcp", NULL, hostname,
> port,
> +NULL);
Indentation looks off.
> +av_dict_set(options, "listen", "1", 0);
> +ret = ffurl_open(&s->hd, lower_url, AVIO_FLAG_READ_WRITE,
> + &h->interrupt_callback, options);
> +if (ret < 0)
> +return ret;
> +ret = ffurl_write(s->hd, header, strlen(header));
> +if (ret < 0)
> +return ret;
> +return 0;
That could be merged.
> +}
> ret = http_open_cnx(h, options);
> if (ret < 0)
> av_dict_free(&s->chained_options);
I suspect freeing chained_options should happen in case of failure for the
server mode too, otherwise it will leak.
Apart from that, it looks good. Of course, other developers may have
comments about it.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: Do not overwrite output if there is no input
Le septidi 7 germinal, an CCXXIII, Michael Niedermayer a écrit : > yes, theres a test that does this in fate Oh, I realize I did not look at your patch closely enough. Sorry. No objection from me. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] af_channelmap: fix number of channels
L'octidi 8 germinal, an CCXXIII, Marton Balint a écrit : > Fixes segfaults with the following command: > > ffmpeg -f lavfi -i aevalsrc=0:c=stereo:n=1920 -af 'channelmap=0' test.ac3 I find strange that "=0" works at all, but the change itself seems absolutely right. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: GSoC: APNG
Sorry for the delay. I was a bit busy this week.
On 25 March 2015 at 09:59, Michael Niedermayer wrote:
> is there any advantage for multiple small IDATs ?
> if not i suggest to make the IDAT change to png as well in a seperate
> patch so that a single frame APNG and PNG produce identical data
> and especially so that the introduction of APNG does not change PNG
> files
Having multiple small IDAT sections is simply to make the encoder easier to
write.
For now, I've left it how it is, but now the APNG encoder and muxer
produces identical output to PNG before.
I've also changed my edits to libavcodec a fair bit as well after thinking
more carefully about the next steps in implementing a full APNG encoder.
The APNG encoder currently just outputs normal PNG headers and IDAT chunks,
while the muxer adds the necessary headers for APNG and converts the IDAT
chunks to fdAT where needed.
On 28 March 2015 at 18:24, Paul B Mahol wrote:
> Dana 28. 3. 2015. 04:56 osoba "Donny Yang" napisala je:
> > On 28 March 2015 at 04:36, Paul B Mahol wrote:
> >>
> >> The style of code inside patch do not match other files in codebase,
> >> look at style of other files inside codebase.
> >
> > I assume you're referring to the opening brace style on functions?
> >
> Yes.
>
Okay, I've fixed them.
Also, I just realised I'm not supposed to be sending more than one patch
per email.
I've put them again for this email, but what should I do instead next time?
From cdc40aa212d3c8a34b2895213f6bc63efe881df5 Mon Sep 17 00:00:00 2001
From: Donny Yang
Date: Sat, 28 Mar 2015 19:09:11 +1100
Subject: [PATCH 1/2] apng: Make PNG encoder only write headers once in APNG
mode
Signed-off-by: Donny Yang
---
configure | 1 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 2 +-
libavcodec/pngenc.c| 326 ++---
libavcodec/version.h | 2 +-
5 files changed, 203 insertions(+), 129 deletions(-)
diff --git a/configure b/configure
index 017a9d2..8a30549 100755
--- a/configure
+++ b/configure
@@ -2096,6 +2096,7 @@ amv_decoder_select="sp5x_decoder exif"
amv_encoder_select="aandcttables mpegvideoenc"
ape_decoder_select="bswapdsp llauddsp"
apng_decoder_select="zlib"
+apng_encoder_select="huffyuvencdsp zlib"
asv1_decoder_select="blockdsp bswapdsp idctdsp"
asv1_encoder_select="bswapdsp fdctdsp pixblockdsp"
asv2_decoder_select="blockdsp bswapdsp idctdsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b2d9c71..9a145d3 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -144,6 +144,7 @@ OBJS-$(CONFIG_ANM_DECODER) += anm.o
OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
OBJS-$(CONFIG_APE_DECODER) += apedec.o
OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
+OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o ass_split.o
OBJS-$(CONFIG_SSA_ENCODER) += assenc.o ass.o
OBJS-$(CONFIG_ASS_DECODER) += assdec.o ass.o ass_split.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 10aad4c..2e5d558 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -107,7 +107,7 @@ void avcodec_register_all(void)
REGISTER_ENCDEC (AMV, amv);
REGISTER_DECODER(ANM, anm);
REGISTER_DECODER(ANSI, ansi);
-REGISTER_DECODER(APNG, apng);
+REGISTER_ENCDEC (APNG, apng);
REGISTER_ENCDEC (ASV1, asv1);
REGISTER_ENCDEC (ASV2, asv2);
REGISTER_DECODER(AURA, aura);
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 9bdefc4..6959435 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -48,6 +48,11 @@ typedef struct PNGEncContext {
uint8_t buf[IOBUF_SIZE];
int dpi; ///< Physical pixel density, in dots per inch, if set
int dpm; ///< Physical pixel density, in dots per meter, if set
+
+int is_progressive;
+int bit_depth;
+int color_type;
+int bits_per_pixel;
} PNGEncContext;
static void png_get_interlaced_row(uint8_t *dst, int row_size,
@@ -286,107 +291,9 @@ static int png_get_gama(enum AVColorTransferCharacteristic trc, uint8_t *buf)
return 1;
}
-static int encode_frame(AVCodecContext *avctx, AVPacket *pkt,
-const AVFrame *pict, int *got_packet)
+static int encode_headers(AVCodecContext *avctx, const AVFrame *pict)
{
-PNGEncContext *s = avctx->priv_data;
-const AVFrame *const p = pict;
-int bit_depth, color_type, y, len, row_size, ret, is_progressive;
-int bits_per_pixel, pass_row_size, enc_row_size;
-int64_t max_packet_size;
-int compression_level;
-uint8_t *ptr, *top, *crow_buf, *crow;
-uint8_t *crow_base = NULL;
-uint8_t *progressive_buf = NULL;
-uint8_t *top_buf = NULL;
-
-is_progressive = !!(
[FFmpeg-devel] [PATCH v2] af_channelmap: fix number of channels
Fixes segfaults with the following command: ffmpeg -f lavfi -i aevalsrc=0:c=stereo:n=1920 -af 'channelmap=0' test.ac3 Signed-off-by: Marton Balint --- libavfilter/af_channelmap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavfilter/af_channelmap.c b/libavfilter/af_channelmap.c index cc66f04..f8289cc 100644 --- a/libavfilter/af_channelmap.c +++ b/libavfilter/af_channelmap.c @@ -348,6 +348,7 @@ static int channelmap_filter_frame(AVFilterLink *inlink, AVFrame *buf) FFMIN(FF_ARRAY_ELEMS(buf->data), nch_out) * sizeof(buf->data[0])); buf->channel_layout = outlink->channel_layout; +av_frame_set_channels(buf, outlink->channels); return ff_filter_frame(outlink, buf); } -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Fix dnxhd pix_fmt change
Hi!
Attached patch fixes ticket #4400 for me, please comment.
Carl Eugen
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index cc011c4..053bf1c 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -119,6 +119,7 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
static const uint8_t header_prefix[]= { 0x00, 0x00, 0x02, 0x80, 0x01 };
static const uint8_t header_prefix444[] = { 0x00, 0x00, 0x02, 0x80, 0x02 };
int i, cid, ret;
+int old_bit_depth = ctx->bit_depth;
if (buf_size < 0x280) {
av_log(ctx->avctx, AV_LOG_ERROR, "buffer too small (%d < 640).\n",
@@ -145,10 +146,6 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
av_dlog(ctx->avctx, "width %d, height %d\n", ctx->width, ctx->height);
-if (!ctx->bit_depth) {
-ff_blockdsp_init(&ctx->bdsp, ctx->avctx);
-ff_idctdsp_init(&ctx->idsp, ctx->avctx);
-}
if (buf[0x21] == 0x58) { /* 10 bit */
ctx->bit_depth = ctx->avctx->bits_per_raw_sample = 10;
@@ -172,6 +169,10 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame
*frame,
buf[0x21]);
return AVERROR_INVALIDDATA;
}
+if (ctx->bit_depth != old_bit_depth) {
+ff_blockdsp_init(&ctx->bdsp, ctx->avctx);
+ff_idctdsp_init(&ctx->idsp, ctx->avctx);
+}
cid = AV_RB32(buf + 0x28);
av_dlog(ctx->avctx, "compression id %d\n", cid);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
