[FFmpeg-devel] [PATCH] avformat/concatdec: add fallback for calculating file duration

[Justin Ruggles]

If a file does not have a known duration, this leads to the timestamps
starting over for the next file, causing non-monotonic timestamps.
To prevent this, track the duration during demuxing and use it to
determine the current file duration before opening the next file.
---
 libavformat/concatdec.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index e8b37d6..0e18901 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -44,6 +44,7 @@ typedef struct {
 int64_t file_start_time;
 int64_t file_inpoint;
 int64_t duration;
+int64_t next_dts;
 ConcatStream *streams;
 int64_t inpoint;
 int64_t outpoint;
@@ -149,6 +150,7 @@ static int add_file(AVFormatContext *avf, char *filename, 
ConcatFile **rfile,
 file->url= url;
 file->start_time = AV_NOPTS_VALUE;
 file->duration   = AV_NOPTS_VALUE;
+file->next_dts   = AV_NOPTS_VALUE;
 file->inpoint= AV_NOPTS_VALUE;
 file->outpoint   = AV_NOPTS_VALUE;
 
@@ -509,8 +511,14 @@ static int open_next_file(AVFormatContext *avf)
 ConcatContext *cat = avf->priv_data;
 unsigned fileno = cat->cur_file - cat->files;
 
-if (cat->cur_file->duration == AV_NOPTS_VALUE)
-cat->cur_file->duration = cat->avf->duration - 
(cat->cur_file->file_inpoint - cat->cur_file->file_start_time);
+if (cat->cur_file->duration == AV_NOPTS_VALUE) {
+if (cat->avf->duration > 0 || cat->cur_file->next_dts == 
AV_NOPTS_VALUE) {
+cat->cur_file->duration = cat->avf->duration;
+} else {
+cat->cur_file->duration = cat->cur_file->next_dts;
+}
+cat->cur_file->duration -= (cat->cur_file->file_inpoint - 
cat->cur_file->file_start_time);
+}
 
 if (++fileno >= cat->nb_files) {
 cat->eof = 1;
@@ -627,6 +635,14 @@ static int concat_read_packet(AVFormatContext *avf, 
AVPacket *pkt)
 memcpy(metadata, packed_metadata, metadata_len);
 av_freep(_metadata);
 }
+
+if (cat->cur_file->duration == AV_NOPTS_VALUE && st->cur_dts != 
AV_NOPTS_VALUE) {
+int64_t next_dts = av_rescale_q(st->cur_dts, st->time_base, 
AV_TIME_BASE_Q);
+if (cat->cur_file->next_dts == AV_NOPTS_VALUE || next_dts > 
cat->cur_file->next_dts) {
+cat->cur_file->next_dts = next_dts;
+}
+}
+
 return ret;
 }
 
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: Fix DoS due to infinite loop

[Michael Niedermayer]

On Mon, Aug 28, 2017 at 11:21:39AM +0200, wm4 wrote:
> On Sun, 27 Aug 2017 19:16:03 +0200
> Michael Niedermayer  wrote:
> 
> > On Sat, Aug 26, 2017 at 01:26:58AM +0200, Michael Niedermayer wrote:
> > > Fixes: loop.m3u
> > > 
> > > The default max iteration count of 1000 is arbitrary and ideas for a 
> > > better solution are welcome
> > > 
> > > Found-by: Xiaohei and Wangchu from Alibaba Security Team
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  doc/demuxers.texi | 18 ++
> > >  libavformat/hls.c |  7 +++
> > >  2 files changed, 25 insertions(+)  
> > 
> > applied
> > 
> > [...]
> 
> I rejected this approach, but I guess patch reviews are ignored anyway.

I explicitly asked if you veto this patch, you did not veto it.
It is extreemly inpolite, to ignore an explicit question about
you objecting and afterwards claim your rejection was ignored.

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

[FFmpeg-devel] [PATCH] compat/cuda/ptx2c: strip CR from each line

[Ricardo Constantino]

Windows nvcc + cl.exe produce a .ctx file with CR+LF newlines which
need to be stripped to work with gcc.
---
 compat/cuda/ptx2c.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/compat/cuda/ptx2c.sh b/compat/cuda/ptx2c.sh
index 1f37023290..44b08b6ea2 100755
--- a/compat/cuda/ptx2c.sh
+++ b/compat/cuda/ptx2c.sh
@@ -29,7 +29,7 @@ NAME="$(basename "$IN" | sed 's/\..*//')"
 printf "const char %s_ptx[] = \\" "$NAME" > "$OUT"
 while read LINE
 do
-printf "\n\t\"%s\\\n\"" "$(printf "%s" "$LINE" | sed 's/["\\]/\\&/g')" >> 
"$OUT"
+printf "\n\t\"%s\\\n\"" "$(printf "%s" "$LINE"  | sed -e 's/\r//g' -e 
's/["\\]/\\&/g')" >> "$OUT"
 done < "$IN"
 printf ";\n" >> "$OUT"
 
-- 
2.13.3

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

Re: [FFmpeg-devel] [PATCH v4] avcodec/snowenc: fix setting motion_est option

[James Almer]

On 8/28/2017 9:13 PM, Michael Niedermayer wrote:
> On Sat, Aug 26, 2017 at 10:53:10PM -0300, James Almer wrote:
>> Remove usage of FF_MPV_COMMON_OPTS, and set SnowContext.motion_est directly.
>> Based on code from svq1enc.c
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/snow.h|  3 ++-
>>  libavcodec/snowenc.c | 11 +++
>>  2 files changed, 9 insertions(+), 5 deletions(-)
> 
> couldnt find another failure
> 
> thx

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

Re: [FFmpeg-devel] [PATCH v4] avcodec/snowenc: fix setting motion_est option

[Michael Niedermayer]

On Sat, Aug 26, 2017 at 10:53:10PM -0300, James Almer wrote:
> Remove usage of FF_MPV_COMMON_OPTS, and set SnowContext.motion_est directly.
> Based on code from svq1enc.c
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/snow.h|  3 ++-
>  libavcodec/snowenc.c | 11 +++
>  2 files changed, 9 insertions(+), 5 deletions(-)

couldnt find another failure

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

[FFmpeg-devel] [PATCH 3/3] avformat/mxfenc: Replace literal numbers by named enum values.

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c | 83 ++--
 1 file changed, 61 insertions(+), 22 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 71f4b5b905..afa5ef7e28 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -120,6 +120,45 @@ static void mxf_write_mpegvideo_desc(AVFormatContext *s, 
AVStream *st);
 static void mxf_write_cdci_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_generic_sound_desc(AVFormatContext *s, AVStream *st);
 
+enum {
+INDEX_MPEG2 = 0,
+INDEX_AES3,
+INDEX_WAV,
+INDEX_D10_625_50_50_VIDEO,
+INDEX_D10_625_50_50_AUDIO,
+INDEX_D10_525_60_50_VIDEO,
+INDEX_D10_525_60_50_AUDIO,
+INDEX_D10_625_50_40_VIDEO,
+INDEX_D10_625_50_40_AUDIO,
+INDEX_D10_525_60_40_VIDEO,
+INDEX_D10_525_60_40_AUDIO,
+INDEX_D10_625_50_30_VIDEO,
+INDEX_D10_625_50_30_AUDIO,
+INDEX_D10_525_60_30_VIDEO,
+INDEX_D10_525_60_30_AUDIO,
+INDEX_DV,
+INDEX_DV25_525_60,
+INDEX_DV25_625_50,
+INDEX_DV50_525_60,
+INDEX_DV50_625_50,
+INDEX_DV100_1080_60,
+INDEX_DV100_1080_50,
+INDEX_DV100_720_60,
+INDEX_DV100_720_50,
+INDEX_DNXHD_1080p_10bit_HIGH,
+INDEX_DNXHD_1080p_8bit_MEDIUM,
+INDEX_DNXHD_1080p_8bit_HIGH,
+INDEX_DNXHD_1080i_10bit_HIGH,
+INDEX_DNXHD_1080i_8bit_MEDIUM,
+INDEX_DNXHD_1080i_8bit_HIGH,
+INDEX_DNXHD_720p_10bit,
+INDEX_DNXHD_720p_8bit_HIGH,
+INDEX_DNXHD_720p_8bit_MEDIUM,
+INDEX_DNXHD_720p_8bit_LOW,
+INDEX_JPEG2000,
+INDEX_H264,
+};
+
 static const MXFContainerEssenceEntry mxf_essence_container_uls[] = {
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x02,0x0D,0x01,0x03,0x01,0x02,0x04,0x60,0x01 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
@@ -1681,37 +1720,37 @@ AVPacket *pkt)
 
 switch (cid) {
 case 1235:
-sc->index = 24;
+sc->index = INDEX_DNXHD_1080p_10bit_HIGH;
 sc->component_depth = 10;
 break;
 case 1237:
-sc->index = 25;
+sc->index = INDEX_DNXHD_1080p_8bit_MEDIUM;
 break;
 case 1238:
-sc->index = 26;
+sc->index = INDEX_DNXHD_1080p_8bit_HIGH;
 break;
 case 1241:
-sc->index = 27;
+sc->index = INDEX_DNXHD_1080i_10bit_HIGH;
 sc->component_depth = 10;
 break;
 case 1242:
-sc->index = 28;
+sc->index = INDEX_DNXHD_1080i_8bit_MEDIUM;
 break;
 case 1243:
-sc->index = 29;
+sc->index = INDEX_DNXHD_1080i_8bit_HIGH;
 break;
 case 1250:
-sc->index = 30;
+sc->index = INDEX_DNXHD_720p_10bit;
 sc->component_depth = 10;
 break;
 case 1251:
-sc->index = 31;
+sc->index = INDEX_DNXHD_720p_8bit_HIGH;
 break;
 case 1252:
-sc->index = 32;
+sc->index = INDEX_DNXHD_720p_8bit_MEDIUM;
 break;
 case 1253:
-sc->index = 33;
+sc->index = INDEX_DNXHD_720p_8bit_LOW;
 break;
 default:
 return -1;
@@ -1772,7 +1811,7 @@ static int mxf_parse_dv_frame(AVFormatContext *s, 
AVStream *st, AVPacket *pkt)
 
 switch (stype) {
 case 0x18: // DV100 720p
-ul_index = 6 + pal;
+ul_index = INDEX_DV100_720_50 + pal;
 frame_size = pal ? 288000 : 24;
 if (sc->interlaced) {
 av_log(s, AV_LOG_ERROR, "source marked as interlaced but codec 
profile is progressive\n");
@@ -1780,19 +1819,19 @@ static int mxf_parse_dv_frame(AVFormatContext *s, 
AVStream *st, AVPacket *pkt)
 }
 break;
 case 0x14: // DV100 1080i
-ul_index = 4 + pal;
+ul_index = INDEX_DV100_1080_50 + pal;
 frame_size = pal ? 576000 : 48;
 break;
 case 0x04: // DV50
-ul_index = 2 + pal;
+ul_index = INDEX_DV50_525_60 + pal;
 frame_size = pal ? 288000 : 24;
 break;
 default: // DV25
-ul_index = 0 + pal;
+ul_index = INDEX_DV25_525_60 + pal;
 frame_size = pal ? 144000 : 12;
 }
 
-sc->index = ul_index + 16;
+sc->index = ul_index;
 sc->codec_ul =  _essence_container_uls[sc->index].codec_ul;
 
 if(s->oformat == _mxf_opatom_muxer) {
@@ -2109,15 +2148,15 @@ static int mxf_write_header(AVFormatContext *s)
 return -1;
 }
 if ((sc->video_bit_rate == 5000) && (mxf->time_base.den == 
25)) {
-sc->index = 3;
+sc->index = INDEX_D10_625_50_50_VIDEO;
 } else if ((sc->video_bit_rate == 4840 || 
sc->video_bit_rate == 5000) && (mxf->time_base.den != 25)) {
-sc->index = 5;
+sc->index = INDEX_D10_525_60_50_VIDEO;
 } else if (sc->video_bit_rate == 4000) {
-if (mxf->time_base.den == 25) sc->index 

[FFmpeg-devel] [PATCH 1/3] avformat/mxfenc: Allow overriding numerical color_siting value.

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/mxfenc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 12fc9abbc6..ccfa0d6341 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -322,6 +322,7 @@ typedef struct MXFContext {
 uint8_t umid[16];///< unique material identifier
 int channel_count;
 int signal_standard;
+int color_siting;
 uint32_t tagged_value_count;
 AVRational audio_edit_rate;
 int store_user_comments;
@@ -2085,6 +2086,8 @@ static int mxf_write_header(AVFormatContext *s)
 case AVCHROMA_LOC_TOP: sc->color_siting = 1; break;
 case AVCHROMA_LOC_CENTER:  sc->color_siting = 3; break;
 }
+if (mxf->color_siting >= 0)
+sc->color_siting = mxf->color_siting;
 
 mxf->timecode_base = (tbc.den + tbc.num/2) / tbc.num;
 spf = ff_mxf_get_samples_per_frame(s, tbc);
@@ -2668,7 +2671,9 @@ static int mxf_interleave(AVFormatContext *s, AVPacket 
*out, AVPacket *pkt, int
 { "smpte349m", "SMPTE 349M (1485 Mbps mappings)",\
   0, AV_OPT_TYPE_CONST, {.i64 = 6}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
"signal_standard"},\
 { "smpte428", "SMPTE 428-1 DCDM",\
-  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
"signal_standard"},
+  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
"signal_standard"},\
+{ "color_siting", "Force/set Color siting",\
+  offsetof(MXFContext, color_siting), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 7, 
AV_OPT_FLAG_ENCODING_PARAM, "color_siting"},\
 
 
 
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 2/3] avformat/mxfenc: Check that the video codec in D-10 is MPEG-2

[Michael Niedermayer]

Others do not work, but nothing rejects them prior to this patch if the
parameters otherwise match

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

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index ccfa0d6341..71f4b5b905 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2104,6 +2104,10 @@ static int mxf_write_header(AVFormatContext *s)
 
 sc->video_bit_rate = st->codecpar->bit_rate;
 if (s->oformat == _mxf_d10_muxer) {
+if (st->codecpar->codec_id != AV_CODEC_ID_MPEG2VIDEO) {
+av_log(s, AV_LOG_ERROR, "error MXF D-10 only support 
MPEG-2 Video\n");
+return -1;
+}
 if ((sc->video_bit_rate == 5000) && (mxf->time_base.den == 
25)) {
 sc->index = 3;
 } else if ((sc->video_bit_rate == 4840 || 
sc->video_bit_rate == 5000) && (mxf->time_base.den != 25)) {
-- 
2.14.1

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

[FFmpeg-devel] [PATCH] Fix SIGBUS on ARM when compiled with binutils 2.29

[James Cowgill]

In binutils 2.29, the behavior of the ADR instruction changed so that 1 is
added to the address of a Thumb function (previously nothing was added). This
allows the loaded address to be passed to a BLX instruction and the correct
mode change will occur.

So that the behavior matches in binutils 2.29 and pre-2.29, use .eqv to
pre-calculate the function address without the automatic +1 fixup. Then use
these new symbols as the function addresses to be loaded.

See: https://sourceware.org/bugzilla/show_bug.cgi?id=21458

Fixes ticket 6571.

Signed-off-by: James Cowgill 
---
 libavcodec/arm/h264idct_neon.S | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/libavcodec/arm/h264idct_neon.S b/libavcodec/arm/h264idct_neon.S
index 4f68bdb9f5..04b1ea583b 100644
--- a/libavcodec/arm/h264idct_neon.S
+++ b/libavcodec/arm/h264idct_neon.S
@@ -20,6 +20,18 @@
 
 #include "libavutil/arm/asm.S"
 
+# In binutils 2.29, the behavior of the ADR instruction changed so that 1 is
+# added to the address of a Thumb function (previously nothing was added).
+#
+# These .eqv are used to pre-calculate the correct address with +CONFIG_THUMB 
so
+# that ADR will work with both old and new versions binutils.
+#
+# See: https://sourceware.org/bugzilla/show_bug.cgi?id=21458
+.eqv eqv_ff_h264_idct_add_neon, X(ff_h264_idct_add_neon) + CONFIG_THUMB
+.eqv eqv_ff_h264_idct_dc_add_neon,  X(ff_h264_idct_dc_add_neon) + CONFIG_THUMB
+.eqv eqv_ff_h264_idct8_add_neon,X(ff_h264_idct8_add_neon) + CONFIG_THUMB
+.eqv eqv_ff_h264_idct8_dc_add_neon, X(ff_h264_idct8_dc_add_neon) + CONFIG_THUMB
+
 function ff_h264_idct_add_neon, export=1
 vld1.64 {d0-d3},  [r1,:128]
 vmov.i16q15, #0
@@ -113,8 +125,8 @@ function ff_h264_idct_add16_neon, export=1
 movne   lr,  #0
 cmp lr,  #0
 ite ne
-adrne   lr,  X(ff_h264_idct_dc_add_neon) + CONFIG_THUMB
-adreq   lr,  X(ff_h264_idct_add_neon)+ CONFIG_THUMB
+adrne   lr,  eqv_ff_h264_idct_dc_add_neon
+adreq   lr,  eqv_ff_h264_idct_add_neon
 blx lr
 2:  subsip,  ip,  #1
 add r1,  r1,  #32
@@ -138,8 +150,8 @@ function ff_h264_idct_add16intra_neon, export=1
 cmp r8,  #0
 ldrsh   r8,  [r1]
 iteet   ne
-adrne   lr,  X(ff_h264_idct_add_neon)+ CONFIG_THUMB
-adreq   lr,  X(ff_h264_idct_dc_add_neon) + CONFIG_THUMB
+adrne   lr,  eqv_ff_h264_idct_add_neon
+adreq   lr,  eqv_ff_h264_idct_dc_add_neon
 cmpeq   r8,  #0
 blxne   lr
 subsip,  ip,  #1
@@ -166,8 +178,8 @@ function ff_h264_idct_add8_neon, export=1
 cmp r8,  #0
 ldrsh   r8,  [r1]
 iteet   ne
-adrne   lr,  X(ff_h264_idct_add_neon)+ CONFIG_THUMB
-adreq   lr,  X(ff_h264_idct_dc_add_neon) + CONFIG_THUMB
+adrne   lr,  eqv_ff_h264_idct_add_neon
+adreq   lr,  eqv_ff_h264_idct_dc_add_neon
 cmpeq   r8,  #0
 blxne   lr
 add r12, r12, #1
@@ -388,8 +400,8 @@ function ff_h264_idct8_add4_neon, export=1
 movne   lr,  #0
 cmp lr,  #0
 ite ne
-adrne   lr,  X(ff_h264_idct8_dc_add_neon) + CONFIG_THUMB
-adreq   lr,  X(ff_h264_idct8_add_neon)+ CONFIG_THUMB
+adrne   lr,  eqv_ff_h264_idct8_dc_add_neon
+adreq   lr,  eqv_ff_h264_idct8_add_neon
 blx lr
 2:  subsr12, r12, #4
 add r1,  r1,  #128
-- 
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [mov] Remove concept of ctts entries with count > 1.

[Dale Curtis]

Previous ctts patches have all changed the system to always using
count=1 since we expect ctts data to be 1:1 with samples. This deletes
the concept of count>1 samples for clarity and performance.

Requires "[mov] Bail when invalid sample data is present." to land first.\

- dale


one_count_ctts.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Dale Curtis]

On Fri, Aug 25, 2017 at 10:18 AM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:
>
> hmm
>
> maybe i misunderstand but assuming we insert a block of dummy blank
> entries (without breaking monotonicity) and keep a pointer to that
> block
>
> then add entries with a av_add_index_entry()
> and in case of failure remove the blank entries
>
> this would result in the same as now and seems relativly simple
> it would not need memmove and in general would not need a log n
> search if each falls on the first spot of the block
>
> or am i missing something ?
>

This patch does what you're suggesting, but I'm not confident it's right in
all cases.

- dale


ctts_fast.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mov: prevent duplication of first fragment's ctts_data

[Dale Curtis]

lgtm, my patch is still necessary to ensure ctts samples aren't trampled
when new headers do need to be read. This should prevent unnecessary work
and spammy logs.

- dale

On Sat, Aug 5, 2017 at 6:04 PM, Daniel Glöckner  wrote:

> MP4 files with fragments might have the first moof box that is mentioned
> in a fragment index before the first mdat box. Since it is then already
> parsed by mov_read_header, we have to make sure that mov_switch_root
> will not parse it again when seeking by setting the headers_read flag in
> the index. Parsing it a second time would cause the ctts_data array to
> receive a second copy of the information from the trun box, leading to
> wrong PTS values for the second and following fragments in presence of
> B-frames.
>
> Fixes ticket 6560.
>
> Signed-off-by: Daniel Glöckner 
> ---
>  libavformat/mov.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 63f84be..c2da1b6 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -6345,6 +6345,13 @@ static int mov_read_header(AVFormatContext *s)
>  }
>  ff_configure_buffers_for_index(s, AV_TIME_BASE);
>
> +for (i = 0; i < mov->fragment_index_count; i++) {
> +MOVFragmentIndex *idx = mov->fragment_index_data[i];
> +for (j = 0; j < idx->item_count; j++)
> +if (idx->items[j].moof_offset <= mov->fragment.moof_offset)
> +idx->items[j].headers_read = 1;
> +}
> +
>  return 0;
>  }
>
> --
> 2.7.0
>
> ___
> 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] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/28/2017 11:42 PM, Hendrik Leppkes wrote:

On Mon, Aug 28, 2017 at 11:36 PM, Jorge Ramirez
 wrote:

But manually "nesting" AVBufferRefs to make any underlying state
refcounted would also work.


I think so, context release now looks like this (it raises an ERROR to the
user) but will not lock or poll.


Thats not really what he was referring to, but to avoid the "blocking" entirely.

Basically, what you would do is have an AVBufferRef that basically
"holds" your v4l2 context, and every frame holds a reference on this
AVBufferRef - and only when all frames are released, the "free"
function on your context AVBufferRef is called, and you can then
release all its resources - without having to block the avcodec_close
function.


I see, thanks for the info

still, with the current v4l2 buffer design (previous thread in the 
discussion), I can't allow avcodec_close to complete - so I have to 
block or at least timeblock- when AVBuffersRefs pointing to v4l2 buffers 
have not been released by the ffmpeg user (if the user tried to access 
that memory it would result in bus errors since the mmaped addresses 
would not be valid)




This is basically what AVHWFramesContext does, just with more frills around it.


ah!
but what about memcpies (do you know if the AVHWFramesContext framework 
copies to the hardware buffers before processing and then back to user 
buffers? because I see no alternative if the AVBufferRefs must be kept 
alive for ever...


- Hendrik
___
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] [mov] Bail when invalid sample data is present.

[Dale Curtis]

On Fri, Aug 25, 2017 at 6:09 PM, Michael Niedermayer  wrote:
>
> This changes the printed duration start time and bitrate for
> MAV_0034.3G2
> see
> https://trac.ffmpeg.org/ticket/2757


Thanks, I've restored the ability to query these types of files. That file
also reveals the potential for a case that was unhandled prior to any of my
patches. File which mixed boxes with and without ctts entries would pick up
either the wrong ctts entry or uninitialized data. Zero initializing the
the ctts data array solves this problem.

- dale


sample_count_fix_v4.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Hendrik Leppkes]

On Mon, Aug 28, 2017 at 11:36 PM, Jorge Ramirez
 wrote:
>>
>> But manually "nesting" AVBufferRefs to make any underlying state
>> refcounted would also work.
>
>
> I think so, context release now looks like this (it raises an ERROR to the
> user) but will not lock or poll.
>

Thats not really what he was referring to, but to avoid the "blocking" entirely.

Basically, what you would do is have an AVBufferRef that basically
"holds" your v4l2 context, and every frame holds a reference on this
AVBufferRef - and only when all frames are released, the "free"
function on your context AVBufferRef is called, and you can then
release all its resources - without having to block the avcodec_close
function.
This is basically what AVHWFramesContext does, just with more frills around it.

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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/28/2017 09:53 PM, wm4 wrote:

On Mon, 28 Aug 2017 21:24:26 +0200
Jorge Ramirez  wrote:


On 08/28/2017 02:16 PM, Jorge Ramirez wrote:

On 08/28/2017 12:47 PM, wm4 wrote:

I guess that instead of polling for the AVBufferRef to be unreferenced,
I can associate a sync (ie a sempahore) to each buffer, take it on
release and post the semaphore on the AVBufferRefs being unreferenced.
that is actually pretty clean in terms of cpu usage.

That would just freeze an API user calling avcodec_close(), when it
keeps around decoded AVFrames for later use.

yes I understand, but it does avoid using the CPU to poll for the
buffer release (an incremental improvement)

but yes I think that the message is that even though this proposal
might suffice for simple video players (my tests) is not good enough
for other users requiring the decoded frame for post processing.

is this a blocker to upstream or could I continue working with it
flagging the encoder/decoder as EXPERIMENTAL? the current situation at
least keeps video players happy.

I'd say yes this is a blocker. We usually try to avoid committing
half-finished code, because it often means it will be never finished.


hi, I forgot to say earlier, thanks for all the review over the past 
couple of days (it has been of much help).


on the half finished matter, the issue that I face is that the current 
code doesn't cover the use case where _all_ the processed frames have to 
be kept available indefinitely (this is why I thought that perhaps 
setting .capabilities to AV_CODEC_CAP_EXPERIMENTAL could be an option to 
upstream and get more exposure to other users;


I do plan to continue supporting v4l2 ffmpeg integration - mmaped 
filters, DRM and so on...having invested this long I do want to see this 
through; and since I can't guaranteed that some "force majeure" wont 
happen I think the sooner the code I have been working on can get 
exposure the sooner we will start seeing contributions.


Anyhow, the current code does support the typical use case of most video 
players so it would benefit a considerable amount of users.


does it have to be an all or nothing at this point or could we flag the 
v4l2 m2m as experimental codecs?




  

just wondering, if the AVBufferRefs must live for ever (ie, after the
codecs have been closed), what do other codecs dequeuing from a limited
number of re-usable hardware allocated buffers do?
do they use the CPU allocate and copy the data from those buffers to the
heap?


Like I wrote before: hwaccels use AVHWFramesContext, which was made
more or less for this situation. If you want FD support later (for
something like zero-copy transcoding or playback), AVHWFramesContext
will probably be mandatory anyway. But I guess it's a big change for
someone not familiar with the codebase.


Yes I had a look and it seems not an easy change to integrate.

Still I'd like to make sure we are talking about the same requirement 
because if AVHWFramesContext works around the issue [1] , I can probably 
do the same with a few more lines of code (including the FD support for 
v4l2 which is pretty straight forward)


[1]  When:
a) there is a limited number of buffers allocated by the hardware and
b) these buffers are mapped to the process address space and
c) the application can choose to keep _all_ decoded buffers for post 
processing,


then there is no other option than copying each of the processed buffers 
to newly allocated areas in the heap (there can be no magic on this 
since the hardware buffers are always limited and have to be reused).


I had a look a AVHWFRamesContext and it seems to me  that under the 
transfer frames semantics it performs some sort of memcpy in/out 
(something I could do on every capture buffer dequeue if this is the 
requirement). I could be wrong and therefore would appreciate the 
clarification if the previous comment is incorrect.


notice that I do insist on continue using V4L2_MEMORY_MMAP (instead of 
switching to V4L2_MEMORY_USERPTR) because it is easy to export the 
buffers as DMABUFs (~30 lines of code) and then pass these in FDs (which 
could be associated to short lived AVBufferRefs for DRM)





But manually "nesting" AVBufferRefs to make any underlying state
refcounted would also work.


I think so, context release now looks like this (it raises an ERROR to 
the user) but will not lock or poll.


void avpriv_v4l2_context_release(V4L2Context* ctx)
{
struct timespec timeout = { 0, 0};
int i, ret;

if (!ctx->buffers)
return;

timeout.tv_sec = av_gettime() / 100 + 10;

/* wait until all buffers owned by the user are returned */
for (i = 0; i < ctx->num_buffers; i++) {
for (;;) {
ret = sem_timedwait(>buffers[i].delete_sync, );
if (!ret)
break;
if (errno == EINTR)
continue;
if (errno == ETIMEDOUT)
av_log(ctx->log_ctx, AV_LOG_ERROR, 

Re: [FFmpeg-devel] [PATCH] Use NULL_IF_CONFIG_SMALL for AVOption tables.

[Marton Balint]

On Mon, 28 Aug 2017, Dale Curtis wrote:


On Mon, Aug 28, 2017 at 2:28 AM, wm4  wrote:



Seems way too intrusive and the result makes AVOption tables even
uglier and harder to read.



Agree it's ugly. Any suggestions? I tried some way of forcing the AVOption
entry to have zero-storage (thus null always), but my language-fu was not
strong enough. Moving options data into some sort of data file and
programmatically generating the tables might work.


Have you considered using/creating a semantic patch to change these? I bet 
there are other semantically well-defined cases where you can get rid of 
text if you are really aiming for reduced size.


I'd love to see that kind of text reducing spatch maintained for people who 
really aiming for small size, and with it probably we can get rid of most 
of the existing NULL_IF_CONFIG_SMALL cases as well.


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

Re: [FFmpeg-devel] [PATCH] Use NULL_IF_CONFIG_SMALL for AVOption tables.

[wm4]

On Mon, 28 Aug 2017 13:28:16 -0700
Dale Curtis  wrote:

> On Mon, Aug 28, 2017 at 12:56 PM, wm4  wrote:
> >
> > LTO seems unlikely to help in this situation - the linker can't know
> > whether struct members and their initializers are unused.
> >  
> 
> Correct.
> 
> 
> >
> > But I think there's much much bigger fish to fry to save space. For
> > example, I bet disabling unneeded codecs will significantly reduce
> > binary size.  
> 
> 
> I think the fish to fry depend on your configuration settings :) Chrome
> disables everything we can already.
> 
> Seems there's consensus that folk don't like the patch, we can carry it
> downstream if that's the case. It's not as much as I hoped, so we may drop
> it as well though.

Well, I agree that it would be nice if the binary size of the libs
would be smaller. How much do you expect to save? Saving 12KB of binary
size with a 200KB patch is just not convincing.

A less realistic approach would be to remove the field from AVOption
completely, and have the CLI programs (ffmpeg.c etc.) use a different
mechanism for getting per-option help strings. But that probably won't
happen for multiple reasons.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Use NULL_IF_CONFIG_SMALL for AVOption tables.

[Dale Curtis]

On Mon, Aug 28, 2017 at 12:56 PM, wm4  wrote:
>
> LTO seems unlikely to help in this situation - the linker can't know
> whether struct members and their initializers are unused.
>

Correct.


>
> But I think there's much much bigger fish to fry to save space. For
> example, I bet disabling unneeded codecs will significantly reduce
> binary size.


I think the fish to fry depend on your configuration settings :) Chrome
disables everything we can already.

Seems there's consensus that folk don't like the patch, we can carry it
downstream if that's the case. It's not as much as I hoped, so we may drop
it as well though.

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

Re: [FFmpeg-devel] [PATCH] Use NULL_IF_CONFIG_SMALL for AVOption tables.

[wm4]

On Mon, 28 Aug 2017 19:42:44 +0100
Rostislav Pehlivanov  wrote:

> On 26 August 2017 at 00:20, Dale Curtis  wrote:
> 
> > Saves ~12kb of binary size and seems like a good use of
> > CONFIG_SMALL. I've only converted some of the largest
> > tables in this patch, there's way more to do if this is a
> > reasonable direction.
> >
> > - dale
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >  
> I disagree with this patch as well. If you need more space savings use LTO.
> IMO we should drop CONFIG_SMALL for codec descriptions too.

LTO seems unlikely to help in this situation - the linker can't know
whether struct members and their initializers are unused.

But I think there's much much bigger fish to fry to save space. For
example, I bet disabling unneeded codecs will significantly reduce
binary size.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[wm4]

On Mon, 28 Aug 2017 21:24:26 +0200
Jorge Ramirez  wrote:

> On 08/28/2017 02:16 PM, Jorge Ramirez wrote:
> > On 08/28/2017 12:47 PM, wm4 wrote:  
> >>> I guess that instead of polling for the AVBufferRef to be unreferenced,
> >>> I can associate a sync (ie a sempahore) to each buffer, take it on
> >>> release and post the semaphore on the AVBufferRefs being unreferenced.
> >>> that is actually pretty clean in terms of cpu usage.  
> >> That would just freeze an API user calling avcodec_close(), when it
> >> keeps around decoded AVFrames for later use.  
> >
> > yes I understand, but it does avoid using the CPU to poll for the 
> > buffer release (an incremental improvement)
> >
> > but yes I think that the message is that even though this proposal 
> > might suffice for simple video players (my tests) is not good enough 
> > for other users requiring the decoded frame for post processing.
> >
> > is this a blocker to upstream or could I continue working with it 
> > flagging the encoder/decoder as EXPERIMENTAL? the current situation at 
> > least keeps video players happy.

I'd say yes this is a blocker. We usually try to avoid committing
half-finished code, because it often means it will be never finished.

> >
> >  
> 
> just wondering, if the AVBufferRefs must live for ever (ie, after the 
> codecs have been closed), what do other codecs dequeuing from a limited 
> number of re-usable hardware allocated buffers do?
> do they use the CPU allocate and copy the data from those buffers to the 
> heap?
> 

Like I wrote before: hwaccels use AVHWFramesContext, which was made
more or less for this situation. If you want FD support later (for
something like zero-copy transcoding or playback), AVHWFramesContext
will probably be mandatory anyway. But I guess it's a big change for
someone not familiar with the codebase.

But manually "nesting" AVBufferRefs to make any underlying state
refcounted would also work.

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

Re: [FFmpeg-devel] Odp: Re: [PATCH v15] avformat/dashdec: add dash demuxer base version

[wm4]

On Mon, 28 Aug 2017 11:28:33 +0200
samsamsam  wrote:

> OK. I will. What about adding validation of format instead of adding  
> something like `%0*PRId64`?   Dnia 28 sierpnia 2017 03:30 
> Rodger Combs rodger.co...@gmail.com napisał(a):  If you know of such 
> a vulnerability, report it toffmpeg-secur...@ffmpeg.org . New code with 
> known vulnerabilities will not be accepted.   Sent from my iPhone   On Aug 
> 27, 2017, at 14:04, samsamsamsamsam...@o2.pl  wrote:  
> get_repl_pattern_and_format, you should have a fixed value of something like 

Your mails are unreadable. In your previous mail, I couldn't
distinguish text you quoted and which you wrote. In this one, your mail
client seems to have removed all line breaks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/28/2017 02:16 PM, Jorge Ramirez wrote:

On 08/28/2017 12:47 PM, wm4 wrote:

I guess that instead of polling for the AVBufferRef to be unreferenced,
I can associate a sync (ie a sempahore) to each buffer, take it on
release and post the semaphore on the AVBufferRefs being unreferenced.
that is actually pretty clean in terms of cpu usage.

That would just freeze an API user calling avcodec_close(), when it
keeps around decoded AVFrames for later use.


yes I understand, but it does avoid using the CPU to poll for the 
buffer release (an incremental improvement)


but yes I think that the message is that even though this proposal 
might suffice for simple video players (my tests) is not good enough 
for other users requiring the decoded frame for post processing.


is this a blocker to upstream or could I continue working with it 
flagging the encoder/decoder as EXPERIMENTAL? the current situation at 
least keeps video players happy.





just wondering, if the AVBufferRefs must live for ever (ie, after the 
codecs have been closed), what do other codecs dequeuing from a limited 
number of re-usable hardware allocated buffers do?
do they use the CPU allocate and copy the data from those buffers to the 
heap?


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

Re: [FFmpeg-devel] [PATCH] Use NULL_IF_CONFIG_SMALL for AVOption tables.

[Carl Eugen Hoyos]

2017-08-28 20:42 GMT+02:00 Rostislav Pehlivanov :

> I disagree with this patch as well.

> If you need more space savings use LTO.

How is this related?

> IMO we should drop CONFIG_SMALL for codec descriptions too.

Did this ever hit you in any way?

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

Re: [FFmpeg-devel] [PATCH] Use NULL_IF_CONFIG_SMALL for AVOption tables.

[Rostislav Pehlivanov]

On 26 August 2017 at 00:20, Dale Curtis  wrote:

> Saves ~12kb of binary size and seems like a good use of
> CONFIG_SMALL. I've only converted some of the largest
> tables in this patch, there's way more to do if this is a
> reasonable direction.
>
> - dale
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
I disagree with this patch as well. If you need more space savings use LTO.
IMO we should drop CONFIG_SMALL for codec descriptions too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Use NULL_IF_CONFIG_SMALL for AVOption tables.

[Dale Curtis]

On Mon, Aug 28, 2017 at 2:28 AM, wm4  wrote:
>
>
> Seems way too intrusive and the result makes AVOption tables even
> uglier and harder to read.


Agree it's ugly. Any suggestions? I tried some way of forcing the AVOption
entry to have zero-storage (thus null always), but my language-fu was not
strong enough. Moving options data into some sort of data file and
programmatically generating the tables might work.

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

[FFmpeg-devel] [PATCH] avfilter/mcdeint: remove usage of deprecated AVCodecContext.me_method

[James Almer]

Signed-off-by: James Almer 
---
Depends on patch "avcodec/snowenc: fix setting motion_est option"

 libavfilter/vf_mcdeint.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_mcdeint.c b/libavfilter/vf_mcdeint.c
index 26387b84e7..f07e1a0d60 100644
--- a/libavfilter/vf_mcdeint.c
+++ b/libavfilter/vf_mcdeint.c
@@ -52,6 +52,7 @@
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 #include "libavcodec/avcodec.h"
+#include "libavcodec/snow.h"
 #include "avfilter.h"
 #include "formats.h"
 #include "internal.h"
@@ -134,7 +135,7 @@ static int config_props(AVFilterLink *inlink)
 case MODE_EXTRA_SLOW:
 enc_ctx->refs = 3;
 case MODE_SLOW:
-enc_ctx->me_method = ME_ITER;
+av_dict_set(, "motion_est", AV_STRINGIFY(FF_ME_ITER), 0);
 case MODE_MEDIUM:
 enc_ctx->flags |= AV_CODEC_FLAG_4MV;
 enc_ctx->dia_size = 2;
-- 
2.13.3

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

[FFmpeg-devel] Odp: Re: [PATCH v15] avformat/dashdec: add dash demuxer base version

[samsamsam]

Validation will be very simple. I am talking about something like this:  static 
int get_repl_pattern_and_format(co char *i_url, const char *i_marker, char 
**o_pattern, char **o_format)   {  ...  +    for(ptr=start + marker_len; 
ptr  (end - 1); ++ptr) {  /*there is need to check this condition :P */  +  
  if (*ptr != 0) {  +   // Unknown format add log 
here   +  � goto finish;  +    }  +    }      
format_len = end - start - marker_len - 1 + strlen(PRId64);      *o_format 
= av_mallocz(format_len+1);      strncpy(*o_format, start + marker_len, end 
- start - marker_len -1);      strcat(*o_format, PRId64);  ...  }




  Dnia 28 sierpnia 2017 11:30 Rodger Combs 
rodger.co...@gmail.com napisał(a):


   I would expect parsing the number internally and using the 
additional arg to be simpler and easier to verify than format string 
validation.   On Aug 28, 2017, at 04:28, samsamsamsamsam...@o2.pl  
wrote:  OK. I will. What about adding validation of format instead of adding 
 something like `%0*PRId64`?   Dnia 28 sierpnia 2017 03:30 
Rodger Combsrodger.co...@gmail.com  napisał(a):  If you know of 
such a vulnerability, report it to ffmpeg-secur...@ffmpeg.org . New code 
with known vulnerabilities will not be accepted.   Sent from my iPhone   On Aug 
27, 2017, at 14:04, samsamsam samsam...@o2.pl  wrote:  
get_repl_pattern_and_format, you should have a fixed value of something like 
`%0*PRId64`   If you afraid about safety then the only thing which 
need to be added to  get_repl_pattern_and_format is validation of format.  
Simple loop to validate format will be enough. Do you agree?    Anyway we are 
talking about safety but parser for mp4 atoms missing checking and there is 
quite easy to make segfault of the libavformat when try to prepared mp4 file.   
I understand that you want to have maximum safety with new code but I hope you 
know that ffmpeg at all is not safety.   Regards,  SSS   Dnia 27 sierpnia 2017 
16:34 Rodger Combs rodger.co...@gmail.com  napisał(a):  Youre 
still calling snprintf with a string derived from the XML, which is still not 
safe. Rather than having a format copied from the source in 
get_repl_pattern_and_format, you should have a fixed value of something like 
`%0*PRId64`, and specify an additional precision argument 
you parse from the XML yourself. I cant reiterate this enough: _never pass 
data from the XML into the format-string arg of a printf-family function_.   
Also, rather than calling snprintf() twice with an av_malloc() in between, you 
can just call av_asprintf(). Thats what it does internally anyway.   On 
Aug 27, 2017, at 09:19, Steven Liu l...@chinaffmpeg.org  wrote:   
ffmpeg need a dash demuxer for demux the dash formats base on  github.com 
github.com   TODO:  1. support multi bitrate dash   v2 fixed:  1. from 
autodetect to disabled  2. from camelCase code style to ffmpeg code style  3. 
from RepType to AVMediaType  4. fix variable typo  5. change time value from 
uint32_t to uint64_t  6. removed be used once API  7. change time(NULL)`, 
except it is not 2038-safe. to av_gettime and av_timegm  8. merge complex 
free operation to free_fragment  9. use API from snprintf to av_asprintf   v3 
fixed:  1. fix typo from --enabled-xml2 to --enable-xml2   v4 fixed:  1. from 
--enable-xml2 to --enable-libxml2  2. move system includes to top  3. remove 
nouse includes  4. rename enum name  5. add a trailing comma for the last entry 
enum  6. fix comment typo  7. add const to DASHContext class front  8. check 
sscanf if return arguments and give warning message when error  9. check 
validity before free seg-url and seg  10. check if the val is null, before 
use atoll   v5 fixed:  1. fix typo from mainifest to manifest   v6 fixed:  1. 
from realloc to av_realloc  2. from free to av_free   v7 fixed:  1. remove the 
-lxml2 from configure when require_pkg_config   v8 fixed:  1. fix replace 
filename template by av_asprintf secure problem   v9 modified:  1. make 
manifest parser clearly   v10 fixed:  1. fix function API name code style  2. 
remove redundant strreplace call  3. remove redundant memory operation and 
check return value from get_content_url()  4. add space between ) and {  5. 
remove no need to log the value for print   v11 fixed:  1. from atoll to 
strtoll   v12 fixed:  1. remove strreplace and instead by av_strreplace   v13 
fixed:  1. fix bug: cannot play:  dash.edgesuite.net dash.edgesuite.net   v14 
fixed:  1. fix bug: TLS connection was non-properly terminated  2. fix bug: No 
trailing CRLF found in HTTP header   v15 fixed:  1. play youtube link: ffmpeg 
-i $(youtube-dl -J  www.youtube.com www.youtube.com  | jq -r 
.requested_formats[0].manifes  2. code refine for timeline living stream   
Reviewed-by: Clément Bœsch u...@pkh.me   Reviewed-by: Michael 
Niedermayer mich...@niedermayer.cc   Reviewed-by: Carl Eugen Hoyos 

Re: [FFmpeg-devel] Odp: Re: [PATCH v15] avformat/dashdec: add dash demuxer base version

[samsamsam]

OK. I will. What about adding validation of format instead of adding  
something like `%0*PRId64`?   Dnia 28 sierpnia 2017 03:30 Rodger 
Combs rodger.co...@gmail.com napisał(a):  If you know of such a 
vulnerability, report it toffmpeg-secur...@ffmpeg.org . New code with known 
vulnerabilities will not be accepted.   Sent from my iPhone   On Aug 27, 2017, 
at 14:04, samsamsamsamsam...@o2.pl  wrote:  
get_repl_pattern_and_format, you should have a fixed value of something like 
`%0*PRId64`   If you afraid about safety then the only thing which 
need to be added to  get_repl_pattern_and_format is validation of format.  
Simple loop to validate format will be enough. Do you agree?    Anyway we are 
talking about safety but parser for mp4 atoms missing checking and there is 
quite easy to make segfault of the libavformat when try to prepared mp4 file.   
I understand that you want to have maximum safety with new code but I hope you 
know that ffmpeg at all is not safety.   Regards,  SSS   Dnia 27 sierpnia 2017 
16:34 Rodger Combsrodger.co...@gmail.com  napisał(a):  Youre 
still calling snprintf with a string derived from the XML, which is still not 
safe. Rather than having a format copied from the source in 
get_repl_pattern_and_format, you should have a fixed value of something like 
`%0*PRId64`, and specify an additional precision argument 
you parse from the XML yourself. I cant reiterate this enough: _never pass 
data from the XML into the format-string arg of a printf-family function_.   
Also, rather than calling snprintf() twice with an av_malloc() in between, you 
can just call av_asprintf(). Thats what it does internally anyway.   On 
Aug 27, 2017, at 09:19, Steven Liul...@chinaffmpeg.org  wrote:   
ffmpeg need a dash demuxer for demux the dash formats base on  github.com 
github.com   TODO:  1. support multi bitrate dash   v2 fixed:  1. from 
autodetect to disabled  2. from camelCase code style to ffmpeg code style  3. 
from RepType to AVMediaType  4. fix variable typo  5. change time value from 
uint32_t to uint64_t  6. removed be used once API  7. change time(NULL)`, 
except it is not 2038-safe. to av_gettime and av_timegm  8. merge complex 
free operation to free_fragment  9. use API from snprintf to av_asprintf   v3 
fixed:  1. fix typo from --enabled-xml2 to --enable-xml2   v4 fixed:  1. from 
--enable-xml2 to --enable-libxml2  2. move system includes to top  3. remove 
nouse includes  4. rename enum name  5. add a trailing comma for the last entry 
enum  6. fix comment typo  7. add const to DASHContext class front  8. check 
sscanf if return arguments and give warning message when error  9. check 
validity before free seg-url and seg  10. check if the val is null, before 
use atoll   v5 fixed:  1. fix typo from mainifest to manifest   v6 fixed:  1. 
from realloc to av_realloc  2. from free to av_free   v7 fixed:  1. remove the 
-lxml2 from configure when require_pkg_config   v8 fixed:  1. fix replace 
filename template by av_asprintf secure problem   v9 modified:  1. make 
manifest parser clearly   v10 fixed:  1. fix function API name code style  2. 
remove redundant strreplace call  3. remove redundant memory operation and 
check return value from get_content_url()  4. add space between ) and {  5. 
remove no need to log the value for print   v11 fixed:  1. from atoll to 
strtoll   v12 fixed:  1. remove strreplace and instead by av_strreplace   v13 
fixed:  1. fix bug: cannot play:  dash.edgesuite.net dash.edgesuite.net   v14 
fixed:  1. fix bug: TLS connection was non-properly terminated  2. fix bug: No 
trailing CRLF found in HTTP header   v15 fixed:  1. play youtube link: ffmpeg 
-i $(youtube-dl -J  www.youtube.com www.youtube.com  | jq -r 
.requested_formats[0].manifes  2. code refine for timeline living stream   
Reviewed-by: Clément Bœschu...@pkh.me   Reviewed-by: Michael 
Niedermayermich...@niedermayer.cc   Reviewed-by: Carl Eugen Hoyos 
   ceho...@ag.or.at   Reviewed-by: Rodger Combs
rodger.co...@gmail.com   Reviewed-by: Moritz Barsnick
barsn...@gmx.net   Reviewed-by: Nicolas Georgegeo...@nsup.org   
Reviewed-by: Ricardo Constantinowiia...@gmail.com   Reviewed-by: 
wm4nfx...@googlemail.com   Tested-by: Andy Furniss
adf.li...@gmail.com   Reported-by: Andy Furnissadf.li...@gmail.com 
  Signed-off-by: Steven Liul...@chinaffmpeg.org   
Signed-off-by: samsamsamsamsam...@o2.pl   ---  configure    
    4 +  libavformat/Makefile |    1 +  libavformat/allformats.c |    2 
+-  libavformat/dashdec.c    | 1981 ++  4 files 
changed, 1987 insertions(+), 1 deletion(-)  create mode 100644 
libavformat/dashdec.c   diff --git a/configure b/configure  index 
05f6dcc99a..7a7d61fa13 100755  --- a/configure  +++ b/configure  @@ -272,6 
+272,7 @@ External library support:   --enable-libxcb-shape    enable X11 
grabbing shape rendering [autodetect]   --enable-libxvid enable Xvid 
encoding via 

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/25/2017 05:35 PM, wm4 wrote:

+static inline int v4l2_h264_profile_from_ff(int p)
+{
+switch(p) {
+case FF_PROFILE_H264_CONSTRAINED_BASELINE:
+return MPEG_VIDEO(H264_PROFILE_CONSTRAINED_BASELINE);
+case FF_PROFILE_H264_HIGH_444_PREDICTIVE:
+return MPEG_VIDEO(H264_PROFILE_HIGH_444_PREDICTIVE);
+case FF_PROFILE_H264_HIGH_422_INTRA:
+return MPEG_VIDEO(H264_PROFILE_HIGH_422_INTRA);
+case FF_PROFILE_H264_HIGH_444_INTRA:
+return MPEG_VIDEO(H264_PROFILE_HIGH_444_INTRA);
+case FF_PROFILE_H264_HIGH_10_INTRA:
+return MPEG_VIDEO(H264_PROFILE_HIGH_10_INTRA);
+case FF_PROFILE_H264_HIGH_422:
+return MPEG_VIDEO(H264_PROFILE_HIGH_422);
+case FF_PROFILE_H264_BASELINE:
+return MPEG_VIDEO(H264_PROFILE_BASELINE);
+case FF_PROFILE_H264_EXTENDED:
+return MPEG_VIDEO(H264_PROFILE_EXTENDED);
+case FF_PROFILE_H264_HIGH_10:
+return MPEG_VIDEO(H264_PROFILE_HIGH_10);
+case FF_PROFILE_H264_MAIN:
+return MPEG_VIDEO(H264_PROFILE_MAIN);
+case FF_PROFILE_H264_HIGH:
+return MPEG_VIDEO(H264_PROFILE_HIGH);
+}
+
+return -1;
+}
+
+static inline int v4l2_mpeg4_profile_from_ff(int p)
+{
+switch(p) {
+case FF_PROFILE_MPEG4_ADVANCED_CODING:
+return MPEG_VIDEO(MPEG4_PROFILE_ADVANCED_CODING_EFFICIENCY);
+case FF_PROFILE_MPEG4_ADVANCED_SIMPLE:
+return MPEG_VIDEO(MPEG4_PROFILE_ADVANCED_SIMPLE);
+case FF_PROFILE_MPEG4_SIMPLE_SCALABLE:
+
+return MPEG_VIDEO(MPEG4_PROFILE_SIMPLE_SCALABLE);
+case FF_PROFILE_MPEG4_SIMPLE:
+return MPEG_VIDEO(MPEG4_PROFILE_SIMPLE);
+case FF_PROFILE_MPEG4_CORE:
+return MPEG_VIDEO(MPEG4_PROFILE_CORE);
+}
+
+return -1;
+}

Would a table be better maybe?



ok, switch replace with tables.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/dv : read dv audio as BE

[Carl Eugen Hoyos]

2017-08-28 18:42 GMT+02:00 Carl Eugen Hoyos :
> 2017-08-28 18:22 GMT+02:00 Александр Слободенюк
> :
>> Fixing the FIXME issue, where BE audio inside the dv codec reads as LE
>> after swapping it's bytes. It's was not very clear, because if we read
>> it on BE machine we'll swap it twice.
>
>> -static int dv_extract_audio(const uint8_t *frame, uint8_t **ppcm,
>> +static int dv_extract_audio(const uint8_t *frame, uint16_t **ppcm,
>
> Is this change necessary?

It is necessary, the cast should be unnecessary though.

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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/25/2017 05:35 PM, wm4 wrote:

+
+#define SET_V4L2_EXT_CTRL(TYPE, ID, VALUE, NAME)\
+{   \
+struct v4l2_ext_control ctrl = { 0 };   \
+struct v4l2_ext_controls ctrls = { 0 }; \
+ctrls.ctrl_class = V4L2_CTRL_CLASS_MPEG;\
+ctrls.controls =  \
+ctrl.TYPE = VALUE ; \
+ctrl.id = ID ;  \
+ctrls.count = 1;\
+\
+if ((ret = ioctl(s->fd, VIDIOC_S_EXT_CTRLS, )) < 0)   \
+av_log(avctx, AV_LOG_WARNING, "Failed to set " NAME "%s\n", STR(ID));  
\
+}
+
+#define SET_V4L2_TIME_PER_FRAME(NUM, DEN)   \
+{   \
+struct v4l2_streamparm parm = { 0 };\
+parm.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;  \
+parm.parm.output.timeperframe.numerator = NUM;  \
+parm.parm.output.timeperframe.denominator = DEN;\
+\
+if ((ret = ioctl(s->fd, VIDIOC_S_PARM, )) < 0) \
+av_log(avctx, AV_LOG_WARNING, "Failed to set  timeperframe");  \
+}

I think those should be functions. ctrl has only 3 fields, so it's ok
to have the caller set it up. (If you use C99 struct literals it won't
be more code than before, maybe.)



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

Re: [FFmpeg-devel] [PATCH] libavformat/dv : read dv audio as BE

[Carl Eugen Hoyos]

2017-08-28 18:22 GMT+02:00 Александр Слободенюк
:
> Fixing the FIXME issue, where BE audio inside the dv codec reads as LE
> after swapping it's bytes. It's was not very clear, because if we read
> it on BE machine we'll swap it twice.

> -static int dv_extract_audio(const uint8_t *frame, uint8_t **ppcm,
> +static int dv_extract_audio(const uint8_t *frame, uint16_t **ppcm,

Is this change necessary?
If not (I believe so) remove it, it makes the patch smaller.

> -c->ast[i]->codecpar->codec_id   = AV_CODEC_ID_PCM_S16LE;
> +c->ast[i]->codecpar->codec_id   = AV_CODEC_ID_PCM_S16BE;

This needs a micro version bump.

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

[FFmpeg-devel] [PATCH] libavformat/dv : read dv audio as BE

[Александр Слободенюк]

Fixing the FIXME issue, where BE audio inside the dv codec reads as LE
after swapping it's bytes. It's was not very clear, because if we read
it on BE machine we'll swap it twice.

0001-libavformat-dv-read-dv-audio-as-BE.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] fate/cineform : add test for yuv 10b

[Martin Vignali]

2017-03-26 1:17 GMT+01:00 Michael Niedermayer :

> On Sat, Mar 25, 2017 at 02:04:03PM +0100, Martin Vignali wrote:
> > Hello,
> >
> > In attach patch to add fate test for cineform decoder
> >
> > Sample can be found here :
> > https://we.tl/y06cKrKh3a
> >
> > there is two sample in the download link
> > The test is about : cineform_yuv10b_hd.mov
>
> uploaded
>
>
> Ping for the patch

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

Re: [FFmpeg-devel] fate/pixlet : add test for rgb

[Martin Vignali]

2017-04-03 2:21 GMT+02:00 Michael Niedermayer :

> On Sun, Apr 02, 2017 at 11:29:38PM +0200, Martin Vignali wrote:
> > Hello,
> >
> > In attach patch to add a fate test for pixlet decoder
> >
> > Sample can be found here :
> > https://we.tl/HYuFmmmfIe
>
> file uploaded
>

Ping for the patch

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

Re: [FFmpeg-devel] FFmpeg 3.4

[James Almer]

On 8/28/2017 6:46 AM, wm4 wrote:
> On Sat, 26 Aug 2017 11:28:29 +0200
> Michael Niedermayer  wrote:
> 
>> Hi all
>>
>> Its a while since FFmpeg 3.3, so its time again to make a new release
>>
>> I intend to make 3.4 in the next weeks
>> Name suggestions needed like always
>>
> 
> At least the new channel mapping API from Libav should be part of this
> release. It deprecates some API, and not having it in the release would
> make the deprecation period longer and more painful.

Deprecation period lasts ~2 years after the introducing commit hits git
master, regardless of how many releases are made before or after.
And we tend to make a release every three to five months, so it's not an
issue like in libav where they make one release per year or so and a
deprecated API making it in means extending its life for at least that
much time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/gdv: Improve palette saturation

[Carl Eugen Hoyos]

2017-08-27 9:03 GMT+02:00 Paul B Mahol :
> On 8/26/17, Carl Eugen Hoyos  wrote:

>> Attached patch slightly improves the saturation of the
>> gdv palette.
>>
>> Please comment, Carl Eugen
>
> Does this match how it is displayed by original game?

The original game was written for a graphic adapter that
supports 6bit palette. FFmpeg only supports 8bit palette,
the patch makes the colour white (and all saturated colours)
as similar to the intended output as possible and does not
change black (and other colours with little intensity).

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

[FFmpeg-devel] [PATCH] avfilter: add despill filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  35 +
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_despill.c | 183 +++
 4 files changed, 220 insertions(+)
 create mode 100644 libavfilter/vf_despill.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 779fd53..1d8b46d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6780,6 +6780,41 @@ FFmpeg was configured with @code{--enable-opencl}. 
Default value is 0.
 
 @end table
 
+@section despill
+
+Remove unwanted contamination of foreground colors, caused by reflected color 
of
+greenscreen or bluescreen.
+
+This filter accepts the following options:
+
+@table @option
+@item type
+Set what type of despill to use.
+
+@item mix
+Set how spillmap will be generated.
+
+@item expand
+Set how much to get rid of still remaining spill.
+
+@item red
+Controls ammount of red in spill area.
+
+@item green
+Controls ammount of green in spill area.
+Should be -1 for greenscreen.
+
+@item blue
+Controls ammount of blue in spill area.
+Should be -1 for bluescreen.
+
+@item brightness
+Controls brightness of spill area, preserving colors.
+
+@item alpha
+Modify alpha from generated spillmap.
+@end table
+
 @section detelecine
 
 Apply an exact inverse of the telecine operation. It requires a predefined
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 1d92dc1..23d20cc 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -166,6 +166,7 @@ OBJS-$(CONFIG_DEINTERLACE_VAAPI_FILTER)  += 
vf_deinterlace_vaapi.o
 OBJS-$(CONFIG_DEJUDDER_FILTER)   += vf_dejudder.o
 OBJS-$(CONFIG_DELOGO_FILTER) += vf_delogo.o
 OBJS-$(CONFIG_DESHAKE_FILTER)+= vf_deshake.o
+OBJS-$(CONFIG_DESPILL_FILTER)+= vf_despill.o
 OBJS-$(CONFIG_DETELECINE_FILTER) += vf_detelecine.o
 OBJS-$(CONFIG_DILATION_FILTER)   += vf_neighbor.o
 OBJS-$(CONFIG_DISPLACE_FILTER)   += vf_displace.o framesync2.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 8b9b9a4..9a2cfea 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -178,6 +178,7 @@ static void register_all(void)
 REGISTER_FILTER(DEJUDDER,   dejudder,   vf);
 REGISTER_FILTER(DELOGO, delogo, vf);
 REGISTER_FILTER(DESHAKE,deshake,vf);
+REGISTER_FILTER(DESPILL,despill,vf);
 REGISTER_FILTER(DETELECINE, detelecine, vf);
 REGISTER_FILTER(DILATION,   dilation,   vf);
 REGISTER_FILTER(DISPLACE,   displace,   vf);
diff --git a/libavfilter/vf_despill.c b/libavfilter/vf_despill.c
new file mode 100644
index 000..eff9877
--- /dev/null
+++ b/libavfilter/vf_despill.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * 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 "libavutil/opt.h"
+#include "libavutil/imgutils.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct DespillContext {
+const AVClass *class;
+
+int co[4]; /* color offsets rgba */
+
+int alpha;
+int type;
+float spillmix;
+float spillexpand;
+float redscale;
+float greenscale;
+float bluescale;
+float brightness;
+} DespillContext;
+
+static int do_despill_slice(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs)
+{
+DespillContext *s = ctx->priv;
+AVFrame *frame = arg;
+const int ro = s->co[0], go = s->co[1], bo = s->co[2], ao = s->co[3];
+const int slice_start = (frame->height * jobnr) / nb_jobs;
+const int slice_end = (frame->height * (jobnr + 1)) / nb_jobs;
+const float brightness = s->brightness;
+const float redscale = s->redscale;
+const float greenscale = s->greenscale;
+const float bluescale = s->bluescale;
+const float spillmix = s->spillmix;
+const float factor = (1.f - spillmix) * (1.f - s->spillexpand);
+float red, green, blue;
+int x, y;
+
+for (y = slice_start; y < slice_end; y++) {
+uint8_t *dst = frame->data[0] + y * frame->linesize[0];
+
+for (x = 0; x < frame->width; x++) {
+float 

Re: [FFmpeg-devel] [V5 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to dynamic alloc.

[Mark Thompson]

On 24/08/17 02:13, Jun Zhao wrote:
> V5: - In h265_vaapi encoder, when setting slice number > max slice number
>   supported by driver, report error and return. Same as h264_vaapi.
> - Clean the logic when setting first_slice_segment_in_pic_flags  
> V4: - Change the array malloc function.
> - Clean the pointless condition check when free the memory.
> 
> V3: - Making pic->slices be VAAPIEncodeSlice* instead of
> VAAPIEncodeSlice**. - Fix resource (vaBuffer) lead when realloc
> pic->param_buffers fail. - Adjust max_slices location in
> VAAPIEncodeContext. - Re-work distributing the macro-blocks for
> multi-slices function. V2: - Change the slice/parameter buffers to
> dynamic alloc and split the mutil-slice support for AVC/HEVC.
> 
> 
> From a1078385915d53ec94559ed897eb253e537d1f65 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Mon, 31 Jul 2017 22:46:23 -0400
> Subject: [V5 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to
>  dynamic alloc.
> 
> Change the slice/parameter buffers to be allocated dynamically.
> 
> Signed-off-by: Wang, Yi A 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/vaapi_encode.c | 44 
>  libavcodec/vaapi_encode.h |  6 ++
>  2 files changed, 34 insertions(+), 16 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 22114bedbe..f49e0e3b91 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -36,13 +36,18 @@ static int vaapi_encode_make_packed_header(AVCodecContext 
> *avctx,
>  VAAPIEncodeContext *ctx = avctx->priv_data;
>  VAStatus vas;
>  VABufferID param_buffer, data_buffer;
> +VABufferID *tmp;
>  VAEncPackedHeaderParameterBuffer params = {
>  .type = type,
>  .bit_length = bit_len,
>  .has_emulation_bytes = 1,
>  };
>  
> -av_assert0(pic->nb_param_buffers + 2 <= MAX_PARAM_BUFFERS);
> +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp), 
> pic->nb_param_buffers + 2);
> +if (!tmp) {
> +return AVERROR(ENOMEM);
> +}
> +pic->param_buffers = tmp;
>  
>  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
>   VAEncPackedHeaderParameterBufferType,
> @@ -77,9 +82,14 @@ static int vaapi_encode_make_param_buffer(AVCodecContext 
> *avctx,
>  {
>  VAAPIEncodeContext *ctx = avctx->priv_data;
>  VAStatus vas;
> +VABufferID *tmp;
>  VABufferID buffer;
>  
> -av_assert0(pic->nb_param_buffers + 1 <= MAX_PARAM_BUFFERS);
> +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp), 
> pic->nb_param_buffers + 1);
> +if (!tmp) {
> +return AVERROR(ENOMEM);
> +}
> +pic->param_buffers = tmp;
>  
>  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
>   type, len, 1, data, );
> @@ -313,15 +323,14 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>  }
>  }
>  
> -av_assert0(pic->nb_slices <= MAX_PICTURE_SLICES);
> +pic->slices = av_mallocz_array(pic->nb_slices, sizeof(*pic->slices));
> +if (!pic->slices) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
>  for (i = 0; i < pic->nb_slices; i++) {
> -slice = av_mallocz(sizeof(*slice));
> -if (!slice) {
> -err = AVERROR(ENOMEM);
> -goto fail;
> -}
> +slice = >slices[i];
>  slice->index = i;
> -pic->slices[i] = slice;
>  
>  if (ctx->codec->slice_params_size > 0) {
>  slice->codec_slice_params = 
> av_mallocz(ctx->codec->slice_params_size);
> @@ -425,8 +434,16 @@ fail_with_picture:
>  fail:
>  for(i = 0; i < pic->nb_param_buffers; i++)
>  vaDestroyBuffer(ctx->hwctx->display, pic->param_buffers[i]);
> +for (i = 0; i < pic->nb_slices; i++) {
> +if (pic->slices) {
> +av_freep(>slices[i].priv_data);
> +av_freep(>slices[i].codec_slice_params);
> +}
> +}
>  fail_at_end:
>  av_freep(>codec_picture_params);
> +av_freep(>param_buffers);
> +av_freep(>slices);
>  av_frame_free(>recon_image);
>  av_buffer_unref(>output_buffer_ref);
>  pic->output_buffer = VA_INVALID_ID;
> @@ -535,15 +552,18 @@ static int vaapi_encode_free(AVCodecContext *avctx,
>  vaapi_encode_discard(avctx, pic);
>  
>  for (i = 0; i < pic->nb_slices; i++) {
> -av_freep(>slices[i]->priv_data);
> -av_freep(>slices[i]->codec_slice_params);
> -av_freep(>slices[i]);
> +if (pic->slices) {
> +av_freep(>slices[i].priv_data);
> +av_freep(>slices[i].codec_slice_params);
> +}
>  }
>  av_freep(>codec_picture_params);
>  
>  av_frame_free(>input_image);
>  av_frame_free(>recon_image);
>  
> +av_freep(>param_buffers);
> +av_freep(>slices);
>  // Output buffer should already be destroyed.
>  

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: Enable VBR mode

[Mark Thompson]

On 25/08/17 08:56, Jun Zhao wrote:
> From 483204cf7c25077d556c86b9e70f591fc2c0d4a3 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Fri, 25 Aug 2017 03:50:37 -0400
> Subject: [PATCH] lavc/vaapi_encode_h265: Enable VBR mode
> 
> Follow vaapi_h264 style, enable the VBR mode.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/vaapi_encode_h265.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index cf6b9388d1..971458db87 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -1185,13 +1185,15 @@ static av_cold int 
> vaapi_encode_h265_configure(AVCodecContext *avctx)
> "%d / %d / %d for IDR- / P- / B-frames.\n",
> priv->fixed_qp_idr, priv->fixed_qp_p, priv->fixed_qp_b);
>  
> -} else if (ctx->va_rc_mode == VA_RC_CBR) {
> +} else if (ctx->va_rc_mode == VA_RC_CBR ||
> +   ctx->va_rc_mode == VA_RC_VBR) {
>  // These still need to be  set for pic_init_qp/slice_qp_delta.
>  priv->fixed_qp_idr = 30;
>  priv->fixed_qp_p   = 30;
>  priv->fixed_qp_b   = 30;
>  
> -av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %"PRId64" 
> bps.\n",
> +av_log(avctx, AV_LOG_DEBUG, "Using %s-bitrate = %"PRId64" bps.\n",
> +   ctx->va_rc_mode == VA_RC_CBR ? "constant" : "variable",
> avctx->bit_rate);
>  
>  } else {
> @@ -1251,9 +1253,12 @@ static av_cold int 
> vaapi_encode_h265_init(AVCodecContext *avctx)
>  }
>  ctx->va_entrypoint = VAEntrypointEncSlice;
>  
> -if (avctx->bit_rate > 0)
> -ctx->va_rc_mode = VA_RC_CBR;
> -else
> +if (avctx->bit_rate > 0) {
> +if (avctx->rc_max_rate == avctx->bit_rate)
> +ctx->va_rc_mode = VA_RC_CBR;
> +else
> +ctx->va_rc_mode = VA_RC_VBR;
> +} else
>  ctx->va_rc_mode = VA_RC_CQP;
>  
>  ctx->va_packed_headers =
> -- 
> 2.11.0
> 

Applied.

Thanks!

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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/28/2017 12:47 PM, wm4 wrote:

I guess that instead of polling for the AVBufferRef to be unreferenced,
I can associate a sync (ie a sempahore) to each buffer, take it on
release and post the semaphore on the AVBufferRefs being unreferenced.
that is actually pretty clean in terms of cpu usage.

That would just freeze an API user calling avcodec_close(), when it
keeps around decoded AVFrames for later use.


yes I understand, but it does avoid using the CPU to poll for the buffer 
release (an incremental improvement)


but yes I think that the message is that even though this proposal might 
suffice for simple video players (my tests) is not good enough for other 
users requiring the decoded frame for post processing.


is this a blocker to upstream or could I continue working with it 
flagging the encoder/decoder as EXPERIMENTAL? the current situation at 
least keeps video players happy.



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

[FFmpeg-devel] [PATCH] avformat/utils: refine av_get_frame_filename2 function

[Steven Liu]

support parse the l for the %lld or %ld

Signed-off-by: Steven Liu 
---
 libavformat/utils.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 23865c88c4..c76a6cc5f8 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4570,6 +4570,7 @@ int av_get_frame_filename2(char *buf, int buf_size, const 
char *path, int number
 if (c == '\0')
 break;
 if (c == '%') {
+ignoredl:
 do {
 nd = 0;
 while (av_isdigit(*p))
@@ -4593,6 +4594,9 @@ int av_get_frame_filename2(char *buf, int buf_size, const 
char *path, int number
 memcpy(q, buf1, len);
 q += len;
 break;
+case 'l':
+goto ignoredl;
+
 default:
 goto fail;
 }
-- 
2.11.0 (Apple Git-81)



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

Re: [FFmpeg-devel] [PATCH v15] avformat/dashdec: add dash demuxer base version

[wm4]

On Sun, 27 Aug 2017 22:19:31 +0800
Steven Liu  wrote:

> ffmpeg need a dash demuxer for demux the dash formats base on
> https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch
> 
> TODO:
> 1. support multi bitrate dash
> 
> v2 fixed:
> 1. from autodetect to disabled
> 2. from camelCase code style to ffmpeg code style
> 3. from RepType to AVMediaType
> 4. fix variable typo
> 5. change time value from uint32_t to uint64_t
> 6. removed be used once API
> 7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and 
> av_timegm
> 8. merge complex free operation to free_fragment
> 9. use API from snprintf to av_asprintf
> 
> v3 fixed:
> 1. fix typo from --enabled-xml2 to --enable-xml2
> 
> v4 fixed:
> 1. from --enable-xml2 to --enable-libxml2
> 2. move system includes to top
> 3. remove nouse includes
> 4. rename enum name
> 5. add a trailing comma for the last entry enum
> 6. fix comment typo
> 7. add const to DASHContext class front
> 8. check sscanf if return arguments and give warning message when error
> 9. check validity before free seg->url and seg
> 10. check if the val is null, before use atoll
> 
> v5 fixed:
> 1. fix typo from mainifest to manifest
> 
> v6 fixed:
> 1. from realloc to av_realloc
> 2. from free to av_free
> 
> v7 fixed:
> 1. remove the -lxml2 from configure when require_pkg_config
> 
> v8 fixed:
> 1. fix replace filename template by av_asprintf secure problem
> 
> v9 modified:
> 1. make manifest parser clearly
> 
> v10 fixed:
> 1. fix function API name code style
> 2. remove redundant strreplace call
> 3. remove redundant memory operation and check return value from 
> get_content_url()
> 4. add space between ) and {
> 5. remove no need to log the value for print
> 
> v11 fixed:
> 1. from atoll to strtoll
> 
> v12 fixed:
> 1. remove strreplace and instead by av_strreplace
> 
> v13 fixed:
> 1. fix bug: cannot play:
> http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd
> 
> v14 fixed:
> 1. fix bug: TLS connection was non-properly terminated
> 2. fix bug: No trailing CRLF found in HTTP header
> 
> v15 fixed:
> 1. play youtube link: ffmpeg -i $(youtube-dl -J 
> "https://www.youtube.com/watch?v=XmL19DOP_Ls; | jq -r 
> ".requested_formats[0].manifest_url")
> 2. code refine for timeline living stream
> 
> Reviewed-by: Clément Bœsch 
> Reviewed-by: Michael Niedermayer 
> Reviewed-by: Carl Eugen Hoyos 
> Reviewed-by: Rodger Combs 
> Reviewed-by: Moritz Barsnick 
> Reviewed-by: Nicolas George 
> Reviewed-by: Ricardo Constantino 
> Reviewed-by: wm4 
> Tested-by: Andy Furniss 
> Reported-by: Andy Furniss 
> Signed-off-by: Steven Liu 
> Signed-off-by: samsamsam 

I only have some superficial comments, since I don't think I have a
full overview over the DASH protocol and this code to tell whether the
more intricate details are handled correctly. As such it's not a full
review.

But I'd like to object to the code duplication. Also, stuffing this
into a single source file isn't ideal.

Also, I don't remember having given a full review on this before.

> ---
>  configure|4 +
>  libavformat/Makefile |1 +
>  libavformat/allformats.c |2 +-
>  libavformat/dashdec.c| 1981 
> ++
>  4 files changed, 1987 insertions(+), 1 deletion(-)
>  create mode 100644 libavformat/dashdec.c
> 
> diff --git a/configure b/configure
> index 05f6dcc99a..7a7d61fa13 100755
> --- a/configure
> +++ b/configure
> @@ -272,6 +272,7 @@ External library support:
>--enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
>--enable-libxvid enable Xvid encoding via xvidcore,
> native MPEG-4/Xvid encoder exists [no]
> +  --enable-libxml2 enable XML parsing using the C library libxml2 
> [no]
>--enable-libzimg enable z.lib, needed for zscale filter [no]
>--enable-libzmq  enable message passing via libzmq [no]
>--enable-libzvbi enable teletext support via libzvbi [no]
> @@ -1576,6 +1577,7 @@ EXTERNAL_LIBRARY_LIST="
>  libvpx
>  libwavpack
>  libwebp
> +libxml2
>  libzimg
>  libzmq
>  libzvbi
> @@ -2937,6 +2939,7 @@ avi_muxer_select="riffenc"
>  caf_demuxer_select="iso_media riffdec"
>  caf_muxer_select="iso_media"
>  dash_muxer_select="mp4_muxer"
> +dash_demuxer_deps="libxml2"
>  dirac_demuxer_select="dirac_parser"
>  dts_demuxer_select="dca_parser"
>  dtshd_demuxer_select="dca_parser"
> @@ -5996,6 +5999,7 @@ enabled openssl   && { use_pkg_config openssl 
> openssl/ssl.h OPENSSL_init
> check_lib openssl openssl/ssl.h 
> SSL_library_init -lssl -lcrypto -lws2_32 

Re: [FFmpeg-devel] [PATCH 0/2] Tile threading support for vp9

[gh0st]

Fixed in PATCHv3

On Mon, Aug 28, 2017 at 7:40 AM, Michael Niedermayer  wrote:

> On Mon, Aug 28, 2017 at 02:22:15AM +0700, Ilia Valiakhmetov wrote:
> > These patches introduce tile threading support for vp9.
> >
> > Tile threading is ~45% faster at 2 threads vs 1.
> > Frame threading is ~55% faster at 2 threads vs 1.
> > ffvp9 tile threading is ~25% faster than libvpx-vp9 at 2 threads
> >
> > execute3() function is similar to execute2(), execept it has
> > a extra argument - main function for avpriv_slicethread_create(), it is
> used for the loopfilter.
> >
> > Ilia Valiakhmetov (2):
> >   avcodec: add execute3() api to utilize the main function of
> > avpriv_slicethread_create().
> >   avcodec/vp9: Add tile threading support
>
> this seems to break build with mips-linux-gnu-gcc-4.4 and
> --disable-pthreads
>
> In file included from src/libavcodec/vp9data.h:28,
>  from src/libavcodec/vp9.c:33:
> src/libavcodec/vp9dec.h:218: error: redefinition of typedef ‘VP9TileData’
> src/libavcodec/vp9dec.h:89: note: previous declaration of ‘VP9TileData’
> was here
> src/libavcodec/vp9.c: In function ‘vp9_free_entries’:
> src/libavcodec/vp9.c:115: error: implicit declaration of function
> ‘pthread_mutex_destroy’
> src/libavcodec/vp9.c:116: error: implicit declaration of function
> ‘pthread_cond_destroy’
> src/libavcodec/vp9.c: In function ‘vp9_alloc_entries’:
> src/libavcodec/vp9.c:138: error: implicit declaration of function
> ‘pthread_mutex_init’
> src/libavcodec/vp9.c:139: error: implicit declaration of function
> ‘pthread_cond_init’
> src/libavcodec/vp9.c: In function ‘vp9_report_tile_progress’:
> src/libavcodec/vp9.c:146: error: implicit declaration of function
> ‘pthread_cond_signal’
> src/libavcodec/vp9.c: In function ‘vp9_await_tile_progress’:
> src/libavcodec/vp9.c:153: error: implicit declaration of function
> ‘pthread_mutex_lock’
> src/libavcodec/vp9.c:155: error: implicit declaration of function
> ‘pthread_cond_wait’
> src/libavcodec/vp9.c:156: error: implicit declaration of function
> ‘pthread_mutex_unlock’
> src/libavcodec/vp9.c: In function ‘vp9_decode_frame’:
> src/libavcodec/vp9.c:1424: warning: ‘pkt_pts’ is deprecated (declared at
> src/libavutil/frame.h:302)
> make: *** [libavcodec/vp9.o] Error 1
> make: *** Waiting for unfinished jobs
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who would give up essential Liberty, to purchase a little
> temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
>
> ___
> 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 02/18] h264: Add stream constraint values to the common header

[Mark Thompson]

On 21/08/17 18:04, Michael Niedermayer wrote:
> On Mon, Aug 21, 2017 at 11:56:11AM +0100, Mark Thompson wrote:
>> On 21/08/17 02:09, Michael Niedermayer wrote:
>>> On Sun, Aug 20, 2017 at 11:41:30PM +0100, Mark Thompson wrote:
 With comments describing the derivation of each value.

 (cherry picked from commit aaf441465080b9bc57f5ca8dea656f9b2c5dc821)
 ---
  libavcodec/h264.h | 45 +
  1 file changed, 45 insertions(+)

 diff --git a/libavcodec/h264.h b/libavcodec/h264.h
 index 86df5eb9b3..650580bf3a 100644
 --- a/libavcodec/h264.h
 +++ b/libavcodec/h264.h
 @@ -44,4 +44,49 @@ enum {
  H264_NAL_AUXILIARY_SLICE = 19,
  };
  
 +
 +enum {
>>>
>>> why is this a enum ?
>>
>> I believe that compile-time symbolic constants are preferable to 
>> preprocessor string replacement.
> 
> I dont mind, but there are many more #defines in the codebase for
> which this argument should apply too.

I agree!  It is nontrivial work with minor gain to change them when they 
already exist, though.

 +// 7.4.2.1.1: seq_parameter_set_id is in [0, 31].
 +H264_MAX_SPS_COUNT = 32,
>>>
>>> Could be doxygen comment compatible
>>
>> Would that have any value?  The comments are explaining the derivation for 
>> verification purposes rather than anything to do with the actual use.
> 
> It would put the value into the doxygen on the webpage. Would make
> the comment easy machine associatable to the constant.
> 
> Not sure thats enough "value", I just noticed that you seem to have
> quite exhaustivly documented these constants, it appeared odd that
> if you go to the troubble to do that that they arent doxygen parsable.
> 
> 
>>
 +// A.3: in table A-1 the highest level allows a MaxFS of 139264.
 +H264_MAX_MB_PIC_SIZE = 139264,
 +// A.3.1, A.3.2: PicWidthInMbs and PicHeightInMbs are constrained
 +// to be not greater than sqrt(MaxFS * 8).  Hence height/width are
 +// bounded above by sqrt(139264 * 8) = 1055.5 macroblocks.
 +H264_MAX_MB_WIDTH= 1055,
 +H264_MAX_MB_HEIGHT   = 1055,
 +H264_MAX_WIDTH   = H264_MAX_MB_WIDTH  * 16,
 +H264_MAX_HEIGHT  = H264_MAX_MB_HEIGHT * 16,
>>>
>>> There should be no problem with files outside these limits. They would
>>> be valid H.264 files, just not within the level and profile constraints
>>> of the currently defined profiles and levels.
>>> or do i miss something ?
>> Currently these values are used for some fixed-size tables in cbs (e.g. 
>> H264_MAX_MB_PIC_SIZE is needed for slice_group_id[]).  More generally, I 
>> don't want to consider files which don't conform to some level limits - once 
>> you allow MaxDPBFrames to exceed 16 the world is a terrible place.
>>
> 
>> (I am not intending to add this constraint to the existing decoder.)
> 
> but some of the newly added code uses the resolution limits IIRC.
> 
> We never previosuly limited resolution based on profile/level.
> Can you summarize what features would be restricted to 1055 MBs
> resolution ?

All bitstream filters based on the cbs infrastructure, and also anything else 
using it (VAAPI encode, but that will have hardware restrictions which are 
smaller anyway).

They will also be restricted by the other level limits in this file - 
max_num_ref_frames at 16 (also enforced by the decoder) and 
num_slice_groups_minus1 at 7 (nonzero values not supported by the decoder at 
all).

The intent of cbs here is very much to be able to fully parse all standard 
streams, and to immediately reject anything nonstandard.  If we want some sort 
of nonstandard support later then it could be added separately, suitably gated 
by options, but I don't want to do that now.

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

Re: [FFmpeg-devel] FFmpeg 3.4

[Paul B Mahol]

On 8/28/17, wm4  wrote:
> On Sat, 26 Aug 2017 11:28:29 +0200
> Michael Niedermayer  wrote:
>
>> Hi all
>>
>> Its a while since FFmpeg 3.3, so its time again to make a new release
>>
>> I intend to make 3.4 in the next weeks
>> Name suggestions needed like always
>>
>
> At least the new channel mapping API from Libav should be part of this
> release. It deprecates some API, and not having it in the release would
> make the deprecation period longer and more painful.

IIRC it is still not in Libav.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 13/18] lavc: Add mpeg2_metadata bitstream filter

[Mark Thompson]

On 21/08/17 19:21, Michael Niedermayer wrote:
> On Sun, Aug 20, 2017 at 11:41:41PM +0100, Mark Thompson wrote:
>> (cherry picked from commit b78c30d7ec26af67c00ce2002709a189f6a87a7e)
>> ---
>>  configure   |   1 +
>>  doc/bitstream_filters.texi  |  36 
>>  libavcodec/Makefile |   1 +
>>  libavcodec/bitstream_filters.c  |   1 +
>>  libavcodec/mpeg2_metadata_bsf.c | 360 
>> 
>>  5 files changed, 399 insertions(+)
>>  create mode 100644 libavcodec/mpeg2_metadata_bsf.c
>>
>> diff --git a/configure b/configure
>> index 7641bd98d4..1e99038dca 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2836,6 +2836,7 @@ h264_metadata_bsf_select="cbs_h264"
>>  h264_redundant_pps_bsf_select="cbs_h264"
>>  hevc_metadata_bsf_select="cbs_h265"
>>  mjpeg2jpeg_bsf_select="jpegtables"
>> +mpeg2_metadata_bsf_select="cbs_mpeg2"
>>  trace_headers_bsf_select="cbs_h264 cbs_h265 cbs_mpeg2"
>>  
>>  # external libraries
>> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
>> index 71c307f2e2..8a8756bdcc 100644
>> --- a/doc/bitstream_filters.texi
>> +++ b/doc/bitstream_filters.texi
>> @@ -324,6 +324,42 @@ See also the @ref{text2movsub} filter.
>>  
>>  Decompress non-standard compressed MP3 audio headers.
>>  
>> +@section mpeg2_metadata
>> +
>> +Modify metadata embedded in an MPEG-2 stream.
>> +
>> +@table @option
>> +@item display_aspect_ratio
>> +Set the display aspect ratio in the stream.
>> +
>> +The following fixed values are supported:
>> +@table @option
>> +@item 4/3
>> +@item 16/9
>> +@item 221/100
>> +@end table
>> +Any other value will result in square pixels being signalled instead
>> +(see H.262 section 6.3.3 and table 6-3).
>> +
>> +@item frame_rate
>> +Set the frame rate in the stream.  This is constructed from a table
>> +of known values combined with a small multiplier and divisor - if
>> +the supplied value is not exactly representable, the nearest
>> +representable value will be used instead (see H.262 section 6.3.3
>> +and table 6-4).
>> +
>> +@item video_format
>> +Set the video format in the stream (see H.262 section 6.3.6 and
>> +table 6-6).
>> +
>> +@item colour_primaries
>> +@item transfer_characteristics
>> +@item matrix_coefficients
>> +Set the colour description in the stream (see H.262 section 6.3.6
>> +and tables 6-7, 6-8 and 6-9).
>> +
>> +@end table
>> +
>>  @section mpeg4_unpack_bframes
>>  
>>  Unpack DivX-style packed B-frames.
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index 72f2bb2a12..3da7b9b508 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -1002,6 +1002,7 @@ OBJS-$(CONFIG_MPEG4_UNPACK_BFRAMES_BSF)   += 
>> mpeg4_unpack_bframes_bsf.o
>>  OBJS-$(CONFIG_MOV2TEXTSUB_BSF)+= movsub_bsf.o
>>  OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF)  += mp3_header_decompress_bsf.o \
>>   mpegaudiodata.o
>> +OBJS-$(CONFIG_MPEG2_METADATA_BSF) += mpeg2_metadata_bsf.o
>>  OBJS-$(CONFIG_NOISE_BSF)  += noise_bsf.o
>>  OBJS-$(CONFIG_NULL_BSF)   += null_bsf.o
>>  OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += remove_extradata_bsf.o
>> diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
>> index 6e6b894e7f..7b0cb5032a 100644
>> --- a/libavcodec/bitstream_filters.c
>> +++ b/libavcodec/bitstream_filters.c
>> @@ -38,6 +38,7 @@ extern const AVBitStreamFilter ff_imx_dump_header_bsf;
>>  extern const AVBitStreamFilter ff_mjpeg2jpeg_bsf;
>>  extern const AVBitStreamFilter ff_mjpega_dump_header_bsf;
>>  extern const AVBitStreamFilter ff_mp3_header_decompress_bsf;
>> +extern const AVBitStreamFilter ff_mpeg2_metadata_bsf;
>>  extern const AVBitStreamFilter ff_mpeg4_unpack_bframes_bsf;
>>  extern const AVBitStreamFilter ff_mov2textsub_bsf;
>>  extern const AVBitStreamFilter ff_noise_bsf;
>> diff --git a/libavcodec/mpeg2_metadata_bsf.c 
>> b/libavcodec/mpeg2_metadata_bsf.c
>> new file mode 100644
>> index 00..b4449eac71
>> --- /dev/null
>> +++ b/libavcodec/mpeg2_metadata_bsf.c
>> @@ -0,0 +1,360 @@
>> +/*
>> + * 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 "libavutil/avstring.h"
>> +#include 

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[wm4]

On Mon, 28 Aug 2017 12:33:38 +0200
Jorge Ramirez  wrote:

> On 08/28/2017 12:04 PM, wm4 wrote:
> >> yes in response to your previous comment on the subject, I am trying to
> >> address that in v7 not releasing the context while there are buffers on
> >> the fly
> >> This is what I came up with (if you can suggest something better - ie, a
> >> way to  block until the AVBufferRefs are unref- please let me know)
> >>
> >> void avpriv_v4l2_context_release(V4L2Context* ctx)
> >> {
> >>   int i, ret;
> >>
> >>   if (!ctx->buffers)
> >>   return;
> >>
> >>   /* wait until all buffers are no longer in use */
> >>   for (i = 0; i < ctx->num_buffers; i++) {
> >>
> >>   if (ctx->buffers[i].status & (V4L2BUF_IN_DRIVER |
> >> V4L2BUF_AVAILABLE))
> >>   continue;
> >>
> >>   while (ctx->buffers[i].status & V4L2BUF_RET_USER)
> >>   usleep(100);
> >>   }
> >>
> >>   ret = ctx->ops.release_buffers(ctx);
> >>   if (ret)
> >>   av_log(ctx->log_ctx, AV_LOG_WARNING, "V4L2 failed to unmap the
> >> %s buffers\n", ctx->name);
> >>   else
> >>   av_log(ctx->log_ctx, AV_LOG_DEBUG, "%s buffers unmapped\n",
> >> ctx->name);
> >>
> >>   av_free(ctx->buffers);
> >>   ctx->buffers = NULL;
> >>   ctx->num_queued = 0;
> >> }
> >>  
> > No, this is not possible.  
> ok
> 
> >   You must make the V4L state reference
> > counted, and AVBufferRefs must implicitly reference this context.  
> that is what we tried to do: the AVBufferRefs "free" callback changes 
> the state to AVAILABLE thus implicitly referencing the context.
> maybe I am misunderstanding what you are trying to say?
> 
> >
> > AVHWFramesContext does this in a more elegant way - it's a frame pool
> > specifically made for hw decoders. I suspect the V4L code should be
> > ported to that. I hope Mark Thompson has some helpful remarks on this.  
> 
> I guess that instead of polling for the AVBufferRef to be unreferenced, 
> I can associate a sync (ie a sempahore) to each buffer, take it on 
> release and post the semaphore on the AVBufferRefs being unreferenced.
> that is actually pretty clean in terms of cpu usage.

That would just freeze an API user calling avcodec_close(), when it
keeps around decoded AVFrames for later use.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Mark Thompson]

On 25/08/17 16:35, wm4 wrote:
> That looks generally OK. Is there any chance a hwaccel approach would
> be possible instead? If I've learned anything about hardware decoding,
> then that hwaccel is vastly superior to vendor-implemented full stream
> decoders.

Unfortunately I think the whole point of the V4L2 M2M push is to define a 
common way for vendors to implement full-stream decoders in the kernel without 
it affecting userspace at all.  It's pretty much OpenMAX IL, except with all of 
the code pushed into the kernel so that users don't need to deal with extra 
userspace libraries.

So, I don't think there is any chance of it working like this at all, though 
there might be something said for parsing the headers externally to extract all 
the metadata correctly before passing it to the kernel.

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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/28/2017 12:04 PM, wm4 wrote:

yes in response to your previous comment on the subject, I am trying to
address that in v7 not releasing the context while there are buffers on
the fly
This is what I came up with (if you can suggest something better - ie, a
way to  block until the AVBufferRefs are unref- please let me know)

void avpriv_v4l2_context_release(V4L2Context* ctx)
{
  int i, ret;

  if (!ctx->buffers)
  return;

  /* wait until all buffers are no longer in use */
  for (i = 0; i < ctx->num_buffers; i++) {

  if (ctx->buffers[i].status & (V4L2BUF_IN_DRIVER |
V4L2BUF_AVAILABLE))
  continue;

  while (ctx->buffers[i].status & V4L2BUF_RET_USER)
  usleep(100);
  }

  ret = ctx->ops.release_buffers(ctx);
  if (ret)
  av_log(ctx->log_ctx, AV_LOG_WARNING, "V4L2 failed to unmap the
%s buffers\n", ctx->name);
  else
  av_log(ctx->log_ctx, AV_LOG_DEBUG, "%s buffers unmapped\n",
ctx->name);

  av_free(ctx->buffers);
  ctx->buffers = NULL;
  ctx->num_queued = 0;
}


No, this is not possible.

ok


  You must make the V4L state reference
counted, and AVBufferRefs must implicitly reference this context.
that is what we tried to do: the AVBufferRefs "free" callback changes 
the state to AVAILABLE thus implicitly referencing the context.

maybe I am misunderstanding what you are trying to say?



AVHWFramesContext does this in a more elegant way - it's a frame pool
specifically made for hw decoders. I suspect the V4L code should be
ported to that. I hope Mark Thompson has some helpful remarks on this.


I guess that instead of polling for the AVBufferRef to be unreferenced, 
I can associate a sync (ie a sempahore) to each buffer, take it on 
release and post the semaphore on the AVBufferRefs being unreferenced.

that is actually pretty clean in terms of cpu usage.




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

Re: [FFmpeg-devel] [PATCH v15] avformat/dashdec: add dash demuxer base version

[刘歧]

> 在 2017年8月28日，18:12，samsamsam  写道：
> 
> Validation will be very simple. I am talking about something like this:
> static int get_repl_pattern_and_format(const char *i_url, const char 
> *i_marker, char **o_pattern, char **o_format) 
> {
> ...
> +for(ptr=start + marker_len; ptr < (end - 1); ++ptr) {  /*there is 
> need to check this condition :P */
> +if (*ptr != '0') {
> +   // Unknown format add log here 
> +goto finish;
> +}
> +}
> format_len = end - start - marker_len - 1 + strlen(PRId64);
> *o_format = av_mallocz(format_len+1);
> strncpy(*o_format, start + marker_len, end - start - marker_len -1);
> strcat(*o_format, PRId64);
> …
> }
maybe more complex than this way, for example:
%d
%lld
%04lld
%PRId64
%PRId32
%PRId16

and think about the safety :
%02c%lld
%s%d%d%d%d

and so on,blablabla.

maybe we need to think a perfect solution.


> 
> 
> Dnia 28 sierpnia 2017 11:30 Rodger Combs  napisał(a):
> 
> I would expect parsing the number internally and using the additional arg to 
> be simpler and easier to verify than format string validation.
> 
>> On Aug 28, 2017, at 04:28, samsamsam  wrote:
>> 
>> OK. I will.
>> What about adding validation of format instead of adding "something like 
>> `"%0*"PRId64`"?
>> 
>> Dnia 28 sierpnia 2017 03:30 Rodger Combs  napisał(a):
>> 
>> If you know of such a vulnerability, report it to 
>> ffmpeg-secur...@ffmpeg.org. New code with known vulnerabilities will not be 
>> accepted.
>> 
>> Sent from my iPhone
>> 
>> On Aug 27, 2017, at 14:04, samsamsam  wrote:
>>> get_repl_pattern_and_format, you should have a fixed value of something 
>>> like `"%0*"PRId64`
>>> 
>>> If you afraid about safety then the only thing which need to be added to 
>>> get_repl_pattern_and_format is validation of format.
>>> Simple loop to validate format will be enough. Do you agree? 
>>> 
>>> Anyway we are talking about safety but parser for mp4 atoms missing 
>>> checking and there is quite easy to make segfault of the libavformat when 
>>> try to prepared mp4 file.
>>> 
>>> I understand that you want to have maximum safety with new code but I hope 
>>> you know that ffmpeg at all is not safety.
>>> 
>>> Regards,
>>> SSS
>>> 
>>> Dnia 27 sierpnia 2017 16:34 Rodger Combs  
>>> napisał(a):
>>> 
>>> You're still calling snprintf with a string derived from the XML, which is 
>>> still not safe. Rather than having a format copied from the source in 
>>> get_repl_pattern_and_format, you should have a fixed value of something 
>>> like `"%0*"PRId64`, and specify an additional "precision" argument you 
>>> parse from the XML yourself. I can't reiterate this enough: _never pass 
>>> data from the XML into the format-string arg of a printf-family function_.
>>> 
>>> Also, rather than calling snprintf() twice with an av_malloc() in between, 
>>> you can just call av_asprintf(). That's what it does internally anyway.
>>> 
>>> On Aug 27, 2017, at 09:19, Steven Liu  wrote:
>>> 
>>> ffmpeg need a dash demuxer for demux the dash formats base on
>>> https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch
>>> 
>>> TODO:
>>> 1. support multi bitrate dash
>>> 
>>> v2 fixed:
>>> 1. from autodetect to disabled
>>> 2. from camelCase code style to ffmpeg code style
>>> 3. from RepType to AVMediaType
>>> 4. fix variable typo
>>> 5. change time value from uint32_t to uint64_t
>>> 6. removed be used once API
>>> 7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and 
>>> av_timegm
>>> 8. merge complex free operation to free_fragment
>>> 9. use API from snprintf to av_asprintf
>>> 
>>> v3 fixed:
>>> 1. fix typo from --enabled-xml2 to --enable-xml2
>>> 
>>> v4 fixed:
>>> 1. from --enable-xml2 to --enable-libxml2
>>> 2. move system includes to top
>>> 3. remove nouse includes
>>> 4. rename enum name
>>> 5. add a trailing comma for the last entry enum
>>> 6. fix comment typo
>>> 7. add const to DASHContext class front
>>> 8. check sscanf if return arguments and give warning message when error
>>> 9. check validity before free seg->url and seg
>>> 10. check if the val is null, before use atoll
>>> 
>>> v5 fixed:
>>> 1. fix typo from mainifest to manifest
>>> 
>>> v6 fixed:
>>> 1. from realloc to av_realloc
>>> 2. from free to av_free
>>> 
>>> v7 fixed:
>>> 1. remove the -lxml2 from configure when require_pkg_config
>>> 
>>> v8 fixed:
>>> 1. fix replace filename template by av_asprintf secure problem
>>> 
>>> v9 modified:
>>> 1. make manifest parser clearly
>>> 
>>> v10 fixed:
>>> 1. fix function API name code style
>>> 2. remove redundant strreplace call
>>> 3. remove redundant memory operation and check return value from 
>>> get_content_url()
>>> 4. add space between ) and {
>>> 5. remove no need to log the 

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Mark Thompson]

On 27/08/17 20:41, Jorge Ramirez wrote:
> On 08/27/2017 09:09 PM, Jorge Ramirez wrote:
>> On 08/25/2017 05:35 PM, wm4 wrote:
 +static int buffer_ops_v4l2buf_to_avframe(AVFrame *frame, V4L2Buffer 
 *avbuf)
 +{
 +int i, ret;
 +
 +av_frame_unref(frame);
 +
 +/* 1. get references to the actual data */
 +for (i = 0; i < avbuf->num_planes; i++) {
 +ret = avbuf->ops.buf_to_bufref(avbuf, i, >buf[i]);
 +if (ret)
 +return ret;
 +
 +frame->linesize[i] = avbuf->bytesperline[i];
 +frame->data[i] = frame->buf[i]->data;
 +}
 +
 +/* 1.1 fixup special cases */
 +switch (avbuf->context->av_pix_fmt) {
 +case AV_PIX_FMT_NV12:
 +if (avbuf->num_planes > 1)
 +break;
 +frame->linesize[1] = avbuf->bytesperline[0];
 +frame->data[1] = frame->buf[0]->data + avbuf->bytesperline[0] * 
 avbuf->context->format.fmt.pix_mp.height;
 +break;
 +default:
 +break;
 +}
 +
 +/* 2. get frame information */
 +frame->key_frame = !!(avbuf->buf.flags & V4L2_BUF_FLAG_KEYFRAME);
 +frame->format = avbuf->context->av_pix_fmt;
 +
 +/* these values are updated also during re-init in 
 process_video_event */
 +frame->height = avbuf->context->height;
 +frame->width = avbuf->context->width;
 +frame->pts = get_pts(avbuf);
 +
 +/* 3. report errors upstream */
 +if (avbuf->buf.flags & V4L2_BUF_FLAG_ERROR) {
 +av_log(avbuf->context->log_ctx, AV_LOG_ERROR, "%s: driver decode 
 error\n", avbuf->context->name);
 +frame->decode_error_flags |= FF_DECODE_ERROR_INVALID_BITSTREAM;
 +}
 +
 +return 0;
 +}
>>> This function seems to lack setting typically required metadata like
>>> colorspace.
>>>
>>
>> ok I will retrieve the colorspace from the v4l2 format structure and set it 
>> in the frame.
> 
> um, I dont see a 1:1 mapping between the colorspaces reported from v4l2 and 
> what ffmpeg expects (I am also not a subject matter expert on this :( ).
> 
> Could I get some guidance on the translation table below please?
> btw in my simple tests - ffplay decoded vp8, vp9, mpeg4, mpeg2, h263, h264 
> and hevc I didnt need this field so I am not sure if I am getting it right.
> 
> TIA
> 
> static inline enum AVColorSpace get_colorspace(V4L2Buffer *buf)
> {
> enum v4l2_colorspace cs;
> 
> cs = V4L2_TYPE_IS_MULTIPLANAR(buf->context->type) ?
> buf->context->format.fmt.pix_mp.colorspace :
> buf->context->format.fmt.pix.colorspace;
> 
> /* */
> switch (cs) {
> case V4L2_COLORSPACE_SMPTE170M: return AVCOL_SPC_SMPTE170M;
> case V4L2_COLORSPACE_SMPTE240M: return AVCOL_SPC_SMPTE240M;
> case V4L2_COLORSPACE_470_SYSTEM_BG: return AVCOL_SPC_BT470BG;
> case V4L2_COLORSPACE_BT2020: return AVCOL_SPC_BT2020_CL;
> case V4L2_COLORSPACE_REC709: return AVCOL_SPC_BT709;
> case V4L2_COLORSPACE_ADOBERGB:
> case V4L2_COLORSPACE_SRGB:
> case V4L2_COLORSPACE_DCI_P3:
> case V4L2_COLORSPACE_JPEG:
> case V4L2_COLORSPACE_RAW:
> default:
> return AVCOL_SPC_RGB;
> }
> }

The ffmpeg enums use the same ISO 11664-1 values as H.264, H.265 and MPEG-2 do. 
 Since there must be code in your V4L2 driver to translate the V4L2 enums both 
to and from that (for encode and decode respectively), I suggest just copying 
the logic of that code to do the matching opposite direction on the ffmpeg 
side.  (Look for code reading/writing colour_primaries, 
transfer_characteristics and matrix_coefficients in the VUI section of the SPS.)

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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/28/2017 11:26 AM, Alexis Ballier wrote:

Hi,


On Sun, 27 Aug 2017 21:41:06 +0200
Jorge Ramirez  wrote:


On 08/27/2017 09:09 PM, Jorge Ramirez wrote:

On 08/25/2017 05:35 PM, wm4 wrote:

+static int buffer_ops_v4l2buf_to_avframe(AVFrame *frame,
V4L2Buffer *avbuf) +{
+int i, ret;
+
+av_frame_unref(frame);
+
+/* 1. get references to the actual data */
+for (i = 0; i < avbuf->num_planes; i++) {
+ret = avbuf->ops.buf_to_bufref(avbuf, i, >buf[i]);
+if (ret)
+return ret;
+
+frame->linesize[i] = avbuf->bytesperline[i];
+frame->data[i] = frame->buf[i]->data;
+}
+
+/* 1.1 fixup special cases */
+switch (avbuf->context->av_pix_fmt) {
+case AV_PIX_FMT_NV12:
+if (avbuf->num_planes > 1)
+break;
+frame->linesize[1] = avbuf->bytesperline[0];
+frame->data[1] = frame->buf[0]->data +
avbuf->bytesperline[0] * avbuf->context->format.fmt.pix_mp.height;
+break;
+default:
+break;
+}
+
+/* 2. get frame information */
+frame->key_frame = !!(avbuf->buf.flags &
V4L2_BUF_FLAG_KEYFRAME);
+frame->format = avbuf->context->av_pix_fmt;
+
+/* these values are updated also during re-init in
process_video_event */
+frame->height = avbuf->context->height;
+frame->width = avbuf->context->width;
+frame->pts = get_pts(avbuf);
+
+/* 3. report errors upstream */
+if (avbuf->buf.flags & V4L2_BUF_FLAG_ERROR) {
+av_log(avbuf->context->log_ctx, AV_LOG_ERROR, "%s:
driver decode error\n", avbuf->context->name);
+frame->decode_error_flags |=
FF_DECODE_ERROR_INVALID_BITSTREAM;
+}
+
+return 0;
+}

This function seems to lack setting typically required metadata
like colorspace.
  

ok I will retrieve the colorspace from the v4l2 format structure
and set it in the frame.

um, I dont see a 1:1 mapping between the colorspaces reported from
v4l2 and what ffmpeg expects (I am also not a subject matter expert
on this :( ).

Could I get some guidance on the translation table below please?
btw in my simple tests - ffplay decoded vp8, vp9, mpeg4, mpeg2, h263,
h264 and hevc I didnt need this field so I am not sure if I am
getting it right.


I don't think it will affect decoding, but the image will be something like too 
pale if it's set wrongly



static inline enum AVColorSpace get_colorspace(V4L2Buffer *buf)
{
  enum v4l2_colorspace cs;

  cs = V4L2_TYPE_IS_MULTIPLANAR(buf->context->type) ?
  buf->context->format.fmt.pix_mp.colorspace :
  buf->context->format.fmt.pix.colorspace;

  /* */
  switch (cs) {
  case V4L2_COLORSPACE_SMPTE170M: return AVCOL_SPC_SMPTE170M;
  case V4L2_COLORSPACE_SMPTE240M: return AVCOL_SPC_SMPTE240M;
  case V4L2_COLORSPACE_470_SYSTEM_BG: return AVCOL_SPC_BT470BG;
  case V4L2_COLORSPACE_BT2020: return AVCOL_SPC_BT2020_CL;
  case V4L2_COLORSPACE_REC709: return AVCOL_SPC_BT709;
  case V4L2_COLORSPACE_ADOBERGB:
  case V4L2_COLORSPACE_SRGB:
  case V4L2_COLORSPACE_DCI_P3:
  case V4L2_COLORSPACE_JPEG:
  case V4L2_COLORSPACE_RAW:
  default:
  return AVCOL_SPC_RGB;
  }


FWIW, here is the conversion I had been using in other projects:
  
 switch(f->colorspace)

 {
 case V4L2_COLORSPACE_SRGB:
 return AVCOL_SPC_RGB;
 case V4L2_COLORSPACE_REC709:
 return AVCOL_SPC_BT709;
 case V4L2_COLORSPACE_470_SYSTEM_M:
 return AVCOL_SPC_FCC;
 case V4L2_COLORSPACE_470_SYSTEM_BG:
 return AVCOL_SPC_BT470BG;
 case V4L2_COLORSPACE_SMPTE170M:
 return AVCOL_SPC_SMPTE170M;
 case V4L2_COLORSPACE_SMPTE240M:
 return AVCOL_SPC_SMPTE240M;
 case V4L2_COLORSPACE_BT2020:
 if(f->ycbcr_enc == V4L2_YCBCR_ENC_BT2020_CONST_LUM)
 return AVCOL_SPC_BT2020_CL;
 return AVCOL_SPC_BT2020_NCL;
 default: return AVCOL_SPC_UNSPECIFIED;
}
   


you'd likely need AVCOL_PRI*:

 switch(f->ycbcr_enc)
 {
 case V4L2_YCBCR_ENC_XV709:
 case V4L2_YCBCR_ENC_709  :
 return AVCOL_PRI_BT709;
 case V4L2_YCBCR_ENC_XV601:
 case V4L2_YCBCR_ENC_601:
 return AVCOL_PRI_BT470M;
 default: break;
 }
  
 switch(f->colorspace)

 {
 case V4L2_COLORSPACE_470_SYSTEM_BG:
 return AVCOL_PRI_BT470BG;
 case V4L2_COLORSPACE_SMPTE170M:
 return AVCOL_PRI_SMPTE170M;
 case V4L2_COLORSPACE_SMPTE240M:
 return AVCOL_PRI_SMPTE240M;
 case V4L2_COLORSPACE_BT2020:
 return 

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[wm4]

On Mon, 28 Aug 2017 10:21:54 +0200
Jorge Ramirez  wrote:

> On 08/25/2017 05:35 PM, wm4 wrote:
> >> +int avpriv_v4l2m2m_reinit(V4L2Context* ctx)
> >> +{
> >> +V4L2m2mContext *s = container_of(ctx, V4L2m2mContext, capture);
> >> +int ret;
> >> +
> >> +av_log(ctx->log_ctx, AV_LOG_DEBUG, "%s reinit context\n", ctx->name);
> >> +
> >> +/* 1. streamoff */
> >> +ret = avpriv_v4l2_context_set_status(ctx, VIDIOC_STREAMOFF);
> >> +if (ret)
> >> +av_log(ctx->log_ctx, AV_LOG_ERROR, "VIDIOC_STREAMOFF %s\n", 
> >> ctx->name);
> >> +
> >> +/* 2. unmap the buffers (v4l2 and ffmpeg) */
> >> +avpriv_v4l2_context_release(ctx);  
> > What happens to AVFrames or AVPackets that are still referenced?
> >  
> 
> yes in response to your previous comment on the subject, I am trying to 
> address that in v7 not releasing the context while there are buffers on 
> the fly
> This is what I came up with (if you can suggest something better - ie, a 
> way to  block until the AVBufferRefs are unref- please let me know)
> 
> void avpriv_v4l2_context_release(V4L2Context* ctx)
> {
>  int i, ret;
> 
>  if (!ctx->buffers)
>  return;
> 
>  /* wait until all buffers are no longer in use */
>  for (i = 0; i < ctx->num_buffers; i++) {
> 
>  if (ctx->buffers[i].status & (V4L2BUF_IN_DRIVER | 
> V4L2BUF_AVAILABLE))
>  continue;
> 
>  while (ctx->buffers[i].status & V4L2BUF_RET_USER)
>  usleep(100);
>  }
> 
>  ret = ctx->ops.release_buffers(ctx);
>  if (ret)
>  av_log(ctx->log_ctx, AV_LOG_WARNING, "V4L2 failed to unmap the 
> %s buffers\n", ctx->name);
>  else
>  av_log(ctx->log_ctx, AV_LOG_DEBUG, "%s buffers unmapped\n", 
> ctx->name);
> 
>  av_free(ctx->buffers);
>  ctx->buffers = NULL;
>  ctx->num_queued = 0;
> }
> 

No, this is not possible. You must make the V4L state reference
counted, and AVBufferRefs must implicitly reference this context.

AVHWFramesContext does this in a more elegant way - it's a frame pool
specifically made for hw decoders. I suspect the V4L code should be
ported to that. I hope Mark Thompson has some helpful remarks on this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[wm4]

On Sun, 27 Aug 2017 21:41:06 +0200
Jorge Ramirez  wrote:

> On 08/27/2017 09:09 PM, Jorge Ramirez wrote:
> > On 08/25/2017 05:35 PM, wm4 wrote:  
> >>> +static int buffer_ops_v4l2buf_to_avframe(AVFrame *frame, V4L2Buffer 
> >>> *avbuf)
> >>> +{
> >>> +int i, ret;
> >>> +
> >>> +av_frame_unref(frame);
> >>> +
> >>> +/* 1. get references to the actual data */
> >>> +for (i = 0; i < avbuf->num_planes; i++) {
> >>> +ret = avbuf->ops.buf_to_bufref(avbuf, i, >buf[i]);
> >>> +if (ret)
> >>> +return ret;
> >>> +
> >>> +frame->linesize[i] = avbuf->bytesperline[i];
> >>> +frame->data[i] = frame->buf[i]->data;
> >>> +}
> >>> +
> >>> +/* 1.1 fixup special cases */
> >>> +switch (avbuf->context->av_pix_fmt) {
> >>> +case AV_PIX_FMT_NV12:
> >>> +if (avbuf->num_planes > 1)
> >>> +break;
> >>> +frame->linesize[1] = avbuf->bytesperline[0];
> >>> +frame->data[1] = frame->buf[0]->data + avbuf->bytesperline[0] * 
> >>> avbuf->context->format.fmt.pix_mp.height;
> >>> +break;
> >>> +default:
> >>> +break;
> >>> +}
> >>> +
> >>> +/* 2. get frame information */
> >>> +frame->key_frame = !!(avbuf->buf.flags & V4L2_BUF_FLAG_KEYFRAME);
> >>> +frame->format = avbuf->context->av_pix_fmt;
> >>> +
> >>> +/* these values are updated also during re-init in 
> >>> process_video_event */
> >>> +frame->height = avbuf->context->height;
> >>> +frame->width = avbuf->context->width;
> >>> +frame->pts = get_pts(avbuf);
> >>> +
> >>> +/* 3. report errors upstream */
> >>> +if (avbuf->buf.flags & V4L2_BUF_FLAG_ERROR) {
> >>> +av_log(avbuf->context->log_ctx, AV_LOG_ERROR, "%s: driver decode 
> >>> error\n", avbuf->context->name);
> >>> +frame->decode_error_flags |= FF_DECODE_ERROR_INVALID_BITSTREAM;
> >>> +}
> >>> +
> >>> +return 0;
> >>> +}  
> >> This function seems to lack setting typically required metadata like
> >> colorspace.
> >>  
> >
> > ok I will retrieve the colorspace from the v4l2 format structure and 
> > set it in the frame.  
> 
> um, I dont see a 1:1 mapping between the colorspaces reported from v4l2 
> and what ffmpeg expects (I am also not a subject matter expert on this :( ).
> 
> Could I get some guidance on the translation table below please?
> btw in my simple tests - ffplay decoded vp8, vp9, mpeg4, mpeg2, h263, 
> h264 and hevc I didnt need this field so I am not sure if I am getting 
> it right.
> 
> TIA
> 
> static inline enum AVColorSpace get_colorspace(V4L2Buffer *buf)
> {
>  enum v4l2_colorspace cs;
> 
>  cs = V4L2_TYPE_IS_MULTIPLANAR(buf->context->type) ?
>  buf->context->format.fmt.pix_mp.colorspace :
>  buf->context->format.fmt.pix.colorspace;
> 
>  /* */
>  switch (cs) {
>  case V4L2_COLORSPACE_SMPTE170M: return AVCOL_SPC_SMPTE170M;
>  case V4L2_COLORSPACE_SMPTE240M: return AVCOL_SPC_SMPTE240M;
>  case V4L2_COLORSPACE_470_SYSTEM_BG: return AVCOL_SPC_BT470BG;
>  case V4L2_COLORSPACE_BT2020: return AVCOL_SPC_BT2020_CL;
>  case V4L2_COLORSPACE_REC709: return AVCOL_SPC_BT709;
>  case V4L2_COLORSPACE_ADOBERGB:
>  case V4L2_COLORSPACE_SRGB:
>  case V4L2_COLORSPACE_DCI_P3:
>  case V4L2_COLORSPACE_JPEG:
>  case V4L2_COLORSPACE_RAW:
>  default:
>  return AVCOL_SPC_RGB;
>  }
> }

I don't know either, but for one, I don't think there's a special jpeg
colorspace. It's just BT.601.

Also, since you have to do these conversions in both direction, using a
table might be better to avoid duplication?

Also I just noticed I sent the previous mails to you personally,
instead of the mailing list. Curse this mail client...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.4

[wm4]

On Sat, 26 Aug 2017 11:28:29 +0200
Michael Niedermayer  wrote:

> Hi all
> 
> Its a while since FFmpeg 3.3, so its time again to make a new release
> 
> I intend to make 3.4 in the next weeks
> Name suggestions needed like always
> 

At least the new channel mapping API from Libav should be part of this
release. It deprecates some API, and not having it in the release would
make the deprecation period longer and more painful.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Use NULL_IF_CONFIG_SMALL for AVOption tables.

[wm4]

On Fri, 25 Aug 2017 16:20:28 -0700
Dale Curtis  wrote:

> Saves ~12kb of binary size and seems like a good use of
> CONFIG_SMALL. I've only converted some of the largest
> tables in this patch, there's way more to do if this is a
> reasonable direction.
> 
> - dale

Seems way too intrusive and the result makes AVOption tables even
uglier and harder to read.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/mov: Always use av_realloc() for AVCodecParameters.extradata

[wm4]

On Sat, 26 Aug 2017 11:43:26 +0200
Michael Niedermayer  wrote:

> but the code removed in
> 3835283293bfd38ba69203f4618f0f0f21377bcc
> also would be a fix for this

That code won't come back.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v15] avformat/dashdec: add dash demuxer base version

[Rodger Combs]

I would expect parsing the number internally and using the additional arg to be 
simpler and easier to verify than format string validation.

> On Aug 28, 2017, at 04:28, samsamsam  wrote:
> 
> OK. I will.
> What about adding validation of format instead of adding "something like 
> `"%0*"PRId64`"?
> 
> Dnia 28 sierpnia 2017 03:30 Rodger Combs  napisał(a):
> 
> If you know of such a vulnerability, report it to  
> ffmpeg-secur...@ffmpeg.org 
> . New code with known vulnerabilities will 
> not be accepted.
> 
> Sent from my iPhone
> 
> On Aug 27, 2017, at 14:04, samsamsam < 
> samsam...@o2.pl > wrote:
>> get_repl_pattern_and_format, you should have a fixed value of something like 
>> `"%0*"PRId64`
>> 
>> If you afraid about safety then the only thing which need to be added to 
>> get_repl_pattern_and_format is validation of format.
>> Simple loop to validate format will be enough. Do you agree? 
>> 
>> Anyway we are talking about safety but parser for mp4 atoms missing checking 
>> and there is quite easy to make segfault of the libavformat when try to 
>> prepared mp4 file.
>> 
>> I understand that you want to have maximum safety with new code but I hope 
>> you know that ffmpeg at all is not safety.
>> 
>> Regards,
>> SSS
>> 
>> Dnia 27 sierpnia 2017 16:34 Rodger Combs < 
>> rodger.co...@gmail.com 
>> > napisał(a):
>> 
>> You're still calling snprintf with a string derived from the XML, which is 
>> still not safe. Rather than having a format copied from the source in 
>> get_repl_pattern_and_format, you should have a fixed value of something like 
>> `"%0*"PRId64`, and specify an additional "precision" argument you parse from 
>> the XML yourself. I can't reiterate this enough: _never pass data from the 
>> XML into the format-string arg of a printf-family function_.
>> 
>> Also, rather than calling snprintf() twice with an av_malloc() in between, 
>> you can just call av_asprintf(). That's what it does internally anyway.
>> 
>> On Aug 27, 2017, at 09:19, Steven Liu < 
>> l...@chinaffmpeg.org 
>> > wrote:
>> 
>> ffmpeg need a dash demuxer for demux the dash formats base on
>> https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch
>>  
>> 
>> 
>> TODO:
>> 1. support multi bitrate dash
>> 
>> v2 fixed:
>> 1. from autodetect to disabled
>> 2. from camelCase code style to ffmpeg code style
>> 3. from RepType to AVMediaType
>> 4. fix variable typo
>> 5. change time value from uint32_t to uint64_t
>> 6. removed be used once API
>> 7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and 
>> av_timegm
>> 8. merge complex free operation to free_fragment
>> 9. use API from snprintf to av_asprintf
>> 
>> v3 fixed:
>> 1. fix typo from --enabled-xml2 to --enable-xml2
>> 
>> v4 fixed:
>> 1. from --enable-xml2 to --enable-libxml2
>> 2. move system includes to top
>> 3. remove nouse includes
>> 4. rename enum name
>> 5. add a trailing comma for the last entry enum
>> 6. fix comment typo
>> 7. add const to DASHContext class front
>> 8. check sscanf if return arguments and give warning message when error
>> 9. check validity before free seg->url and seg
>> 10. check if the val is null, before use atoll
>> 
>> v5 fixed:
>> 1. fix typo from mainifest to manifest
>> 
>> v6 fixed:
>> 1. from realloc to av_realloc
>> 2. from free to av_free
>> 
>> v7 fixed:
>> 1. remove the -lxml2 from configure when require_pkg_config
>> 
>> v8 fixed:
>> 1. fix replace filename template by av_asprintf secure problem
>> 
>> v9 modified:
>> 1. make manifest parser clearly
>> 
>> v10 fixed:
>> 1. fix function API name code style
>> 2. remove redundant strreplace call
>> 3. remove redundant memory operation and check return value from 
>> get_content_url()
>> 4. add space between ) and {
>> 5. remove no need to log the value for print
>> 
>> v11 fixed:
>> 1. from atoll to strtoll
>> 
>> v12 fixed:
>> 1. remove strreplace and instead by av_strreplace
>> 
>> v13 fixed:
>> 1. fix bug: cannot play:
>> http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd 
>> 
>> 
>> v14 fixed:
>> 1. fix bug: TLS connection was non-properly terminated
>> 2. fix bug: No trailing CRLF found in HTTP header
>> 
>> v15 fixed:
>> 1. play youtube link: ffmpeg -i $(youtube-dl -J 
>> "https://www.youtube.com/watch?v=XmL19DOP_Ls; 
>>  | jq -r 
>> ".requested_formats[0].manifest_url")
>> 2. code refine for timeline living stream
>> 
>> Reviewed-by: Clément Bœsch < u...@pkh.me 
>> 

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Alexis Ballier]

Hi,


On Sun, 27 Aug 2017 21:41:06 +0200
Jorge Ramirez  wrote:

> On 08/27/2017 09:09 PM, Jorge Ramirez wrote:
> > On 08/25/2017 05:35 PM, wm4 wrote:  
> >>> +static int buffer_ops_v4l2buf_to_avframe(AVFrame *frame,
> >>> V4L2Buffer *avbuf) +{
> >>> +int i, ret;
> >>> +
> >>> +av_frame_unref(frame);
> >>> +
> >>> +/* 1. get references to the actual data */
> >>> +for (i = 0; i < avbuf->num_planes; i++) {
> >>> +ret = avbuf->ops.buf_to_bufref(avbuf, i, >buf[i]);
> >>> +if (ret)
> >>> +return ret;
> >>> +
> >>> +frame->linesize[i] = avbuf->bytesperline[i];
> >>> +frame->data[i] = frame->buf[i]->data;
> >>> +}
> >>> +
> >>> +/* 1.1 fixup special cases */
> >>> +switch (avbuf->context->av_pix_fmt) {
> >>> +case AV_PIX_FMT_NV12:
> >>> +if (avbuf->num_planes > 1)
> >>> +break;
> >>> +frame->linesize[1] = avbuf->bytesperline[0];
> >>> +frame->data[1] = frame->buf[0]->data +
> >>> avbuf->bytesperline[0] * avbuf->context->format.fmt.pix_mp.height;
> >>> +break;
> >>> +default:
> >>> +break;
> >>> +}
> >>> +
> >>> +/* 2. get frame information */
> >>> +frame->key_frame = !!(avbuf->buf.flags &
> >>> V4L2_BUF_FLAG_KEYFRAME);
> >>> +frame->format = avbuf->context->av_pix_fmt;
> >>> +
> >>> +/* these values are updated also during re-init in
> >>> process_video_event */
> >>> +frame->height = avbuf->context->height;
> >>> +frame->width = avbuf->context->width;
> >>> +frame->pts = get_pts(avbuf);
> >>> +
> >>> +/* 3. report errors upstream */
> >>> +if (avbuf->buf.flags & V4L2_BUF_FLAG_ERROR) {
> >>> +av_log(avbuf->context->log_ctx, AV_LOG_ERROR, "%s:
> >>> driver decode error\n", avbuf->context->name);
> >>> +frame->decode_error_flags |=
> >>> FF_DECODE_ERROR_INVALID_BITSTREAM;
> >>> +}
> >>> +
> >>> +return 0;
> >>> +}  
> >> This function seems to lack setting typically required metadata
> >> like colorspace.
> >>  
> >
> > ok I will retrieve the colorspace from the v4l2 format structure
> > and set it in the frame.  
> 
> um, I dont see a 1:1 mapping between the colorspaces reported from
> v4l2 and what ffmpeg expects (I am also not a subject matter expert
> on this :( ).
> 
> Could I get some guidance on the translation table below please?
> btw in my simple tests - ffplay decoded vp8, vp9, mpeg4, mpeg2, h263, 
> h264 and hevc I didnt need this field so I am not sure if I am
> getting it right.


I don't think it will affect decoding, but the image will be something like too 
pale if it's set wrongly


> static inline enum AVColorSpace get_colorspace(V4L2Buffer *buf)
> {
>  enum v4l2_colorspace cs;
> 
>  cs = V4L2_TYPE_IS_MULTIPLANAR(buf->context->type) ?
>  buf->context->format.fmt.pix_mp.colorspace :
>  buf->context->format.fmt.pix.colorspace;
> 
>  /* */
>  switch (cs) {
>  case V4L2_COLORSPACE_SMPTE170M: return AVCOL_SPC_SMPTE170M;
>  case V4L2_COLORSPACE_SMPTE240M: return AVCOL_SPC_SMPTE240M;
>  case V4L2_COLORSPACE_470_SYSTEM_BG: return AVCOL_SPC_BT470BG;
>  case V4L2_COLORSPACE_BT2020: return AVCOL_SPC_BT2020_CL;
>  case V4L2_COLORSPACE_REC709: return AVCOL_SPC_BT709;
>  case V4L2_COLORSPACE_ADOBERGB:
>  case V4L2_COLORSPACE_SRGB:
>  case V4L2_COLORSPACE_DCI_P3:
>  case V4L2_COLORSPACE_JPEG:
>  case V4L2_COLORSPACE_RAW:
>  default:
>  return AVCOL_SPC_RGB;
>  }


FWIW, here is the conversion I had been using in other projects:

 
switch(f->colorspace)   
 
{   
 
case V4L2_COLORSPACE_SRGB:  
 
return AVCOL_SPC_RGB;   
 
case V4L2_COLORSPACE_REC709:
 
return AVCOL_SPC_BT709; 
 
case V4L2_COLORSPACE_470_SYSTEM_M:  
 
return AVCOL_SPC_FCC;   
 
case V4L2_COLORSPACE_470_SYSTEM_BG: 
 
return AVCOL_SPC_BT470BG;   
 
case V4L2_COLORSPACE_SMPTE170M:   

Re: [FFmpeg-devel] [PATCH] avformat/hls: Fix DoS due to infinite loop

[wm4]

On Sun, 27 Aug 2017 19:16:03 +0200
Michael Niedermayer  wrote:

> On Sat, Aug 26, 2017 at 01:26:58AM +0200, Michael Niedermayer wrote:
> > Fixes: loop.m3u
> > 
> > The default max iteration count of 1000 is arbitrary and ideas for a better 
> > solution are welcome
> > 
> > Found-by: Xiaohei and Wangchu from Alibaba Security Team
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  doc/demuxers.texi | 18 ++
> >  libavformat/hls.c |  7 +++
> >  2 files changed, 25 insertions(+)  
> 
> applied
> 
> [...]

I rejected this approach, but I guess patch reviews are ignored anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/25/2017 05:35 PM, wm4 wrote:

+#if CONFIG_VP8_V4L2M2M_DECODER
+M2MDEC(vp8, "VP8", AV_CODEC_ID_VP8, NULL);
+#endif
+
+#if CONFIG_VP9_V4L2M2M_DECODER
+M2MDEC(vp9, "VP9", AV_CODEC_ID_VP9, NULL);
+#endif
+
+#if CONFIG_HEVC_V4L2M2M_DECODER
+M2MDEC(hevc, "HEVC", AV_CODEC_ID_HEVC, "h264_mp4toannexb");
+#endif

You don't need all this ifdeffery. A codec entry doesn't pull in
any additional functions, so a disabled codec entry will simply not
reference the AVCodec.



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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/25/2017 05:35 PM, wm4 wrote:

+/*
+ * increase the number of buffers to support h.264/h.265
+ * default (configurable via option) is 16
+ */
+switch (avctx->codec_id) {
+case AV_CODEC_ID_H264:
+case AV_CODEC_ID_HEVC:
+output->num_buffers += 4;
+break;
+ }

That sounds questionable. The maximum DPB for h264 and HEVC are usually
put at 16. So it should add 14 buffers, assuming traditional MPEG
codecs use 2. VP9 uses something between.



ffmpeg will request 20 out buffers (ie, input frames to the driver) in 
this case (16 + 4).
The kernel _driver_ might return more or less depending on what the 
hardware can handle and the codec_id.


this is just a tentative...


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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/25/2017 05:35 PM, wm4 wrote:

+int avpriv_v4l2m2m_reinit(V4L2Context* ctx)
+{
+V4L2m2mContext *s = container_of(ctx, V4L2m2mContext, capture);
+int ret;
+
+av_log(ctx->log_ctx, AV_LOG_DEBUG, "%s reinit context\n", ctx->name);
+
+/* 1. streamoff */
+ret = avpriv_v4l2_context_set_status(ctx, VIDIOC_STREAMOFF);
+if (ret)
+av_log(ctx->log_ctx, AV_LOG_ERROR, "VIDIOC_STREAMOFF %s\n", ctx->name);
+
+/* 2. unmap the buffers (v4l2 and ffmpeg) */
+avpriv_v4l2_context_release(ctx);

What happens to AVFrames or AVPackets that are still referenced?



yes in response to your previous comment on the subject, I am trying to 
address that in v7 not releasing the context while there are buffers on 
the fly
This is what I came up with (if you can suggest something better - ie, a 
way to  block until the AVBufferRefs are unref- please let me know)


void avpriv_v4l2_context_release(V4L2Context* ctx)
{
int i, ret;

if (!ctx->buffers)
return;

/* wait until all buffers are no longer in use */
for (i = 0; i < ctx->num_buffers; i++) {

if (ctx->buffers[i].status & (V4L2BUF_IN_DRIVER | 
V4L2BUF_AVAILABLE))

continue;

while (ctx->buffers[i].status & V4L2BUF_RET_USER)
usleep(100);
}

ret = ctx->ops.release_buffers(ctx);
if (ret)
av_log(ctx->log_ctx, AV_LOG_WARNING, "V4L2 failed to unmap the 
%s buffers\n", ctx->name);

else
av_log(ctx->log_ctx, AV_LOG_DEBUG, "%s buffers unmapped\n", 
ctx->name);


av_free(ctx->buffers);
ctx->buffers = NULL;
ctx->num_queued = 0;
}

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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/25/2017 05:35 PM, wm4 wrote:

+
+dirp = opendir("/dev");
+if (!dirp)
+return AVERROR(errno);
+
+for (entry = readdir(dirp); entry; entry = readdir(dirp)) {
+
+if (strncmp(entry->d_name, "video", 5))
+continue;
+
+snprintf(node, sizeof(node), "/dev/%s", entry->d_name);
+
+av_log(log_ctx, AV_LOG_DEBUG, "probing device %s\n", node);
+
+s->devname = node;
+ret = probe_v4l2_driver(s, log_ctx);
+if (!ret)
+break;
+}

This doesn't really look like a good idea. Even somehow trying to
enumerate stuff in/sys/class/  sounds better. Just because device
filename starts with "video" it doesn't need to be relevant, and poking
random ioctl()s at arbitrary devices doesn't sound very reliable.



yes it might seem that way but this is pretty much the standard way of 
opening v4l2 devices (I am not reimplementing the API to my understanding).
for an example already present in ffmpeg  check libavdevice/v4l2.c 
v4l2_get_device_list.



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

Re: [FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

On 08/25/2017 05:35 PM, wm4 wrote:

+static V4L2Buffer* context_ops_dequeue_v4l2buf(V4L2Context *ctx, unsigned int 
timeout)
+{
+struct v4l2_plane planes[VIDEO_MAX_PLANES];
+struct v4l2_buffer buf = { 0 };
+V4L2Buffer* avbuf = NULL;
+struct pollfd pfd = {
+.events =  POLLIN | POLLRDNORM | POLLPRI, /* default capture context */
+.fd = ctx->fd,
+};
+int ret;
+
+if (ctx->num_queued < ctx->min_queued_buffers)
+return NULL;
+
+if (V4L2_TYPE_IS_OUTPUT(ctx->type))
+pfd.events =  POLLOUT | POLLWRNORM;
+
+for (;;) {
+ret = poll(, 1, timeout);

Why does this have a timeout? This makes no sense: either a frame will
be decoded/packet can be encoded, or you need to give it more input
frames or packets, or an error happened.



yes, it does makes no sense when we consider only the capture buffers in 
a decoding scenario (those don't time out for the reasons that you 
pointed out);
however we also should look into how the output buffers are handled (in 
the same decoding case...see context_ops_getfree_v4l2buf).


every time a new output buffer is required to input data to the driver, 
we poll (with a timeout) until we have recovered _all_ the buffers that 
are no longer needed in the driver.

I dont think this is an issue.


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

[FFmpeg-devel] Odp: Re: [PATCH v15] avformat/dashdec: add dash demuxer base version

[samsamsam]

get_repl_pattern_and_format, you should have a fixed value of something like 
`%0*PRId64`   If you afraid about safety then the only thing which 
need to be added to  get_repl_pattern_and_format is validation of format.  
Simple loop to validate format will be enough. Do you agree?    Anyway we are 
talking about safety but parser for mp4 atoms missing checking and there is 
quite easy to make segfault of the libavformat when try to prepared mp4 file.   
I understand that you want to have maximum safety with new code but I hope you 
know that ffmpeg at all is not safety.   Regards,  SSS 

  
   
 
  Dnia 27 sierpnia 2017 16:34 Rodger Combs 
rodger.co...@gmail.com napisał(a):
 
 
   Youre still calling snprintf with a string derived from 
the XML, which is still not safe. Rather than having a format copied from the 
source in get_repl_pattern_and_format, you should have a fixed value of 
something like `%0*PRId64`, and specify an additional 
precision argument you parse from the XML yourself. I cant 
reiterate this enough: _never pass data from the XML into the format-string arg 
of a printf-family function_. 
  
 Also, rather than calling snprintf() twice with an av_malloc() in between, you 
can just call av_asprintf(). Thats what it does internally anyway. 
  
 
 On Aug 27, 2017, at 09:19, Steven Liu l...@chinaffmpeg.org wrote: 
  
 ffmpeg need a dash demuxer for demux the dash formats base on 
 github.com github.com 
  
 TODO: 
 1. support multi bitrate dash 
  
 v2 fixed: 
 1. from autodetect to disabled 
 2. from camelCase code style to ffmpeg code style 
 3. from RepType to AVMediaType 
 4. fix variable typo 
 5. change time value from uint32_t to uint64_t 
 6. removed be used once API 
 7. change time(NULL)`, except it is not 2038-safe. to av_gettime and 
av_timegm 
 8. merge complex free operation to free_fragment 
 9. use API from snprintf to av_asprintf 
  
 v3 fixed: 
 1. fix typo from --enabled-xml2 to --enable-xml2 
  
 v4 fixed: 
 1. from --enable-xml2 to --enable-libxml2 
 2. move system includes to top 
 3. remove nouse includes 
 4. rename enum name 
 5. add a trailing comma for the last entry enum 
 6. fix comment typo 
 7. add const to DASHContext class front 
 8. check sscanf if return arguments and give warning message when error 
 9. check validity before free seg-url and seg 
 10. check if the val is null, before use atoll 
  
 v5 fixed: 
 1. fix typo from mainifest to manifest 
  
 v6 fixed: 
 1. from realloc to av_realloc 
 2. from free to av_free 
  
 v7 fixed: 
 1. remove the -lxml2 from configure when require_pkg_config 
  
 v8 fixed: 
 1. fix replace filename template by av_asprintf secure problem 
  
 v9 modified: 
 1. make manifest parser clearly 
  
 v10 fixed: 
 1. fix function API name code style 
 2. remove redundant strreplace call 
 3. remove redundant memory operation and check return value from 
get_content_url() 
 4. add space between ) and { 
 5. remove no need to log the value for print 
  
 v11 fixed: 
 1. from atoll to strtoll 
  
 v12 fixed: 
 1. remove strreplace and instead by av_strreplace 
  
 v13 fixed: 
 1. fix bug: cannot play: 
 dash.edgesuite.net dash.edgesuite.net 
  
 v14 fixed: 
 1. fix bug: TLS connection was non-properly terminated 
 2. fix bug: No trailing CRLF found in HTTP header 
  
 v15 fixed: 
 1. play youtube link: ffmpeg -i $(youtube-dl -J  www.youtube.com 
www.youtube.com  | jq -r .requested_formats[0].manifes 
 2. code refine for timeline living stream 
  
 Reviewed-by: Clément Bœsch u...@pkh.me 
 Reviewed-by: Michael Niedermayer mich...@niedermayer.cc 
 Reviewed-by: Carl Eugen Hoyos ceho...@ag.or.at 
 Reviewed-by: Rodger Combs rodger.co...@gmail.com 
 Reviewed-by: Moritz Barsnick barsn...@gmx.net 
 Reviewed-by: Nicolas George geo...@nsup.org 
 Reviewed-by: Ricardo Constantino wiia...@gmail.com 
 Reviewed-by: wm4 nfx...@googlemail.com 
 Tested-by: Andy Furniss adf.li...@gmail.com 
 Reported-by: Andy Furniss adf.li...@gmail.com 
 Signed-off-by: Steven Liu l...@chinaffmpeg.org 
 Signed-off-by: samsamsam samsam...@o2.pl 
 --- 
 configure        4 + 
 libavformat/Makefile |    1 + 
 libavformat/allformats.c |    2 +- 
 libavformat/dashdec.c    | 1981 ++ 
 4 files changed, 1987 insertions(+), 1 deletion(-) 
 create mode 100644 libavformat/dashdec.c 
  
 diff --git a/configure b/configure 
 index 05f6dcc99a..7a7d61fa13 100755 
 --- a/configure 
 +++ b/configure 
 @@ -272,6 +272,7 @@ External library support: 
   --enable-libxcb-shape    enable X11 grabbing shape rendering [autodetect] 
   --enable-libxvid enable Xvid encoding via xvidcore, 
      MPEG-4/Xvid encoder exists [no] 
 +  --enable-libxml2 enable XML parsing using the C library libxml2 
[no] 
   --enable-libzimg enable z.lib, needed for zscale filter [no] 
   --enable-libzmq