Re: [FFmpeg-devel] [PATCH]lavf/mov: Accept multiple fourcc for AVID 1:1

[ffmpeg]

On 2016-12-01 19:58, compn wrote:

On Tue, 29 Nov 2016 22:10:47 +0100
Carl Eugen Hoyos  wrote:


From add7f5d51491152af6d0431331543212c2c21ca4 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 29 Nov 2016 22:09:21 +0100
Subject: [PATCH] lavf/mov: Accept multiple fourcc for AVID 1:1.

Fixes ticket #5982.
---
 libavformat/mov.c |1 +
 1 file changed, 1 insertion(+)


 if (codec_tag &&
  (codec_tag != format &&
+  (codec_tag != AV_RL32("AV1x") || format != AV_RL32("AVup")) 
&&
   // prores is allowed to have differing data format and codec 
tag
   codec_tag != AV_RL32("apcn") && codec_tag != AV_RL32("apch") 
&&

   // so is dv (sigh)

what about adding a comment like the prores/dv comments?
(or in a separate patch, make a nicer comment for prores,avid and dv?)

there are more than just these two AVID isoms.

a quick search reveals...

'AV1X': 'Avid 1:1x (Quick Time)',
'AVD1': 'Avid DV (Quick Time)',
'AVDN': 'Avid DNxHD (Quick Time)',
'AVMP': 'Avid IMX (Quick Time)',
'AVUP': 'Avid 10bit Packed (Quick Time)',

possibly AVin
sample here : 
http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket524/AVCI50.mov


do any of these isoms need to be added to the list in mov.c ?

otherwise, looks ok if tested with our av1x/avup samples.



Can this patch be pushed to master please? Seems to work for me (I
orignally reported the issue). If any work still needs to be done , tell
me then I can have a look if I'm capable of doing it.

Kind regards,

Samuel



thanks,
-compn
___
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] HRTF SOFA reader lib

[Christian Hoene]

Hi,

currently, we are writing a small library to read HRTF SOFA files.
https://github.com/choene/libmysofa

It is intended for embedded devices or mobiles that have a small (code)
memory footprint. Of course, it might be useful for ffmpeg, too – because you do
not need the hdf5 and netcdf libs.

It is not yet fully finished but I though it is time to collect feedback so that
I can enhance it.

If you have same spare time, please let me know on what to change to make
it useful for you guys…

Best regards,

 Christian Hoene

--
Symonics GmbH
Geierweg 25
72144 Dußlingen
Tel +49 7072 8006100
Fax +49 7072 8006109
Email: christian.ho...@symonics.com
Geschäftsführer/President: Dr. Christian Hoene 
Sitz der Gesellschaft/Place of Business: Tübingen
Registereintrag/Commercial Register: Amtsgericht Stuttgart, HRB 739918
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Added test for libavcodec/avpacket.c

[Thomas Turner]

Signed-off-by: Thomas Turner 
---
 libavcodec/Makefile |   3 +-
 libavcodec/tests/avpacket.c | 128 
 tests/fate/libavcodec.mak   |   5 ++
 3 files changed, 135 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/tests/avpacket.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 82f7fa2..6dd294e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1003,7 +1003,8 @@ SKIPHEADERS-$(CONFIG_VDA)  += vda.h 
vda_vt_internal.h
 SKIPHEADERS-$(CONFIG_VDPAU)+= vdpau.h vdpau_internal.h
 SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.h vda_vt_internal.h
 
-TESTPROGS = imgconvert  \
+TESTPROGS = avpacket\
+imgconvert  \
 jpeg2000dwt \
 mathops\
 options \
diff --git a/libavcodec/tests/avpacket.c b/libavcodec/tests/avpacket.c
new file mode 100644
index 000..90b7234
--- /dev/null
+++ b/libavcodec/tests/avpacket.c
@@ -0,0 +1,128 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "libavcodec/avcodec.h"
+#include "libavutil/error.h"
+
+
+
+static int setup_side_data_entry(AVPacket* avpkt)
+{
+const uint8_t *data_name = NULL;
+int ret = 0, bytes;
+uint8_t *extra_data = NULL;
+
+
+/* get side_data_name string */
+data_name = av_packet_side_data_name(AV_PKT_DATA_NEW_EXTRADATA);
+
+/* Allocate a memory bloc */
+bytes = strlen(data_name);
+
+if(!(extra_data = av_malloc(bytes))){
+ret = AVERROR(ENOMEM);
+fprintf(stderr, "Error occurred: %s\n", av_err2str(ret));
+exit(1);
+}
+/* copy side_data_name to extra_data array */
+memcpy(extra_data, data_name, bytes);
+
+/* create side data for AVPacket */
+ret = av_packet_add_side_data(avpkt, AV_PKT_DATA_NEW_EXTRADATA,
+extra_data, bytes);
+if(ret < 0){
+fprintf(stderr,
+"Error occurred in av_packet_add_side_data: %s\n",
+av_err2str(ret));
+}
+
+return ret;
+}
+
+static int initializations(AVPacket* avpkt)
+{
+const static uint8_t* data = "selftest for av_packet_clone(...)";
+int ret = 0;
+
+/* initialize avpkt */
+av_init_packet(avpkt);
+
+/* set values for avpkt */
+avpkt->pts = 17;
+avpkt->dts = 2;
+avpkt->data = (uint8_t*)data;
+avpkt->size = strlen(data);
+avpkt->flags = AV_PKT_FLAG_DISCARD;
+avpkt->duration = 100;
+avpkt->pos = 3;
+
+ret = setup_side_data_entry(avpkt);
+
+return ret;
+}
+
+int main(void)
+{
+AVPacket avpkt;
+AVPacket *avpkt_clone = NULL;
+int ret = 0;
+
+if(initializations() < 0){
+printf("failed to initialize variables\n");
+return 1;
+}
+/* test av_packet_clone*/
+avpkt_clone = av_packet_clone();
+
+if(!avpkt_clone) {
+av_log(NULL, AV_LOG_ERROR,"av_packet_clone failed to clone 
AVPacket\n");
+return 1;
+}
+/*test av_grow_packet*/
+if(av_grow_packet(avpkt_clone, 20) < 0){
+av_log(NULL, AV_LOG_ERROR, "av_grow_packet failed\n");
+return 1;
+}
+if(av_grow_packet(avpkt_clone, INT_MAX) == 0){
+printf( "av_grow_packet failed to return error "
+"when \"grow_by\" parameter is too large.\n" );
+ret = 1;
+}
+/* test size error check in av_new_packet*/
+if(av_new_packet(avpkt_clone, INT_MAX) == 0){
+printf( "av_new_packet failed to return error "
+"when \"size\" parameter is too large.\n" );
+ret = 1;
+}
+/*test size error check in av_packet_from_data*/
+if(av_packet_from_data(avpkt_clone, avpkt_clone->data, INT_MAX) == 0){
+printf("av_packet_from_data failed to return error "
+"when \"size\" parameter is too large.\n" );
+ret = 1;
+}
+/*clean up*/
+av_packet_free(_clone);
+ 

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Rostislav Pehlivanov]

On 5 Dec 2016 6:45 a.m., "wm4"  wrote:

On Mon, 28 Nov 2016 19:15:28 +0100
Nicolas George  wrote:

> Deadline: 2016-12-06 00:00 UTC.
>
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
>
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.
>
> I support the decision. Pros:
>
> ffserver has users, if there are no reason to drop it, doing so is a
> gratuitous annoyance to them.
>
> Apparently James Almer opposes the decision. Cons, if I understand
> correctly:
>
> A decision was made, a project should stick to it stubbornly.
>
> Regards,
>

I need more time to decide.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Me too, I'm not sure now because IMO fixing it would be better and it
started getting attention now
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/hlsenc: save the EXT-X-DISCONTINUITY from old list

[Steven Liu]

when use fix ticket 2nd problem.

command line test step:
rm -rf output*;./ffmpeg  -i ~/Movies/objectC/facebook.mp4 -an -c:v copy
-f hls -hls_time 4 -hls_list_size 5 -hls_flags +delete_segments
-hls_flags +append_list -hls_flags +omit_endlist -hls_flags
+discont_start -t 50 output.m3u8
./ffmpeg -i ~/Movies/objectC/facebook.mp4 -an -c:v libx264 -g 4 -f hls
-hls_time 4 -hls_list_size 5 -hls_flags +delete_segments -hls_flags
+append_list -hls_flags +omit_endlist -hls_flags +discont_start -t 5
output.m3u8
./ffmpeg -i ~/Movies/objectC/facebook.mp4 -an -c:v libx264 -g 4 -f hls
-hls_time 4 -hls_list_size 5 -hls_flags +delete_segments -hls_flags
+append_list -hls_flags +omit_endlist -hls_flags +discont_start -t 5
output.m3u8

result:
 #EXTM3U
 #EXT-X-VERSION:3
 #EXT-X-TARGETDURATION:5
 #EXT-X-MEDIA-SEQUENCE:6
 #EXTINF:4.12,
 output6.ts
 #EXT-X-DISCONTINUITY
 #EXTINF:4.00,
 output7.ts
 #EXTINF:0.96,
 output8.ts
 #EXT-X-DISCONTINUITY
 #EXTINF:4.00,
 output9.ts
 #EXTINF:0.96,
 output10.ts

Signed-off-by: Steven Liu 
Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 0e55a31..acf3a30 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -459,6 +459,9 @@ static int parse_playlist(AVFormatContext *s, const char 
*url)
 read_chomp_line(in, line, sizeof(line));
 if (av_strstart(line, "#EXT-X-MEDIA-SEQUENCE:", )) {
 hls->sequence = atoi(ptr);
+} else if (av_strstart(line, "#EXT-X-DISCONTINUITY", )) {
+is_segment = 1;
+hls->discontinuity = 1;
 } else if (av_strstart(line, "#EXTINF:", )) {
 is_segment = 1;
 hls->duration = atof(ptr);
-- 
1.7.1



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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp9: move bpp to the shared context for use in hwaccel

[Mark Thompson]

On 05/12/16 20:32, Mathieu Velten wrote:
> ---
>  libavcodec/vp9.c | 28 ++--
>  libavcodec/vp9.h |  1 +
>  2 files changed, 15 insertions(+), 14 deletions(-)
> 
On 05/12/16 20:32, Mathieu Velten wrote:
> ---
>  libavcodec/vaapi_vp9.c |  1 +
>  libavcodec/vp9.c   | 10 +-
>  2 files changed, 10 insertions(+), 1 deletion(-)

Retested, applied.

Thank you!

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

[FFmpeg-devel] [PATCH] ffmpeg_vaapi: Enable decoding of H.265 main 10 profile

[Mark Thompson]

---
Already present in lavc, just not enabled in ffmpeg.  Tested on Kaby Lake.

 ffmpeg_vaapi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ffmpeg_vaapi.c b/ffmpeg_vaapi.c
index b6bdeb9..dd11e77 100644
--- a/ffmpeg_vaapi.c
+++ b/ffmpeg_vaapi.c
@@ -165,6 +165,7 @@ static const struct {
 MAP(H264,H264_HIGH,   H264High),
 #if VA_CHECK_VERSION(0, 37, 0)
 MAP(HEVC,HEVC_MAIN,   HEVCMain),
+MAP(HEVC,HEVC_MAIN_10,HEVCMain10  ),
 #endif
 MAP(WMV3,VC1_SIMPLE,  VC1Simple   ),
 MAP(WMV3,VC1_MAIN,VC1Main ),
-- 
2.10.2

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

[FFmpeg-devel] [PATCH] yuv4mpegdec: fix leaking pkt in yuv4_read_packet

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/yuv4mpegdec.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/yuv4mpegdec.c b/libavformat/yuv4mpegdec.c
index a91645f..462b823 100644
--- a/libavformat/yuv4mpegdec.c
+++ b/libavformat/yuv4mpegdec.c
@@ -295,9 +295,10 @@ static int yuv4_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 ret = av_get_packet(s->pb, pkt, s->packet_size - Y4M_FRAME_MAGIC_LEN);
 if (ret < 0)
 return ret;
-else if (ret != s->packet_size - Y4M_FRAME_MAGIC_LEN)
+else if (ret != s->packet_size - Y4M_FRAME_MAGIC_LEN) {
+av_packet_unref(pkt);
 return s->pb->eof_reached ? AVERROR_EOF : AVERROR(EIO);
-
+}
 pkt->stream_index = 0;
 pkt->pts = (off - s->internal->data_offset) / s->packet_size;
 pkt->duration = 1;
-- 
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] truemotion1: fix leaking frame on init failure

[Andreas Cadhalpun]

On 05.12.2016 22:33, Michael Niedermayer wrote:
> On Mon, Dec 05, 2016 at 09:51:31PM +0100, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/truemotion1.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> LGTM

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] lavfi/formats: allow unknown channel layouts by default

[Marton Balint]

On Sat, 3 Dec 2016, Marton Balint wrote:


Since the default in the libav fork is to only allow known layouts, making
unknown layouts allowed by default here can be a security risk for filters
directly merged from libav. However, usually it is simple to detect such cases,
use of av_get_channel_layout_nb_channels is a good indicator, so I suggest we
change this regardless.

See http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203204.html.

This patch indirectly adds unknown channel layout support for filters where
query_formats is not specified:

abench
afifo
ainterleave
anullsink
apad
aperms
arealtime
aselect
asendcmd
asetnsamples
asetpts
asettb
ashowinfo
asyncts
azmq

And it removes .query_format callback from filters where it was only there to
support unknown layouts, as this is now the default:

aloop
ametadata
anull
asidedata
asplit
atrim

Signed-off-by: Marton Balint 
---
libavfilter/af_anull.c   |  1 -
libavfilter/f_loop.c |  1 -
libavfilter/f_metadata.c |  1 -
libavfilter/f_sidedata.c |  1 -
libavfilter/formats.c|  5 -
libavfilter/formats.h| 10 --
libavfilter/split.c  |  1 -
libavfilter/trim.c   |  1 -
8 files changed, 21 deletions(-)



I will apply this in a few days, unless someone objects.

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

[FFmpeg-devel] [PATCH] ffmpeg_vaapi: Enable decoding of VP9 profile 2

[Mark Thompson]

First released in libva 1.7.0 (0.39.0).  Also fix version requirement
of VP9 profile 0, which was first released in libva 1.6.0 (0.38.0).
---
Tested on Kaby Lake.

 ffmpeg_vaapi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ffmpeg_vaapi.c b/ffmpeg_vaapi.c
index f1e7c76..b6bdeb9 100644
--- a/ffmpeg_vaapi.c
+++ b/ffmpeg_vaapi.c
@@ -177,9 +177,12 @@ static const struct {
 #if VA_CHECK_VERSION(0, 35, 0)
 MAP(VP8, UNKNOWN,   VP8Version0_3 ),
 #endif
-#if VA_CHECK_VERSION(0, 37, 1)
+#if VA_CHECK_VERSION(0, 38, 0)
 MAP(VP9, VP9_0,   VP9Profile0 ),
 #endif
+#if VA_CHECK_VERSION(0, 39, 0)
+MAP(VP9, VP9_2,   VP9Profile2 ),
+#endif
 #undef MAP
 };
 
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH] truemotion1: fix leaking frame on init failure

[Michael Niedermayer]

On Mon, Dec 05, 2016 at 09:51:31PM +0100, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/truemotion1.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

LGTM

thx

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

[FFmpeg-devel] [PATCH] checkasm/vp9: benchmark all sub-IDCTs (but not WHT or ADST).

[Ronald S. Bultje]

---
 tests/checkasm/vp9dsp.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/tests/checkasm/vp9dsp.c b/tests/checkasm/vp9dsp.c
index 441041c..f32b97c 100644
--- a/tests/checkasm/vp9dsp.c
+++ b/tests/checkasm/vp9dsp.c
@@ -331,15 +331,20 @@ static void check_itxfm(void)
 int n_txtps = tx < TX_32X32 ? N_TXFM_TYPES : 1;
 
 for (txtp = 0; txtp < n_txtps; txtp++) {
-if (check_func(dsp.itxfm_add[tx][txtp], 
"vp9_inv_%s_%dx%d_add_%d",
-   tx == 4 ? "wht_wht" : txtp_types[txtp], sz, sz,
-   bit_depth)) {
-randomize_buffers();
-ftx(coef, tx, txtp, sz, bit_depth);
-
-for (sub = (txtp == 0) ? 1 : 2; sub <= sz; sub <<= 1) {
+// skip testing sub-IDCTs for WHT or ADST since they don't
+// implement it in any of the SIMD functions. If they do,
+// consider changing this to ensure we have complete test
+// coverage
+for (sub = (txtp == 0 && tx < 4) ? 1 : sz; sub <= sz; sub <<= 
1) {
+if (check_func(dsp.itxfm_add[tx][txtp],
+   "vp9_inv_%s_%dx%d_sub%d_add_%d",
+   tx == 4 ? "wht_wht" : txtp_types[txtp],
+   sz, sz, sub, bit_depth)) {
 int eob;
 
+randomize_buffers();
+ftx(coef, tx, txtp, sz, bit_depth);
+
 if (sub < sz) {
 eob = copy_subcoefs(subcoef0, coef, tx, txtp,
 sz, sub, bit_depth);
@@ -357,8 +362,9 @@ static void check_itxfm(void)
 !iszero(subcoef0, sz * sz * SIZEOF_COEF) ||
 !iszero(subcoef1, sz * sz * SIZEOF_COEF))
 fail();
+
+bench_new(dst, sz * SIZEOF_PIXEL, coef, eob);
 }
-bench_new(dst, sz * SIZEOF_PIXEL, coef, sz * sz);
 }
 }
 }
-- 
2.8.1

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

Re: [FFmpeg-devel] [FFmpeg-user] The transcoded file can't see the video played by the JW player which used the VAAPI to transcode file to the FLV format.

[Mark Thompson]

On 05/12/16 17:37, Archer Chang wrote:
> 2016-12-05 23:52 GMT+08:00 Mark Thompson :
>> On 05/12/16 12:51, Archer Chang wrote:
>>> I use the VAAPI HW ACCEL to transcode file to the FLV format that the
>>> command as follows.
>>>
>>> ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi
>>> -hwaccel_output_format vaapi -hwaccel_lax_profile_check -i infile.mkv
>> -vf
>>> "format=nv12|vaapi,hwupload" -c:v h264_vaapi -c:a aac -ac 2 -ar 44100
>>> *outfile1.flv*
>>>
>>> The transcoded file(outfile.flv) only can hear the audio but no video
>> that
>>> played by the JW player.  But when I transcode the file to the MKV and
>> make
>>> the stream copy to the FLV format and
>>> this file can be played normally by the JW player. The command as
>> follows.
>>>
>>> ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi
>>> -hwaccel_output_format vaapi -hwaccel_lax_profile_check -i infile.mkv
>> -vf
>>> "format=nv12|vaapi,hwupload" -c:v h264_vaapi -c:a aac -ac 2 -ar 44100
>>>  outfile.mkv
>>> ffmpeg -i outfile.mkv  -c:v copy -c:a copy  *outfile2.flv*
>>>
>>> I try to use the flv parser utility to find out the difference between
>> the
>>> outfile1.flv and the outfile2.flv.
>>> Seems the Video Tag1 were different. the content as follows.
>>>
>>> outfile1.flv (transcode using the ffmpeg directly with VAAPI)
>>> 09 00 00 05 00 00 00 00 00 00 00 17 00 00 00 00
>>>
>>> outfile2.flv(mke the stream copy from transcoded file)
>>> 09 00 00 30 00 00 00 00 00 00 00 17 00 00 00 00
>>> 01 6E 00 28 FF E1 00 1A 67 6E 00 28 A6 CD 94 07
>>> 80 22 7E 5C 04 40 00 00 FA 40 00 2E E0 03 C6 0C
>>> 65 80 01 00 06 68 EB E3 CB 22 C0
>>>
>>> I not familiar with the video transcoding. I trace the flvenc.c seems the
>>> par->extradata_size would be 0 when use the VAAPI to transcode the file
>> to
>>> the FLV directly,
>>> And it has some value which makes stream copy or use SW transcode
>>>
>>> ffmpeg  -i infile.mkv   -c:v libx264 -c:a aac -ac 2 -ar 44100
>> *outfile.flv
>>>  (can be played  normally by JW Player)*
>>
>> Is this JW player something which can only play streams with global
>> headers, then?
>>
>> If so, try applying > 0cf86fabfa5820596cca2cfead63c6f8df76c3f2> and see if it works.
>>
>> (This is on the assumption that you are using a packed-header VAAPI driver
>> like i965, if you are using a whole-stream driver like mesa/gallium then it
>> isn't really fixable.)
> 
> Hi Mark,
> 
> It works with the applying  0cf86fabfa5820596cca2cfead63c6f8df76c3f2>
> The JW player seem can only play streams with global headers.
> 
> Thank you very much.
> 
> Thanks again
> Archer Chang


Merged as below.

Thanks,

- Mark


On 05/12/16 21:09, Mark Thompson wrote:
> ffmpeg | branch: master | Mark Thompson  | Sun Oct  2 
> 08:48:34 2016 +0100| [51020adcecf4004c1586a708d96acc6cbddd050a] | committer: 
> Mark Thompson
> 
> vaapi_encode: Write sequence header as extradata
> 
> Only works if packed headers are supported, where we can know the
> output before generating the first frame.
> 
> (cherry picked from commit 0cf86fabfa5820596cca2cfead63c6f8df76c3f2)
> 
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=51020adcecf4004c1586a708d96acc6cbddd050a
> ---
> 
>  libavcodec/vaapi_encode.c | 22 ++
>  libavcodec/vaapi_encode.h |  2 ++
>  2 files changed, 24 insertions(+)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 262968a..a3c9991 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1405,6 +1405,28 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
>  // where it actually overlaps properly, though.)
>  ctx->issue_mode = ISSUE_MODE_MAXIMISE_THROUGHPUT;
>  
> +if (ctx->va_packed_headers & VA_ENC_PACKED_HEADER_SEQUENCE &&
> +ctx->codec->write_sequence_header) {
> +char data[MAX_PARAM_BUFFER_SIZE];
> +size_t bit_len = 8 * sizeof(data);
> +
> +err = ctx->codec->write_sequence_header(avctx, data, _len);
> +if (err < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to write sequence header "
> +   "for extradata: %d.\n", err);
> +goto fail;
> +} else {
> +avctx->extradata_size = (bit_len + 7) / 8;
> +avctx->extradata = av_mallocz(avctx->extradata_size +
> +  AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!avctx->extradata) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
> +memcpy(avctx->extradata, data, avctx->extradata_size);
> +}
> +}
> +
>  return 0;
>  
>  fail:
> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> index abce6b8..cc05ac8 100644
> --- a/libavcodec/vaapi_encode.h
> +++ b/libavcodec/vaapi_encode.h
> @@ -235,6 +235,8 @@ typedef struct VAAPIEncodeType {
>  int 

Re: [FFmpeg-devel] [PATCH] omx: Fix OOM check

[Andreas Cadhalpun]

On 05.12.2016 18:49, Timothy Gu wrote:
> Also use av_mallocz_array().
> 
> Fixes CID1396839.
> ---
>  libavcodec/omx.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/omx.c b/libavcodec/omx.c
> index c1b6fb9..b5093f4 100644
> --- a/libavcodec/omx.c
> +++ b/libavcodec/omx.c
> @@ -352,12 +352,12 @@ static av_cold int find_component(OMXContext 
> *omx_context, void *logctx,
>  av_log(logctx, AV_LOG_WARNING, "No component for role %s found\n", 
> role);
>  return AVERROR_ENCODER_NOT_FOUND;
>  }
> -components = av_mallocz(sizeof(char*) * num);
> +components = av_mallocz_array(num, sizeof(*components));

This is not really related, but probably OK.

>  if (!components)
>  return AVERROR(ENOMEM);
>  for (i = 0; i < num; i++) {
>  components[i] = av_mallocz(OMX_MAX_STRINGNAME_SIZE);
> -if (!components) {
> +if (!components[i]) {
>  ret = AVERROR(ENOMEM);
>  goto end;
>  }
> 

This looks good.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] truemotion1: fix leaking frame on init failure

[Andreas Cadhalpun]

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/truemotion1.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index da843c4..c2022fb 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -489,8 +489,10 @@ static av_cold int truemotion1_decode_init(AVCodecContext 
*avctx)
 /* there is a vertical predictor for each pixel in a line; each vertical
  * predictor is 0 to start with */
 av_fast_malloc(>vert_pred, >vert_pred_size, s->avctx->width * 
sizeof(unsigned int));
-if (!s->vert_pred)
+if (!s->vert_pred) {
+av_frame_free(>frame);
 return AVERROR(ENOMEM);
+}
 
 return 0;
 }
-- 
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avcodec/vp9: move bpp to the shared context for use in hwaccel

[Mathieu Velten]

---
 libavcodec/vp9.c | 28 ++--
 libavcodec/vp9.h |  1 +
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 0ec895a..793e356 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -68,7 +68,7 @@ typedef struct VP9Context {
 ptrdiff_t y_stride, uv_stride;
 
 uint8_t ss_h, ss_v;
-uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
+uint8_t last_bpp, bpp_index, bytesperpixel;
 uint8_t last_keyframe;
 // sb_cols/rows, rows/cols and last_fmt are used for allocating all 
internal
 // arrays, and are thus per-thread. w/h and gf_fmt are synced between 
threads
@@ -326,10 +326,10 @@ static int update_size(AVCodecContext *ctx, int w, int h)
 av_freep(>b_base);
 av_freep(>block_base);
 
-if (s->bpp != s->last_bpp) {
-ff_vp9dsp_init(>dsp, s->bpp, ctx->flags & AV_CODEC_FLAG_BITEXACT);
-ff_videodsp_init(>vdsp, s->bpp);
-s->last_bpp = s->bpp;
+if (s->s.h.bpp != s->last_bpp) {
+ff_vp9dsp_init(>dsp, s->s.h.bpp, ctx->flags & 
AV_CODEC_FLAG_BITEXACT);
+ff_videodsp_init(>vdsp, s->s.h.bpp);
+s->last_bpp = s->s.h.bpp;
 }
 
 return 0;
@@ -458,8 +458,8 @@ static int read_colorspace_details(AVCodecContext *ctx)
 int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(>gb); // 0:8, 1:10, 
2:12
 
 s->bpp_index = bits;
-s->bpp = 8 + bits * 2;
-s->bytesperpixel = (7 + s->bpp) >> 3;
+s->s.h.bpp = 8 + bits * 2;
+s->bytesperpixel = (7 + s->s.h.bpp) >> 3;
 ctx->colorspace = colorspaces[get_bits(>gb, 3)];
 if (ctx->colorspace == AVCOL_SPC_RGB) { // RGB = profile 1
 static const enum AVPixelFormat pix_fmt_rgb[3] = {
@@ -571,7 +571,7 @@ static int decode_frame_header(AVCodecContext *ctx,
 return res;
 } else {
 s->ss_h = s->ss_v = 1;
-s->bpp = 8;
+s->s.h.bpp = 8;
 s->bpp_index = 0;
 s->bytesperpixel = 1;
 s->pix_fmt = AV_PIX_FMT_YUV420P;
@@ -2278,7 +2278,7 @@ static int decode_coeffs_b_16bpp(VP9Context *s, int16_t 
*coef, int n_coeffs,
  const int16_t (*nb)[2], const int16_t 
*band_counts,
  const int16_t *qmul)
 {
-return decode_coeffs_b_generic(>c, coef, n_coeffs, 0, 0, s->bpp, cnt, 
eob, p,
+return decode_coeffs_b_generic(>c, coef, n_coeffs, 0, 0, s->s.h.bpp, 
cnt, eob, p,
nnz, scan, nb, band_counts, qmul);
 }
 
@@ -2288,7 +2288,7 @@ static int decode_coeffs_b32_16bpp(VP9Context *s, int16_t 
*coef, int n_coeffs,
const int16_t (*nb)[2], const int16_t 
*band_counts,
const int16_t *qmul)
 {
-return decode_coeffs_b_generic(>c, coef, n_coeffs, 1, 0, s->bpp, cnt, 
eob, p,
+return decode_coeffs_b_generic(>c, coef, n_coeffs, 1, 0, s->s.h.bpp, 
cnt, eob, p,
nnz, scan, nb, band_counts, qmul);
 }
 
@@ -2479,7 +2479,7 @@ static av_always_inline int check_intra_mode(VP9Context 
*s, int mode, uint8_t **
 int have_top = row > 0 || y > 0;
 int have_left = col > s->tile_col_start || x > 0;
 int have_right = x < w - 1;
-int bpp = s->bpp;
+int bpp = s->s.h.bpp;
 static const uint8_t mode_conv[10][2 /* have_left */][2 /* have_top */] = {
 [VERT_PRED]= { { DC_127_PRED,  VERT_PRED },
{ DC_127_PRED,  VERT_PRED } },
@@ -3310,13 +3310,13 @@ static void decode_b(AVCodecContext *ctx, int row, int 
col,
 s->uv_stride = f->linesize[1];
 }
 if (b->intra) {
-if (s->bpp > 8) {
+if (s->s.h.bpp > 8) {
 intra_recon_16bpp(ctx, yoff, uvoff);
 } else {
 intra_recon_8bpp(ctx, yoff, uvoff);
 }
 } else {
-if (s->bpp > 8) {
+if (s->s.h.bpp > 8) {
 inter_recon_16bpp(ctx);
 } else {
 inter_recon_8bpp(ctx);
@@ -4353,7 +4353,7 @@ static int 
vp9_decode_update_thread_context(AVCodecContext *dst, const AVCodecCo
 s->gf_fmt = ssrc->gf_fmt;
 s->w = ssrc->w;
 s->h = ssrc->h;
-s->bpp = ssrc->bpp;
+s->s.h.bpp = ssrc->s.h.bpp;
 s->bpp_index = ssrc->bpp_index;
 s->pix_fmt = ssrc->pix_fmt;
 memcpy(>prob_ctx, >prob_ctx, sizeof(s->prob_ctx));
diff --git a/libavcodec/vp9.h b/libavcodec/vp9.h
index df5bd4d..89b1bd3 100644
--- a/libavcodec/vp9.h
+++ b/libavcodec/vp9.h
@@ -137,6 +137,7 @@ typedef struct VP9Frame {
 typedef struct VP9BitstreamHeader {
 // bitstream header
 uint8_t profile;
+uint8_t bpp;
 uint8_t keyframe;
 uint8_t invisible;
 uint8_t errorres;
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 2/2] avcodec/vaapi-vp9: add support for profile 2 (bpp > 8)

[Mathieu Velten]

---
 libavcodec/vaapi_vp9.c |  1 +
 libavcodec/vp9.c   | 10 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
index b360dcb..9b3e81a 100644
--- a/libavcodec/vaapi_vp9.c
+++ b/libavcodec/vaapi_vp9.c
@@ -38,6 +38,7 @@ static void fill_picture_parameters(AVCodecContext
 *avctx,
 pp->first_partition_size = h->h.compressed_header_size;
 
 pp->profile = h->h.profile;
+pp->bit_depth = h->h.bpp;
 
 pp->filter_level = h->h.filter.level;
 pp->sharpness_level = h->h.filter.sharpness;
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 793e356..09365f8 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -258,7 +258,8 @@ static int update_size(AVCodecContext *ctx, int w, int h)
 if ((res = ff_set_dimensions(ctx, w, h)) < 0)
 return res;
 
-if (s->pix_fmt == AV_PIX_FMT_YUV420P) {
+switch (s->pix_fmt) {
+case AV_PIX_FMT_YUV420P:
 #if CONFIG_VP9_DXVA2_HWACCEL
 *fmtp++ = AV_PIX_FMT_DXVA2_VLD;
 #endif
@@ -268,6 +269,13 @@ static int update_size(AVCodecContext *ctx, int w, int h)
 #if CONFIG_VP9_VAAPI_HWACCEL
 *fmtp++ = AV_PIX_FMT_VAAPI;
 #endif
+break;
+case AV_PIX_FMT_YUV420P10:
+case AV_PIX_FMT_YUV420P12:
+#if CONFIG_VP9_VAAPI_HWACCEL
+*fmtp++ = AV_PIX_FMT_VAAPI;
+#endif
+break;
 }
 
 *fmtp++ = s->pix_fmt;
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH] lavf: fix the wrong warning msg and comments about av_find_stream_info

[Michael Niedermayer]

On Mon, Dec 05, 2016 at 03:33:22PM +0800, Jun Zhao wrote:
>  avformat.h |4 ++--
>  utils.c|6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 2af81d9d6033e66daa2f7a5c981129cbb87ca5c7  
> 0001-lavf-fix-the-wrong-warning-msg-and-comments-about-av.patch
> From 1c4b61ef42baae788e950c36f292ddd2e7cd9943 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Mon, 5 Dec 2016 15:17:13 +0800
> Subject: [PATCH] lavf: fix the wrong  warning msg and comments about
>  av_find_stream_info
> 
> av_find_stream_info() was deprecated by avformat_find_stream_info(),
> correct the warning message in the avformat_find_stream_info() and
> comments in the avformat.h
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavformat/avformat.h | 4 ++--
>  libavformat/utils.c| 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)

applied

thx

[...]
-- 
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] [PATCH 1/2] Avoid using the term "file" and prefer "url" in some docs and comments

[Michael Niedermayer]

On Mon, Dec 05, 2016 at 01:52:50PM +0100, Michael Niedermayer wrote:
> This should make it less ambigous that these are URLs
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/ffmpeg.texi  | 18 +-
>  doc/ffplay.texi  |  6 +++---
>  doc/ffprobe.texi | 10 +-
>  ffmpeg_opt.c |  4 ++--
>  4 files changed, 19 insertions(+), 19 deletions(-)

applied


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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

[FFmpeg-devel] [PATCH 3/4] avcodec/h264: mmx2, sse2, avx 10-bit h chroma deblock/loop filter

[James Darnley]

Yorkfield:
 - mmx2: 2.45x (279 vs. 114 cycles)
 - sse2: 3.36x (279 vs.  83 cycles)

Nehalem:
 - mmx2: 2.10x (192 vs.  92 cycles)
 - sse2: 2.84x (192 vs.  68 cycles)

Skylake:
 - mmx2: 1.75x (170 vs.  97 cycles)
 - sse2: 2.47x (170 vs.  69 cycles)
 - avx:  2.47x (170 vs.  69 cycles)
---
 libavcodec/x86/h264_deblock_10bit.asm | 118 ++
 libavcodec/x86/h264dsp_init.c |   9 +++
 2 files changed, 127 insertions(+)

diff --git a/libavcodec/x86/h264_deblock_10bit.asm 
b/libavcodec/x86/h264_deblock_10bit.asm
index ebf8a3f..3536e41 100644
--- a/libavcodec/x86/h264_deblock_10bit.asm
+++ b/libavcodec/x86/h264_deblock_10bit.asm
@@ -843,6 +843,88 @@ DEBLOCK_LUMA_INTRA
 mova [r0+2*r1], m2
 %endmacro
 
+; expands to [base],...,[base+7*stride]
+%define PASS8ROWS(base, base3, stride, stride3) \
+[base], [base+stride], [base+stride*2], [base3], \
+[base3+stride], [base3+stride*2], [base3+stride3], [base3+stride*4]
+
+; in: 8 rows of 4 words in %4..%11
+; out: 4 rows of 8 words in m0..m3
+%macro TRANSPOSE4x8W_LOAD 8
+movq m0, %1
+movq m2, %2
+movq m1, %3
+movq m3, %4
+
+punpcklwdm0, m2
+punpcklwdm1, m3
+punpckhdqm2, m0, m1
+punpckldqm0, m1
+
+movq m4, %5
+movq m6, %6
+movq m5, %7
+movq m3, %8
+
+punpcklwdm4, m6
+punpcklwdm5, m3
+punpckhdqm6, m4, m5
+punpckldqm4, m5
+
+punpckhqdq   m1, m0, m4
+punpcklqdq   m0, m4
+punpckhqdq   m3, m2, m6
+punpcklqdq   m2, m6
+%endmacro
+
+; in: 4 rows of 8 words in m0..m3
+; out: 8 rows of 4 words in %1..%8
+%macro TRANSPOSE8x4W_STORE 8
+TRANSPOSE4x4W 0, 1, 2, 3, 4
+movq %1, m0
+movhps   %2, m0
+movq %3, m1
+movhps   %4, m1
+movq %5, m2
+movhps   %6, m2
+movq %7, m3
+movhps   %8, m3
+%endmacro
+
+; %1 = base + 3*stride
+; %2 = 3*stride (unused on mmx)
+; %3, %4 = place to store p1 and q1 values
+%macro CHROMA_H_LOAD 4
+%if mmsize == 8
+movq m0, [pix_q - 4]
+movq m1, [pix_q +   stride_q - 4]
+movq m2, [pix_q + 2*stride_q - 4]
+movq m3, [%1 - 4]
+TRANSPOSE4x4W 0, 1, 2, 3, 4
+%else
+TRANSPOSE4x8W_LOAD PASS8ROWS(pix_q-4, %1-4, stride_q, %2)
+%endif
+mova %3, m0
+mova %4, m3
+%endmacro
+
+; %1 = base + 3*stride
+; %2 = 3*stride (unused on mmx)
+; %3, %4 = place to load p1 and q1 values
+%macro CHROMA_H_STORE 4
+mova m0, %3
+mova m3, %4
+%if mmsize == 8
+TRANSPOSE4x4W 0, 1, 2, 3, 4
+movq [pix_q - 4],  m0
+movq [pix_q +   stride_q - 4], m1
+movq [pix_q + 2*stride_q - 4], m2
+movq [%1 - 4], m3
+%else
+TRANSPOSE8x4W_STORE PASS8ROWS(pix_q-4, %1-4, stride_q, %2)
+%endif
+%endmacro
+
 %macro CHROMA_V_LOAD_TC 2
 movd%1, [%2]
 punpcklbw   %1, %1
@@ -914,6 +996,42 @@ cglobal deblock_v_chroma_intra_10, 
4,6-(mmsize/16),8*(mmsize/16)
 %else
 RET
 %endif
+
+;-
+; void ff_deblock_h_chroma_10(uint16_t *pix, int stride, int alpha, int beta,
+; int8_t *tc0)
+;-
+cglobal deblock_h_chroma_10, 5, 7, 8, 2*mmsize, pix_, stride_, alpha_, beta_, 
tc0_
+shl alpha_d,  2
+shl beta_d,   2
+mov r5,   pix_q
+lea r6,  [3*stride_q]
+add r5,   r6
+%if mmsize == 8
+mov r6d,  2
+.loop:
+%endif
+
+CHROMA_H_LOAD r5, r6, [rsp], [rsp + mmsize]
+LOAD_AB  m4,  m5, alpha_d, beta_d
+LOAD_MASKm0,  m1, m2, m3, m4, m5, m7, m6, m4
+pxor m4,  m4
+CHROMA_V_LOAD_TC m6,  tc0_q
+psubwm6, [pw_3]
+pmaxsw   m6,  m4
+pand m7,  m6
+DEBLOCK_P0_Q0m1,  m2, m0, m3, m7, m5, m6
+CHROMA_H_STORE r5, r6, [rsp], [rsp + mmsize]
+
+%if mmsize == 8
+lea pix_q, [pix_q + 4*stride_q]
+lea r5,[r5 + 4*stride_q]
+add tc0_q,  2
+dec r6d
+jg .loop
+%endif
+RET
+
 %endmacro
 
 %if ARCH_X86_64 == 0
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index 7e16dca..ab270da 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -313,6 +313,9 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 #if ARCH_X86_32
 c->h264_v_loop_filter_chroma   = ff_deblock_v_chroma_10_mmxext;
 c->h264_v_loop_filter_chroma_intra = 
ff_deblock_v_chroma_intra_10_mmxext;
+if (chroma_format_idc <= 1) {
+c->h264_h_loop_filter_chroma = ff_deblock_h_chroma_10_mmxext;
+ 

[FFmpeg-devel] [PATCH 4/4] avcodec/h264: mmx2, sse2, avx 10-bit 4:2:2 h chroma deblock/loop filter

[James Darnley]

Yorkfield:
 - mmx2: 2.53x (504 vs. 199 cycles)
 - sse2: 3.83x (504 vs. 131 cycles)

Nehalem:
 - mmx2: 2.42x (365 vs. 151 cycles)
 - sse2: 3.56x (365 vs. 103 cycles)

Skylake:
 - mmx2: 1.81x (308 vs. 170 cycles)
 - sse2: 2.84x (308 vs. 108 cycles)
 - avx:  2.93x (308 vs. 105 cycles)
---
 libavcodec/x86/h264_deblock_10bit.asm | 39 +++
 libavcodec/x86/h264dsp_init.c |  6 ++
 2 files changed, 45 insertions(+)

diff --git a/libavcodec/x86/h264_deblock_10bit.asm 
b/libavcodec/x86/h264_deblock_10bit.asm
index 3536e41..56cf4d6 100644
--- a/libavcodec/x86/h264_deblock_10bit.asm
+++ b/libavcodec/x86/h264_deblock_10bit.asm
@@ -1032,6 +1032,45 @@ cglobal deblock_h_chroma_10, 5, 7, 8, 2*mmsize, pix_, 
stride_, alpha_, beta_, tc
 %endif
 RET
 
+;-
+; void ff_deblock_h_chroma422_10(uint16_t *pix, int stride, int alpha, int 
beta,
+;int8_t *tc0)
+;-
+cglobal deblock_h_chroma422_10, 5, 7, 8, 3*mmsize, pix_, stride_, alpha_, 
beta_, tc0_
+shl alpha_d,  2
+shl beta_d,   2
+
+movd m0, [tc0_q]
+punpcklbw m0, m0
+psraw m0, 6
+movq [rsp], m0
+
+mov r5,   pix_q
+lea r6,  [3*stride_q]
+add r5,   r6
+
+mov r4, -8
+.loop:
+
+CHROMA_H_LOAD r5, r6, [rsp + 1*mmsize], [rsp + 2*mmsize]
+LOAD_AB  m4,  m5, alpha_d, beta_d
+LOAD_MASKm0,  m1, m2, m3, m4, m5, m7, m6, m4
+pxor m4,  m4
+movd m6, [rsp + r4 + 8]
+punpcklwdm6,  m6
+punpcklwdm6,  m6
+psubwm6, [pw_3]
+pmaxsw   m6,  m4
+pand m7,  m6
+DEBLOCK_P0_Q0m1,  m2, m0, m3, m7, m5, m6
+CHROMA_H_STORE r5, r6, [rsp + 1*mmsize], [rsp + 2*mmsize]
+
+lea pix_q, [pix_q + (mmsize/2)*stride_q]
+lea r5,[r5 +(mmsize/2)*stride_q]
+add r4, (mmsize/4)
+jl .loop
+RET
+
 %endmacro
 
 %if ARCH_X86_64 == 0
diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index ab270da..7b3d17f 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -315,6 +315,8 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 c->h264_v_loop_filter_chroma_intra = 
ff_deblock_v_chroma_intra_10_mmxext;
 if (chroma_format_idc <= 1) {
 c->h264_h_loop_filter_chroma = ff_deblock_h_chroma_10_mmxext;
+} else {
+c->h264_h_loop_filter_chroma = 
ff_deblock_h_chroma422_10_mmxext;
 }
 c->h264_v_loop_filter_luma = ff_deblock_v_luma_10_mmxext;
 c->h264_h_loop_filter_luma = ff_deblock_h_luma_10_mmxext;
@@ -351,6 +353,8 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 c->h264_v_loop_filter_chroma_intra = 
ff_deblock_v_chroma_intra_10_sse2;
 if (chroma_format_idc <= 1) {
 c->h264_h_loop_filter_chroma = ff_deblock_h_chroma_10_sse2;
+} else {
+c->h264_h_loop_filter_chroma = ff_deblock_h_chroma422_10_sse2;
 }
 #if HAVE_ALIGNED_STACK
 c->h264_v_loop_filter_luma   = ff_deblock_v_luma_10_sse2;
@@ -389,6 +393,8 @@ av_cold void ff_h264dsp_init_x86(H264DSPContext *c, const 
int bit_depth,
 c->h264_v_loop_filter_chroma_intra = 
ff_deblock_v_chroma_intra_10_avx;
 if (chroma_format_idc <= 1) {
 c->h264_h_loop_filter_chroma = ff_deblock_h_chroma_10_avx;
+} else {
+c->h264_h_loop_filter_chroma = ff_deblock_h_chroma422_10_avx;
 }
 #if HAVE_ALIGNED_STACK
 c->h264_v_loop_filter_luma = ff_deblock_v_luma_10_avx;
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 1/4] avcodec/h264: clean up and expand x86 function definitions

[James Darnley]

---
 libavcodec/x86/h264dsp_init.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index c6c643a..7cc0655 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -110,6 +110,8 @@ void ff_deblock_ ## DIR ## _ ## TYPE ## _ ## DEPTH ## _ ## 
OPT(uint8_t *pix,  \
 #define LF_FUNCS(type, depth)   \
 LF_FUNC(h,  chroma,   depth, mmxext)\
 LF_IFUNC(h, chroma_intra, depth, mmxext)\
+LF_FUNC(h,  chroma422,   depth, mmxext) \
+LF_IFUNC(h, chroma422_intra, depth, mmxext) \
 LF_FUNC(v,  chroma,   depth, mmxext)\
 LF_IFUNC(v, chroma_intra, depth, mmxext)\
 LF_FUNC(h,  luma, depth, mmxext)\
@@ -120,6 +122,8 @@ LF_FUNC(v,  luma, depth, sse2)  \
 LF_IFUNC(v, luma_intra,   depth, sse2)  \
 LF_FUNC(h,  chroma,   depth, sse2)  \
 LF_IFUNC(h, chroma_intra, depth, sse2)  \
+LF_FUNC(h,  chroma422,   depth, sse2)   \
+LF_IFUNC(h, chroma422_intra, depth, sse2)   \
 LF_FUNC(v,  chroma,   depth, sse2)  \
 LF_IFUNC(v, chroma_intra, depth, sse2)  \
 LF_FUNC(h,  luma, depth, avx)   \
@@ -128,15 +132,14 @@ LF_FUNC(v,  luma, depth, avx)   \
 LF_IFUNC(v, luma_intra,   depth, avx)   \
 LF_FUNC(h,  chroma,   depth, avx)   \
 LF_IFUNC(h, chroma_intra, depth, avx)   \
+LF_FUNC(h,  chroma422,   depth, avx)\
+LF_IFUNC(h, chroma422_intra, depth, avx)\
 LF_FUNC(v,  chroma,   depth, avx)   \
 LF_IFUNC(v, chroma_intra, depth, avx)
 
 LF_FUNCS(uint8_t,   8)
 LF_FUNCS(uint16_t, 10)
 
-void ff_deblock_h_chroma422_8_mmxext(uint8_t *pix, int stride, int alpha, int 
beta, int8_t *tc0);
-LF_IFUNC(h, chroma422_intra, 8, mmxext)
-
 #if ARCH_X86_32 && HAVE_MMXEXT_EXTERNAL
 LF_FUNC(v8, luma, 8, mmxext)
 static void deblock_v_luma_8_mmxext(uint8_t *pix, int stride, int alpha,
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 2/4] whitespace changes after last commit

[James Darnley]

---
 libavcodec/x86/h264dsp_init.c | 44 +--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/libavcodec/x86/h264dsp_init.c b/libavcodec/x86/h264dsp_init.c
index 7cc0655..7e16dca 100644
--- a/libavcodec/x86/h264dsp_init.c
+++ b/libavcodec/x86/h264dsp_init.c
@@ -108,34 +108,34 @@ void ff_deblock_ ## DIR ## _ ## TYPE ## _ ## DEPTH ## _ 
## OPT(uint8_t *pix,  \
int beta);
 
 #define LF_FUNCS(type, depth)   \
-LF_FUNC(h,  chroma,   depth, mmxext)\
-LF_IFUNC(h, chroma_intra, depth, mmxext)\
+LF_FUNC(h,  chroma,  depth, mmxext) \
+LF_IFUNC(h, chroma_intra,depth, mmxext) \
 LF_FUNC(h,  chroma422,   depth, mmxext) \
 LF_IFUNC(h, chroma422_intra, depth, mmxext) \
-LF_FUNC(v,  chroma,   depth, mmxext)\
-LF_IFUNC(v, chroma_intra, depth, mmxext)\
-LF_FUNC(h,  luma, depth, mmxext)\
-LF_IFUNC(h, luma_intra,   depth, mmxext)\
-LF_FUNC(h,  luma, depth, sse2)  \
-LF_IFUNC(h, luma_intra,   depth, sse2)  \
-LF_FUNC(v,  luma, depth, sse2)  \
-LF_IFUNC(v, luma_intra,   depth, sse2)  \
-LF_FUNC(h,  chroma,   depth, sse2)  \
-LF_IFUNC(h, chroma_intra, depth, sse2)  \
+LF_FUNC(v,  chroma,  depth, mmxext) \
+LF_IFUNC(v, chroma_intra,depth, mmxext) \
+LF_FUNC(h,  luma,depth, mmxext) \
+LF_IFUNC(h, luma_intra,  depth, mmxext) \
+LF_FUNC(h,  luma,depth, sse2)   \
+LF_IFUNC(h, luma_intra,  depth, sse2)   \
+LF_FUNC(v,  luma,depth, sse2)   \
+LF_IFUNC(v, luma_intra,  depth, sse2)   \
+LF_FUNC(h,  chroma,  depth, sse2)   \
+LF_IFUNC(h, chroma_intra,depth, sse2)   \
 LF_FUNC(h,  chroma422,   depth, sse2)   \
 LF_IFUNC(h, chroma422_intra, depth, sse2)   \
-LF_FUNC(v,  chroma,   depth, sse2)  \
-LF_IFUNC(v, chroma_intra, depth, sse2)  \
-LF_FUNC(h,  luma, depth, avx)   \
-LF_IFUNC(h, luma_intra,   depth, avx)   \
-LF_FUNC(v,  luma, depth, avx)   \
-LF_IFUNC(v, luma_intra,   depth, avx)   \
-LF_FUNC(h,  chroma,   depth, avx)   \
-LF_IFUNC(h, chroma_intra, depth, avx)   \
+LF_FUNC(v,  chroma,  depth, sse2)   \
+LF_IFUNC(v, chroma_intra,depth, sse2)   \
+LF_FUNC(h,  luma,depth, avx)\
+LF_IFUNC(h, luma_intra,  depth, avx)\
+LF_FUNC(v,  luma,depth, avx)\
+LF_IFUNC(v, luma_intra,  depth, avx)\
+LF_FUNC(h,  chroma,  depth, avx)\
+LF_IFUNC(h, chroma_intra,depth, avx)\
 LF_FUNC(h,  chroma422,   depth, avx)\
 LF_IFUNC(h, chroma422_intra, depth, avx)\
-LF_FUNC(v,  chroma,   depth, avx)   \
-LF_IFUNC(v, chroma_intra, depth, avx)
+LF_FUNC(v,  chroma,  depth, avx)\
+LF_IFUNC(v, chroma_intra,depth, avx)
 
 LF_FUNCS(uint8_t,   8)
 LF_FUNCS(uint16_t, 10)
-- 
2.10.2

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

[FFmpeg-devel] [PATCH] qsvdec: Fix memory leak

[Timothy Gu]

Found by Coverity in FFmpeg.
---
 libavcodec/qsvdec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index ea4abfa..258042d 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -305,8 +305,10 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
 
 do {
 ret = get_surface(avctx, q, );
-if (ret < 0)
+if (ret < 0) {
+av_freep();
 return ret;
+}
 
 ret = MFXVideoDECODE_DecodeFrameAsync(q->session, avpkt->size ?  : 
NULL,
   insurf, , sync);
-- 
2.10.2

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

Re: [FFmpeg-devel] FFmpeg 2.8.9, 3.1.6, 3.0.5

[Reto Kromer]

Michael Niedermayer wrote:

>moved 2.5 and 2.6 to olddownloads
>
>and 2.8.9 release made

Thank you!

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

[FFmpeg-devel] [PATCH 0/4] More H.264 assembly (the sequel) [version 2]

[James Darnley]

Fixed the problem Michael highlighted.  Dropped the intra functions until it
becomes clear why their performance is unexpected. Updated the benchmarks with
results from a Nehalem and used (slightly) more accurate data.

Regarding the age of MMX:  I have written it so unless someone tells me to
remove it I will keep the code.  However, I will probably not write any more
going forward.

James Darnley (4):
  avcodec/h264: clean up and expand x86 function definitions
  whitespace changes after last commit
  avcodec/h264: mmx2, sse2, avx 10-bit h chroma deblock/loop filter
  avcodec/h264: mmx2, sse2, avx 10-bit 4:2:2 h chroma deblock/loop
filter

 libavcodec/x86/h264_deblock_10bit.asm | 157 ++
 libavcodec/x86/h264dsp_init.c |  68 +--
 2 files changed, 200 insertions(+), 25 deletions(-)

-- 
2.10.2

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

[FFmpeg-devel] [PATCH] qsvdec: Fix memory leak

[Timothy Gu]

Fixes CID1396851.
---
 libavcodec/qsvdec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index ea4abfa..258042d 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -305,8 +305,10 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
 
 do {
 ret = get_surface(avctx, q, );
-if (ret < 0)
+if (ret < 0) {
+av_freep();
 return ret;
+}
 
 ret = MFXVideoDECODE_DecodeFrameAsync(q->session, avpkt->size ?  : 
NULL,
   insurf, , sync);
-- 
2.10.2

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

[FFmpeg-devel] [PATCH] omx: Fix OOM check

[Timothy Gu]

Also use av_mallocz_array().

Fixes CID1396839.
---
 libavcodec/omx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index c1b6fb9..b5093f4 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -352,12 +352,12 @@ static av_cold int find_component(OMXContext 
*omx_context, void *logctx,
 av_log(logctx, AV_LOG_WARNING, "No component for role %s found\n", 
role);
 return AVERROR_ENCODER_NOT_FOUND;
 }
-components = av_mallocz(sizeof(char*) * num);
+components = av_mallocz_array(num, sizeof(*components));
 if (!components)
 return AVERROR(ENOMEM);
 for (i = 0; i < num; i++) {
 components[i] = av_mallocz(OMX_MAX_STRINGNAME_SIZE);
-if (!components) {
+if (!components[i]) {
 ret = AVERROR(ENOMEM);
 goto end;
 }
-- 
2.10.2

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

Re: [FFmpeg-devel] [PATCH] configure: check for strtoull on msvc

[Michael Niedermayer]

On Mon, Dec 05, 2016 at 01:07:22PM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  configure | 1 +
>  1 file changed, 1 insertion(+)

Tested-by: michael on mingw32/64, arm, mips, x86-32/64 linux
build works as expected as before

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [PATCH] configure: check for strtoull on msvc

[James Almer]

On 12/5/2016 2:25 PM, Michael Niedermayer wrote:
> On Mon, Dec 05, 2016 at 01:07:22PM -0300, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  configure | 1 +
>>  1 file changed, 1 insertion(+)
> 
> Tested-by: michael on mingw32/64, arm, mips, x86-32/64 linux
> build works as expected as before

Pushed. Thanks.

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

[FFmpeg-devel] [PATCH] configure: check for strtoull on msvc

[James Almer]

Signed-off-by: James Almer 
---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index ddc065e..21ec552 100755
--- a/configure
+++ b/configure
@@ -6284,6 +6284,7 @@ __declspec($_restrict) void* foo(int);
 EOF
 fi
 check_func strtoll || add_cflags -Dstrtoll=_strtoi64
+check_func strtoull || add_cflags -Dstrtoull=_strtoui64
 # the new SSA optimzer in VS2015 U3 is mis-optimizing some parts of the 
code
 # this flag should be re-checked on newer compiler releases and put under a
 # version check once its fixed
-- 
2.10.2

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 12/5/2016 11:45 AM, Carl Eugen Hoyos wrote:
> 2016-12-05 15:23 GMT+01:00 James Almer :
>> On 12/5/2016 7:20 AM, Carl Eugen Hoyos wrote:
>>> 2016-11-29 21:53 GMT+01:00 James Almer :
 On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote:
> 2016-11-29 21:11 GMT+01:00 James Almer :
>>>
>> He's trying to override an announced project decision of removing a 
>> feature.
>
> We - obviously - announced it to find somebody who would fix the issues
> raised. If they are fixed, the "decision" is of course void, and we don't
> have to vote about it.

 That's not what was announced, at all. Please, read the news entry in 
 question
 and inform yourself in the subject before trying to participate in a 
 discussion.
>>>
>>> That is exactly what I would like you to do.
>>> What else would have been the reason for the announcement?
>>
>> How about you actually *try* reading the news entry, instead of passing the
>> ball? You might just find out if you do it carefully and pay attention to
>> each sentence. Especially the part where it invites people to write a
>> replacement, and says nothing about voiding the decision if "issues are
>> fixed".
> 
> You misunderstand:
> I did not claim that the news entry says that the issues should be fixed,
> I wrote that the only reasonable base on which the entry was written is
> imo the search for somebody to fix the issues.

That's an odd interpretation of a news entry consisting on very few, very
clear paragraphs, and ending with a sentence that goes completely against
said interpretation.

> 
> Or are you arguing that ffserver should be removed because some
> developers don't like it?
> 
>>> I believe that it is absolutely unacceptable to remove a used feature of
>>> FFmpeg without a technical reason and I therefore believe that this
>>> vote does not make much sense.
>>
>> The technical reasons are there, described in the news entry you seem to
>> not want to read, or at least properly parse.
>> These past week however saw one developer working against the clock doing
>> what the actual people interested in ffserver should have done for the past
>> few months and even years. That is, he addressed most, but not all, of those
>> and other reasons.
> 
> Which reasons were not adressed?

<@wbs> I don't think it's still "fixed" in the sense that ffserver and ffmpeg 
can be built from differing major versions
<@wbs> since it sends literal enum values over the wire, and those enum values 
are free to be changed at any major bump 
<@wbs> and also, it doesn't even specify which major version it is talking 
about in the protocol
<@wbs> so api-wise it might be "fixed"; design wise, not yet
<+wm4> so my question would be does ffserver always use ffm for input/output, 
require it only for one of them, or is it completely optional?
<@wbs> wm4: afaik both ffmpeg and ffserver uses ffm, so if ffmpeg were to be 
able to communicate with ffserver, it needs an ffm demuxer/muxer as well
<@wbs> wm4: and it's all pretty backwards compare to most other protocols; if 
ffmpeg is to send data to ffserver, ffserver first tells it what codecs and 
encoder parameters to use, and then switches(?) communication direction to 
ffmpeg sending, ffserver receiving
<+wm4> huh
<@wbs> all of this is custom code in ffmpeg.c ofc
<+wm4> lol really?
<+wm4> so ffmpeg.c has explicit ffserver handling, outside of the ffm 
libavformat parts?
<@wbs> yes
<@wbs> see ffmpeg_opt.c, read_ffserver_streams etc
<@wbs> was the first I found with a quick grep
<+wm4> ah
<@wbs> so yes, it no longer uses deprecated api (avstream->avcodeccontext), but 
it still uses a bunch of networking internals from lavf, and the design is 
buried deep in ffmpeg
<+wm4> just looked at ffserver.c
<+wm4> #include "libavformat/avio_internal.h"
<+wm4> ...yeah
<+wm4> even #include "libavformat/internal.h"
<@wbs> and it uses a bunch of internal rtp/udp functions that don't fit in in 
the normal avio/urlprotocol api
<@wbs> so it's not "fixed" yet. one of the deprecated details in codecpar might 
be worked around

Also, the part about "confusing configuration file syntax", but i guess that
can be considered subjective.

> 
>> You and Nicolas sure love your historical revisionism.
> 
> I am sure you know that I was strongly against adding mailing list rules.
> But if you continue calling people names in this thread, I suggest you go
> elsewhere.

Saying you and Nicolas are ignoring events (or rewriting history) to support you
position on this subject is not name calling.

And i suggest you go hunt instead the people that actually called others names.
I pointed them to you in a previous email.

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Ronald S. Bultje]

Hi,

On Mon, Dec 5, 2016 at 9:45 AM, Carl Eugen Hoyos  wrote:

> 2016-12-05 15:23 GMT+01:00 James Almer :
> > The technical reasons are there, described in the news entry you seem to
> > not want to read, or at least properly parse.
> > These past week however saw one developer working against the clock doing
> > what the actual people interested in ffserver should have done for the
> past
> > few months and even years. That is, he addressed most, but not all, of
> those
> > and other reasons.
>
> Which reasons were not adressed?


ffm is a pretty important one?

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Carl Eugen Hoyos]

2016-12-05 15:23 GMT+01:00 James Almer :
> On 12/5/2016 7:20 AM, Carl Eugen Hoyos wrote:
>> 2016-11-29 21:53 GMT+01:00 James Almer :
>>> On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote:
 2016-11-29 21:11 GMT+01:00 James Almer :
>>
> He's trying to override an announced project decision of removing a 
> feature.

 We - obviously - announced it to find somebody who would fix the issues
 raised. If they are fixed, the "decision" is of course void, and we don't
 have to vote about it.
>>>
>>> That's not what was announced, at all. Please, read the news entry in 
>>> question
>>> and inform yourself in the subject before trying to participate in a 
>>> discussion.
>>
>> That is exactly what I would like you to do.
>> What else would have been the reason for the announcement?
>
> How about you actually *try* reading the news entry, instead of passing the
> ball? You might just find out if you do it carefully and pay attention to
> each sentence. Especially the part where it invites people to write a
> replacement, and says nothing about voiding the decision if "issues are
> fixed".

You misunderstand:
I did not claim that the news entry says that the issues should be fixed,
I wrote that the only reasonable base on which the entry was written is
imo the search for somebody to fix the issues.

Or are you arguing that ffserver should be removed because some
developers don't like it?

>> I believe that it is absolutely unacceptable to remove a used feature of
>> FFmpeg without a technical reason and I therefore believe that this
>> vote does not make much sense.
>
> The technical reasons are there, described in the news entry you seem to
> not want to read, or at least properly parse.
> These past week however saw one developer working against the clock doing
> what the actual people interested in ffserver should have done for the past
> few months and even years. That is, he addressed most, but not all, of those
> and other reasons.

Which reasons were not adressed?

> You and Nicolas sure love your historical revisionism.

I am sure you know that I was strongly against adding mailing list rules.
But if you continue calling people names in this thread, I suggest you go
elsewhere.

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[wm4]

On Mon, 28 Nov 2016 19:15:28 +0100
Nicolas George  wrote:

> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.
> 
> I support the decision. Pros:
> 
> ffserver has users, if there are no reason to drop it, doing so is a
> gratuitous annoyance to them.
> 
> Apparently James Almer opposes the decision. Cons, if I understand
> correctly:
> 
> A decision was made, a project should stick to it stubbornly.
> 
> Regards,
> 

I need more time to decide.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 11/28/2016 3:15 PM, Nicolas George wrote:
> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.

As asked before, what would be the deadline? 3.3 or next major bump?

There are still some unsolved technical problems, even after Michael
fixed years of complains alone in one week. So at the current state,
even with this vote passing ffserver will still be scheduled for
removal in an upcoming release.

In any case, I confirm I'm against this motion to revoke the decision.
I have stated the reasons why i still want the current course of action
to remain as such more than once in the other thread.
I'm not going to repeat myself, and I'm pretty much done being ganged
up on, insulted and fallaciously threatened with the CoC by people here.

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

Re: [FFmpeg-devel] [PATCH 1/2] img2: added support for %t output pattern

[Michael Niedermayer]

On Mon, Dec 05, 2016 at 07:06:35AM -0700, Roger Pack wrote:
> On 12/2/16, James Almer  wrote:
> > On 12/2/2016 10:06 PM, Roger Pack wrote:
> >> On 11/25/16, Roger Pack  wrote:
> >>> On 11/18/16, Roger Pack  wrote:
>  On 11/15/16, James Almer  wrote:
> > On 11/10/2016 4:26 PM, Roger Pack wrote:
> >> On 11/1/16, James Almer  wrote:
>  On 11/1/2016 6:43 PM, James Almer wrote:
> >> On 10/25/2016 9:38 PM, Roger Pack wrote:
>  From e8cac5c7de18766ce0f8f286f7dc140b82129df2 Mon Sep 17
>  00:00:00
>  2001
>  From: rogerdpack 
>  Date: Tue, 25 Oct 2016 18:33:12 -0600
>  Subject: [PATCH 1/2] img2 encoder: allow %t in filename, based
>  on
>  patch
>  from
>   Yuval Adam
> 
>  Signed-off-by: rogerdpack 
>  ---
>   doc/muxers.texi| 13 +
>   libavformat/avformat.h |  3 ++-
>   libavformat/hlsenc.c   |  6 +++---
>   libavformat/img2enc.c  |  6 --
>   libavformat/utils.c| 42
>  ++
>   5 files changed, 60 insertions(+), 10 deletions(-)
> 
>  diff --git a/doc/muxers.texi b/doc/muxers.texi
>  index 0d856db..0c3a198 100644
>  --- a/doc/muxers.texi
>  +++ b/doc/muxers.texi
>  @@ -619,6 +619,12 @@ If the pattern contains "%d" or
>  "%0@var{N}d",
>  the
>  first filename of
>   the file list specified will contain the number 1, all the
>  following
>   numbers will be sequential.
> 
>  +If the pattern contains "%t", the frame's timestamps will be
>  inserted
>  +in the filename like "00.00.00.000" for hours, minutes,
>  seconds,
>  +and milliseconds.
>  +
>  +The "%t" and "%d" patterns may be used simultaneously.
>  +
>   The pattern may contain a suffix which is used to automatically
>   determine the format of the image files to write.
> 
>  @@ -664,6 +670,13 @@ can be used:
>   ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1
>  "%Y-%m-%d_%H-%M-%S.jpg"
>   @end example
> 
>  +The following example uses the timestamp parameter to generate
>  one
>  +image file per video frame from the input, and name it
>  including
>  its
>  original
>  +timestamp.
>  +@example
>  +ffmpeg -i in.avi -vsync vfr -copyts img-%t.jpg
>  +@end example
>  +
>   @subsection Options
> 
>   @table @option
>  diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>  index f9f4d72..7f39698 100644
>  --- a/libavformat/avformat.h
>  +++ b/libavformat/avformat.h
>  @@ -2780,10 +2780,11 @@ void av_dump_format(AVFormatContext *ic,
>    * @param path numbered sequence string
>    * @param number frame number
>    * @param flags AV_FRAME_FILENAME_FLAGS_*
>  + * @param ts frame timestamp in AV_TIME_BASE fractional
>  seconds.
>    * @return 0 if OK, -1 on format error
>    */
>   int av_get_frame_filename2(char *buf, int buf_size,
>  -  const char *path, int number, int
>  flags);
>  +  const char *path, int number, int
>  flags,
>  int64_t ts);
> >>
> >> Uhh, what? did you just break API modifying a public function?
> >>
> 
>  For the record, this was reverted.
> 
>  Shouldn't be hard to solve, i think. Just add a new
>  ff_get_frame_filename()
>  function to internal.h with this new signature, at least for now and
>  for
>  this
>  feature, to avoid adding a third public function doing the same
>  thing
>  unless
>  absolutely necessary.
> >> OK see attached.  Wasn't sure if I should duplicate docs or not, feel
> >> free to modify.
> >> Cheers!
> >> -roger-
> >>
> >>
> >> 0001-img2-encoder-allow-t-in-filepattern-based-on-patch-f.patch
> >>
> >>
> >> From 8287f1ca543f764e9e88659ee5a07873860d607d Mon Sep 17 00:00:00 2001
> >> From: rogerdpack 
> >> Date: Thu, 10 Nov 2016 12:24:49 -0700
> >> Subject: [PATCH] 

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 12/5/2016 7:20 AM, Carl Eugen Hoyos wrote:
> 2016-11-29 21:53 GMT+01:00 James Almer :
>> On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote:
>>> 2016-11-29 21:11 GMT+01:00 James Almer :
> 
 He's trying to override an announced project decision of removing a 
 feature.
>>>
>>> We - obviously - announced it to find somebody who would fix the issues
>>> raised. If they are fixed, the "decision" is of course void, and we don't
>>> have to vote about it.
>>
>> That's not what was announced, at all. Please, read the news entry in 
>> question
>> and inform yourself in the subject before trying to participate in a 
>> discussion.
> 
> That is exactly what I would like you to do.
> What else would have been the reason for the announcement?

How about you actually *try* reading the news entry, instead of passing the
ball? You might just find out if you do it carefully and pay attention to
each sentence. Especially the part where it invites people to write a
replacement, and says nothing about voiding the decision if "issues are
fixed".

> 
> I believe that it is absolutely unacceptable to remove a used feature of
> FFmpeg without a technical reason and I therefore believe that this
> vote does not make much sense.

The technical reasons are there, described in the news entry you seem to
not want to read, or at least properly parse.
These past week however saw one developer working against the clock doing
what the actual people interested in ffserver should have done for the past
few months and even years. That is, he addressed most, but not all, of those
and other reasons.

You and Nicolas sure love your historical revisionism.

> In any case, I am - still - all for keeping ffserver.
> 
> Carl Eugen
> ___
> 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] [PATCH 1/2] img2: added support for %t output pattern

[Roger Pack]

On 12/2/16, James Almer  wrote:
> On 12/2/2016 10:06 PM, Roger Pack wrote:
>> On 11/25/16, Roger Pack  wrote:
>>> On 11/18/16, Roger Pack  wrote:
 On 11/15/16, James Almer  wrote:
> On 11/10/2016 4:26 PM, Roger Pack wrote:
>> On 11/1/16, James Almer  wrote:
 On 11/1/2016 6:43 PM, James Almer wrote:
>> On 10/25/2016 9:38 PM, Roger Pack wrote:
 From e8cac5c7de18766ce0f8f286f7dc140b82129df2 Mon Sep 17
 00:00:00
 2001
 From: rogerdpack 
 Date: Tue, 25 Oct 2016 18:33:12 -0600
 Subject: [PATCH 1/2] img2 encoder: allow %t in filename, based
 on
 patch
 from
  Yuval Adam

 Signed-off-by: rogerdpack 
 ---
  doc/muxers.texi| 13 +
  libavformat/avformat.h |  3 ++-
  libavformat/hlsenc.c   |  6 +++---
  libavformat/img2enc.c  |  6 --
  libavformat/utils.c| 42
 ++
  5 files changed, 60 insertions(+), 10 deletions(-)

 diff --git a/doc/muxers.texi b/doc/muxers.texi
 index 0d856db..0c3a198 100644
 --- a/doc/muxers.texi
 +++ b/doc/muxers.texi
 @@ -619,6 +619,12 @@ If the pattern contains "%d" or
 "%0@var{N}d",
 the
 first filename of
  the file list specified will contain the number 1, all the
 following
  numbers will be sequential.

 +If the pattern contains "%t", the frame's timestamps will be
 inserted
 +in the filename like "00.00.00.000" for hours, minutes,
 seconds,
 +and milliseconds.
 +
 +The "%t" and "%d" patterns may be used simultaneously.
 +
  The pattern may contain a suffix which is used to automatically
  determine the format of the image files to write.

 @@ -664,6 +670,13 @@ can be used:
  ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1
 "%Y-%m-%d_%H-%M-%S.jpg"
  @end example

 +The following example uses the timestamp parameter to generate
 one
 +image file per video frame from the input, and name it
 including
 its
 original
 +timestamp.
 +@example
 +ffmpeg -i in.avi -vsync vfr -copyts img-%t.jpg
 +@end example
 +
  @subsection Options

  @table @option
 diff --git a/libavformat/avformat.h b/libavformat/avformat.h
 index f9f4d72..7f39698 100644
 --- a/libavformat/avformat.h
 +++ b/libavformat/avformat.h
 @@ -2780,10 +2780,11 @@ void av_dump_format(AVFormatContext *ic,
   * @param path numbered sequence string
   * @param number frame number
   * @param flags AV_FRAME_FILENAME_FLAGS_*
 + * @param ts frame timestamp in AV_TIME_BASE fractional
 seconds.
   * @return 0 if OK, -1 on format error
   */
  int av_get_frame_filename2(char *buf, int buf_size,
 -  const char *path, int number, int
 flags);
 +  const char *path, int number, int
 flags,
 int64_t ts);
>>
>> Uhh, what? did you just break API modifying a public function?
>>

 For the record, this was reverted.

 Shouldn't be hard to solve, i think. Just add a new
 ff_get_frame_filename()
 function to internal.h with this new signature, at least for now and
 for
 this
 feature, to avoid adding a third public function doing the same
 thing
 unless
 absolutely necessary.
>> OK see attached.  Wasn't sure if I should duplicate docs or not, feel
>> free to modify.
>> Cheers!
>> -roger-
>>
>>
>> 0001-img2-encoder-allow-t-in-filepattern-based-on-patch-f.patch
>>
>>
>> From 8287f1ca543f764e9e88659ee5a07873860d607d Mon Sep 17 00:00:00 2001
>> From: rogerdpack 
>> Date: Thu, 10 Nov 2016 12:24:49 -0700
>> Subject: [PATCH] img2 encoder: allow %t in filepattern, based on patch
>> from
>>  Yuval Adam
>>
>> Signed-off-by: rogerdpack 
>> ---
>>  doc/muxers.texi| 13 +
>>  libavformat/img2enc.c  |  8 +---
>>  libavformat/internal.h | 18 

Re: [FFmpeg-devel] [PATCH 2/2] [RFC] avformat/avio: Fail on opening non file urls which exist as local files without whitelists

[wm4]

On Mon,  5 Dec 2016 13:52:51 +0100
Michael Niedermayer  wrote:

> TODO: this needs to cleanly open a file url context for checking
> 
> This stops someone having a local file like "http:evilhost.com" and playing it
> as "http:evilhost.com" without explicitly specifying the http protocol on the 
> whitelist
> 
> That is it reduces the impact of people not using the "file:" scheme 
> explicitly on untrusted
> filenames at the expense of causing some problems if a remote url exists ad a 
> local file
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/avio.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/libavformat/avio.c b/libavformat/avio.c
> index 3606eb0fda..5a11add415 100644
> --- a/libavformat/avio.c
> +++ b/libavformat/avio.c
> @@ -31,6 +31,8 @@
>  #endif
>  #include "url.h"
>  
> +static const struct URLProtocol *url_find_protocol(const char *filename);
> +
>  /** @name Logging context. */
>  /*@{*/
>  static const char *urlcontext_to_name(void *ptr)
> @@ -188,6 +190,17 @@ int ffurl_connect(URLContext *uc, AVDictionary **options)
>  return AVERROR(EINVAL);
>  }
>  
> +if ((uc->flags & AVIO_FLAG_READ) &&
> +!uc->protocol_whitelist &&
> +!uc->protocol_blacklist &&
> +strcmp(uc->prot->name, "file")) {
> +const URLProtocol *file_protocol = url_find_protocol("file:");
> +if (file_protocol->url_check(uc, 0) >= 0) {
> +av_log(uc, AV_LOG_ERROR, "Ambigous filename %s exists, specify a 
> whitelist!\n", uc->filename);

This error message is completely dongs. A whitelist, what?? I don't
care if it makes sense in context of some obscure feature that no user
will know.

This also shouldn't depend on whether the file exists (url_check seems
to do that).

> +return AVERROR(EEXIST);
> +}
> +}
> +
>  if (!uc->protocol_whitelist && uc->prot->default_whitelist) {
>  av_log(uc, AV_LOG_DEBUG, "Setting default whitelist '%s'\n", 
> uc->prot->default_whitelist);
>  uc->protocol_whitelist = av_strdup(uc->prot->default_whitelist);

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

[FFmpeg-devel] [PATCH 1/2] Avoid using the term "file" and prefer "url" in some docs and comments

[Michael Niedermayer]

This should make it less ambigous that these are URLs

Signed-off-by: Michael Niedermayer 
---
 doc/ffmpeg.texi  | 18 +-
 doc/ffplay.texi  |  6 +++---
 doc/ffprobe.texi | 10 +-
 ffmpeg_opt.c |  4 ++--
 4 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 4b159fd659..b56bdbe261 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -12,7 +12,7 @@
 
 @chapter Synopsis
 
-ffmpeg [@var{global_options}] @{[@var{input_file_options}] -i 
@file{input_file}@} ... @{[@var{output_file_options}] @file{output_file}@} ...
+ffmpeg [@var{global_options}] @{[@var{input_file_options}] -i 
@file{input_url}@} ... @{[@var{output_file_options}] @file{output_url}@} ...
 
 @chapter Description
 @c man begin DESCRIPTION
@@ -24,10 +24,10 @@ rates and resize video on the fly with a high quality 
polyphase filter.
 @command{ffmpeg} reads from an arbitrary number of input "files" (which can be 
regular
 files, pipes, network streams, grabbing devices, etc.), specified by the
 @code{-i} option, and writes to an arbitrary number of output "files", which 
are
-specified by a plain output filename. Anything found on the command line which
-cannot be interpreted as an option is considered to be an output filename.
+specified by a plain output url. Anything found on the command line which
+cannot be interpreted as an option is considered to be an output url.
 
-Each input or output file can, in principle, contain any number of streams of
+Each input or output url can, in principle, contain any number of streams of
 different types (video/audio/subtitle/attachment/data). The allowed number 
and/or
 types of streams may be limited by the container format. Selecting which
 streams from which inputs will go into which output is either done 
automatically
@@ -243,8 +243,8 @@ Force input or output file format. The format is normally 
auto detected for inpu
 files and guessed from the file extension for output files, so this option is 
not
 needed in most cases.
 
-@item -i @var{filename} (@emph{input})
-input file name
+@item -i @var{url} (@emph{input})
+input file url
 
 @item -y (@emph{global})
 Overwrite output files without asking.
@@ -281,7 +281,7 @@ libx264, and the 138th audio, which will be encoded with 
libvorbis.
 When used as an input option (before @code{-i}), limit the @var{duration} of
 data read from the input file.
 
-When used as an output option (before an output filename), stop writing the
+When used as an output option (before an output url), stop writing the
 output after its duration reaches @var{duration}.
 
 @var{duration} must be a time duration specification,
@@ -310,7 +310,7 @@ extra segment between the seek point and @var{position} 
will be decoded and
 discarded. When doing stream copy or when @option{-noaccurate_seek} is used, it
 will be preserved.
 
-When used as an output option (before an output filename), decodes but discards
+When used as an output option (before an output url), decodes but discards
 input until the timestamps reach @var{position}.
 
 @var{position} must be a time duration specification,
@@ -1168,7 +1168,7 @@ may be reassigned to a different value.
 For example, to set the stream 0 PID to 33 and the stream 1 PID to 36 for
 an output mpegts file:
 @example
-ffmpeg -i infile -streamid 0:33 -streamid 1:36 out.ts
+ffmpeg -i inurl -streamid 0:33 -streamid 1:36 out.ts
 @end example
 
 @item -bsf[:@var{stream_specifier}] @var{bitstream_filters} 
(@emph{output,per-stream})
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index 4bc3ced39a..073b457256 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -12,7 +12,7 @@
 
 @chapter Synopsis
 
-ffplay [@var{options}] [@file{input_file}]
+ffplay [@var{options}] [@file{input_url}]
 
 @chapter Description
 @c man begin DESCRIPTION
@@ -106,8 +106,8 @@ the input audio.
 Use the option "-filters" to show all the available filters (including
 sources and sinks).
 
-@item -i @var{input_file}
-Read @var{input_file}.
+@item -i @var{input_url}
+Read @var{input_url}.
 @end table
 
 @section Advanced options
diff --git a/doc/ffprobe.texi b/doc/ffprobe.texi
index 1069ae32de..7514b2df73 100644
--- a/doc/ffprobe.texi
+++ b/doc/ffprobe.texi
@@ -12,7 +12,7 @@
 
 @chapter Synopsis
 
-ffprobe [@var{options}] [@file{input_file}]
+ffprobe [@var{options}] [@file{input_url}]
 
 @chapter Description
 @c man begin DESCRIPTION
@@ -24,8 +24,8 @@ For example it can be used to check the format of the 
container used
 by a multimedia stream and the format and type of each media stream
 contained in it.
 
-If a filename is specified in input, ffprobe will try to open and
-probe the file content. If the file cannot be opened or recognized as
+If a url is specified in input, ffprobe will try to open and
+probe the url content. If the url cannot be opened or recognized as
 a multimedia file, a positive exit code is returned.
 
 ffprobe may be employed both as a standalone application or in

[FFmpeg-devel] [PATCH 2/2] [RFC] avformat/avio: Fail on opening non file urls which exist as local files without whitelists

[Michael Niedermayer]

TODO: this needs to cleanly open a file url context for checking

This stops someone having a local file like "http:evilhost.com" and playing it
as "http:evilhost.com" without explicitly specifying the http protocol on the 
whitelist

That is it reduces the impact of people not using the "file:" scheme explicitly 
on untrusted
filenames at the expense of causing some problems if a remote url exists ad a 
local file

Signed-off-by: Michael Niedermayer 
---
 libavformat/avio.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libavformat/avio.c b/libavformat/avio.c
index 3606eb0fda..5a11add415 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -31,6 +31,8 @@
 #endif
 #include "url.h"
 
+static const struct URLProtocol *url_find_protocol(const char *filename);
+
 /** @name Logging context. */
 /*@{*/
 static const char *urlcontext_to_name(void *ptr)
@@ -188,6 +190,17 @@ int ffurl_connect(URLContext *uc, AVDictionary **options)
 return AVERROR(EINVAL);
 }
 
+if ((uc->flags & AVIO_FLAG_READ) &&
+!uc->protocol_whitelist &&
+!uc->protocol_blacklist &&
+strcmp(uc->prot->name, "file")) {
+const URLProtocol *file_protocol = url_find_protocol("file:");
+if (file_protocol->url_check(uc, 0) >= 0) {
+av_log(uc, AV_LOG_ERROR, "Ambigous filename %s exists, specify a 
whitelist!\n", uc->filename);
+return AVERROR(EEXIST);
+}
+}
+
 if (!uc->protocol_whitelist && uc->prot->default_whitelist) {
 av_log(uc, AV_LOG_DEBUG, "Setting default whitelist '%s'\n", 
uc->prot->default_whitelist);
 uc->protocol_whitelist = av_strdup(uc->prot->default_whitelist);
-- 
2.11.0

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Carl Eugen Hoyos]

2016-11-29 21:53 GMT+01:00 James Almer :
> On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote:
>> 2016-11-29 21:11 GMT+01:00 James Almer :

>>> He's trying to override an announced project decision of removing a feature.
>>
>> We - obviously - announced it to find somebody who would fix the issues
>> raised. If they are fixed, the "decision" is of course void, and we don't
>> have to vote about it.
>
> That's not what was announced, at all. Please, read the news entry in question
> and inform yourself in the subject before trying to participate in a 
> discussion.

That is exactly what I would like you to do.
What else would have been the reason for the announcement?

I believe that it is absolutely unacceptable to remove a used feature of
FFmpeg without a technical reason and I therefore believe that this
vote does not make much sense.
In any case, I am - still - all for keeping ffserver.

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix ticket id 5988 for DISCONTINUITY

[Steven Liu]

2016-12-04 21:36 GMT+08:00 Steven Liu :

> add EXT-X-DISCONTINUITY tag at the position of the append point.
>
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c |   14 ++
>  1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index e16fb0c..0e55a31 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -46,6 +46,7 @@ typedef struct HLSSegment {
>  char filename[1024];
>  char sub_filename[1024];
>  double duration; /* in seconds */
> +int discont;
>  int64_t pos;
>  int64_t size;
>
> @@ -107,6 +108,7 @@ typedef struct HLSContext {
>  int64_t max_seg_size; // every segment file max size
>  int nb_entries;
>  int discontinuity_set;
> +int discontinuity;
>
>  HLSSegment *segments;
>  HLSSegment *last_segment;
> @@ -387,6 +389,12 @@ static int hls_append_segment(struct AVFormatContext
> *s, HLSContext *hls, double
>  en->pos  = pos;
>  en->size = size;
>  en->next = NULL;
> +en->discont  = 0;
> +
> +if (hls->discontinuity) {
> +en->discont = 1;
> +hls->discontinuity = 0;
> +}
>
>  if (hls->key_info_file) {
>  av_strlcpy(en->key_uri, hls->key_uri, sizeof(en->key_uri));
> @@ -446,6 +454,7 @@ static int parse_playlist(AVFormatContext *s, const
> char *url)
>  goto fail;
>  }
>
> +hls->discontinuity = 0;
>  while (!avio_feof(in)) {
>  read_chomp_line(in, line, sizeof(line));
>  if (av_strstart(line, "#EXT-X-MEDIA-SEQUENCE:", )) {
> @@ -560,6 +569,10 @@ static int hls_window(AVFormatContext *s, int last)
>  iv_string = en->iv_string;
>  }
>
> +if (en->discont) {
> +avio_printf(out, "#EXT-X-DISCONTINUITY\n");
> +}
> +
>  if (hls->flags & HLS_ROUND_DURATIONS)
>  avio_printf(out, "#EXTINF:%ld,\n",  lrint(en->duration));
>  else
> @@ -883,6 +896,7 @@ static int hls_write_header(AVFormatContext *s)
>
>  if (hls->flags & HLS_APPEND_LIST) {
>  parse_playlist(s, s->filename);
> +hls->discontinuity = 1;
>  if (hls->init_time > 0) {
>  av_log(s, AV_LOG_WARNING, "append_list mode does not support
> hls_init_time,"
> " hls_init_time value will have no effect\n");
> --
> 1.7.1
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

applied!



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

Re: [FFmpeg-devel] [PATCH] ffprobe: Support adding av_log output to frames

[Stefano Sabatini]

On date Thursday 2016-12-01 22:21:17 +0100, Michael Niedermayer encoded:
> On Tue, Jun 14, 2016 at 05:55:47PM +0200, Stefano Sabatini wrote:
> > On date Wednesday 2016-06-08 18:20:39 +0200, Michael Niedermayer encoded:
> > > On Sun, Jun 05, 2016 at 12:56:08PM +0200, Stefano Sabatini wrote:
> > > > On date Tuesday 2016-05-31 21:23:27 +0200, Michael Niedermayer encoded:
> > > > > adding demuxer and other logs should be easy
> > > > > This forces single threaded decoding for simplicity
> > > > > It also requires pthreads, this could be avoided either with
> > > > > some lockless tricks or simply by assuming av_log would never be 
> > > > > called from
> > > > > another thread.
> > > > > 
> > > > > doc/ffprobe.xsd update missing (TODO & help welcome)
> > > > > 
> > > > > Fixes Ticket5521
> [...]
> > > > I'm not really sure about storing the log in frame, since they could
> > > > come from any context, not necessarily related to decoding.
> > > > 
> > > > OTOH, I'm not really sure how such feature could be implemented in a
> > > > really clean way.
> > > > 
> > > > About frame decoding errors, we could store an error in the decoded
> > > > frame itself.
> > > 
> > 
> > > I dont know what exactly is wanted ?
> > > 
> > 
> > I mean, we already have the AVFrame.decode_error_flags we could expose
> > to the user.
> > 
> 
> > > What i found interresting was to partition all av_log into
> > > closest related sections like decoder/demuxer/filter/...
> > > and add them there
> > > so that detailed information, not limited to errors about frame and
> > > packet related information can be associated with them
> > > this patch was just a step toward that
> > > if that feature isnt wanted we can drop the patch
> > 
> > I think this patch is interesting, but I don't want to clutter the
> > code too much, especially if we found a more general design which
> > could deprecate this one.
> 
> has anyone found a more general design ?
> 
> 
> > 
> > The problem with this approach is that the log is contained in the
> > frame element, when it could come from other parts of the code as
> > well.
> 
> when decoding a frame triggers a log message then its caused by the
> frame.
> It may come ultimately from the experssion evaluator for example but
> knowig that the message comes from the experssion evaluator is of
> little use, a grep would tell one that already.
> Knowing which frame triggers it seems more usefull to me
> 
> 
> > 
> > One option could be to define a -show_logs options, and optionally add
> > a filter specifying the contexts. Just storing the log in the frame
> > elements sounds a bit weird to me.
> 

> its certainly possible to extend this patch to also cover demuxer
> and other areas and then add a -show_logs to select what should be
> enabled
> is that what you meant ?
> 
> it seems thats not a argument against the patch as it is, just something
> that can be done as additional work afterwards
> 
> but quite possibly i misunderstand

Feel free to push the patch as is. The other thing I don't like is the
threading dependency but probably there is not much we can do about
it.
-- 
FFmpeg = Fostering and Free Mystic Patchable Egregious Ghost
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel