[FFmpeg-devel] [PATCH] Ignore expired cookies

2017-02-11 Thread Micah Galizia
---
 libavformat/http.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 944a6cf..24368aa 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -682,12 +682,46 @@ static int parse_icy(HTTPContext *s, const char *tag, 
const char *p)
 
 static int parse_cookie(HTTPContext *s, const char *p, AVDictionary **cookies)
 {
-char *eql, *name;
+char *eql, *name, *expiry;
 
 // duplicate the cookie name (dict will dupe the value)
 if (!(eql = strchr(p, '='))) return AVERROR(EINVAL);
 if (!(name = av_strndup(p, eql - p))) return AVERROR(ENOMEM);
 
+// ensure the expiry is sane
+if ((expiry = strstr(eql, "Expires="))) {
+struct tm tm_buf = {0};
+char *end;
+
+// get the start & the end of the expiry ('11 Feb 2017 09:41:35 GMT')
+// this skips past the day of the week by finding the space following 
it
+expiry += 8 * sizeof(char);
+while (*expiry != ' ') expiry++;
+expiry++;
+end = expiry+1;
+while (*end != ';') end++;
+
+// ensure the time is parsable
+end = strptime(expiry, "%d %b %Y %H:%M:%S %Z", &tm_buf);
+
+// ensure neulion's different format is parsable
+if (!end) end = strptime(expiry, "%d-%b-%Y %H:%M:%S %Z", &tm_buf);
+
+// if the expire is specified but unparsable, this cookie is invalid
+if (!end) {
+av_log(s, AV_LOG_ERROR, "Unable to parse expiry for cookie 
'%s'\n", p);
+av_free(name);
+return AVERROR(EINVAL);
+}
+
+// no cookies from the past (neulion)
+if (mktime(&tm_buf) < time(NULL)) {
+av_log(s, AV_LOG_ERROR, "Ignoring cookie from the past '%s'\n", p);
+av_free(name);
+return AVERROR(EINVAL);
+}
+}
+
 // add the cookie to the dictionary
 av_dict_set(cookies, name, eql, AV_DICT_DONT_STRDUP_KEY);
 
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] Ignore expired cookies

2017-02-11 Thread Micah Galizia
This one fixes the memory leak -- sorry for all the spam.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] Ignore expired cookies

2017-02-11 Thread Micah Galizia
Signed-off-by: Micah Galizia 
---
 libavformat/http.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 944a6cf..e7b8ac3 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -682,12 +682,44 @@ static int parse_icy(HTTPContext *s, const char *tag, 
const char *p)
 
 static int parse_cookie(HTTPContext *s, const char *p, AVDictionary **cookies)
 {
-char *eql, *name;
+char *eql, *name, *expiry;
 
 // duplicate the cookie name (dict will dupe the value)
 if (!(eql = strchr(p, '='))) return AVERROR(EINVAL);
 if (!(name = av_strndup(p, eql - p))) return AVERROR(ENOMEM);
 
+// ensure the expiry is sane
+if ((expiry = strstr(eql, "Expires="))) {
+struct tm tm_buf = {0};
+char *end;
+
+// get the start & the end of the expiry ('11 Feb 2017 09:41:35 GMT')
+// this skips past the day of the week by finding the space following 
it
+expiry += 8 * sizeof(char);
+while (*expiry != ' ') expiry++;
+expiry++;
+end = expiry+1;
+while (*end != ';') end++;
+
+// ensure the time is parsable
+end = strptime(expiry, "%d %b %Y %H:%M:%S %Z", &tm_buf);
+
+// ensure neulion's different format is parsable
+if (!end) end = strptime(expiry, "%d-%b-%Y %H:%M:%S %Z", &tm_buf);
+
+// if the expire is specified but unparsable, this cookie is invalid
+if (!end) {
+av_log(s, AV_LOG_ERROR, "Unable to parse expiry for cookie 
'%s'\n", p);
+return AVERROR(EINVAL);
+}
+
+// no cookies from the past (neulion)
+if (mktime(&tm_buf) < time(NULL)) {
+av_log(s, AV_LOG_ERROR, "Ignoring cookie from the past '%s'\n", p);
+return AVERROR(EINVAL);
+}
+}
+
 // add the cookie to the dictionary
 av_dict_set(cookies, name, eql, AV_DICT_DONT_STRDUP_KEY);
 
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] Ignore expired cookies

2017-02-11 Thread Micah Galizia
Appologies, gmail screwed up the patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] Ignore expired cookies

2017-02-11 Thread Micah Galizia
Hello,

On some authenticated Neulion streams, they send a cookie from the past,
like so:

Set-Cookie: nlqptid=""; Domain=.neulion.com; Expires=Thu, 01-Jan-1970
00:00:10 GMT; Path=/

As a result, the good cookie value is overwritten and authentication breaks
immediately. I realise disqualifying a cookie over the date might open a
can of worms when it comes to date formatting used by different systems,
but I added Neulions wrong format and the http standard format.

Please let me know if this is acceptable. I've run it against fate and
there were no problems.
-- 
"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
From 1fecda5a7a36b530208a9428b86eebda66b0 Mon Sep 17 00:00:00 2001
From: Micah Galizia 
Date: Sat, 11 Feb 2017 21:18:41 -0500
Subject: [PATCH] Ignore expired cookies

Signed-off-by: Micah Galizia 
---
 libavformat/http.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 944a6cf..e7b8ac3 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -682,12 +682,44 @@ static int parse_icy(HTTPContext *s, const char *tag, const char *p)
 
 static int parse_cookie(HTTPContext *s, const char *p, AVDictionary **cookies)
 {
-char *eql, *name;
+char *eql, *name, *expiry;
 
 // duplicate the cookie name (dict will dupe the value)
 if (!(eql = strchr(p, '='))) return AVERROR(EINVAL);
 if (!(name = av_strndup(p, eql - p))) return AVERROR(ENOMEM);
 
+// ensure the expiry is sane
+if ((expiry = strstr(eql, "Expires="))) {
+struct tm tm_buf = {0};
+char *end;
+
+// get the start & the end of the expiry ('11 Feb 2017 09:41:35 GMT')
+// this skips past the day of the week by finding the space following it
+expiry += 8 * sizeof(char);
+while (*expiry != ' ') expiry++;
+expiry++;
+end = expiry+1;
+while (*end != ';') end++;
+
+// ensure the time is parsable
+end = strptime(expiry, "%d %b %Y %H:%M:%S %Z", &tm_buf);
+
+// ensure neulion's different format is parsable
+if (!end) end = strptime(expiry, "%d-%b-%Y %H:%M:%S %Z", &tm_buf);
+
+// if the expire is specified but unparsable, this cookie is invalid
+if (!end) {
+av_log(s, AV_LOG_ERROR, "Unable to parse expiry for cookie '%s'\n", p);
+return AVERROR(EINVAL);
+}
+
+// no cookies from the past (neulion)
+if (mktime(&tm_buf) < time(NULL)) {
+av_log(s, AV_LOG_ERROR, "Ignoring cookie from the past '%s'\n", p);
+return AVERROR(EINVAL);
+}
+}
+
 // add the cookie to the dictionary
 av_dict_set(cookies, name, eql, AV_DICT_DONT_STRDUP_KEY);
 
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix stream level metadata handling

2017-02-11 Thread Steven Liu
2017-02-12 5:31 GMT+08:00 Bodecs Bela :

> Dear All,
>
> hls-encoder currently does not provide stream level metadata to mpegts
> muxer. This patch also fixes track #3848 bug.
>
> Please review this bug fix. Thank you in advance.
>
>
> best regards,
>
> Bela Bodecs
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>


hls-encoder currenlty does not provide stream level metadata to mpegts
muxer. This patch fixes track #3848 bug.

Signed-off-by: Bela Bodecs 
---
 libavformat/hlsenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bd1e684..a58ded9 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -446,6 +446,7 @@ static int hls_mux_init(AVFormatContext *s)
 avcodec_parameters_copy(st->codecpar, s->streams[i]->codecpar);
 st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio;
 st->time_base = s->streams[i]->time_base;
+av_dict_copy(&st->metadata, s->streams[i]->metadata, 0);
 }
 hls->start_pos = 0;
 hls->new_start = 1;
-- 
2.5.3.windows.1




LGTM





Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavc/libzvbi: remove deprecated API usage

2017-02-11 Thread Carl Eugen Hoyos
2017-02-12 0:23 GMT+01:00 Josh de Kock :

> -if (!vbi_event_handler_add(ctx->vbi, VBI_EVENT_TTX_PAGE, handler, 
> ctx)) {
> +if (!vbi_event_handler_register(ctx->vbi, VBI_EVENT_TTX_PAGE, 
> handler, ctx)) {
>  vbi_decoder_delete(ctx->vbi);
>  ctx->vbi = NULL;
>  return AVERROR(ENOMEM);
> @@ -524,8 +524,12 @@ static int teletext_close_decoder(AVCodecContext *avctx)
>  subtitle_rect_free(&ctx->pages[--ctx->nb_pages].sub_rect);
>  av_freep(&ctx->pages);
>
> -vbi_decoder_delete(ctx->vbi);
> -ctx->vbi = NULL;
> +if (ctx->vbi) {
> +vbi_event_handler_unregister(ctx->vbi, handler, ctx);

Does this work with 0.2.28?

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] lavc/libzvbi: remove deprecated API usage

2017-02-11 Thread Josh de Kock
Signed-off-by: Josh de Kock 
---
 libavcodec/libzvbi-teletextdec.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavcodec/libzvbi-teletextdec.c b/libavcodec/libzvbi-teletextdec.c
index d1f0a9f..2ed4a82 100644
--- a/libavcodec/libzvbi-teletextdec.c
+++ b/libavcodec/libzvbi-teletextdec.c
@@ -395,7 +395,7 @@ static int teletext_decode_frame(AVCodecContext *avctx, 
void *data, int *data_si
 if (!ctx->vbi) {
 if (!(ctx->vbi = vbi_decoder_new()))
 return AVERROR(ENOMEM);
-if (!vbi_event_handler_add(ctx->vbi, VBI_EVENT_TTX_PAGE, handler, 
ctx)) {
+if (!vbi_event_handler_register(ctx->vbi, VBI_EVENT_TTX_PAGE, handler, 
ctx)) {
 vbi_decoder_delete(ctx->vbi);
 ctx->vbi = NULL;
 return AVERROR(ENOMEM);
@@ -524,8 +524,12 @@ static int teletext_close_decoder(AVCodecContext *avctx)
 subtitle_rect_free(&ctx->pages[--ctx->nb_pages].sub_rect);
 av_freep(&ctx->pages);
 
-vbi_decoder_delete(ctx->vbi);
-ctx->vbi = NULL;
+if (ctx->vbi) {
+vbi_event_handler_unregister(ctx->vbi, handler, ctx);
+vbi_decoder_delete(ctx->vbi);
+ctx->vbi = NULL;
+}
+
 ctx->pts = AV_NOPTS_VALUE;
 if (!(avctx->flags2 & AV_CODEC_FLAG2_RO_FLUSH_NOOP))
 ctx->readorder = 0;
-- 
2.10.1 (Apple Git-78)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avformat/hlsenc: fix stream level metadata handling

2017-02-11 Thread Bodecs Bela

Dear All,

hls-encoder currently does not provide stream level metadata to mpegts
muxer. This patch also fixes track #3848 bug.

Please review this bug fix. Thank you in advance.


best regards,

Bela Bodecs

>From 06a5e2dff962d0e2127ddbb00f6bd8a3d03d3e51 Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Sat, 11 Feb 2017 22:22:24 +0100
Subject: [PATCH] avformat/hlsenc: fix stream level metadata handling

hls-encoder currenlty does not provide stream level metadata to mpegts
muxer. This patch fixes track #3848 bug.

Signed-off-by: Bela Bodecs 
---
 libavformat/hlsenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bd1e684..a58ded9 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -446,6 +446,7 @@ static int hls_mux_init(AVFormatContext *s)
 avcodec_parameters_copy(st->codecpar, s->streams[i]->codecpar);
 st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio;
 st->time_base = s->streams[i]->time_base;
+av_dict_copy(&st->metadata, s->streams[i]->metadata, 0);
 }
 hls->start_pos = 0;
 hls->new_start = 1;
-- 
2.5.3.windows.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

2017-02-11 Thread u-9iep
Hello,

This is my best effort attempt to make the patch acceptable
by the upstream's criteria.

Daniel, do you mind that I referred to your message in the commit?
I believe is is best to indicate numbers from a third party measurement.

The code seems to be equvalent to the previous patch,
with about 20% less LOC.

This hurts readability (my subjective impression) but on the positive side
the change makes the structure of the code more explicit.

Attaching the patch.

Now I have done what I can, have to leave.
Unless there are bugs there in the patch, my attempt to contribute ends
at this point.

Thanks to everyone who cared to objectively discuss a specific case
of ffmpeg usage, the implications of techniques around VQ and whether/why
some non-traditional approaches can make sense.

Good luck to the ffmpeg project, it is very useful and valuable.

Best regards,
Rune
>From 0c9badec5d144b995c0bb52c7a80939b672be3f5 Mon Sep 17 00:00:00 2001
From: Rl 
Date: Sat, 11 Feb 2017 20:28:54 +0100
Subject: [PATCH] Cinepak: speed up decoding several-fold, depending on the
 scenario, by supporting multiple output pixel formats.

Decoding to rgb24 and pal8 is optimized.

Added rgb32, rgb565, yuv420p, each with faster decoding than to rgb24.

The most noticeable gain is achieved by the created possibility
to skip format conversions, for example when decoding to rgb565

Using matrixbench_mpeg2.mpg (720x567) encoded with ffmpeg into Cinepak
using default settings, decoding on an i5 3570K, 3.4 GHz:

bicubic (default):  ~24x realtime
fast_bilinear:  ~65x realtime
patch w/rgb565 override:~154x realtime

(https://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/206799.html)

palettized input can be decoded to any of the output formats,
pal8 output is still limited to palettized input

with input other than palettized/grayscale
yuv420 is approximated by the Cinepak colorspace

The output format can be chosen at runtime by an option or via the API.
---
 libavcodec/cinepak.c | 844 +--
 1 file changed, 692 insertions(+), 152 deletions(-)

diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
index d657e9c0c1..7b08e20e06 100644
--- a/libavcodec/cinepak.c
+++ b/libavcodec/cinepak.c
@@ -31,6 +31,8 @@
  *
  * Cinepak colorspace support (c) 2013 Rl, Aetey Global Technologies AB
  * @author Cinepak colorspace, Rl, Aetey Global Technologies AB
+ * Extra output formats / optimizations (c) 2017 Rl, Aetey Global Technologies 
AB
+ * @author Extra output formats / optimizations, Rl, Aetey Global Technologies 
AB
  */
 
 #include 
@@ -39,23 +41,48 @@
 
 #include "libavutil/common.h"
 #include "libavutil/intreadwrite.h"
+#include "libavutil/opt.h"
+/* #include "libavutil/avassert.h" */
 #include "avcodec.h"
 #include "internal.h"
 
+/* rounding to nearest; truncation would be slightly faster
+ * but it noticeably affects the picture quality;
+ * unless we become extremely desperate to use every single cycle
+ * we do not bother implementing a choice -- rl */
+#define PACK_RGB_RGB565(r,g,b) 
(((av_clip_uint8((r)+4)>>3)<<11)|((av_clip_uint8((g)+2)>>2)<<5)|(av_clip_uint8((b)+4)>>3))
 
-typedef uint8_t cvid_codebook[12];
+/*
+ * more "desperate/ultimate" optimization possibilites:
+ * - possibly (hardly?) spare a cycle or two by not ensuring to stay
+ *   inside the frame at vector decoding (the frame is allocated with
+ *   a margin for us as an extra precaution, we can as well use this)
+ * - skip filling in opacity when it is not needed by the data consumer,
+ *   in many cases rgb32 is almost as fast as rgb565, with full quality,
+ *   improving its speed can make sense
+ */
+
+typedef union cvid_codebook {
+uint32_t  rgb32[256][ 4];
+uint8_t   rgb24[256][12];
+uint16_t rgb565[256][ 4];
+uint8_t  yuv420[256][ 6];
+uint8_tpal8[256][ 4];
+} cvid_codebook;
 
-#define MAX_STRIPS  32
+#define MAX_STRIPS  32/* an arbitrary limit -- rl */
 
 typedef struct cvid_strip {
 uint16_t  id;
 uint16_t  x1, y1;
 uint16_t  x2, y2;
-cvid_codebook v4_codebook[256];
-cvid_codebook v1_codebook[256];
+cvid_codebook v4_codebook;
+cvid_codebook v1_codebook;
 } cvid_strip;
 
-typedef struct CinepakContext {
+typedef struct CinepakContext CinepakContext;
+struct CinepakContext {
+const AVClass *class;
 
 AVCodecContext *avctx;
 AVFrame *frame;
@@ -71,57 +98,192 @@ typedef struct CinepakContext {
 int sega_film_skip_bytes;
 
 uint32_t pal[256];
-} CinepakContext;
 
-static void cinepak_decode_codebook (cvid_codebook *codebook,
- int chunk_id, int size, const uint8_t 
*data)
-{
-const uint8_t *eod = (data + size);
-uint32_t flag, mask;
-int  i, n;
-uint8_t *p;
-
-/* check if this chunk contains 4- or 6-element vectors */
-n= (chunk_id & 0x04) ? 4 : 6;
-flag = 0;
-mask = 0;
-
-p = codebook[0]

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add ffmpeg-security alias members

2017-02-11 Thread Paul B Mahol
On 2/10/17, Michael Niedermayer  wrote:
> Iam listing the reason for each, this is mostly my oppinion and i didnt ask
> most
> if they agree with the listed reason to be listed with their name, so its
> largly
> my oppinion. Which is why i will remove the reasons before pushing i just
> added them
> to be transparent on this but as said its mostly my oppinion, i just talked
> with ubitux and noone else ...
>
> Signed-off-by: Michael Niedermayer 
> ---
>  MAINTAINERS | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 80721e183d..39339d620d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -60,6 +60,11 @@ mailing lists   Baptiste
> Coudurier, Lou Logan
>  Google+ Paul B Mahol, Michael Niedermayer,
> Alexander Strasser
>  Twitter Lou Logan, Reynaldo H. Verdejo
> Pinochet
>  Launchpad   Timothy Gu
> +ffmpeg-security Andreas Cadhalpun (keeping
> debian/ubuntu packages secure, activly works on security)
> +Carl Eugen Hoyos (keeping track of
> every bug, testing, finding wrongly listed CVEs)
> +Clement Boesch (fix security issues
> in code i maintain)
> +Michael Niedermayer (fixing most
> reported issues)
> +Reimar Doeffinger (root admin able
> to fix issues on the server, occasional patch reviews)

I thought he is no longer active?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC/PATCH]lavf/omadec: Fix timestamps for Atrac 3 lossless

2017-02-11 Thread Carl Eugen Hoyos
2017-02-11 18:58 GMT+01:00 Paul B Mahol :
> On 2/11/17, Carl Eugen Hoyos  wrote:
>> 2017-02-11 18:25 GMT+01:00 Paul B Mahol :
>>> On 2/11/17, Carl Eugen Hoyos  wrote:
 2017-02-11 14:32 GMT+01:00 Paul B Mahol :
> On 2/11/17, Carl Eugen Hoyos  wrote:

>> Attached patch fixes timestamps and duration for
>> atrac_3_lossless_132kbps.aa3
>> from ticket #5334, the only Atrac 3 lossless sample I have.
>>
>> Please comment, Carl Eugen
>
> This is wrong thing to do, packets duration should be half
> of what is set for atrac3al.

 Where can this be done?
>>>
>>> In demuxer, when packet duration is set.
>>
>> New try attached.
>>
>> Thank you, Carl Eugen
>>
>
> lgtm

Patch applied.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC/PATCH]lavf/omadec: Fix timestamps for Atrac 3 lossless

2017-02-11 Thread Paul B Mahol
On 2/11/17, Carl Eugen Hoyos  wrote:
> 2017-02-11 18:25 GMT+01:00 Paul B Mahol :
>> On 2/11/17, Carl Eugen Hoyos  wrote:
>>> 2017-02-11 14:32 GMT+01:00 Paul B Mahol :
 On 2/11/17, Carl Eugen Hoyos  wrote:
>>>
> Attached patch fixes timestamps and duration for
> atrac_3_lossless_132kbps.aa3
> from ticket #5334, the only Atrac 3 lossless sample I have.
>
> Please comment, Carl Eugen

 This is wrong thing to do, packets duration should be half
 of what is set for atrac3al.
>>>
>>> Where can this be done?
>>
>> In demuxer, when packet duration is set.
>
> New try attached.
>
> Thank you, Carl Eugen
>

lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC/PATCH]lavf/omadec: Fix timestamps for Atrac 3 lossless

2017-02-11 Thread Carl Eugen Hoyos
2017-02-11 18:25 GMT+01:00 Paul B Mahol :
> On 2/11/17, Carl Eugen Hoyos  wrote:
>> 2017-02-11 14:32 GMT+01:00 Paul B Mahol :
>>> On 2/11/17, Carl Eugen Hoyos  wrote:
>>
 Attached patch fixes timestamps and duration for
 atrac_3_lossless_132kbps.aa3
 from ticket #5334, the only Atrac 3 lossless sample I have.

 Please comment, Carl Eugen
>>>
>>> This is wrong thing to do, packets duration should be half
>>> of what is set for atrac3al.
>>
>> Where can this be done?
>
> In demuxer, when packet duration is set.

New try attached.

Thank you, Carl Eugen
From 40b6497e7716372545083be6704058afb2d404e4 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 11 Feb 2017 18:53:18 +0100
Subject: [PATCH] lavf/omadec: Fix packet duration for Atrac 3 lossless.

---
 libavformat/omadec.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavformat/omadec.c b/libavformat/omadec.c
index 321e77e..fa53636 100644
--- a/libavformat/omadec.c
+++ b/libavformat/omadec.c
@@ -374,8 +374,13 @@ static int aal_read_packet(AVFormatContext *s, AVPacket *pkt)
 
 pkt->stream_index = 0;
 pkt->pos = pos;
-pkt->pts = pts * 2048LL;
-pkt->duration = 2048;
+if (s->streams[0]->codecpar->codec_id == AV_CODEC_ID_ATRAC3AL) {
+pkt->duration = 1024;
+pkt->pts = pts * 1024LL;
+} else {
+pkt->duration = 2048;
+pkt->pts = pts * 2048LL;
+}
 
 return ret;
 }
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/mpl2dec: skip BOM when probing

2017-02-11 Thread Clément Bœsch
On Sat, Feb 11, 2017 at 11:56:07AM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/mpl2dec.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/libavformat/mpl2dec.c b/libavformat/mpl2dec.c
> index 59589d5..0e30cb0 100644
> --- a/libavformat/mpl2dec.c
> +++ b/libavformat/mpl2dec.c
> @@ -23,6 +23,8 @@
>   * MPL2 subtitles format demuxer
>   */
>  
> +#include "libavutil/intreadwrite.h"
> +
>  #include "avformat.h"
>  #include "internal.h"
>  #include "subtitles.h"
> @@ -39,6 +41,9 @@ static int mpl2_probe(AVProbeData *p)
>  const unsigned char *ptr = p->buf;
>  const unsigned char *ptr_end = ptr + p->buf_size;
>  
> +if (AV_RB24(ptr) == 0xefbbbf)
> +ptr += 3;
> +
>  for (i = 0; i < 2; i++) {
>  if (sscanf(ptr, "[%"SCNd64"][%"SCNd64"]%c", &start, &end, &c) != 3 &&
>  sscanf(ptr, "[%"SCNd64"][]%c",  &start,   &c) != 2)
> @@ -94,6 +99,9 @@ static int mpl2_read_header(AVFormatContext *s)
>  if (!len)
>  break;
>  
> +if (AV_RB24(p) == 0xefbbbf)
> +p += 3;
> +

The BOM is supposed to be at the beginning of the file, not at every line.
The check should be outside the while loop.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC/PATCH]lavf/omadec: Fix timestamps for Atrac 3 lossless

2017-02-11 Thread Paul B Mahol
On 2/11/17, Carl Eugen Hoyos  wrote:
> 2017-02-11 14:32 GMT+01:00 Paul B Mahol :
>> On 2/11/17, Carl Eugen Hoyos  wrote:
>
>>> Attached patch fixes timestamps and duration for
>>> atrac_3_lossless_132kbps.aa3
>>> from ticket #5334, the only Atrac 3 lossless sample I have.
>>>
>>> Please comment, Carl Eugen
>>
>> This is wrong thing to do, packets duration should be half
>> of what is set for atrac3al.
>
> Where can this be done?

In demuxer, when packet duration is set.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2] AVFrame: add an opaque_ref field

2017-02-11 Thread Michael Niedermayer
On Sat, Feb 11, 2017 at 02:17:36PM +0100, wm4 wrote:
> This is an extended version of the AVFrame.opaque field, which can be
> used to attach arbitrary user information to an AVFrame.
> 
> The usefulness of the opaque field is rather limited, because it can
> store only up to 32 bits of information (or 64 bit on 64 bit systems).
> It's not possible to set this field to a memory allocation, because
> there is no way to deallocate it correctly.
> 
> The opaque_ref field circumvents this by letting the user set an
> AVBuffer, which makes the user data refcounted.
> 
> Signed-off-by: Anton Khirnov 
> 
> Merges Libav commit 04f3bd349651.
> ---
>  doc/APIchanges  |  3 +++
>  libavutil/frame.c   |  9 +
>  libavutil/frame.h   | 11 +++
>  libavutil/version.h |  2 +-
>  4 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 8bca71ef36..81e49c22b9 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2015-08-28
>  
>  API changes, most recent first:
>  
> +2017-02-11 - xxx - lavu 55.47.100 - frame.h
> +  Add AVFrame.opaque_ref.
> +
>  2017-01-31 - xxx - lavu 55.46.100 / 55.20.0 - cpu.h
>Add AV_CPU_FLAG_SSSE3SLOW.
>  
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index a08e0c539d..2913982e91 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -379,6 +379,13 @@ FF_DISABLE_DEPRECATION_WARNINGS
>  FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
>  
> +av_buffer_unref(&dst->opaque_ref);
> +if (src->opaque_ref) {
> +dst->opaque_ref = av_buffer_ref(src->opaque_ref);
> +if (!dst->opaque_ref)
> +return AVERROR(ENOMEM);
> +}

not just here but
the error handling in the whole function is not optimal,
ideally the destination frame should be left intact on error while
this could leave a half copied, unref and left as is mix


> +
>  return 0;
>  }
>  
> @@ -513,6 +520,8 @@ void av_frame_unref(AVFrame *frame)
>  
>  av_buffer_unref(&frame->hw_frames_ctx);
>  
> +av_buffer_unref(&frame->opaque_ref);
> +
>  get_frame_defaults(frame);
>  }
>  
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index b4500923af..3023559beb 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -538,6 +538,17 @@ typedef struct AVFrame {
>   * AVHWFramesContext describing the frame.
>   */
>  AVBufferRef *hw_frames_ctx;
> +
> +/**
> + * AVBufferRef for free use by the API user. Libav will never check the
> + * contents of the buffer ref. Libav calls av_buffer_unref() on it when

wrong project name

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC/PATCH]lavf/omadec: Fix timestamps for Atrac 3 lossless

2017-02-11 Thread Carl Eugen Hoyos
2017-02-11 14:32 GMT+01:00 Paul B Mahol :
> On 2/11/17, Carl Eugen Hoyos  wrote:

>> Attached patch fixes timestamps and duration for
>> atrac_3_lossless_132kbps.aa3
>> from ticket #5334, the only Atrac 3 lossless sample I have.
>>
>> Please comment, Carl Eugen
>
> This is wrong thing to do, packets duration should be half
> of what is set for atrac3al.

Where can this be done?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH]lavf/mpegts: Make a pointer cast explicit to silence a warning

2017-02-11 Thread Carl Eugen Hoyos
Hi!

Attached patch silences a warning, don't know what is preferred here.

Please comment, Carl Eugen
From a196a316697eae495ffe51a917bd0a813bb944f4 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 11 Feb 2017 16:53:34 +0100
Subject: [PATCH] lavf/mpegts: Make a pointer cast explicit.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Silences an "assignment discards ‘const’ qualifier" warning.
---
 libavformat/mpegts.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 0aa0ad7..590abb0 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -881,7 +881,7 @@ static void reset_pes_packet_state(PESContext *pes)
 static void new_data_packet(const uint8_t *buffer, int len, AVPacket *pkt)
 {
 av_init_packet(pkt);
-pkt->data = buffer;
+pkt->data = (uint8_t *)buffer;
 pkt->size = len;
 }
 
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v2 5/5] opus: add a native Opus encoder

2017-02-11 Thread Rostislav Pehlivanov
On 11 February 2017 at 00:25, Rostislav Pehlivanov 
wrote:

> This marks the first time anyone has written an Opus encoder without
> using any libopus code. The aim of the encoder is to prove how far
> the format can go by writing the craziest encoder for it.
>
> Right now the encoder's basic, it only supports CBR encoding, however
> internally every single feature the CELT layer has is implemented
> (except the pitch pre-filter which needs to work well with the rest of
> whatever gets implemented). Psychoacoustic and rate control systems are
> under development.
>
> The encoder takes in frames of 120 samples and depending on the value of
> opus_delay the plan is to use the extra buffered frames as lookahead.
> Right now the encoder will pick the nearest largest legal frame size and
> won't use the lookahead, but that'll change once there's a
> psychoacoustic system.
>
> Even though its a pretty basic encoder its already outperforming
> any other native encoder FFmpeg has by a huge amount.
>
> The PVQ search algorithm is faster and more accurate than libopus's
> algorithm so the encoder's performance is close to that of libopus
> at zero complexity (libopus has more SIMD).
> The algorithm might be ported to libopus or other codecs using PVQ in
> the future.
>
> The encoder still has a few minor bugs, like desyncs at ultra low
> bitrates (below 9kbps with 20ms frames).
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>
>

I don't free the frame and rc pointers from the main encoder struct on exit,
fixed locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavf/omadec: Remove an unused variable

2017-02-11 Thread Carl Eugen Hoyos
2017-02-11 14:32 GMT+01:00 Paul B Mahol :
> On 2/11/17, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> Attached patch fixes a compilation warning.
>>
>> Please comment, Carl Eugen
>>
>
> patch lgtm

Patch applied.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC/PATCH]lavf/omadec: Fix timestamps for Atrac 3 lossless

2017-02-11 Thread Paul B Mahol
On 2/11/17, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes timestamps and duration for
> atrac_3_lossless_132kbps.aa3
> from ticket #5334, the only Atrac 3 lossless sample I have.
>
> Please comment, Carl Eugen
>

This is wrong thing to do, packets duration should be half of what is
set for atrac3al.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavf/omadec: Remove an unused variable

2017-02-11 Thread Paul B Mahol
On 2/11/17, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes a compilation warning.
>
> Please comment, Carl Eugen
>

patch lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 1/2] AVFrame: add an opaque_ref field

2017-02-11 Thread wm4
This is an extended version of the AVFrame.opaque field, which can be
used to attach arbitrary user information to an AVFrame.

The usefulness of the opaque field is rather limited, because it can
store only up to 32 bits of information (or 64 bit on 64 bit systems).
It's not possible to set this field to a memory allocation, because
there is no way to deallocate it correctly.

The opaque_ref field circumvents this by letting the user set an
AVBuffer, which makes the user data refcounted.

Signed-off-by: Anton Khirnov 

Merges Libav commit 04f3bd349651.
---
 doc/APIchanges  |  3 +++
 libavutil/frame.c   |  9 +
 libavutil/frame.h   | 11 +++
 libavutil/version.h |  2 +-
 4 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 8bca71ef36..81e49c22b9 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2017-02-11 - xxx - lavu 55.47.100 - frame.h
+  Add AVFrame.opaque_ref.
+
 2017-01-31 - xxx - lavu 55.46.100 / 55.20.0 - cpu.h
   Add AV_CPU_FLAG_SSSE3SLOW.
 
diff --git a/libavutil/frame.c b/libavutil/frame.c
index a08e0c539d..2913982e91 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -379,6 +379,13 @@ FF_DISABLE_DEPRECATION_WARNINGS
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
+av_buffer_unref(&dst->opaque_ref);
+if (src->opaque_ref) {
+dst->opaque_ref = av_buffer_ref(src->opaque_ref);
+if (!dst->opaque_ref)
+return AVERROR(ENOMEM);
+}
+
 return 0;
 }
 
@@ -513,6 +520,8 @@ void av_frame_unref(AVFrame *frame)
 
 av_buffer_unref(&frame->hw_frames_ctx);
 
+av_buffer_unref(&frame->opaque_ref);
+
 get_frame_defaults(frame);
 }
 
diff --git a/libavutil/frame.h b/libavutil/frame.h
index b4500923af..3023559beb 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -538,6 +538,17 @@ typedef struct AVFrame {
  * AVHWFramesContext describing the frame.
  */
 AVBufferRef *hw_frames_ctx;
+
+/**
+ * AVBufferRef for free use by the API user. Libav will never check the
+ * contents of the buffer ref. Libav calls av_buffer_unref() on it when
+ * the frame is unreferenced. av_frame_copy_props() calls create a new
+ * reference with av_buffer_ref() for the target frame's opaque_ref field.
+ *
+ * This is unrelated to the opaque field, although it serves a similar
+ * purpose.
+ */
+AVBufferRef *opaque_ref;
 } AVFrame;
 
 /**
diff --git a/libavutil/version.h b/libavutil/version.h
index 8866064aac..a8b00bfc64 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  55
-#define LIBAVUTIL_VERSION_MINOR  46
+#define LIBAVUTIL_VERSION_MINOR  47
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 2/2] hwcontext_dxva2: support D3D9Ex

2017-02-11 Thread wm4
D3D9Ex uses different driver paths. This helps with "headless"
configurations when no user logs in. Plain D3D9 device creation will
fail if no user is logged in, while it works with D3D9Ex.

Signed-off-by: Anton Khirnov 

Merges Libav commit c2f97f0508708.
---
 libavutil/hwcontext_dxva2.c | 117 
 1 file changed, 87 insertions(+), 30 deletions(-)

diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 02632b7dae..4feb0a7306 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -40,8 +40,22 @@
 #include "compat/w32dlfcn.h"
 
 typedef IDirect3D9* WINAPI pDirect3DCreate9(UINT);
+typedef HRESULT WINAPI pDirect3DCreate9Ex(UINT, IDirect3D9Ex **);
 typedef HRESULT WINAPI pCreateDeviceManager9(UINT *, IDirect3DDeviceManager9 
**);
 
+#define FF_D3DCREATE_FLAGS (D3DCREATE_SOFTWARE_VERTEXPROCESSING | \
+D3DCREATE_MULTITHREADED | \
+D3DCREATE_FPU_PRESERVE)
+
+static const D3DPRESENT_PARAMETERS dxva2_present_params = {
+.Windowed = TRUE,
+.BackBufferWidth  = 640,
+.BackBufferHeight = 480,
+.BackBufferCount  = 0,
+.SwapEffect   = D3DSWAPEFFECT_DISCARD,
+.Flags= D3DPRESENTFLAG_VIDEO,
+};
+
 typedef struct DXVA2FramesContext {
 IDirect3DSurface9 **surfaces_internal;
 int  nb_surfaces_used;
@@ -317,19 +331,83 @@ static void dxva2_device_free(AVHWDeviceContext *ctx)
 av_freep(&ctx->user_opaque);
 }
 
+static int dxva2_device_create9(AVHWDeviceContext *ctx, UINT adapter)
+{
+DXVA2DevicePriv *priv = ctx->user_opaque;
+D3DPRESENT_PARAMETERS d3dpp = dxva2_present_params;
+D3DDISPLAYMODE d3ddm;
+HRESULT hr;
+pDirect3DCreate9 *createD3D = (pDirect3DCreate9 *)dlsym(priv->d3dlib, 
"Direct3DCreate9");
+if (!createD3D) {
+av_log(ctx, AV_LOG_ERROR, "Failed to locate Direct3DCreate9\n");
+return AVERROR_UNKNOWN;
+}
+
+priv->d3d9 = createD3D(D3D_SDK_VERSION);
+if (!priv->d3d9) {
+av_log(ctx, AV_LOG_ERROR, "Failed to create IDirect3D object\n");
+return AVERROR_UNKNOWN;
+}
+
+IDirect3D9_GetAdapterDisplayMode(priv->d3d9, adapter, &d3ddm);
+
+d3dpp.BackBufferFormat = d3ddm.Format;
+
+hr = IDirect3D9_CreateDevice(priv->d3d9, adapter, D3DDEVTYPE_HAL, 
GetDesktopWindow(),
+ FF_D3DCREATE_FLAGS,
+ &d3dpp, &priv->d3d9device);
+if (FAILED(hr)) {
+av_log(ctx, AV_LOG_ERROR, "Failed to create Direct3D device\n");
+return AVERROR_UNKNOWN;
+}
+
+return 0;
+}
+
+static int dxva2_device_create9ex(AVHWDeviceContext *ctx, UINT adapter)
+{
+DXVA2DevicePriv *priv = ctx->user_opaque;
+D3DPRESENT_PARAMETERS d3dpp = dxva2_present_params;
+D3DDISPLAYMODEEX modeex = {0};
+IDirect3D9Ex *d3d9ex = NULL;
+IDirect3DDevice9Ex *exdev = NULL;
+HRESULT hr;
+pDirect3DCreate9Ex *createD3DEx = (pDirect3DCreate9Ex 
*)dlsym(priv->d3dlib, "Direct3DCreate9Ex");
+if (!createD3DEx)
+return AVERROR(ENOSYS);
+
+hr = createD3DEx(D3D_SDK_VERSION, &d3d9ex);
+if (FAILED(hr))
+return AVERROR_UNKNOWN;
+
+IDirect3D9Ex_GetAdapterDisplayModeEx(d3d9ex, adapter, &modeex, NULL);
+
+d3dpp.BackBufferFormat = modeex.Format;
+
+hr = IDirect3D9Ex_CreateDeviceEx(d3d9ex, adapter, D3DDEVTYPE_HAL, 
GetDesktopWindow(),
+ FF_D3DCREATE_FLAGS,
+ &d3dpp, NULL, &exdev);
+if (FAILED(hr)) {
+IDirect3D9Ex_Release(d3d9ex);
+return AVERROR_UNKNOWN;
+}
+
+av_log(ctx, AV_LOG_VERBOSE, "Using D3D9Ex device.\n");
+priv->d3d9 = (IDirect3D9 *)d3d9ex;
+priv->d3d9device = (IDirect3DDevice9 *)exdev;
+return 0;
+}
+
 static int dxva2_device_create(AVHWDeviceContext *ctx, const char *device,
AVDictionary *opts, int flags)
 {
 AVDXVA2DeviceContext *hwctx = ctx->hwctx;
 DXVA2DevicePriv *priv;
-
-pDirect3DCreate9 *createD3D = NULL;
 pCreateDeviceManager9 *createDeviceManager = NULL;
-D3DPRESENT_PARAMETERS d3dpp = {0};
-D3DDISPLAYMODEd3ddm;
 unsigned resetToken = 0;
 UINT adapter = D3DADAPTER_DEFAULT;
 HRESULT hr;
+int err;
 
 if (device)
 adapter = atoi(device);
@@ -354,11 +432,6 @@ static int dxva2_device_create(AVHWDeviceContext *ctx, 
const char *device,
 return AVERROR_UNKNOWN;
 }
 
-createD3D = (pDirect3DCreate9 *)dlsym(priv->d3dlib, "Direct3DCreate9");
-if (!createD3D) {
-av_log(ctx, AV_LOG_ERROR, "Failed to locate Direct3DCreate9\n");
-return AVERROR_UNKNOWN;
-}
 createDeviceManager = (pCreateDeviceManager9 *)dlsym(priv->dxva2lib,
  
"DXVA2CreateDirect3DDeviceManager9");
 if (!createDeviceManager) {
@@ -366,27 +439,11 @@ static int dxva2_device_create(AVHWDeviceCont

[FFmpeg-devel] [PATCH 0/2] Two minor Libav merges

2017-02-11 Thread wm4
It seems it makes merging easier if we cherry-pick Libav commits and
push them early, instead of letting whoever does the merges do the work.
So I'm merging 2 of my Libav commits.

wm4 (2):
  AVFrame: add an opaque_ref field
  hwcontext_dxva2: support D3D9Ex

 doc/APIchanges  |   3 ++
 libavutil/frame.c   |   9 
 libavutil/frame.h   |  11 +
 libavutil/hwcontext_dxva2.c | 117 
 libavutil/version.h |   2 +-
 5 files changed, 111 insertions(+), 31 deletions(-)

-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [RFC/PATCH]lavf/omadec: Fix timestamps for Atrac 3 lossless

2017-02-11 Thread Carl Eugen Hoyos
Hi!

Attached patch fixes timestamps and duration for atrac_3_lossless_132kbps.aa3 
from ticket #5334, the only Atrac 3 lossless sample I have.

Please comment, Carl Eugen
From d1a22a151cc02fc475710c20576ecbed7c66aeac Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 11 Feb 2017 13:51:12 +0100
Subject: [PATCH] lavf/omadec: Fix timestamps for Atrac 3 lossless.

---
 libavformat/omadec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/omadec.c b/libavformat/omadec.c
index 076da78..96fdeea 100644
--- a/libavformat/omadec.c
+++ b/libavformat/omadec.c
@@ -501,7 +501,7 @@ static int oma_read_header(AVFormatContext *s)
 st->codecpar->channels= 2;
 st->codecpar->channel_layout = AV_CH_LAYOUT_STEREO;
 st->codecpar->sample_rate = 44100;
-avpriv_set_pts_info(st, 64, 1, 44100);
+avpriv_set_pts_info(st, 64, 1, 44100 * st->codecpar->channels);
 oc->read_packet = aal_read_packet;
 framesize = 4096;
 break;
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH]lavf/omadec: Remove an unused variable

2017-02-11 Thread Carl Eugen Hoyos
Hi!

Attached patch fixes a compilation warning.

Please comment, Carl Eugen
From bce13fbff1b9394fd3e89c7387f9d96e43934fb0 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 11 Feb 2017 13:17:20 +0100
Subject: [PATCH] lavf/omadec: Remove an unsed variable.

---
 libavformat/omadec.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/omadec.c b/libavformat/omadec.c
index 076da78..321e77e 100644
--- a/libavformat/omadec.c
+++ b/libavformat/omadec.c
@@ -345,7 +345,7 @@ static int read_packet(AVFormatContext *s, AVPacket *pkt)
 static int aal_read_packet(AVFormatContext *s, AVPacket *pkt)
 {
 int64_t pos = avio_tell(s->pb);
-int ret, type, pts;
+int ret, pts;
 int packet_size;
 unsigned tag;
 
@@ -358,7 +358,7 @@ static int aal_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 else if (tag != MKBETAG(0,'B','L','K'))
 return AVERROR_INVALIDDATA;
 
-type = avio_r8(s->pb);
+avio_skip(s->pb, 1);
 packet_size = avio_rb16(s->pb);
 avio_skip(s->pb, 2);
 pts = avio_rb32(s->pb);
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC] ffmpeg security

2017-02-11 Thread Steven Liu
2017-02-11 19:05 GMT+08:00 Michael Niedermayer :

> On Sat, Feb 11, 2017 at 11:57:31AM +0800, Steven Liu wrote:
> > 2017-02-11 11:14 GMT+08:00 Michael Niedermayer :
> >
> > > On Fri, Feb 10, 2017 at 04:43:17PM -0300, James Almer wrote:
> > > > On 2/10/2017 4:03 PM, Michael Niedermayer wrote:
> > > > > Hi community
> > > > >
> > > > > what do you prefer about the ffmpeg-security alias ?
> > > > > in no particular order
> > > > >
> > > > > Should everyone on the alias be listed in MAINTAINERs under a
> > > > > ffmpeg-security point?
> > > >
> > > > I'd say yes. From a transparency PoV, people should know who will
> > > > get access to such reports.
> > > >
> > > > >
> > > > > Should for everyone who is on the alias a reason be listed in
> > > > > MAINTAINERs why (s)he is on the alias ?
> > > >
> > > > IMO, there's no need for this. Read below.
> > > >
> > >
> > > > >
> > > > > Should everyone on the alias have a reason beyond curiousity to be
> > > > > on the alias? (that is a reason that clearly benefits FFmpeg)
> > > >
> > > > Yes, it should be about intending to fix reports and/or review fixes
> > > > made by others. Curiosity alone is not enough at all.
> > >
> > > ok
> > >
> > > We have 938 open bugs on trac
> > > We have 84 open bugs on trac that contain the keyword "regression"
> > > We have 55 open coverity issues
> > > We have 475 patches on patchwork needing some action, either having
> > > their status updated if its wrong or needing review/apply/reject
> > >
> > > someone wanting to review patches can do that
> > > someone wanting to fix issues can do that
> > >
> > > We have no open security issues on the ffmpeg-security alias, we have
> > > no patches that need a review, in fact i think we have had no patch
> > > there this year yet. (not countig ones referenced from ffmpeg-devel)
> > >
> > > So one wanting to review patches or fix issues shouldnt really have
> > > much desire on ffmpeg-security.
> > >
> > > We can add more people to it, but what does that fix?
> > > Shouldnt we rather try to find someone to fix the regressions on trac
> > > or go over the patches on patchwork ?
> > >
> > I saw "连一汉" sometime report some security issue and fixed by Michael.
> > I think we need a ffmpeg-security to report security issue and review
> patch
> > in it.
> > And i can join to fix it :)
>
> sounds like you have alot of time
> did you see the 36 issues about hls on trac: ?
> https://trac.ffmpeg.org/query?status=new&status=open&status=
> reopened&keywords=~hls&col=id&col=summary&col=status&col=
> type&col=priority&col=component&col=version&order=priority
>
> Ok, Let me try to fix them ;)

> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you fake or manipulate statistics in a paper in physics you will never
> get a job again.
> If you fake or manipulate statistics in a paper in medicin you will get
> a job for life at the pharma industry.
>
> ___
> 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


Re: [FFmpeg-devel] GSoC 2017

2017-02-11 Thread Michael Niedermayer
Hi all

On Mon, Jan 23, 2017 at 03:39:09PM +0100, Michael Niedermayer wrote:
> Hi all

just wanted to remind all that during
February 10 - 26Google program administrators review organization 
applications

the ideas page already looks quite good but any improvments you can do
to it should be done ASAP


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/mpl2dec: skip BOM when probing

2017-02-11 Thread Carl Eugen Hoyos
2017-02-11 11:56 GMT+01:00 Paul B Mahol :
> Signed-off-by: Paul B Mahol 

Please mention ticket #5442.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC] ffmpeg security

2017-02-11 Thread Michael Niedermayer
On Sat, Feb 11, 2017 at 11:57:31AM +0800, Steven Liu wrote:
> 2017-02-11 11:14 GMT+08:00 Michael Niedermayer :
> 
> > On Fri, Feb 10, 2017 at 04:43:17PM -0300, James Almer wrote:
> > > On 2/10/2017 4:03 PM, Michael Niedermayer wrote:
> > > > Hi community
> > > >
> > > > what do you prefer about the ffmpeg-security alias ?
> > > > in no particular order
> > > >
> > > > Should everyone on the alias be listed in MAINTAINERs under a
> > > > ffmpeg-security point?
> > >
> > > I'd say yes. From a transparency PoV, people should know who will
> > > get access to such reports.
> > >
> > > >
> > > > Should for everyone who is on the alias a reason be listed in
> > > > MAINTAINERs why (s)he is on the alias ?
> > >
> > > IMO, there's no need for this. Read below.
> > >
> >
> > > >
> > > > Should everyone on the alias have a reason beyond curiousity to be
> > > > on the alias? (that is a reason that clearly benefits FFmpeg)
> > >
> > > Yes, it should be about intending to fix reports and/or review fixes
> > > made by others. Curiosity alone is not enough at all.
> >
> > ok
> >
> > We have 938 open bugs on trac
> > We have 84 open bugs on trac that contain the keyword "regression"
> > We have 55 open coverity issues
> > We have 475 patches on patchwork needing some action, either having
> > their status updated if its wrong or needing review/apply/reject
> >
> > someone wanting to review patches can do that
> > someone wanting to fix issues can do that
> >
> > We have no open security issues on the ffmpeg-security alias, we have
> > no patches that need a review, in fact i think we have had no patch
> > there this year yet. (not countig ones referenced from ffmpeg-devel)
> >
> > So one wanting to review patches or fix issues shouldnt really have
> > much desire on ffmpeg-security.
> >
> > We can add more people to it, but what does that fix?
> > Shouldnt we rather try to find someone to fix the regressions on trac
> > or go over the patches on patchwork ?
> >
> I saw "连一汉" sometime report some security issue and fixed by Michael.
> I think we need a ffmpeg-security to report security issue and review patch
> in it.
> And i can join to fix it :)

sounds like you have alot of time
did you see the 36 issues about hls on trac: ?
https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~hls&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&order=priority

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avformat/mpl2dec: skip BOM when probing

2017-02-11 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavformat/mpl2dec.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavformat/mpl2dec.c b/libavformat/mpl2dec.c
index 59589d5..0e30cb0 100644
--- a/libavformat/mpl2dec.c
+++ b/libavformat/mpl2dec.c
@@ -23,6 +23,8 @@
  * MPL2 subtitles format demuxer
  */
 
+#include "libavutil/intreadwrite.h"
+
 #include "avformat.h"
 #include "internal.h"
 #include "subtitles.h"
@@ -39,6 +41,9 @@ static int mpl2_probe(AVProbeData *p)
 const unsigned char *ptr = p->buf;
 const unsigned char *ptr_end = ptr + p->buf_size;
 
+if (AV_RB24(ptr) == 0xefbbbf)
+ptr += 3;
+
 for (i = 0; i < 2; i++) {
 if (sscanf(ptr, "[%"SCNd64"][%"SCNd64"]%c", &start, &end, &c) != 3 &&
 sscanf(ptr, "[%"SCNd64"][]%c",  &start,   &c) != 2)
@@ -94,6 +99,9 @@ static int mpl2_read_header(AVFormatContext *s)
 if (!len)
 break;
 
+if (AV_RB24(p) == 0xefbbbf)
+p += 3;
+
 line[strcspn(line, "\r\n")] = 0;
 
 if (!read_ts(&p, &pts_start, &duration)) {
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel