[FFmpeg-devel] [PATCH] [BACKPORT] tests: Fix test name for pixfmts tests
Hi, Please if possible backport the following commit to all release branches currently being tested: >From e1ee0521a698809ed216e9e5c11bd2bbb466ed04 Mon Sep 17 00:00:00 2001 From: Timothy Gu Date: Sun, 9 Nov 2014 21:37:18 -0800 Subject: [PATCH] tests: Fix test name for pixfmts tests --- tests/fate-run.sh | 2 ++ 1 file changed, 2 insertions(+) it is only in 2.5 and later. Sorry about not being able to send a pull request as I do not have my main computer with me at this moment. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fateserver: Support parsing version 1 headers
On Tue, Apr 7, 2015 at 8:04 PM Lou Logan wrote: > On Tue, Apr 7, 2015, at 06:53 PM, Timothy Gu wrote: > > ...but unfortunately their fateserver source code is not open to public > > Why? > Last year when I asked Luca he said it was Janne's territory, and an email to Janne was not replied. That was 2014-02-09. When I asked him on IRC (I think) his reply was something to the degree of (not original quote, and I didn't keep IRC logs back then) "sorry the source code is not public." So, to answer your question, I don't know. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fateserver: Support parsing version 1 headers
On Tue, Apr 7, 2015, at 06:53 PM, Timothy Gu wrote: > ...but unfortunately their fateserver source code is not open to public Why? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fateserver: Support parsing version 1 headers
To clarify this patch, a key component in the new fateserver is the support
for the separation of release branches from the master branch. This depends
on adding the branch information to the FATE payload headers. Libav has
already made the change to both fateserver and fate.sh a while ago, but
unfortunately their fateserver source code is not open to public (even
though Måns has released it under ISC license). Therefore when merging the
code to fate.sh Michael commented it out.
This patch does not represent that fate.ffmpeg.org will have full branches
support, but rather that version 1 (the version with branch info) headers
will be parsed correctly.
I will send a patch to enable the use of version 1 headers in fate.sh after
this is applied.
On an unrelated note, the design for version 1 is pretty dumb, as one can
simply make `branch` the last element to avoid API break.
On Tue, Apr 7, 2015 at 7:45 PM Timothy Gu wrote:
> diff --git a/FATE.pm b/FATE.pm
> index 544e80f..30c220b 100644
> --- a/FATE.pm
> +++ b/FATE.pm
> @@ -47,7 +47,7 @@ our $gitweb = "http://git.videolan.org/?p=ffmpeg.git";;
> sub split_header {
> my @hdr = split /:/, $_[0];
> $hdr[0] eq 'fate' or return undef;
> -return {
> +my $parsed = {
> version => $hdr[1],
> date=> $hdr[2],
> slot=> $hdr[3],
> @@ -56,6 +56,11 @@ sub split_header {
> errstr => $hdr[6],
> comment => $hdr[7],
> };
>
> +if ($hdr[1] eq '1') {
> + $parsed->{'comment'} = $hdr[8];
> + $parsed->{'branch'} = $hdr[7];
> +}
>
Perl guru needed to maybe shorten this.
> +return $parsed;
> }
>
> sub split_config {
>
Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fateserver: Support parsing version 1 headers
---
Now with proper commit message
---
FATE.pm | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/FATE.pm b/FATE.pm
index 544e80f..30c220b 100644
--- a/FATE.pm
+++ b/FATE.pm
@@ -47,7 +47,7 @@ our $gitweb = "http://git.videolan.org/?p=ffmpeg.git";;
sub split_header {
my @hdr = split /:/, $_[0];
$hdr[0] eq 'fate' or return undef;
-return {
+my $parsed = {
version => $hdr[1],
date=> $hdr[2],
slot=> $hdr[3],
@@ -56,6 +56,11 @@ sub split_header {
errstr => $hdr[6],
comment => $hdr[7],
};
+if ($hdr[1] eq '1') {
+ $parsed->{'comment'} = $hdr[8];
+ $parsed->{'branch'} = $hdr[7];
+}
+return $parsed;
}
sub split_config {
@@ -132,7 +137,7 @@ sub load_report {
my $hdr = split_header scalar or return;
my $conf = split_config scalar or return;
-$$hdr{version} eq '0' or return undef;
+$$hdr{version} eq '0' or $$hdr{version} eq '1' or return undef;
while () {
my $rec = split_rec $_;
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Support parsing version 1 headers
---
FATE.pm | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/FATE.pm b/FATE.pm
index 544e80f..30c220b 100644
--- a/FATE.pm
+++ b/FATE.pm
@@ -47,7 +47,7 @@ our $gitweb = "http://git.videolan.org/?p=ffmpeg.git";;
sub split_header {
my @hdr = split /:/, $_[0];
$hdr[0] eq 'fate' or return undef;
-return {
+my $parsed = {
version => $hdr[1],
date=> $hdr[2],
slot=> $hdr[3],
@@ -56,6 +56,11 @@ sub split_header {
errstr => $hdr[6],
comment => $hdr[7],
};
+if ($hdr[1] eq '1') {
+ $parsed->{'comment'} = $hdr[8];
+ $parsed->{'branch'} = $hdr[7];
+}
+return $parsed;
}
sub split_config {
@@ -132,7 +137,7 @@ sub load_report {
my $hdr = split_header scalar or return;
my $conf = split_config scalar or return;
-$$hdr{version} eq '0' or return undef;
+$$hdr{version} eq '0' or $$hdr{version} eq '1' or return undef;
while () {
my $rec = split_rec $_;
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] hqx codec patch: faster decode with multi threaded decoding of slices; fixed clipping bug
On 07/04/15 10:49 AM, Ferdinand Oeinck wrote:
> From 77116c82d128cb7efcdf5f55481fa5f349c31f22 Mon Sep 17 00:00:00 2001
> From: fo
> Date: Tue, 7 Apr 2015 12:42:17 +0200
> Subject: [PATCH 2/2] libavcodec/hqx: correct clipping error
>
> ---
> libavcodec/hqx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c
> index ee851ed..ecaba98 100644
> --- a/libavcodec/hqx.c
> +++ b/libavcodec/hqx.c
> @@ -182,7 +182,7 @@ static void hqx_idct_put(uint16_t *dst, ptrdiff_t stride,
>
> for (i = 0; i < 8; i++) {
> for (j = 0; j < 8; j++) {
> -int v = av_clip(block[j + i * 8] + 0x800, 0, 0x1000);
> +int v = av_clip(block[j + i * 8] + 0x800, 0, 0xFFF);
> dst[j] = (v << 4) | (v >> 8);
> }
> dst += stride >> 1;
> --
> 2.3.4
If you want to put more than one patch in a single email then please attach
them instead
of inlining them all together in the body.
Nonetheless, keep in mind using git send-email is still preferred over attached
patches,
so use that if possible.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] hqx codec patch: faster decode with multi threaded decoding of slices; fixed clipping bug
On Tue, Apr 07, 2015 at 03:49:09PM +0200, Ferdinand Oeinck wrote:
> From e750ddd8b1b79cfad04f2cdd58b5ba438390adf1 Mon Sep 17 00:00:00 2001
> From: fo
> Date: Mon, 6 Apr 2015 15:47:14 +0200
> Subject: [PATCH 1/2] libavcodec/hqx: made decoding multi threaded!
>
> ---
> libavcodec/hqx.c | 142
> +++
> libavcodec/hqx.h | 9 +++-
> 2 files changed, 99 insertions(+), 52 deletions(-)
>
> diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c
> index d7e605f..ee851ed 100644
> --- a/libavcodec/hqx.c
> +++ b/libavcodec/hqx.c
> @@ -39,7 +39,7 @@ enum HQXFormat {
>
> #define HQX_HEADER_SIZE 59
>
> -typedef int (*mb_decode_func)(HQXContext *ctx, AVFrame *pic,
> +typedef int (*mb_decode_func)(HQXContext *ctx, slice_data_t *
> slice_data, AVFrame *pic,
> GetBitContext *gb, int x, int y);
>
> /* macroblock selects a group of 4 possible quants and
> @@ -260,7 +260,7 @@ static int decode_block(GetBitContext *gb, VLC *vlc,
> return 0;
> }
>
> -static int hqx_decode_422(HQXContext *ctx, AVFrame *pic,
> +static int hqx_decode_422(HQXContext *ctx, slice_data_t *
> slice_data, AVFrame *pic,
> GetBitContext *gb, int x, int y)
> {
> const int *quants;
> @@ -280,20 +280,20 @@ static int hqx_decode_422(HQXContext *ctx,
> AVFrame *pic,
> if (i == 0 || i == 4 || i == 6)
> last_dc = 0;
> ret = decode_block(gb, &ctx->dc_vlc[vlc_index], quants,
> - ctx->dcb, ctx->block[i], &last_dc);
> + ctx->dcb, slice_data->block[i], &last_dc);
> if (ret < 0)
> return ret;
> }
>
> -put_blocks(pic, 0, x, y, flag, ctx->block[0],
> ctx->block[2], hqx_quant_luma);
> -put_blocks(pic, 0, x + 8, y, flag, ctx->block[1],
> ctx->block[3], hqx_quant_luma);
> -put_blocks(pic, 2, x >> 1, y, flag, ctx->block[4],
> ctx->block[5], hqx_quant_chroma);
> -put_blocks(pic, 1, x >> 1, y, flag, ctx->block[6],
> ctx->block[7], hqx_quant_chroma);
> +put_blocks(pic, 0, x, y, flag, slice_data->block[0],
> slice_data->block[2], hqx_quant_luma);
> +put_blocks(pic, 0, x + 8, y, flag, slice_data->block[1],
> slice_data->block[3], hqx_quant_luma);
> +put_blocks(pic, 2, x >> 1, y, flag, slice_data->block[4],
> slice_data->block[5], hqx_quant_chroma);
> +put_blocks(pic, 1, x >> 1, y, flag, slice_data->block[6],
> slice_data->block[7], hqx_quant_chroma);
this appears to be corrupted by linebreaks
Applying: hqx codec patch: faster decode with multi threaded decoding of
slices; fixed clipping bug
fatal: corrupt patch at line 13
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 hqx codec patch: faster decode with multi threaded
decoding of slices; fixed clipping bug
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for High color and High bit-depth support
On Tue, Apr 07, 2015 at 02:30:34PM -0700, Debargha Mukherjee wrote:
> Resolutions inline.
>
> On Mon, Apr 6, 2015 at 3:21 PM, James Zern wrote:
>
> > On Fri, Apr 3, 2015 at 6:37 PM, Debargha Mukherjee
> > wrote:
> >
> > >>
> > >> You can probably merge profile 1 like 2/3 to cut down on the
> > duplication.
> > >> You
> > >> might want to set bitdepth to 8 by default reducing the ifdefs here too.
> > >>
> > >
> > > done.
> > >
> >
> > > +#ifdef VPX_IMG_FMT_HIGHBITDEPTH
> > > +case AV_PIX_FMT_YUV420P10LE:
> > > +case AV_PIX_FMT_YUV420P12LE:
> > > +if (codec_caps & VPX_CODEC_CAP_HIGHBITDEPTH) {
> > > +enccfg->g_bit_depth = enccfg->g_input_bit_depth =
> > > +avctx->pix_fmt == AV_PIX_FMT_YUV420P10LE ? 10 : 12;
> > > +enccfg->g_profile = 2;
> > > +*img_fmt = VPX_IMG_FMT_I42016;
> > > +*flags |= VPX_CODEC_USE_HIGHBITDEPTH;
> > > +return 0;
> > > +} else {
> > > +break;
> > > +}
> > >
> >
> > just drop the else, you return from the other block.
> >
>
> Done.
>
>
> >
> > >
> > >>
> > >> > +#if CONFIG_LIBVPX_VP9_ENCODER
> > >> > +if (avctx->codec_id == AV_CODEC_ID_VP9) {
> > >> > +if (set_pix_fmt(avctx, codec_caps, &enccfg, &flags,
> > &img_fmt))
> > >> > +return AVERROR(EINVAL);
> > >> > +av_log(avctx, AV_LOG_INFO, "Bit-depth: %d\n",
> > >> enccfg.g_bit_depth);
> > >> >
> > >>
> > >> Won't build with a non-high-bitdepth build.
> > >>
> > >
> > > done.
> > >
> >
> > This should get output in dump_enc_cfg(), no? I think the log can be
> > dropped.
> >
>
> Done.
>
>
> >
> > >
> > >>
> > >> > -.pix_fmts = (const enum AVPixelFormat[]){
> > AV_PIX_FMT_YUV420P,
> > >> AV_PIX_FMT_NONE },
> > >> > +.pix_fmts = (const enum AVPixelFormat[]){
> > AV_PIX_FMT_YUV420P,
> > >> > +
> > AV_PIX_FMT_YUV422P,
> > >> > +
> > AV_PIX_FMT_YUV444P,
> > >> > +#ifdef VPX_IMG_FMT_HIGHBITDEPTH
> > >> > +
> > >> AV_PIX_FMT_YUV420P10LE,
> > >> > +
> > >> AV_PIX_FMT_YUV422P10LE,
> > >> > +
> > >> AV_PIX_FMT_YUV444P10LE,
> > >> > +
> > >> AV_PIX_FMT_YUV420P12LE,
> > >> > +
> > >> AV_PIX_FMT_YUV422P12LE,
> > >> > +
> > >> AV_PIX_FMT_YUV444P12LE,
> > >> > +#endif
> > >>
> > >
> > > done using ff_vp9_init_static().
> > >
> > > diff --git a/libavcodec/libvpx.c b/libavcodec/libvpx.c
> > > index 5d29893..5111eed 100644
> > > --- a/libavcodec/libvpx.c
> > > +++ b/libavcodec/libvpx.c
> > > @@ -19,12 +19,47 @@
> > > */
> > >
> > > #include
> > > -
> > > +#include
> > > +#include
> > >
> >
> > You need to make sure the encoder is available. Keep the break between
> > local
> > and system headers.
> >
>
> Kept the break.
>
>
> >
> > > if (vpx_codec_version_major() < 1
> > > || (vpx_codec_version_major() == 1 && vpx_codec_version_minor()
> > < 3))
> > > codec->capabilities |= CODEC_CAP_EXPERIMENTAL;
> > > +if (vpx_codec_version_major() == 1 && vpx_codec_version_minor()
> > >= 3) {
> > >
> >
> > 1.4.0 would be better for all high bitdepth since it wasn't working at
> > 1.3.0
> > and identifying anything in between would need a configure change. Also
> > check
> > for major > 1.
> >
>
> Done.
>
>
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
>
>
> --
> Debargha Mukherjee, Ph.D.
> Staff Software Engineer,
> Google, Inc.
> Email: debar...@google.com
> Phone: 408-234-5956 (cell)
> libvpx.c| 36 ++
> libvpxenc.c | 83
> ++--
> 2 files changed, 117 insertions(+), 2 deletions(-)
> 34db5acf9792c28b106393d11e441c85bac756f6
> 0001-Support-for-VP9-high-color-high-bit-depth-encoding.patch
> From cbbd046deb0ccdd8274d66faf5ec13efc1ad95ce Mon Sep 17 00:00:00 2001
> From: Deb Mukherjee
> Date: Wed, 25 Mar 2015 17:10:16 -0700
> Subject: [PATCH] Support for VP9 high-color/high-bit-depth encoding
>
> Patch to support VP9 encoding with new profiles 1-3.
> Profile 1 (8-bit 422/444) should work with default libvpx
> configuration.
> However you will need to configure libvpx with
> --enable-vp9-highbitdepth before building and linking
> with ffmpeg for profile 2 (10-/12-bit 420) and profile 3
> (10-/12-bit 422/444) encoding.
>
> You may use the appropriate profile option on the
> command line:
> -profile:v 1 for 422/444 8-bit encoding
> -profile:v 2 for 420 10-/12- bit encoding
> -profile:v 3 for 422/444 10-/12-bit encoding
> If you do not use the -profile:v option, it will be deduced
> from the source format.
> ---
> libavcodec/libvpx.c| 36 ++
> libavcodec/libvpxenc.c | 83
> --
> 2 files changed, 117 insertions(+), 2 deletions(-)
fails with:
./configure --enable-libvpx --enable-libopus
libavcodec/libvpx.c: In function ‘ff_vp9_init_static’:
libavcodec/libvpx.c:59:
[FFmpeg-devel] [PATCH 2/3] ffplay: add basic credentials handler
Signed-off-by: Lukasz Marek
---
ffplay.c | 63 ++-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/ffplay.c b/ffplay.c
index 8fa8566..692773e 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -29,6 +29,9 @@
#include
#include
#include
+#if HAVE_TERMIOS_H
+#include
+#endif
#include "libavutil/avstring.h"
#include "libavutil/colorspace.h"
@@ -1690,7 +1693,7 @@ display:
}
}
is->force_refresh = 0;
-if (show_status) {
+if (show_status && is->ic) {
static int64_t last_time;
int64_t cur_time;
int aqsize, vqsize, sqsize;
@@ -3781,6 +3784,62 @@ static int lockmgr(void **mtx, enum AVLockOp op)
return 1;
}
+static void console_change_echo(int echo)
+{
+#if HAVE_TERMIOS_H
+struct termios t;
+tcgetattr(0, &t);
+if (echo)
+t.c_lflag |= ECHO;
+else
+t.c_lflag &= ~ECHO;
+tcsetattr(0, TCSANOW, &t);
+#endif
+}
+
+static int credetials_callback_get_val(const char *query, const char
*default_val, char **value)
+{
+char val[1024];
+size_t len;
+
+if (default_val)
+printf("Enter %s [%s]: ", query, default_val);
+else
+printf("Enter %s: ", query);
+fflush(stdout);
+fgets(val, sizeof(val), stdin);
+len = strlen(val);
+if (len > 1) {
+av_freep(value);
+val[len - 1] = '\0'; //remove trailing \n
+*value = av_strdup(val);
+if (!*value)
+return AVERROR(ENOMEM);
+}
+return 0;
+}
+
+static int credetials_callback_func(AVIOCredentials *credentials, void *opaque)
+{
+int ret = 0;
+
+printf("Provide credentials for URL: %s\n", credentials->url);
+if (credentials->username)
+ret = credetials_callback_get_val("username", credentials->username,
&credentials->username);
+if (credentials->password && ret >= 0) {
+console_change_echo(0);
+ret = credetials_callback_get_val("password", NULL,
&credentials->password);
+console_change_echo(1);
+}
+printf("\n");
+return ret;
+}
+
+static const AVIOCredentialsCB credetials_callback = {
+.callback = credetials_callback_func,
+.opaque = NULL,
+};
+
/* Called from the main */
int main(int argc, char **argv)
{
@@ -3801,6 +3860,8 @@ int main(int argc, char **argv)
av_register_all();
avformat_network_init();
+avio_register_default_credentials_callback(&credetials_callback);
+
init_opts();
signal(SIGINT , sigterm_handler); /* Interrupt (ANSI).*/
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] [RFC]lavf/avio: add custom authentication API
Signed-off-by: Lukasz Marek
---
libavformat/avio.c | 46 ++
libavformat/avio.h | 28
libavformat/url.h | 12
3 files changed, 86 insertions(+)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index a990ea2..9006cac 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -30,9 +30,12 @@
#include "network.h"
#endif
#include "url.h"
+#include "internal.h"
static URLProtocol *first_protocol = NULL;
+static AVIOCredentialsCB g_credentials_callback;
+
URLProtocol *ffurl_protocol_next(const URLProtocol *prev)
{
return prev ? prev->next : first_protocol;
@@ -543,3 +546,46 @@ int ff_check_interrupt(AVIOInterruptCB *cb)
return ret;
return 0;
}
+
+void avio_register_default_credentials_callback(const AVIOCredentialsCB
*callback)
+{
+if (callback)
+g_credentials_callback = *callback;
+}
+
+int ff_url_get_credentials(const URLContext *h, AVIOCredentials *credentials)
+{
+char url[MAX_URL_SIZE], proto[MAX_URL_SIZE], host[MAX_URL_SIZE];
+int port, ret = 0;
+
+if (!credentials) {
+//probe
+if (g_credentials_callback.callback || (h &&
h->credentials_callback.callback))
+return 0;
+return AVERROR(ENOSYS);
+}
+
+av_assert0(h);
+av_url_split(proto, sizeof(proto), NULL, 0, host, sizeof(host), &port,
NULL, 0, h->filename);
+ff_url_join(url, sizeof(url), proto, NULL, host, port, NULL);
+
+av_free(credentials->url);
+credentials->url = av_strdup(url);
+if (!credentials->url) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+if (h->credentials_callback.callback)
+ret = h->credentials_callback.callback(credentials,
h->credentials_callback.opaque);
+else if (g_credentials_callback.callback)
+ret = g_credentials_callback.callback(credentials,
g_credentials_callback.opaque);
+else
+ret = AVERROR(ENOSYS);
+ fail:
+av_freep(&credentials->url);
+if (ret < 0) {
+av_freep(&credentials->username);
+av_freep(&credentials->password);
+}
+return ret;
+}
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 51913e3..60381c4 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -53,6 +53,27 @@ typedef struct AVIOInterruptCB {
} AVIOInterruptCB;
/**
+ * User provided URL credentials. Used by AVIOCredentialsCB.
+ * Protocol may ask for all fields or only for some of the (e.g. for password
only).
+ * Protocol allocates required fields with default values (empty string for no
default).
+ * Non-allocated fields must be skipped by the user.
+ * Allocated fields may be reallocated with their new values provided by the
user.
+ */
+typedef struct AVIOCredentials {
+char *url;/**< Read only, never include any
credentials */
+char *username; /**< User's name */
+char *password; /**< User's password */
+} AVIOCredentials;
+
+/**
+ * Callback for asking user to enter URL credentials.
+ */
+typedef struct AVIOCredentialsCB {
+int (*callback)(AVIOCredentials *credentials, void*);
+void *opaque;
+} AVIOCredentialsCB;
+
+/**
* Directory entry types.
*/
enum AVIODirEntryType {
@@ -617,4 +638,11 @@ struct AVBPrint;
*/
int avio_read_to_bprint(AVIOContext *h, struct AVBPrint *pb, size_t max_size);
+
+/**
+ * Register credentials callback
+ * @param callback callback data
+ */
+void avio_register_default_credentials_callback(const AVIOCredentialsCB
*callback);
+
#endif /* AVFORMAT_AVIO_H */
diff --git a/libavformat/url.h b/libavformat/url.h
index 1a845b7..f873734 100644
--- a/libavformat/url.h
+++ b/libavformat/url.h
@@ -47,6 +47,7 @@ typedef struct URLContext {
int is_connected;
AVIOInterruptCB interrupt_callback;
int64_t rw_timeout; /**< maximum time to wait for (network)
read/write operation completion, in mcs */
+AVIOCredentialsCB credentials_callback;
} URLContext;
typedef struct URLProtocol {
@@ -290,5 +291,16 @@ void ff_make_absolute_url(char *buf, int size, const char
*base,
*/
AVIODirEntry *ff_alloc_dir_entry(void);
+/**
+ * Get user provided credentials.
+ *
+ * May be called with NULL credentials (or even protocol context) to probe
implementation.
+ * Must not be called with NULL context when credentials is not NULL.
+ *
+ * @param h protocol context
+ * @param[inout] credentials credentails data, may be NULL for implementation
probing.
+ * @return >=0 on success, negative on error
+ */
+int ff_url_get_credentials(const URLContext *h, AVIOCredentials *credentials);
#endif /* AVFORMAT_URL_H */
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] lavf/ftp: support credentials callback
---
libavformat/ftp.c | 96 +++
1 file changed, 83 insertions(+), 13 deletions(-)
diff --git a/libavformat/ftp.c b/libavformat/ftp.c
index 27a172e..1133e02 100644
--- a/libavformat/ftp.c
+++ b/libavformat/ftp.c
@@ -74,6 +74,36 @@ static const AVClass ftp_context_class = {
static int ftp_close(URLContext *h);
+static int ftp_get_password(URLContext *h)
+{
+FTPContext *s = h->priv_data;
+int ret;
+AVIOCredentials cretentials = {
+.username = av_strdup(av_x_if_null(s->user, "anonymous")),
+.password = av_strdup(av_x_if_null(s->password, "")),
+};
+
+if (!cretentials.username || !cretentials.password) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+if ((ret = ff_url_get_credentials(h, &cretentials)) < 0)
+goto fail;
+
+av_free(s->user);
+av_free(s->password);
+s->user = cretentials.username;
+s->password = cretentials.password;
+
+return 0;
+
+ fail:
+av_free(cretentials.username);
+av_free(cretentials.password);
+return ret;
+}
+
static int ftp_getc(FTPContext *s)
{
int len;
@@ -82,7 +112,7 @@ static int ftp_getc(FTPContext *s)
if (len < 0) {
return len;
} else if (!len) {
-return -1;
+return AVERROR(EPIPE);
} else {
s->control_buf_ptr = s->control_buffer;
s->control_buf_end = s->control_buffer + len;
@@ -191,7 +221,7 @@ static int ftp_send_command(FTPContext *s, const char
*command,
if ((err = ffurl_write(s->conn_control, command, strlen(command))) < 0)
return err;
if (!err)
-return -1;
+return AVERROR(EPIPE);
/* return status */
if (response_codes) {
@@ -213,12 +243,13 @@ static void ftp_close_both_connections(FTPContext *s)
ftp_close_data_connection(s);
}
-static int ftp_auth(FTPContext *s)
+static int ftp_auth(URLContext *h)
{
+FTPContext *s = h->priv_data;
char buf[CONTROL_BUFFER_SIZE];
int err;
-static const int user_codes[] = {331, 230, 0};
-static const int pass_codes[] = {230, 0};
+static const int user_codes[] = {421, 331, 230, 0};
+static const int pass_codes[] = {421, 230, 0};
snprintf(buf, sizeof(buf), "USER %s\r\n", s->user);
err = ftp_send_command(s, buf, user_codes, NULL);
@@ -229,6 +260,10 @@ static int ftp_auth(FTPContext *s)
} else
return AVERROR(EACCES);
}
+if (err < 0)
+return err;
+if (err == 421)
+return AVERROR(EPIPE);
if (err != 230)
return AVERROR(EACCES);
@@ -434,6 +469,17 @@ static int ftp_restart(FTPContext *s, int64_t pos)
return 0;
}
+static int ftp_noop(FTPContext *s)
+{
+static const char *command = "TYPE I\r\n";
+static const int noop_codes[] = {200, 0};
+
+if (ftp_send_command(s, command, noop_codes, NULL) != 200)
+return AVERROR(EIO);
+
+return 0;
+}
+
static int ftp_features(FTPContext *s)
{
static const char *feat_command= "FEAT\r\n";
@@ -459,6 +505,11 @@ static int ftp_connect_control_connection(URLContext *h)
FTPContext *s = h->priv_data;
static const int connect_codes[] = {220, 0};
+if (s->conn_control) {
+/* check if connection is alive */
+if (ftp_noop(s) < 0)
+ftp_close_both_connections(s);
+}
if (!s->conn_control) {
ff_url_join(buf, sizeof(buf), "tcp", NULL,
s->hostname, s->server_control_port, NULL);
@@ -484,10 +535,21 @@ static int ftp_connect_control_connection(URLContext *h)
}
av_free(response);
-if ((err = ftp_auth(s)) < 0) {
-av_log(h, AV_LOG_ERROR, "FTP authentication failed\n");
-return err;
-}
+do {
+err = ftp_auth(h);
+if (err >= 0)
+break;
+if (err < 0 && err != AVERROR(EACCES)) {
+if (err != AVERROR(EPIPE))
+av_log(h, AV_LOG_ERROR, "FTP authentication failed\n");
+return err;
+}
+if ((err = ftp_get_password(h)) < 0) {
+if (err == AVERROR(ENOSYS))
+err = AVERROR(EACCES);
+return err;
+}
+} while (1);
if ((err = ftp_type(s)) < 0) {
av_log(h, AV_LOG_ERROR, "Set content type failed\n");
@@ -575,7 +637,7 @@ static int ftp_open(URLContext *h, const char *url, int
flags)
char proto[10], path[MAX_URL_SIZE], credencials[MAX_URL_SIZE],
hostname[MAX_URL_SIZE];
const char *tok_user = NULL, *tok_pass = NULL;
char *end = NULL;
-int err;
+int err, retry = 100;
size_t pathlen;
FTPContext *s = h->priv_data;
@@ -596,7 +658,7 @@ static int ftp_open(URLContext *h, const char *url, int
flags)
tok_pass = av_strtok(end, ":", &end);
if (!tok_user) {
tok_user = "anonymous";
-tok_pass = av_
[FFmpeg-devel] [PATCH 0/3] Authentication callbacks
One of the most annoying things with ffmpeg is that password must be provided as a program param. It is visible while typing and on process list. (I'm talking about ffplay/ffmpeg/ffprobe here.) This patchset provides API that protocols may use to ask user for password interactively. I added implementation in ffplay, but I see it potentially useful for any user application. The question is: is this really required, application may just ask for password when connection fails. Assuming application knows it is matter of credentials (not wrong hostname, file permissions etc), it may be ineffective. It is almost sure connection has to be established at each try. API also allows to distinguish password for reqular user/pass authentication and password for private key (not included in this patchset, but libssh may benefit from this probably). I added callback as global variable with settter and as part of URLContext. Global variable is not nice, but it allows to avoid massive attack on avio API :) I don't see any reason it cannot be done this way. I also added it to URLContext to allow muxers, demuxers (like HLS, DASH, SmoothStreaming, image2) to add a wrapper and cache these credentials as they open many urls to store sequential data (images/chunks). Patchset available at https://github.com/lukaszmluki/ffmpeg branch: auth Lukasz Marek (3): [RFC]lavf/avio: add custom authentication API ffplay: add basic credentials handler lavf/ftp: support credentials callback ffplay.c | 63 ++- libavformat/avio.c | 46 ++ libavformat/avio.h | 28 libavformat/ftp.c | 96 ++ libavformat/url.h | 12 +++ 5 files changed, 231 insertions(+), 14 deletions(-) -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Areas needing work
Hi I am interested in contributing to any of the projects.Please enroll me and tell me the procedure how can i contribute to ffmpeg Regards Mayank On Mon, Apr 6, 2015 at 10:18 PM, Timothy Gu wrote: > On Sun, Apr 5, 2015 at 8:43 PM Michael Niedermayer wrote: > >> Hi all >> >> There are various areas in the project that are not maintained as well as >> they >> should be, heres a certainly not comlpete list, dont hesitate to reply and >> add to it. >> If someone wants to pick something up and contribute that is VERY welcome >> >> * Post merge review&cleanup, changes merged from libav would benefit from >> people reviewing and MUCH MUCH more importantly also people actually >> caring >> about and taking responsibility not just dumping comments with the idea >> "someone" will fix it. >> Ideally each area would have a maintainer who takes care of it and >> keeps it in good nick. >> >> >> * fate clients >> we lack a armcc test, a real android test >> someone should take over haiku and sunos/solaris fate clients, my haiku >> VM just >> keeps crashing >> > > I can take care of the Haiku test if I have (access to) a better/faster > computer… > > >> * our fate server lacks the ability to display a user specified release >> this makes the output look quite unwieldy >> Timothy was working on a rewrite >> > > I haven't touched that thing in a few months but it's in a pretty good > shape. With a few minor updates it should be good to go at least on > fate-beta.ffmpeg.org or something like that. There are still a few minor > things I want to fix (like minirep/minilog, warning diff (is it really > useful now since most boxes are using make -jx and testing order changes > every time?), and some minor styling issue). > > [...] > >> * Decentralize >> Too many things are done and admined by me, iam doing security updates >> to the >> servers, doing the git merges, maintaining all releases, maintaining >> half the >> fate clients, submitting data to coverity and doing all the crap that >> noone >> else wants to do. >> Does the community care so little that they want me to be a single point >> of >> failure? >> We need people to take some of this over at least on the basis of a >> backup >> in case iam unavailable for whatever reason, and i think it should >> ideally >> be people who do not yet have their daily work shedule overflowing with >> ffmpeg >> work but better new volunteers. >> > > - Project servers: MAINTAINERS list four people [1], one of which I have > never > ever seen on this list, and it is not clear to me how the servers are > administered (who pays for it? who has access to it? who has access to the > hosting company's setting page?) [2] > - Git merges: when I first came to this project merges are still called > "Merge > from remote tracking branch 'qatar/master'." WTF is qatar? Now of course > that is not a problem any more, but the merges remain undocumented on any > official documentation I could find (maybe I didn't look hard enough?). If > the behavior itself is not known publicly how can anyone help? > - Coverity: one can easily hook it up to a FATE box. > > [1]: https://github.com/FFmpeg/FFmpeg/blob/master/MAINTAINERS#L48 > [2]: Yes I guess I can ask on IRC or whatever but I am lazy, and I know that > there are people lazier than me. If it is so hard to find out how to > *volunteer* I would not imagine many people trying to volunteer. > > But anyway, I can volunteer to take over coverage.ffmpeg.org. But again who > should I find to discuss this thing in detail? Michael? Clément? I don't > know. > > Also a news article on a call for maintainers would be beneficial (?). > > Timothy > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] hqx codec patch: faster decode with multi threaded decoding of slices; fixed clipping bug
From e750ddd8b1b79cfad04f2cdd58b5ba438390adf1 Mon Sep 17 00:00:00 2001
From: fo
Date: Mon, 6 Apr 2015 15:47:14 +0200
Subject: [PATCH 1/2] libavcodec/hqx: made decoding multi threaded!
---
libavcodec/hqx.c | 142
+++
libavcodec/hqx.h | 9 +++-
2 files changed, 99 insertions(+), 52 deletions(-)
diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c
index d7e605f..ee851ed 100644
--- a/libavcodec/hqx.c
+++ b/libavcodec/hqx.c
@@ -39,7 +39,7 @@ enum HQXFormat {
#define HQX_HEADER_SIZE 59
-typedef int (*mb_decode_func)(HQXContext *ctx, AVFrame *pic,
+typedef int (*mb_decode_func)(HQXContext *ctx, slice_data_t * slice_data,
AVFrame *pic,
GetBitContext *gb, int x, int y);
/* macroblock selects a group of 4 possible quants and
@@ -260,7 +260,7 @@ static int decode_block(GetBitContext *gb, VLC *vlc,
return 0;
}
-static int hqx_decode_422(HQXContext *ctx, AVFrame *pic,
+static int hqx_decode_422(HQXContext *ctx, slice_data_t * slice_data,
AVFrame *pic,
GetBitContext *gb, int x, int y)
{
const int *quants;
@@ -280,20 +280,20 @@ static int hqx_decode_422(HQXContext *ctx, AVFrame
*pic,
if (i == 0 || i == 4 || i == 6)
last_dc = 0;
ret = decode_block(gb, &ctx->dc_vlc[vlc_index], quants,
- ctx->dcb, ctx->block[i], &last_dc);
+ ctx->dcb, slice_data->block[i], &last_dc);
if (ret < 0)
return ret;
}
-put_blocks(pic, 0, x, y, flag, ctx->block[0], ctx->block[2],
hqx_quant_luma);
-put_blocks(pic, 0, x + 8, y, flag, ctx->block[1], ctx->block[3],
hqx_quant_luma);
-put_blocks(pic, 2, x >> 1, y, flag, ctx->block[4], ctx->block[5],
hqx_quant_chroma);
-put_blocks(pic, 1, x >> 1, y, flag, ctx->block[6], ctx->block[7],
hqx_quant_chroma);
+put_blocks(pic, 0, x, y, flag, slice_data->block[0],
slice_data->block[2], hqx_quant_luma);
+put_blocks(pic, 0, x + 8, y, flag, slice_data->block[1],
slice_data->block[3], hqx_quant_luma);
+put_blocks(pic, 2, x >> 1, y, flag, slice_data->block[4],
slice_data->block[5], hqx_quant_chroma);
+put_blocks(pic, 1, x >> 1, y, flag, slice_data->block[6],
slice_data->block[7], hqx_quant_chroma);
return 0;
}
-static int hqx_decode_422a(HQXContext *ctx, AVFrame *pic,
+static int hqx_decode_422a(HQXContext *ctx, slice_data_t * slice_data,
AVFrame *pic,
GetBitContext *gb, int x, int y)
{
const int *quants;
@@ -305,9 +305,9 @@ static int hqx_decode_422a(HQXContext *ctx, AVFrame
*pic,
cbp = get_vlc2(gb, ctx->cbp_vlc.table, ctx->cbp_vlc.bits, 1);
for (i = 0; i < 12; i++)
-memset(ctx->block[i], 0, sizeof(**ctx->block) * 64);
+memset(slice_data->block[i], 0, sizeof(**slice_data->block) * 64);
for (i = 0; i < 12; i++)
-ctx->block[i][0] = -0x800;
+slice_data->block[i][0] = -0x800;
if (cbp) {
if (ctx->interlaced)
flag = get_bits1(gb);
@@ -325,24 +325,24 @@ static int hqx_decode_422a(HQXContext *ctx, AVFrame
*pic,
if (cbp & (1 << i)) {
int vlc_index = ctx->dcb - 9;
ret = decode_block(gb, &ctx->dc_vlc[vlc_index], quants,
- ctx->dcb, ctx->block[i], &last_dc);
+ctx->dcb, slice_data->block[i], &last_dc);
if (ret < 0)
return ret;
}
}
}
-put_blocks(pic, 3, x, y, flag, ctx->block[ 0], ctx->block[ 2],
hqx_quant_luma);
-put_blocks(pic, 3, x + 8, y, flag, ctx->block[ 1], ctx->block[ 3],
hqx_quant_luma);
-put_blocks(pic, 0, x, y, flag, ctx->block[ 4], ctx->block[ 6],
hqx_quant_luma);
-put_blocks(pic, 0, x + 8, y, flag, ctx->block[ 5], ctx->block[ 7],
hqx_quant_luma);
-put_blocks(pic, 2, x >> 1, y, flag, ctx->block[ 8], ctx->block[ 9],
hqx_quant_chroma);
-put_blocks(pic, 1, x >> 1, y, flag, ctx->block[10], ctx->block[11],
hqx_quant_chroma);
+put_blocks(pic, 3, x, y, flag, slice_data->block[ 0],
slice_data->block[ 2], hqx_quant_luma);
+put_blocks(pic, 3, x + 8, y, flag, slice_data->block[ 1],
slice_data->block[ 3], hqx_quant_luma);
+put_blocks(pic, 0, x, y, flag, slice_data->block[ 4],
slice_data->block[ 6], hqx_quant_luma);
+put_blocks(pic, 0, x + 8, y, flag, slice_data->block[ 5],
slice_data->block[ 7], hqx_quant_luma);
+put_blocks(pic, 2, x >> 1, y, flag, slice_data->block[ 8],
slice_data->block[ 9], hqx_quant_chroma);
+put_blocks(pic, 1, x >> 1, y, flag, slice_data->block[10],
slice_data->block[11], hqx_quant_chroma);
return 0;
}
-static int hqx_decode_444(HQXContext *ctx, AVFrame *pic,
+static int hqx_decode_444(HQXContext *ctx, slice_data_t * slice_data,
AVFrame *pic,
GetBitContext *gb, int x, int y)
{
const int *quants;
@@ -362,22 +362,22 @@ static int hqx_decode_444(HQXCo
Re: [FFmpeg-devel] [PATCH] webmdashenc: Fix fate in MSVC
On Tue, Apr 7, 2015 at 12:50 PM, Michael Niedermayer wrote: > On Tue, Apr 07, 2015 at 12:21:02PM -0700, Vignesh Venkatasubramanian wrote: >> MSVC does not support the %F and %T format specifiers in strftime. >> Replace that with the expanded version. This fixes the broken fate >> tests in MSVC (webm-dash-manifest-*). >> >> Signed-off-by: Vignesh Venkatasubramanian >> --- >> libavformat/webmdashenc.c | 19 +-- >> 1 file changed, 9 insertions(+), 10 deletions(-) > > applied > > also this seems missing a malloc failure check, but that was > missig before already will fix in in a subsequent patch. thanks for applying! > > thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Into a blind darkness they enter who follow after the Ignorance, > they as if into a greater darkness enter who devote themselves > to the Knowledge alone. -- Isha Upanishad > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > -- Vignesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] webmdashenc: Fix fate in MSVC
On Tue, Apr 07, 2015 at 12:21:02PM -0700, Vignesh Venkatasubramanian wrote: > MSVC does not support the %F and %T format specifiers in strftime. > Replace that with the expanded version. This fixes the broken fate > tests in MSVC (webm-dash-manifest-*). > > Signed-off-by: Vignesh Venkatasubramanian > --- > libavformat/webmdashenc.c | 19 +-- > 1 file changed, 9 insertions(+), 10 deletions(-) applied also this seems missing a malloc failure check, but that was missig before already thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] microdvd: do not export framerate hint as subtitle packet
MicroDVD has a "hack" for specifying the video framerate the subtitle
was authored against. The demuxer reads this hint correctly, but didn't
skip it correctly.
This was not noticed, because the exported packet has its duration set
to 0, making it invisible (depending on the API user's rendering logic).
---
libavformat/microdvddec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/microdvddec.c b/libavformat/microdvddec.c
index ce3433c..a383905 100644
--- a/libavformat/microdvddec.c
+++ b/libavformat/microdvddec.c
@@ -112,6 +112,7 @@ static int microdvd_read_header(AVFormatContext *s)
&& frame <= 1 && fps > 3 && fps < 100) {
pts_info = av_d2q(fps, 10);
has_real_fps = 1;
+continue;
}
if (!st->codec->extradata && sscanf(line, "{DEFAULT}{}%c", &c) ==
1) {
st->codec->extradata = av_strdup(line + 11);
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Areas needing work
On date Tuesday 2015-04-07 14:40:50 +0100, Derek Buitenhuis encoded: > On 4/6/2015 11:23 PM, compn wrote: > > i think we tried this a few years ago and found that we do still have > > ffserver users, they are just quiet until we threaten to rm it. if/when > > it breaks, someone will either be there to fix it or it will rot. > > That's stupid. Either someone steps up to fix it (read: actually cares), > or it remove it. Having a broken piece of crap that nobody cares about > in the repo benefits nobody. I did some consulting about the use of ffserver in the past, with variying degrees of success (hint: RTP streaming is usually tricky and highly depends on network and bandwith constraints). I agree that ffserver is painfully underkill, but still better than nothing. Also we have an official maintainer and some substantial work has been done on it recently. Use cases: real time streaming of interactive content through HTTP or RTSP/RTP. Probably these days there are better solutions but I think ffserver still cover an use case which cannot be fullfilled by the other FFmpeg tools. At the present days there are probably other valid alternatives (e.g. Flash/RTMP, webRTC, HTML5/Media Source Extensions, JavaScript native decoding + websockets, HLS, DASH) which cover similar areas, but are not completely equivalent. For example HLS is known to introduce some significative delay. -- FFmpeg = Fundamentalist & Fiendish Multimedia Pitiful Elfic Game ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Areas needing work
On 4/6/2015 11:23 PM, compn wrote: > i think we tried this a few years ago and found that we do still have > ffserver users, they are just quiet until we threaten to rm it. if/when > it breaks, someone will either be there to fix it or it will rot. That's stupid. Either someone steps up to fix it (read: actually cares), or it remove it. Having a broken piece of crap that nobody cares about in the repo benefits nobody. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: Add support for WebM Live Muxing
On Mon, Apr 06, 2015 at 02:52:24PM -0700, Vignesh Venkatasubramanian wrote:
> On Mon, Apr 6, 2015 at 2:25 PM, Michael Niedermayer wrote:
> > On Mon, Apr 06, 2015 at 11:19:36AM -0700, Vignesh Venkatasubramanian wrote:
> >> On Sat, Apr 4, 2015 at 3:38 PM, Michael Niedermayer
> >> wrote:
> >> > On Mon, Mar 30, 2015 at 02:46:10PM -0700, Vignesh Venkatasubramanian
> >> > wrote:
> >> >> This patch adds support for WebM Live Muxing by adding a new WebM
> >> >> Chunk muxer. It writes out live WebM Chunks which can be used for
> >> >> playback using Live DASH Clients.
> >> >>
> >> >> Please see muxers.texi for sample usage.
> >> >
> >> > [...]
> >> >
> >> >> diff --git a/libavformat/version.h b/libavformat/version.h
> >> >> index a183d7f..ff85227 100644
> >> >> --- a/libavformat/version.h
> >> >> +++ b/libavformat/version.h
> >> >> @@ -30,7 +30,7 @@
> >> >> #include "libavutil/version.h"
> >> >>
> >> >> #define LIBAVFORMAT_VERSION_MAJOR 56
> >> >> -#define LIBAVFORMAT_VERSION_MINOR 26
> >> >> +#define LIBAVFORMAT_VERSION_MINOR 27
> >> >> #define LIBAVFORMAT_VERSION_MICRO 101
> >> >>
> >> >> #define LIBAVFORMAT_VERSION_INT
> >> >> AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> >> >> diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
> >> >> new file mode 100644
> >> >> index 000..48ea6f0
> >> >> --- /dev/null
> >> >> +++ b/libavformat/webm_chunk.c
> >> >> @@ -0,0 +1,262 @@
> >> >> +/*
> >> >> + * Copyright (c) 2015, Vignesh Venkatasubramanian
> >> >> + *
> >> >> + * 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
> >> >> + */
> >> >> +
> >> >> +/**
> >> >> + * @file WebM Chunk Muxer
> >> >> + * The chunk muxer enables writing WebM Live chunks where there is a
> >> >> header
> >> >> + * chunk, followed by data chunks where each Cluster is written out as
> >> >> a Chunk.
> >> >> + */
> >> >> +
> >> >> +#include
> >> >> +#include
> >> >> +
> >> >> +#include "avformat.h"
> >> >> +#include "avio.h"
> >> >> +#include "internal.h"
> >> >> +
> >> >> +#include "libavutil/avassert.h"
> >> >> +#include "libavutil/log.h"
> >> >> +#include "libavutil/opt.h"
> >> >> +#include "libavutil/avstring.h"
> >> >> +#include "libavutil/parseutils.h"
> >> >> +#include "libavutil/mathematics.h"
> >> >> +#include "libavutil/time.h"
> >> >> +#include "libavutil/time_internal.h"
> >> >> +#include "libavutil/timestamp.h"
> >> >> +
> >> >> +typedef struct WebMChunkContext {
> >> >> +const AVClass *class;
> >> >> +int chunk_start_index;
> >> >> +char *header_filename;
> >> >> +int chunk_duration;
> >> >> +int chunk_count;
> >> >> +int chunk_index;
> >> >> +uint64_t duration_written;
> >> >> +int prev_pts;
> >> >> +AVOutputFormat *oformat;
> >> >> +AVFormatContext *avf;
> >> >> +} WebMChunkContext;
> >> >> +
> >> >> +static int chunk_mux_init(AVFormatContext *s)
> >> >> +{
> >> >> +WebMChunkContext *wc = s->priv_data;
> >> >> +AVFormatContext *oc;
> >> >> +int ret;
> >> >> +
> >> >> +ret = avformat_alloc_output_context2(&wc->avf, wc->oformat, NULL,
> >> >> NULL);
> >> >> +if (ret < 0)
> >> >> +return ret;
> >> >> +oc = wc->avf;
> >> >> +
> >> >> +oc->interrupt_callback = s->interrupt_callback;
> >> >> +oc->max_delay = s->max_delay;
> >> >> +av_dict_copy(&oc->metadata, s->metadata, 0);
> >> >> +
> >> >> +oc->priv_data = av_mallocz(oc->oformat->priv_data_size);
> >> >> +if (!oc->priv_data) {
> >> >> +avio_close(oc->pb);
> >> >> +return AVERROR(ENOMEM);
> >> >> +}
> >> >> +*(const AVClass**)oc->priv_data = oc->oformat->priv_class;
> >> >> +av_opt_set_defaults(oc->priv_data);
> >> >> +av_opt_set_int(oc->priv_data, "dash", 1, 0);
> >> >> +av_opt_set_int(oc->priv_data, "cluster_time_limit",
> >> >> wc->chunk_duration, 0);
> >> >> +av_opt_set_int(oc->priv_data, "live", 1, 0);
> >> >> +
> >> >
> >> >> +oc->streams = s->streams;
> >> >> +oc->nb_streams = s->nb_streams;
> >> >
> >> > why doesnt the code use avformat_new_stream() and avcodec_copy_context()
> >> > see hlsenc/segment muxers for examples
> >> >
> >> > or is there a reason why this would not
Re: [FFmpeg-devel] [PATCH] avformat: Drop const qualifier to avoid compiler warning
On Tue, Apr 07, 2015 at 03:31:25AM +0530, Himangi Saraogi wrote: > --- > libavformat/format.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavformat/format.c b/libavformat/format.c > index fa94b7d..0713849 100644 > --- a/libavformat/format.c > +++ b/libavformat/format.c > @@ -172,7 +172,8 @@ AVInputFormat *av_probe_input_format3(AVProbeData *pd, > int is_opened, > AVProbeData lpd = *pd; > AVInputFormat *fmt1 = NULL, *fmt; > int score, nodat = 0, score_max = 0; > -const static uint8_t zerobuffer[AVPROBE_PADDING_SIZE]; > +static uint8_t zerobuffer[AVPROBE_PADDING_SIZE]; the buffer should never be changed, so const seems correct if its not const, a human reader might think "can this change? its not const" a cast where the warning ocurs or replacing the const by a comment seems better [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. 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/apng: Do not print a warning when writing pngs
On Tue, Apr 07, 2015 at 12:19:03PM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch stops FFmpeg from printing a warning in > the normal use case. > > Please comment, Carl Eugen 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
Re: [FFmpeg-devel] Areas needing work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/04/15 21:00, Michael Niedermayer wrote: [..] > we need to move things to a new server (we already have one but > against expectations moving things over is happening at a snails pace) > ATM fate-suite and samples are on the new server, rest is still on the > old. The reason for the need to move is the aging platform and > potential lack of future security support for it ... > maybe beastd and lou can comment on this as beastd was the one who did > most of the work that was done sofar and lou seemed to be willing to > help. > question is do we need another volunteer to make this move happen? > [...] As indicated elsewhere I am happy to assist with the bits I know about and have fiddled with in the past ;) - -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJVI8pfAAoJEAwL/ESLC/yD/BkH/3wCkyNG53mhW5YUcmlbFhhx 3MCdjKp/nzsvzMh43/UJEapTqdmQquAAQL2Sqv/pP96Ol8RYq1zPikjntdTUslP0 XFlD6eRqfIpuhZzn3IpmhxPYtxAzgydKppXIiL60borVGMsLfHBGfcphSKSP9Yx9 E+gaB6byoLS3nIWPFzWLWr6PE84OmnM4UDPZOQtZC249eaW6PkoZ4LcNhpOmxULI X0cwt2aQvptgwB/wFCofikC6n3dWKE0fFpixfPvBGd0jNyNgADHrHX8pXaa7kCAJ jBi4QKDI3JhuD6u1xWQO97LoiL9NlcaoBSzcmwAkGm4yeo8KAw0hnawTGaZ0DgY= =VvqM -END PGP SIGNATURE- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Backporting tests/fate.sh: report different status for different errors
On Tue, Apr 07, 2015 at 04:17:49AM +, Timothy Gu wrote: > Hi all, > > The aforementioned commit: > > From cc0057a31c7097839f9c4e4da61e2933b5b0e055 Mon Sep 17 00:00:00 2001 > From: Timothy Gu > Date: Mon, 9 Jun 2014 21:46:37 -0700 > Subject: [PATCH] tests/fate.sh: report different status for different errors > > The order of error codes will be useful in my future fateserver patches. > > Signed-off-by: Timothy Gu > Signed-off-by: Michael Niedermayer > > is only in release/2.3 and later, causing it to wreck major havoc when > results from 2.2 or older branches are submitted to the new fateserver. > > Please find branches: > > - release/1.2 > - release/2.0 > - release/2.1 > - release/2.2 i didnt see the commit in your release/1.2 ive locally backported the others and pushed 2.2 i dont think anyone tests 2.0/2.1 anymore [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Error in mpegaudio_parser.c
On Mon, Apr 06, 2015 at 03:58:59PM -0700, Dan Haddix wrote: > I think this line in mpegaudio_parser.c is wrong > > int header_threshold = avctx->codec_id != AV_CODEC_ID_NONE && avctx->codec_id > != codec_id; > > I believe it should be... > > int header_threshold = avctx->codec_id != AV_CODEC_ID_NONE && avctx->codec_id > == codec_id; > > I believe the intention of the line is to skip setting the params if they > were already set correctly by the container demuxer. However the current code > skips the setting of the params when the codec_ids do not match rather then > when they do, which is incorrect. the intent of the line is to prevent changing the codec id when theres a single faulty packet > > I have a file which is an MP4 with MP2 audio. The demuxer sets the codec_id > to MP3. With the current code the parser skips over setting the params and > leaves the codec_id set to MP3, which is incorrect. If I make the change I > suggested then it works correctly. please open a ticket on trac and upload the file i would say the first area to look at is the mp4 demuxer which sets the codec id to mp3 (which would be incorrect if it was mp1) so if you want to fix it first would be to look at if the demuxer can be made to detect this and set it correctly in the first place only if that is not practical/easy should we fall back on later stages overriding [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/apng: Do not print a warning when writing pngs
Hi!
Attached patch stops FFmpeg from printing a warning in
the normal use case.
Please comment, Carl Eugen
diff --git a/libavformat/apngenc.c b/libavformat/apngenc.c
index 8dbe9e4..4b31309 100644
--- a/libavformat/apngenc.c
+++ b/libavformat/apngenc.c
@@ -114,7 +114,7 @@ static void flush_packet(AVFormatContext *format_context,
AVPacket *packet)
uint8_t *existing_acTL_chunk;
uint8_t *existing_fcTL_chunk;
-av_log(format_context, AV_LOG_WARNING, "Only a single frame so saving
as a normal PNG.\n");
+av_log(format_context, AV_LOG_INFO, "Only a single frame so saving as
a normal PNG.\n");
// Write normal PNG headers without acTL chunk
existing_acTL_chunk = apng_find_chunk(MKBETAG('a', 'c', 'T', 'L'),
codec_context->extradata, codec_context->extradata_size);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
