Re: [FFmpeg-devel] [RFC] beginner difficulty bug trac tag for new open source developers

[Clément Bœsch]

On Sun, Jul 03, 2016 at 02:29:31PM -0400, compn wrote:
[...]
> i'm also not suggesting tagging every bug with a difficulty rating , as
> that would take a while and i'm not sure of the benefit. i just want to
> have a solid number (100-300+) of bugs that are somewhat easy to
> understand, implement, review and finish.

I'd say there is probably no easy bug opened, or very few (a hand at
best). Most of the easy bugs are solved as soon as they show up, because
they are generally related to a recent feature on which the author is
still available and working on.

The other easy bugs are stuff like typo/spelling etc. You could re-read
all the documentation and look for inconsistencies for instance. It's not
hard, but it's just boring as shit.

Now if you let the user rate the difficulty, they're going to say "hey
it's easy, fix it quick for me", but they have no clue whatsoever. As a
result, I'm not convinced that's a good idea.

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

On Mon, 2016-07-04 at 06:22 +, Carl Eugen Hoyos wrote:
> Dan Parrot  mail.com> writes:
> 
> > Finish providing SIMD versions for POWER8 VSX of functions 
> > in libswscale/input.c
> > That should allow trac ticket #5570 to be closed.
> 
> Please add some numbers:
> Either for single functions or for a single ffmpeg command.
> (for rgb/bgr, mono is irrelevant)
> 
> Carl Eugen
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

The data below show the running times, for each of the functions,
obtained using SystemTap. The dataset used was the entire FATE
regression suite. Only the first  calls are used in obtaining the
data (for functions called more often). SIMD functions have suffix
"_vsx". The unit of time used is nanosecond.

---
name: abgrToA_c_vsx. 
no. of calls: 1408. min: 2772 ns. avg: 3106 ns. max: 44282 ns. total:
4373993 ns. 

name: abgrToA_c. 
no. of calls: 1408. min: 3088 ns. avg: 3385 ns. max: 24698 ns. total: 4766911 
ns.
---
name: bgr24ToUV_c_vsx. 
no. of calls: 288. min: 5213 ns. avg: 5452 ns. max: 26635 ns. total:
1570338 ns. 

name: bgr24ToUV_c. 
no. of calls: 288. min: 5351 ns. avg: 5636 ns. max: 27284 ns. total: 1623277 ns.
---
name: bgr24ToUV_half_c_vsx. 
no. of calls: . min: 4792 ns. avg: 4941 ns. max: 34340 ns. total:
49411622 ns. 

name: bgr24ToUV_half_c. 
no. of calls: . min: 4795 ns. avg: 6012 ns. max: 66135 ns. total: 60122454 
ns.
---
name: bgr24ToY_c_vsx. 
no. of calls: . min: 4475 ns. avg: 4654 ns. max: 28739 ns. total:
46539077 ns. 

name: bgr24ToY_c. 
no. of calls: . min: 4551 ns. avg: 5974 ns. max: 218357 ns. total: 59741865 
ns.
---
name: monoblack2Y_c_vsx. 
no. of calls: 288. min: 2902 ns. avg: 3102 ns. max: 25454 ns. total:
893490 ns. 

name: monoblack2Y_c. 
no. of calls: 288. min: 3011 ns. avg: 3203 ns. max: 26008 ns. total: 922515 ns.
---
name: monowhite2Y_c_vsx. 
no. of calls: . min: 2813 ns. avg: 3025 ns. max: 81510 ns. total:
30248113 ns. 

name: monowhite2Y_c. 
no. of calls: . min: 2692 ns. avg: 2891 ns. max: 43653 ns. total: 28911676 
ns.
---
name: nv12ToUV_c_vsx. 
no. of calls: 144. min: 2709 ns. avg: 2960 ns. max: 26249 ns. total:
426364 ns. 

name: nv12ToUV_c. 
no. of calls: 144. min: 2930 ns. avg: 3169 ns. max: 24483 ns. total: 456353 ns.
---
name: nv21ToUV_c_vsx. 
no. of calls: 144. min: 2707 ns. avg: 3001 ns. max: 26050 ns. total:
432150 ns. 

name: nv21ToUV_c. 
no. of calls: 144. min: 2887 ns. avg: 3141 ns. max: 24704 ns. total: 452426 ns.
---
name: planar_rgb_to_a_vsx. 
no. of calls: 288. min: 2977 ns. avg: 3223 ns. max: 24993 ns. total:
928305 ns. 

name: planar_rgb_to_a. 
no. of calls: 288. min: 3306 ns. avg: 3538 ns. max: 24350 ns. total: 1019154 ns.
---
name: planar_rgb_to_uv_vsx. 
no. of calls: 576. min: 5092 ns. avg: 5295 ns. max: 27170 ns. total:
3050431 ns. 

name: planar_rgb_to_uv. 
no. of calls: 576. min: 5605 ns. avg: 5864 ns. max: 26177 ns. total: 3377983 ns.
---
name: planar_rgb_to_y_vsx. 
no. of calls: 576. min: 4459 ns. avg: 4666 ns. max: 27760 ns. total:
2688039 ns. 

name: planar_rgb_to_y. 
no. of calls: 576. min: 4877 ns. avg: 5149 ns. max: 27879 ns. total: 2965982 ns.
---
name: rgb24ToUV_c_vsx. 
no. of calls: 688. min: 4090 ns. avg: 4791 ns. max: 25602 ns. total:
3296223 ns. 

name: rgb24ToUV_c. 
no. of calls: 688. min: 4077 ns. avg: 4891 ns. max: 26629 ns. total: 3365385 ns.
---
name: rgb24ToUV_half_c_vsx. 
no. of calls: . min: 4062 ns. avg: 5074 ns. max: 975914 ns. total:
50738567 ns. 

name: rgb24ToUV_half_c. 
no. of ca

[FFmpeg-devel] [PATCH] mediacodecdec_h264: properly convert extradata to annex-b

[Matthieu Bouron]

From: Matthieu Bouron 

H264ParamSets has its SPS/PPS stored raw (SODB) and needs to be
converted to NAL units before sending them to MediaCodec.

This patch adds the missing convertion of the SPS/PPS from SOBP to RBSP
which makes the resulting NAL units correct.

Fixes codec initialization on Nexus 4 and Nexus 7.
---
 libavcodec/mediacodecdec_h264.c | 69 +
 1 file changed, 56 insertions(+), 13 deletions(-)

diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index 0664e49..f07c7cc 100644
--- a/libavcodec/mediacodecdec_h264.c
+++ b/libavcodec/mediacodecdec_h264.c
@@ -65,6 +65,54 @@ static av_cold int mediacodec_decode_close(AVCodecContext 
*avctx)
 return 0;
 }
 
+static int h264_ps_to_nalu(const uint8_t *src, int src_size, uint8_t **out, 
int *out_size)
+{
+int i;
+int ret = 0;
+uint8_t *p = NULL;
+static const uint8_t nalu_header[] = { 0x00, 0x00, 0x00, 0x01 };
+
+if (!out) {
+return AVERROR(EINVAL);
+}
+
+*out_size = sizeof(nalu_header) + src_size;
+*out = p = av_malloc(*out_size);
+if (!*out) {
+return AVERROR(ENOMEM);
+}
+
+memcpy(p, nalu_header, sizeof(nalu_header));
+memcpy(p + sizeof(nalu_header), src, src_size);
+
+/* Escape 0x00, 0x00, 0x0{0-3} pattern */
+for (i = 4; i < *out_size; i++) {
+if (i < *out_size - 3 &&
+p[i + 0] == 0 &&
+p[i + 1] == 0 &&
+p[i + 2] <= 3) {
+uint8_t *new;
+
+*out_size += 1;
+new = av_realloc(*out, *out_size);
+if (!new) {
+ret = AVERROR(ENOMEM);
+goto done;
+}
+*out = p = new;
+
+i = i + 3;
+memmove(p + i, p + i - 1, *out_size - i);
+p[i - 1] = 0x03;
+}
+}
+done:
+if (ret < 0)
+av_freep(out);
+
+return ret;
+}
+
 static av_cold int mediacodec_decode_init(AVCodecContext *avctx)
 {
 int i;
@@ -112,24 +160,19 @@ static av_cold int mediacodec_decode_init(AVCodecContext 
*avctx)
 }
 
 if (pps && sps) {
-static const uint8_t nal_headers[] = { 0x00, 0x00, 0x00, 0x01 };
-
 uint8_t *data = NULL;
-size_t data_size = sizeof(nal_headers) + FFMAX(sps->data_size, 
pps->data_size);
+size_t data_size = 0;
 
-data = av_mallocz(data_size);
-if (!data) {
-ret = AVERROR(ENOMEM);
+if ((ret = h264_ps_to_nalu(sps->data, sps->data_size, &data, 
&data_size)) < 0) {
 goto done;
 }
+ff_AMediaFormat_setBuffer(format, "csd-0", (void*)data, data_size);
+av_freep(&data);
 
-memcpy(data, nal_headers, sizeof(nal_headers));
-memcpy(data + sizeof(nal_headers), sps->data, sps->data_size);
-ff_AMediaFormat_setBuffer(format, "csd-0", (void*)data, 
sizeof(nal_headers) + sps->data_size);
-
-memcpy(data + sizeof(nal_headers), pps->data, pps->data_size);
-ff_AMediaFormat_setBuffer(format, "csd-1", (void*)data, 
sizeof(nal_headers) + pps->data_size);
-
+if ((ret = h264_ps_to_nalu(pps->data, pps->data_size, &data, 
&data_size)) < 0) {
+goto done;
+}
+ff_AMediaFormat_setBuffer(format, "csd-1", (void*)data, data_size);
 av_freep(&data);
 } else {
 av_log(avctx, AV_LOG_ERROR, "Could not extract PPS/SPS from 
extradata");
-- 
2.9.0

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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Carl Eugen Hoyos]

Dan Parrot  mail.com> writes:

> The dataset used was the entire FATE regression suite.

I don't think this is a particularly useful testcase:
It takes very long but mostly tests other things.

Did you test if using ffmpeg -benchmark -f rawvideo -i /dev/zero... 
showed different results?
I believe this should be both easier and faster to test.

> name: rgb24ToY_c_vsx. 
> no. of calls: . min: 3832 ns. avg: 4709 ns. max: 37550 ns. 
> total: 47093533 ns. 
> 
> name: rgb24ToY_c. 
> no. of calls: . min: 3809 ns. avg: 4707 ns. max: 29041 ns. 
> total: 47072923 ns.

Without any data, I would have thought that this is the most 
important function (and "no. of calls" seems to confirm this).

Why is this not faster?
Can you confirm with START_TIMER / STOP_TIMER that there is no 
gain?

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer

[Jan Sebechlebsky]

Hello Moritz,
Thanks for feedback and help with grammar! I'll include your fixes in 
the next version of patch, which I'm planning to send today.


On 07/02/2016 08:49 PM, Moritz Barsnick wrote:

+#define FIFO_DEFAULT_RECOVERY_WAIT_TIME100 // 1 second

 You're assigning it as a default to an option which claims to be
in seconds:


+{"recovery_wait_time", "Waiting time between recovery attempts 
(seconds)", OFFSET(recovery_wait_time),
+ AV_OPT_TYPE_DURATION, {.i64 = FIFO_DEFAULT_RECOVERY_WAIT_TIME}, 0, 
INT64_MAX, AV_OPT_FLAG_ENCODING_PARAM},

So the default you are setting happens to be 100 seconds. Or am I
missing something? (I could check by applying your patch. Sorry, didn't
do so.)
I agree this is confusing - The type of the recovery_wait_time option is 
"duration" which allows you to enter duration in several formats and 
converts it to the microseconds. So, when you enter an integer it 
actually takes this number for a number of seconds and converts it to 
the microseconds. The default value is therefore really just 1 second.
I will change the constant name to FIFO_DEFAULT_RECOVERY_WAIT_TIME_USEC 
and take a look at how "duration" options are usually documented.


Thank you for your help

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

Re: [FFmpeg-devel] [RFC] beginner difficulty bug trac tag for new open source developers

[Sami Hult]

On 4 July 2016 at 11:02, Clément Bœsch  wrote:

> On Sun, Jul 03, 2016 at 02:29:31PM -0400, compn wrote:
> [...]
> > i'm also not suggesting tagging every bug with a difficulty rating , as
> > that would take a while and i'm not sure of the benefit. i just want to
> > have a solid number (100-300+) of bugs that are somewhat easy to
> > understand, implement, review and finish.
>
> I'd say there is probably no easy bug opened, or very few (a hand at
> best). Most of the easy bugs are solved as soon as they show up, because
> they are generally related to a recent feature on which the author is
> still available and working on.
>

I think Randall has it right about bugs :)

http://xkcd.com/1700/

OTOH as someone new to ffmpeg ecosystem I think one could benefit from more
clear documentation on contribution.

I'm myself working on several projects - not all of them are
computer-related - and trying to contribute features or changes that I find
useful for myself is a spare moment thing. One of the surprises along the
way was "won't compile". Sure it did, just not with hardening features
enabled (which I think ARE useful).

My five cents would be to advice every aspiring contributor to focus on
bugs or lacking features that are an issue for themselves. That ensures
motivation to really fix it :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Fix memory leaks in segment muxer

[Jan Sebechlebsky]

Ping...

On 06/20/2016 05:24 PM, sebechlebsky...@gmail.com wrote:

From: Jan Sebechlebsky 

Hello,
I've observed several memory leaks in segment muxer in case the
failure happens in seg_init (write_header call).
I'm sending patchset to fix those.

Regards,
Jan

Jan Sebechlebsky (3):
   avformat/segment: Check write_header return value immediately
   avformat/segment: Ensure write_trailer is called
   avformat/segment: Use deinit function to deinitialize muxer

  libavformat/segment.c | 68 ---
  1 file changed, 37 insertions(+), 31 deletions(-)



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

[FFmpeg-devel] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

Hi,

https://bestpractices.coreinfrastructure.org/.

Thoughts on getting this done for FFmpeg?

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

Re: [FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer

[Moritz Barsnick]

On Mon, Jul 04, 2016 at 11:28:55 +0200, Jan Sebechlebsky wrote:
> >> +{"recovery_wait_time", "Waiting time between recovery attempts 
> >> (seconds)", OFFSET(recovery_wait_time),
> >> + AV_OPT_TYPE_DURATION, {.i64 = FIFO_DEFAULT_RECOVERY_WAIT_TIME}, 
> >> 0, INT64_MAX, AV_OPT_FLAG_ENCODING_PARAM},
> > So the default you are setting happens to be 100 seconds. Or am I
> > missing something? (I could check by applying your patch. Sorry, didn't
> > do so.)
> I agree this is confusing - The type of the recovery_wait_time option is 
> "duration" which allows you to enter duration in several formats and 
> converts it to the microseconds.

I totally missed AV_OPT_TYPE_DURATION, which makes this quite obvious
(I do know a bit of av_opts). Sorry!

Perhaps drop "(seconds)", as "ffmpeg -h full" will mark it as
"". And the texi source could refer to duration syntax, as
often expressed thus:
as @ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils}

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Kieran Kunhya]

On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde  wrote:

> Hi,
>
> https://bestpractices.coreinfrastructure.org/.
>
> Thoughts on getting this done for FFmpeg?
>
>
> That would imply this project could act like adults. We are centuries away
from that.

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Clément Bœsch]

On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde  wrote:
> Hi,
>
> https://bestpractices.coreinfrastructure.org/.
>
> Thoughts on getting this done for FFmpeg?

Any thing we need to adjust in the project? I don't see much things to
change by looking at https://bestpractices.coreinfrastructure.org/projects/1

On Mon, Jul 04, 2016 at 02:14:10PM +, Kieran Kunhya wrote:
> That would imply this project could act like adults. We are centuries away
> from that.
> 

You mean by getting rid of people with childish and toxic behaviour such
as this one?

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer

[Jan Sebechlebsky]

Hello Nicolas,
I am sending the second version of patch, I have some notes why certain 
things from your feedback are not implemented (yet?) and additional 
questions :)


On 06/28/2016 03:42 PM, Nicolas George wrote:



+@item block_on_overflow 0|1

+If set to 0, fully non-blocking mode will be used and in case the queue
+fills up, packets will be dropped. By default this option is set to 1,
+so in case of queue overflow the encoder will be block until muxer
+processes some of the packets.

IMHO, this should use AVFMT_FLAG_NONBLOCK.

This is not yet exposed to the user via cmd options, do you think I 
should add this flag to options in option_table.h (for encoding only)?


I had to look twice to be sure it was only used in the thread.

Suggestions:

- make sure function names describe exactly where they can be called:
   fifo_thread_description() for functions called in the thread,
   fifo_description() for functions called from the main thread,
   description() for utility functions that are used in both but do nothing
   dangerous.

- move fields that are only useful in the thread to a different struct,
   allocate it on the stack in the main function of the thread;

- try to make the FifoContext pointer const in the thread.
I've renamed the functions and also moved the fields accessed only from 
the thread to separate structure, however I didn't make the FifoContext 
const in thread - it would require creating another structure for the 
fields accessed both by "main" thread and fifo thread (or some other 
solution which seemed more messy to me).





+avf2->interrupt_callback = avf->interrupt_callback;

This is wrong. First, we do not know that the application-provided callback
is thread-safe. Second, the thread needs an interrupt_callback of its own to
interrupt the actual I/O when asked to abort.
Can you please explain little bit more why is this wrong (appart from 
the undocumented requirement for the interrupt callback to be thread-safe)?

+FifoMessage message = {.type = FIFO_WRITE_HEADER};
+
+ret = av_thread_message_queue_send(fifo->queue, &message, 0);
+if (ret < 0)
+return ret;

This message is sent only once. Maybe take it out of the loop to make things
simpler.
I decided not to take it out of the loop - it would be a special case to 
handle in case the call would fail.


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

[FFmpeg-devel] [PATCH 2/7] avformat/tee: Use ff_stream_encode_params_copy()

[sebechlebskyjan]

From: Jan Sebechlebsky 

Use ff_stream_encode_params_copy() to copy encoding-related
fields (parameters) of stream.

Signed-off-by: Jan Sebechlebsky 
---
 libavformat/tee.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/libavformat/tee.c b/libavformat/tee.c
index 9d0a4cb..c276a37 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -294,17 +294,9 @@ static int open_slave(AVFormatContext *avf, char *slave, 
TeeSlave *tee_slave)
 ret = AVERROR(ENOMEM);
 goto end;
 }
-st2->id = st->id;
-st2->r_frame_rate= st->r_frame_rate;
-st2->time_base   = st->time_base;
-st2->start_time  = st->start_time;
-st2->duration= st->duration;
-st2->nb_frames   = st->nb_frames;
-st2->disposition = st->disposition;
-st2->sample_aspect_ratio = st->sample_aspect_ratio;
-st2->avg_frame_rate  = st->avg_frame_rate;
-av_dict_copy(&st2->metadata, st->metadata, 0);
-if ((ret = avcodec_parameters_copy(st2->codecpar, st->codecpar)) < 0)
+
+ret = ff_stream_encode_params_copy(st2, st);
+if (ret < 0)
 goto end;
 }
 
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 3/7] avformat/tee: Handle AV_NOPTS_VALUE correctly

[sebechlebskyjan]

From: Jan Sebechlebsky 

Do not rescale pts and dts if they are set to
AV_NOPTS_VALUE.

Signed-off-by: Jan Sebechlebsky 
---
 libavformat/tee.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavformat/tee.c b/libavformat/tee.c
index c276a37..a56d449 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -533,8 +533,10 @@ static int tee_write_packet(AVFormatContext *avf, AVPacket 
*pkt)
 }
 tb  = avf ->streams[s ]->time_base;
 tb2 = avf2->streams[s2]->time_base;
-pkt2.pts  = av_rescale_q(pkt->pts,  tb, tb2);
-pkt2.dts  = av_rescale_q(pkt->dts,  tb, tb2);
+if (pkt->pts != AV_NOPTS_VALUE)
+pkt2.pts = av_rescale_q(pkt->pts, tb, tb2);
+if (pkt->dts != AV_NOPTS_VALUE)
+pkt2.dts = av_rescale_q(pkt->dts, tb, tb2);
 pkt2.duration = av_rescale_q(pkt->duration, tb, tb2);
 pkt2.stream_index = s2;
 
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 4/7] avformat/tee: Support flushing by writing NULL pkt

[sebechlebskyjan]

From: Jan Sebechlebsky 

This will fix crash when caller attempts to flush by
calling write_packet with NULL packet pointer and
flushes slaves as expected.

Signed-off-by: Jan Sebechlebsky 
---
 libavformat/tee.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavformat/tee.c b/libavformat/tee.c
index a56d449..996d64d 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -520,6 +520,17 @@ static int tee_write_packet(AVFormatContext *avf, AVPacket 
*pkt)
 if (!(avf2 = tee->slaves[i].avf))
 continue;
 
+/* Flush slave if pkt is NULL*/
+if (!pkt) {
+ret = av_interleaved_write_frame(avf2, NULL);
+if (ret < 0) {
+ret = tee_process_slave_failure(avf, i, ret);
+if (!ret_all && ret < 0)
+ret_all = ret;
+}
+continue;
+}
+
 s = pkt->stream_index;
 s2 = tee->slaves[i].stream_map[s];
 if (s2 < 0)
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 6/7] avformat/tee: Use ff_format_output_open() function

[sebechlebskyjan]

From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 
---
 libavformat/tee.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/libavformat/tee.c b/libavformat/tee.c
index 996d64d..c60a77f 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -300,12 +300,11 @@ static int open_slave(AVFormatContext *avf, char *slave, 
TeeSlave *tee_slave)
 goto end;
 }
 
-if (!(avf2->oformat->flags & AVFMT_NOFILE)) {
-if ((ret = avf2->io_open(avf2, &avf2->pb, filename, AVIO_FLAG_WRITE, 
NULL)) < 0) {
-av_log(avf, AV_LOG_ERROR, "Slave '%s': error opening: %s\n",
-   slave, av_err2str(ret));
-goto end;
-}
+ret = ff_format_output_open(avf2, filename, NULL);
+if (ret < 0) {
+av_log(avf, AV_LOG_ERROR, "Slave '%s': error opening: %s\n", slave,
+   av_err2str(ret));
+goto end;
 }
 
 if ((ret = avformat_write_header(avf2, &options)) < 0) {
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 7/7] libavformat: Add FIFO pseudo-muxer

[sebechlebskyjan]

From: Jan Sebechlebsky 

The fifo pseudo-muxer allows to separate encoder from the
actual output by using a first-in-first-out queue and
running actual muxer asynchronously in separate thread.

It can be configured to attempt transparent recovery
of output on failure.

Signed-off-by: Jan Sebechlebsky 
---
 configure|   1 +
 doc/muxers.texi  |  80 ++
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/fifo.c   | 666 +++
 5 files changed, 749 insertions(+)
 create mode 100644 libavformat/fifo.c

diff --git a/configure b/configure
index 126d0d6..b71c75f 100755
--- a/configure
+++ b/configure
@@ -2826,6 +2826,7 @@ dv_muxer_select="dvprofile"
 dxa_demuxer_select="riffdec"
 eac3_demuxer_select="ac3_parser"
 f4v_muxer_select="mov_muxer"
+fifo_muxer_deps="pthreads"
 flac_demuxer_select="flac_parser"
 hds_muxer_select="flv_muxer"
 hls_muxer_select="mpegts_muxer"
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c2ca0ba..7ca14f6 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1408,6 +1408,86 @@ Specify whether to remove all fragments when finished. 
Default 0 (do not remove)
 
 @end table
 
+@section fifo
+
+The fifo pseudo-muxer allows to separate encoding from any other muxer by using
+first-in-first-out queue and running the actual muxer in a separate thread. 
This
+is especially useful in combination with the @ref{tee} muxer and output to
+several destinations with different reliability/writing speed/latency.
+
+The fifo muxer can operate in regular or non-blocking mode. This determines the
+behaviour in case the queue fills up. In regular mode the encoding is blocked
+until the muxer processes some of the packets from queue; in non-blocking mode
+the packets are thrown away rather than blocking the encoder (this might be
+useful in real-time streaming scenarios).
+
+@table @option
+
+@item fifo_format
+Specify the format name. Useful if it cannot be guessed from the
+output name suffix.
+
+@item queue_size
+Specify size of the queue (number of packets). Default value is 60.
+
+@item format_opts
+Specify format options for the underlying muxer. Muxer options can be specified
+as a list of @var{key}=@var{value} pairs separated by ':'.
+
+@item block_on_overflow @var{bool}
+If set to 0 (false), non-blocking mode will be used and in case the queue fills
+up, packets will be dropped. By default this option is set to 1 (true), so in
+case of queue overflow the encoder will be blocked until the muxer processes
+some of the packets.
+
+@item attempt_recovery @var{bool}
+If failure occurs, attempt to recover the output. This is especially useful
+when used with network output, allows to restart streaming transparently.
+By default this option set to 0 (false).
+
+@item max_recovery_attempts
+Sets maximum number of successive unsucessful recovery attempts after which
+the output fails permanently. Unlimited if set to zero. Default value is 16.
+
+@item recovery_wait_time @var{duration}
+Waiting time before the next recovery attempt after previous unsuccessfull
+recovery attempt. Default value is 5 seconds.
+
+s@item recovery_wait_streamtime @var{bool}
+If set to 0 (false), the real time is used when waiting for the recovery
+attempt (i.e. the recovery will be attempted after at least
+recovery_wait_time seconds).
+If set to 1 (true), the time of the processed stream is taken into account
+instead (i.e. the recovery will be attempted after at least recovery_wait_time
+seconds of the stream is omitted).
+By default, this option is set to 0 (false).
+
+@item recover_any_error @var{bool}
+If set to 1 (true), recovery will be attempted regardless of type of the error
+causing the failure. By default this option is set to 0 (false) and in case of
+certain errors the recovery is not attempted even when @ref{attempt_recovery}
+is set to 1.
+
+@item restart_with_keyframe @var{bool}
+Specify whether to wait for the keyframe after recovering from
+queue overflow or failure. This option is set to 0 (false) by default.
+
+@end table
+
+@subsection Examples
+
+@itemize
+
+@item
+Stream something to rtmp server using non-blocking mode and recover 
automatically
+in case failure happens (for example the network becomes unavailable for a 
moment).
+@example
+ffmpeg -re -i ... -c:v libx264 -c:a mp2 -f fifo -fifo_format flv -map 0:v -map 
0:a
+  -block_on_overflow 0 -attempt_recovery 1 rtmp://example.com/live/stream_name
+@end example
+
+@end itemize
+
 @section tee
 
 The tee muxer can be used to write the same data to several files or any
diff --git a/libavformat/Makefile b/libavformat/Makefile
index c49f9de..42fb9be 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -162,6 +162,7 @@ OBJS-$(CONFIG_FFM_DEMUXER)   += ffmdec.o
 OBJS-$(CONFIG_FFM_MUXER) += ffmenc.o
 OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
 OBJS-$(CONFIG_FFMETADATA_MUXER)  += ffmetaenc.o
+OBJS-$(CON

[FFmpeg-devel] [PATCH 5/7] avformat/utils: Add ff_format_output_open() function

[sebechlebskyjan]

From: Jan Sebechlebsky 

Add ff_format_output_open utility function to wrap
io_open callback of AVFormatContext structure.

Signed-off-by: Jan Sebechlebsky 
---
 libavformat/internal.h | 10 ++
 libavformat/utils.c| 10 ++
 2 files changed, 20 insertions(+)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index 1b44bea..0119749 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -572,6 +572,16 @@ int ffio_open2_wrapper(struct AVFormatContext *s, 
AVIOContext **pb, const char *
  */
 #define FFERROR_REDO FFERRTAG('R','E','D','O')
 
+/**
+ * Utility function to open IO stream of output format.
+ *
+ * @param s AVFormatContext
+ * @param url URL or file name to open for writing
+ * @options optional options which will be passed to io_open callback
+ * @return >=0 on success, negative AVERROR in case of failure
+ */
+int ff_format_output_open(AVFormatContext *s, const char *url, AVDictionary 
**options);
+
 /*
  * A wrapper around AVFormatContext.io_close that should be used
  * instead of calling the pointer directly.
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8c16374..d728ca3 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5168,6 +5168,16 @@ int av_apply_bitstream_filters(AVCodecContext *codec, 
AVPacket *pkt,
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
+int ff_format_output_open(AVFormatContext *s, const char *url, AVDictionary 
**options)
+{
+if (!s->oformat)
+return AVERROR(EINVAL);
+
+if (!(s->oformat->flags & AVFMT_NOFILE))
+return s->io_open(s, &s->pb, url, AVIO_FLAG_WRITE, options);
+return 0;
+}
+
 void ff_format_io_close(AVFormatContext *s, AVIOContext **pb)
 {
 if (*pb)
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 1/7] avformat/utils: Add ff_stream_encode_params_copy()

[sebechlebskyjan]

From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 
---
 libavformat/internal.h |  9 
 libavformat/utils.c| 56 ++
 2 files changed, 65 insertions(+)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index 647ad65..1b44bea 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -491,6 +491,15 @@ int ff_generate_avci_extradata(AVStream *st);
 int ff_stream_add_bitstream_filter(AVStream *st, const char *name, const char 
*args);
 
 /**
+ * Copy encoding parameters from source to destination stream
+ *
+ * @param dst pointer to destination AVStream
+ * @param src pointer to source AVStream
+ * @return >=0 on success, AVERROR code on error
+ */
+int ff_stream_encode_params_copy(AVStream *dst, const AVStream *src);
+
+/**
  * Wrap errno on rename() error.
  *
  * @param oldpath source path
diff --git a/libavformat/utils.c b/libavformat/utils.c
index d2a709c..8c16374 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3951,6 +3951,62 @@ int av_read_pause(AVFormatContext *s)
 return AVERROR(ENOSYS);
 }
 
+int ff_stream_encode_params_copy(AVStream *dst, const AVStream *src)
+{
+int ret, i;
+
+dst->id  = src->id;
+dst->time_base   = src->time_base;
+dst->nb_frames   = src->nb_frames;
+dst->disposition = src->disposition;
+dst->sample_aspect_ratio = src->sample_aspect_ratio;
+dst->avg_frame_rate  = src->avg_frame_rate;
+dst->r_frame_rate= src->r_frame_rate;
+
+ret = av_dict_copy(&dst->metadata, src->metadata, 0);
+if (ret < 0)
+return ret;
+
+ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
+if (ret < 0)
+return ret;
+
+/* Free existing side data*/
+for (i = 0; i < dst->nb_side_data; i++)
+av_free(dst->side_data[i].data);
+av_freep(&dst->side_data);
+dst->nb_side_data = 0;
+
+/* Copy side data if present */
+if (src->nb_side_data) {
+dst->side_data = av_mallocz_array(src->nb_side_data,
+  sizeof(AVPacketSideData));
+if (!dst->side_data)
+return AVERROR(ENOMEM);
+dst->nb_side_data = src->nb_side_data;
+
+for (i = 0; i < src->nb_side_data; i++) {
+uint8_t *data = av_memdup(src->side_data[i].data,
+  src->side_data[i].size);
+if (!data)
+return AVERROR(ENOMEM);
+dst->side_data[i].type = src->side_data[i].type;
+dst->side_data[i].size = src->side_data[i].size;
+dst->side_data[i].data = data;
+}
+}
+
+av_freep(&dst->recommended_encoder_configuration);
+if (src->recommended_encoder_configuration) {
+const char *conf_str = src->recommended_encoder_configuration;
+dst->recommended_encoder_configuration = av_strdup(conf_str);
+if (!dst->recommended_encoder_configuration)
+return AVERROR(ENOMEM);
+}
+
+return 0;
+}
+
 static void free_stream(AVStream **pst)
 {
 AVStream *st = *pst;
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

On Mon, 2016-07-04 at 09:20 +, Carl Eugen Hoyos wrote:
> Dan Parrot  mail.com> writes:
> 
> > The dataset used was the entire FATE regression suite.
> 
> I don't think this is a particularly useful testcase:
> It takes very long but mostly tests other things.
> 
> Did you test if using ffmpeg -benchmark -f rawvideo -i /dev/zero... 
> showed different results?
> I believe this should be both easier and faster to test.
Sorry, I don't understand what that command line just above is trying to
achieve. Could you elaborate?

> > name: rgb24ToY_c_vsx. 
> > no. of calls: . min: 3832 ns. avg: 4709 ns. max: 37550 ns. 
> > total: 47093533 ns. 
> > 
> > name: rgb24ToY_c. 
> > no. of calls: . min: 3809 ns. avg: 4707 ns. max: 29041 ns. 
> > total: 47072923 ns.
> 
> Without any data, I would have thought that this is the most 
> important function (and "no. of calls" seems to confirm this).
> 
> Why is this not faster?
Surprisingly, gcc is producing some badly suboptimal assembly. I need to
follow up with IBM's Linux Technology Center. The major issue is that
multiplication of vector quantities in C is generating as many
multiplications in assembly as would scalar multiplication in a loop. No
way that should be occurring.

> Can you confirm with START_TIMER / STOP_TIMER that there is no 
> gain?
SystemTap probes provide identical functionality by measuring deltas
between function entry and function return.


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

Re: [FFmpeg-devel] [PATCH 3/7] avformat/tee: Handle AV_NOPTS_VALUE correctly

[Hendrik Leppkes]

On Mon, Jul 4, 2016 at 4:45 PM,   wrote:
> From: Jan Sebechlebsky 
>
> Do not rescale pts and dts if they are set to
> AV_NOPTS_VALUE.
>
> Signed-off-by: Jan Sebechlebsky 
> ---
>  libavformat/tee.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/tee.c b/libavformat/tee.c
> index c276a37..a56d449 100644
> --- a/libavformat/tee.c
> +++ b/libavformat/tee.c
> @@ -533,8 +533,10 @@ static int tee_write_packet(AVFormatContext *avf, 
> AVPacket *pkt)
>  }
>  tb  = avf ->streams[s ]->time_base;
>  tb2 = avf2->streams[s2]->time_base;
> -pkt2.pts  = av_rescale_q(pkt->pts,  tb, tb2);
> -pkt2.dts  = av_rescale_q(pkt->dts,  tb, tb2);
> +if (pkt->pts != AV_NOPTS_VALUE)
> +pkt2.pts = av_rescale_q(pkt->pts, tb, tb2);
> +if (pkt->dts != AV_NOPTS_VALUE)
> +pkt2.dts = av_rescale_q(pkt->dts, tb, tb2);

Maybe this entire thing could use av_packet_rescale_ts?

>  pkt2.duration = av_rescale_q(pkt->duration, tb, tb2);
>  pkt2.stream_index = s2;
>
> --
> 1.9.1
>
> ___
> 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 3/7] avformat/tee: Handle AV_NOPTS_VALUE correctly

[Jan Sebechlebsky]

On 07/04/2016 05:07 PM, Hendrik Leppkes wrote:

On Mon, Jul 4, 2016 at 4:45 PM,   wrote:

+if (pkt->pts != AV_NOPTS_VALUE)
+pkt2.pts = av_rescale_q(pkt->pts, tb, tb2);
+if (pkt->dts != AV_NOPTS_VALUE)
+pkt2.dts = av_rescale_q(pkt->dts, tb, tb2);

Maybe this entire thing could use av_packet_rescale_ts?

Sure! I wasn't aware there is such function, I'll wait if there are some 
more comments to the patchset and change this.


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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[James Almer]

On 7/4/2016 11:33 AM, Clément Bœsch wrote:
> On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde  wrote:
>> Hi,
>>
>> https://bestpractices.coreinfrastructure.org/.
>>
>> Thoughts on getting this done for FFmpeg?
> 
> Any thing we need to adjust in the project? I don't see much things to
> change by looking at https://bestpractices.coreinfrastructure.org/projects/1
> 
> On Mon, Jul 04, 2016 at 02:14:10PM +, Kieran Kunhya wrote:
>> That would imply this project could act like adults. We are centuries away
>> from that.

There was no need for this...

>>
> 
> You mean by getting rid of people with childish and toxic behaviour such
> as this one?

Or this... at all.

Last month was a disaster. Please, lets not make it worse.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fate: add test for asetrate

[Petru Rares Sincraian]

Hi there,


Here is a patch for libavfilter/asetrate.
From f855dbc610888acf6a36b2df16a9146a14fc22f6 Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 
Date: Mon, 4 Jul 2016 17:51:54 +0200
Subject: [PATCH] fate: add test for asetrate

---
 tests/fate/filter-audio.mak|   5 +
 tests/ref/fate/filter-asetrate | 264 +
 2 files changed, 269 insertions(+)
 create mode 100644 tests/ref/fate/filter-asetrate

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index a40755a..95cb404 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -89,6 +89,11 @@ fate-filter-asetnsamples: tests/data/asynth-44100-2.wav
 fate-filter-asetnsamples: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
 fate-filter-asetnsamples: CMD = framecrc -i $(SRC) -af asetnsamples=512:p=1
 
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETRATE, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-asetrate
+fate-filter-asetrate: tests/data/asynth-44100-2.wav
+fate-filter-asetrate: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-asetrate: CMD = framecrc -i $(SRC) -af asetrate=2
+
 tests/data/hls-list.m3u8: TAG = GEN
 tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
 	$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
diff --git a/tests/ref/fate/filter-asetrate b/tests/ref/fate/filter-asetrate
new file mode 100644
index 000..a24d206
--- /dev/null
+++ b/tests/ref/fate/filter-asetrate
@@ -0,0 +1,264 @@
+#tb 0: 1/2
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 2
+#channel_layout 0: 3
+0,  0,  0, 1024, 4096, 0x29e3eecf
+0,   1024,   1024, 1024, 4096, 0x18390b96
+0,   2048,   2048, 1024, 4096, 0xc477fa99
+0,   3072,   3072, 1024, 4096, 0x3bc0f14f
+0,   4096,   4096, 1024, 4096, 0x2379ed91
+0,   5120,   5120, 1024, 4096, 0xfd6a0070
+0,   6144,   6144, 1024, 4096, 0x0b01f4cf
+0,   7168,   7168, 1024, 4096, 0x6716fd93
+0,   8192,   8192, 1024, 4096, 0x1840f25b
+0,   9216,   9216, 1024, 4096, 0x9c1ffaf1
+0,  10240,  10240, 1024, 4096, 0xcbedefaf
+0,  11264,  11264, 1024, 4096, 0x3e050390
+0,  12288,  12288, 1024, 4096, 0xb30e0090
+0,  13312,  13312, 1024, 4096, 0x26b8f75b
+0,  14336,  14336, 1024, 4096, 0xd706e311
+0,  15360,  15360, 1024, 4096, 0x0c480138
+0,  16384,  16384, 1024, 4096, 0x6c9a0216
+0,  17408,  17408, 1024, 4096, 0x7abce54f
+0,  18432,  18432, 1024, 4096, 0xda45f63f
+0,  19456,  19456, 1024, 4096, 0x50d5ff87
+0,  20480,  20480, 1024, 4096, 0x59be0352
+0,  21504,  21504, 1024, 4096, 0xa61af077
+0,  22528,  22528, 1024, 4096, 0x84c4fc07
+0,  23552,  23552, 1024, 4096, 0x4a35f345
+0,  24576,  24576, 1024, 4096, 0xbb65fa81
+0,  25600,  25600, 1024, 4096, 0xf6c7f5e5
+0,  26624,  26624, 1024, 4096, 0xd3270138
+0,  27648,  27648, 1024, 4096, 0x4782ed53
+0,  28672,  28672, 1024, 4096, 0xe308f055
+0,  29696,  29696, 1024, 4096, 0x7d33f97d
+0,  30720,  30720, 1024, 4096, 0xb8b00dd4
+0,  31744,  31744, 1024, 4096, 0x7ff7efab
+0,  32768,  32768, 1024, 4096, 0x29e3eecf
+0,  33792,  33792, 1024, 4096, 0x18390b96
+0,  34816,  34816, 1024, 4096, 0xc477fa99
+0,  35840,  35840, 1024, 4096, 0x3bc0f14f
+0,  36864,  36864, 1024, 4096, 0x2379ed91
+0,  37888,  37888, 1024, 4096, 0xfd6a0070
+0,  38912,  38912, 1024, 4096, 0x0b01f4cf
+0,  39936,  39936, 1024, 4096, 0x6716fd93
+0,  40960,  40960, 1024, 4096, 0x1840f25b
+0,  41984,  41984, 1024, 4096, 0x9c1ffaf1
+0,  43008,  43008, 1024, 4096, 0xcbedefaf
+0,  44032,  44032, 1024, 4096, 0xda37d691
+0,  45056,  45056, 1024, 4096, 0x7193ecbf
+0,  46080,  46080, 1024, 4096, 0x6e4a0a36
+0,  47104,  47104, 1024, 4096, 0x61cfe70d
+0,  48128,  48128, 1024, 4096, 0xc19ffa15
+0,  49152,  49152, 1024, 4096, 0x7b32fb3d
+0,  50176,  50176, 1024, 4096, 0xdacefd3f
+0,  51200,  51200, 1024, 4096, 0x3964f64d
+0,  52224,  52224, 1024, 4096, 0xdcf2edad
+0,  53248,  53248, 1024, 4096, 0x1367f69b
+0,  54272,  54272, 1024, 4096, 0xd4c6f7b9
+0,  55296,  55296, 1024, 4096, 0x9e041186
+0,  56320,  56320, 1024, 4096, 0xe939edd7
+0,  57344,  57344, 1024, 4096, 0xa932336a
+0,  58368,  58368, 1024,

Re: [FFmpeg-devel] [PATCH] fate: add test for asetrate

[Clément Bœsch]

On Mon, Jul 04, 2016 at 04:01:17PM +, Petru Rares Sincraian wrote:
> Hi there,
> 
> 
> Here is a patch for libavfilter/asetrate.

> From f855dbc610888acf6a36b2df16a9146a14fc22f6 Mon Sep 17 00:00:00 2001
> From: Petru Rares Sincraian 
> Date: Mon, 4 Jul 2016 17:51:54 +0200
> Subject: [PATCH] fate: add test for asetrate
> 
> ---
>  tests/fate/filter-audio.mak|   5 +
>  tests/ref/fate/filter-asetrate | 264 
> +
>  2 files changed, 269 insertions(+)
>  create mode 100644 tests/ref/fate/filter-asetrate
> 
> diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
> index a40755a..95cb404 100644
> --- a/tests/fate/filter-audio.mak
> +++ b/tests/fate/filter-audio.mak
> @@ -89,6 +89,11 @@ fate-filter-asetnsamples: tests/data/asynth-44100-2.wav
>  fate-filter-asetnsamples: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
>  fate-filter-asetnsamples: CMD = framecrc -i $(SRC) -af asetnsamples=512:p=1
>  
> +FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETRATE, WAV, PCM_S16LE, PCM_S16LE, 
> WAV) += fate-filter-asetrate
> +fate-filter-asetrate: tests/data/asynth-44100-2.wav
> +fate-filter-asetrate: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
> +fate-filter-asetrate: CMD = framecrc -i $(SRC) -af asetrate=2
> +

This is not the first patch like this, but I don't think you need to
decode the whole file. 20-30 frames should be more than enough IMO

Regards,

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] fate: add test for asetrate

[Petru Rares Sincraian]

On 04/07/16 18:03, Clément Bœsch wrote:

On Mon, Jul 04, 2016 at 04:01:17PM +, Petru Rares Sincraian wrote:


Hi there,


Here is a patch for libavfilter/asetrate.





From f855dbc610888acf6a36b2df16a9146a14fc22f6 Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 

Date: Mon, 4 Jul 2016 17:51:54 +0200
Subject: [PATCH] fate: add test for asetrate

---
 tests/fate/filter-audio.mak|   5 +
 tests/ref/fate/filter-asetrate | 264 +
 2 files changed, 269 insertions(+)
 create mode 100644 tests/ref/fate/filter-asetrate

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index a40755a..95cb404 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -89,6 +89,11 @@ fate-filter-asetnsamples: tests/data/asynth-44100-2.wav
 fate-filter-asetnsamples: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
 fate-filter-asetnsamples: CMD = framecrc -i $(SRC) -af asetnsamples=512:p=1

+FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETRATE, WAV, PCM_S16LE, PCM_S16LE, 
WAV) += fate-filter-asetrate
+fate-filter-asetrate: tests/data/asynth-44100-2.wav
+fate-filter-asetrate: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-asetrate: CMD = framecrc -i $(SRC) -af asetrate=2
+



This is not the first patch like this, but I don't think you need to
decode the whole file. 20-30 frames should be more than enough IMO

Regards,



How can I do that?

Thanks,
Petru Rares.


___
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] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Carl Eugen Hoyos]

Dan Parrot  mail.com> writes:

> > Did you test if using ffmpeg -benchmark -f rawvideo -i /dev/zero... 
> > showed different results?
> > I believe this should be both easier and faster to test.
>
> Sorry, I don't understand what that command line just above 
> is trying to achieve. Could you elaborate?

Instead of running the whole fate suite that takes long and 
does not test libswscale for most commands, just test an 
ffmpeg command line that only tests libswscale:
$ ffmpeg -benchmark -f rawvideo -pix_fmt rgb24 
-i /dev/zero -pix_fmt yuv420p -f null -vframes 1 -

vs

$ ffmpeg -cpuflags 0 -benchmark -f rawvideo -pix_fmt rgb24 
-i /dev/zero -pix_fmt yuv420p -f null -vframes 1 -

[...]

> Surprisingly, gcc is producing some badly suboptimal assembly.

Just to make sure I don't misunderstand:
Does this mean intrinsics are suboptimal to write assembly 
code?

> > Can you confirm with START_TIMER / STOP_TIMER that there is no 
> > gain?
>
> SystemTap probes provide identical functionality by measuring 
> deltas between function entry and function return.

Sorry, I don't understand:
Did you test with both methods to verify that they provide 
the same results?

Note that if it turns out that START_TIMER / STOP_TIMER 
cannot be used on ppc64 (le) this would be important 
information for us.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] fate: add test for asetrate

[Petru Rares Sincraian]

How can I do that?



Thanks,

Petru.


From: Petru Rares Sincraian 
Sent: Monday, July 4, 2016 6:23:05 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] fate: add test for asetrate



On 04/07/16 18:03, Cl?ment Boesch wrote:

On Mon, Jul 04, 2016 at 04:01:17PM +, Petru Rares Sincraian wrote:


Hi there,


Here is a patch for libavfilter/asetrate.





From f855dbc610888acf6a36b2df16a9146a14fc22f6 Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 

Date: Mon, 4 Jul 2016 17:51:54 +0200
Subject: [PATCH] fate: add test for asetrate

---
 tests/fate/filter-audio.mak|   5 +
 tests/ref/fate/filter-asetrate | 264 +
 2 files changed, 269 insertions(+)
 create mode 100644 tests/ref/fate/filter-asetrate

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index a40755a..95cb404 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -89,6 +89,11 @@ fate-filter-asetnsamples: tests/data/asynth-44100-2.wav
 fate-filter-asetnsamples: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
 fate-filter-asetnsamples: CMD = framecrc -i $(SRC) -af asetnsamples=512:p=1

+FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETRATE, WAV, PCM_S16LE, PCM_S16LE, 
WAV) += fate-filter-asetrate
+fate-filter-asetrate: tests/data/asynth-44100-2.wav
+fate-filter-asetrate: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-asetrate: CMD = framecrc -i $(SRC) -af asetrate=2
+



This is not the first patch like this, but I don't think you need to
decode the whole file. 20-30 frames should be more than enough IMO

Regards,



How can I do that?

Thanks,
Petru Rares.


___
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] fate: add test for asetrate

[James Almer]

On 7/4/2016 1:34 PM, Petru Rares Sincraian wrote:
> How can I do that?

Add -aframes 20 to the command line
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/5] lavf: add cue sheet demuxer

[Rodger Combs]

---
 Changelog|   1 +
 doc/demuxers.texi|   8 ++
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/cuedec.c | 204 +++
 libavformat/version.h|   2 +-
 6 files changed, 216 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/cuedec.c

diff --git a/Changelog b/Changelog
index 99cdb80..58576f6 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest 
within each release,
 releases are sorted from youngest to oldest.
 
 version :
+- Cue sheet demuxer
 
 
 version 3.1:
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e34f8b3..bd8a844 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -243,6 +243,14 @@ file subdir/file-2.wav
 @end example
 @end itemize
 
+@section cue
+
+Cue sheet demuxer.
+
+This demuxer reads a cue sheet (text file) and exports its track listing in
+the form of AVChapters. Packet data is read from the file listed in the sheet.
+To override the path the packet data is read from, use the @code{url} option.
+
 @section flv
 
 Adobe Flash Video Format demuxer.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index c49f9de..a217889 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -131,6 +131,7 @@ OBJS-$(CONFIG_CDXL_DEMUXER)  += cdxl.o
 OBJS-$(CONFIG_CINE_DEMUXER)  += cinedec.o
 OBJS-$(CONFIG_CONCAT_DEMUXER)+= concatdec.o
 OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
+OBJS-$(CONFIG_CUE_DEMUXER)   += cuedec.o
 OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
 OBJS-$(CONFIG_DATA_MUXER)+= rawdec.o
 OBJS-$(CONFIG_DASH_MUXER)+= dashenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d490cc4..d062e35 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -100,6 +100,7 @@ void av_register_all(void)
 REGISTER_DEMUXER (CINE, cine);
 REGISTER_DEMUXER (CONCAT,   concat);
 REGISTER_MUXER   (CRC,  crc);
+REGISTER_DEMUXER (CUE,  cue);
 REGISTER_MUXER   (DASH, dash);
 REGISTER_MUXDEMUX(DATA, data);
 REGISTER_MUXDEMUX(DAUD, daud);
diff --git a/libavformat/cuedec.c b/libavformat/cuedec.c
new file mode 100644
index 000..8753937
--- /dev/null
+++ b/libavformat/cuedec.c
@@ -0,0 +1,204 @@
+/*
+ * Cue sheet demuxer
+ * Copyright (c) 2016 The FFmpeg Project
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Cue sheet demuxer
+ * @author Rodger Combs 
+ */
+
+#include "avformat.h"
+#include "internal.h"
+#include "subtitles.h"
+#include "url.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+
+typedef struct CueDemuxContext {
+AVClass *class;
+char *url;
+AVFormatContext *avf;
+} CueDemuxContext;
+
+static int cue_probe(AVProbeData *p)
+{
+const unsigned char *ptr = p->buf;
+
+if (AV_RB24(ptr) == 0xEFBBBF)
+ptr += 3;  /* skip UTF-8 BOM */
+while (*ptr && strncmp(ptr, "FILE ", 5))
+ptr += ff_subtitles_next_line(ptr);
+if (!strncmp(ptr, "FILE ", 5))
+return AVPROBE_SCORE_MAX - 5;
+return 0;
+}
+
+static char *get_token(char *in)
+{
+char *end;
+while (av_isspace(*in))
+in++;
+if (*in == '"') {
+in++;
+end = in + strcspn(in, "\"\n\t\r");
+} else {
+end = in + strcspn(in, " \n\t\r");
+}
+*end = '\0';
+return in;
+}
+
+static int cue_read_header(AVFormatContext *s)
+{
+int ret, i;
+CueDemuxContext *cue = s->priv_data;
+char line[4096], *ptr;
+AVDictionary **meta = &s->metadata;
+AVChapter *chap = NULL;
+while (ff_get_line(s->pb, line, sizeof(line))) {
+ptr = line;
+if (AV_RB24(ptr) == 0xEFBBBF)
+ptr += 3;  /* skip UTF-8 BOM */
+while (*ptr == ' ' || *ptr == '\t')
+ptr++;
+if (!strncmp(ptr, "REM ", 4)) {
+char *end = ptr + strcspn(ptr, "\r\n");
+*end = '\0';
+av_log(s, AV_LOG_INFO, "Comment: \"%s\"\n", ptr + 4);
+} else if (!strncmp(ptr, "TITLE ", 6)) {
+  

[FFmpeg-devel] [PATCH 3/5] lavf/segment: add option to segment by chapter

[Rodger Combs]

---
 doc/muxers.texi   |  6 +
 libavformat/segment.c | 65 +++
 libavformat/version.h |  2 +-
 3 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index c2ca0ba..adf853e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1293,6 +1293,12 @@ This option specifies to start a new segment whenever a 
reference
 stream key frame is found and the sequential number (starting from 0)
 of the frame is greater or equal to the next value in the list.
 
+@item segment_chapters @var{1|0}
+Split each chapter into its own segment. Metadata from the chapters
+will be written to the corresponding segments. If this option is selected
+and the filename contains tokens in the format @code{$varname$}, they
+will be replaced by the corresponding metadata values.
+
 @item segment_wrap @var{limit}
 Wrap around segment index once it reaches @var{limit}.
 
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 4c6c6d4..9c766a5 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -108,6 +108,8 @@ typedef struct SegmentContext {
 int frame_count;   ///< total number of reference frames
 int segment_frame_count; ///< number of reference frames in the segment
 
+int split_chapters;///< split on chapter markers
+
 int64_t time_delta;
 int  individual_header_trailer; /**< Set by a private option. */
 int  write_header_trailer; /**< Set by a private option. */
@@ -188,6 +190,43 @@ static int segment_mux_init(AVFormatContext *s)
 return 0;
 }
 
+static int replace_variables(AVFormatContext *oc)
+{
+char name[sizeof(oc->filename)];
+char *p = name;
+char *out = oc->filename;
+strncpy(name, oc->filename, sizeof(name));
+while (*p) {
+char c = *p++;
+if (c == '$') {
+if (*p == '$') {
+p++;
+goto append;
+} else {
+int len;
+const char *val;
+const AVDictionaryEntry *e;
+int end = strcspn(p, "$");
+if (p[end] == '\0')
+continue;
+p[end] = '\0';
+e = av_dict_get(oc->metadata, p, NULL, 0);
+val = e ? e->value : "(unknown)";
+len = strlen(val);
+strncpy(out, val, oc->filename + sizeof(oc->filename) - 1 - 
out);
+out = FFMIN(oc->filename + sizeof(oc->filename) - 1, out + 
len);
+p += end + 1;
+}
+} else {
+append:
+if (out - oc->filename < sizeof(oc->filename) - 1)
+*out++ = c;
+}
+}
+*out = '\0';
+return 0;
+}
+
 static int set_segment_filename(AVFormatContext *s)
 {
 SegmentContext *seg = s->priv_data;
@@ -212,6 +251,9 @@ static int set_segment_filename(AVFormatContext *s)
 return AVERROR(EINVAL);
 }
 
+if (seg->split_chapters)
+replace_variables(oc);
+
 /* copy modified name in list entry */
 size = strlen(av_basename(oc->filename)) + 1;
 if (seg->entry_prefix)
@@ -238,6 +280,8 @@ static int segment_start(AVFormatContext *s, int 
write_header)
 if ((err = segment_mux_init(s)) < 0)
 return err;
 oc = seg->avf;
+if (seg->split_chapters && seg->segment_count < s->nb_chapters && (err 
= av_dict_copy(&oc->metadata, s->chapters[seg->segment_count]->metadata, 0)) < 
0)
+return err;
 }
 
 seg->segment_idx++;
@@ -651,10 +695,14 @@ static int seg_init(AVFormatContext *s)
 seg->individual_header_trailer = 0;
 }
 
-if (!!seg->time_str + !!seg->times_str + !!seg->frames_str > 1) {
+if (seg->segment_idx < 0)
+seg->segment_idx = seg->split_chapters;
+
+if (!!seg->time_str + !!seg->times_str + !!seg->frames_str + 
!!seg->split_chapters > 1) {
 av_log(s, AV_LOG_ERROR,
-   "segment_time, segment_times, and segment_frames options "
-   "are mutually exclusive, select just one of them\n");
+   "segment_time, segment_times, segment_frames, and "
+   "segment_chapters options are mutually exclusive; "
+   "select just one of them\n");
 return AVERROR(EINVAL);
 }
 
@@ -664,7 +712,7 @@ static int seg_init(AVFormatContext *s)
 } else if (seg->frames_str) {
 if ((ret = parse_frames(s, &seg->frames, &seg->nb_frames, 
seg->frames_str)) < 0)
 return ret;
-} else {
+} else if (!seg->split_chapters) {
 /* set default value if not specified */
 if (!seg->time_str)
 seg->time_str = av_strdup("2");
@@ -734,6 +782,9 @@ static int seg_init(AVFormatContext *s)
 if ((ret = segment_mux_init(s)) < 0)
 goto fail;
 
+if (seg->split_chapters && s->nb_chapters && (ret = 
av_dict_copy(&seg->avf->metadata, s->chapters[0]->metadata, 0)) < 0)
+goto fail;
+
 if ((ret = set_segm

[FFmpeg-devel] [PATCH 5/5] lavf/segment: write attached pictures to all segments by default

[Rodger Combs]

---
 doc/muxers.texi   |  4 
 libavformat/segment.c | 33 +
 libavformat/version.h |  2 +-
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index adf853e..fe95cc6 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1331,6 +1331,10 @@ argument must be a time duration specification, and 
defaults to 0.
 If enabled, write an empty segment if there are no packets during the period a
 segment would usually span. Otherwise, the segment will be filled with the next
 packet written. Defaults to @code{0}.
+
+@item dup_attached_pics @var{1|0}
+If enabled, attached-picture packets will be written to all segments, rather
+than only the first. Defaults to @code{1}.
 @end table
 
 @subsection Examples
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 5aec018..a0857c9 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -121,6 +121,7 @@ typedef struct SegmentContext {
 int   reference_stream_index;
 int   break_non_keyframes;
 int   write_empty;
+int   dup_attached_pics;
 
 int use_rename;
 char temp_list_filename[1024];
@@ -128,6 +129,8 @@ typedef struct SegmentContext {
 SegmentListEntry cur_entry;
 SegmentListEntry *segment_list_entries;
 SegmentListEntry *segment_list_entries_end;
+
+AVPacket *attached_pics;
 } SegmentContext;
 
 static void print_csv_escaped_str(AVIOContext *ctx, const char *str)
@@ -303,12 +306,20 @@ static int segment_start(AVFormatContext *s, int 
write_header)
 av_opt_set(oc->priv_data, "mpegts_flags", "+resend_headers", 0);
 
 if (write_header) {
+int i;
 AVDictionary *options = NULL;
 av_dict_copy(&options, seg->format_options, 0);
 err = avformat_write_header(oc, &options);
 av_dict_free(&options);
 if (err < 0)
 return err;
+for (i = 0; i < s->nb_streams; i++) {
+if (seg->dup_attached_pics &&
+s->streams[i]->disposition & AV_DISPOSITION_ATTACHED_PIC &&
+seg->attached_pics[i].data) {
+av_write_frame(oc, &seg->attached_pics[i]);
+}
+}
 }
 
 seg->segment_frame_count = 0;
@@ -826,6 +837,11 @@ static int seg_init(AVFormatContext *s)
 avpriv_set_pts_info(outer_st, inner_st->pts_wrap_bits, 
inner_st->time_base.num, inner_st->time_base.den);
 }
 
+if (seg->dup_attached_pics && !(seg->attached_pics = 
av_calloc(s->nb_streams, sizeof(AVPacket {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
 if (oc->avoid_negative_ts > 0 && s->avoid_negative_ts < 0)
 s->avoid_negative_ts = 1;
 
@@ -864,6 +880,9 @@ static int seg_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (!seg->avf)
 return AVERROR(EINVAL);
 
+if (seg->dup_attached_pics && st->disposition & 
AV_DISPOSITION_ATTACHED_PIC)
+av_copy_packet(&seg->attached_pics[pkt->stream_index], pkt);
+
 calc_times:
 if (seg->times) {
 end_pts = seg->segment_count < seg->nb_times ?
@@ -1012,6 +1031,17 @@ fail:
 return ret;
 }
 
+static void seg_deinit(struct AVFormatContext *s)
+{
+SegmentContext *seg = s->priv_data;
+int i;
+if (seg->attached_pics) {
+for (i = 0; i < s->nb_streams; i++)
+av_packet_unref(&seg->attached_pics[i]);
+av_freep(&seg->attached_pics);
+}
+}
+
 static int seg_check_bitstream(struct AVFormatContext *s, const AVPacket *pkt)
 {
 SegmentContext *seg = s->priv_data;
@@ -1075,6 +1105,7 @@ static const AVOption options[] = {
 { "reset_timestamps", "reset timestamps at the begin of each segment", 
OFFSET(reset_timestamps), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, E },
 { "initial_offset", "set initial timestamp offset", 
OFFSET(initial_offset), AV_OPT_TYPE_DURATION, {.i64 = 0}, -INT64_MAX, 
INT64_MAX, E },
 { "write_empty_segments", "allow writing empty 'filler' segments", 
OFFSET(write_empty), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, E },
+{ "dup_attached_pics",  "write attached pictures to all segments", 
OFFSET(dup_attached_pics), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, E },
 { NULL },
 };
 
@@ -1093,6 +1124,7 @@ AVOutputFormat ff_segment_muxer = {
 .init   = seg_init,
 .write_packet   = seg_write_packet,
 .write_trailer  = seg_write_trailer,
+.deinit = seg_deinit,
 .check_bitstream = seg_check_bitstream,
 .priv_class = &seg_class,
 };
@@ -1112,6 +1144,7 @@ AVOutputFormat ff_stream_segment_muxer = {
 .init   = seg_init,
 .write_packet   = seg_write_packet,
 .write_trailer  = seg_write_trailer,
+.deinit = seg_deinit,
 .check_bitstream = seg_check_bitstream,
 .priv_class = &sseg_class,
 };
diff --git a/libavformat/version.h b/libavformat/version.h
index 1c398a4..badf95b 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
 // Also please add any ticket numbers that you bel

[FFmpeg-devel] [PATCH 2/5] lavf/flacenc: support writing attached pictures

[Rodger Combs]

---
 libavformat/flacenc.c | 253 +++---
 1 file changed, 218 insertions(+), 35 deletions(-)

diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
index 89b21e9..b7b3016 100644
--- a/libavformat/flacenc.c
+++ b/libavformat/flacenc.c
@@ -21,10 +21,13 @@
 
 #include "libavutil/channel_layout.h"
 #include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
 #include "libavcodec/flac.h"
 #include "avformat.h"
 #include "avio_internal.h"
 #include "flacenc.h"
+#include "id3v2.h"
+#include "internal.h"
 #include "vorbiscomment.h"
 #include "libavcodec/bytestream.h"
 
@@ -33,6 +36,12 @@ typedef struct FlacMuxerContext {
 const AVClass *class;
 int write_header;
 
+int audio_stream_idx;
+AVPacket *pics;
+int nb_pics, waiting_pics;
+/* audio packets are queued here until we get all the attached pictures */
+AVPacketList *queue, *queue_end;
+
 /* updated streaminfo sent by the encoder at the end */
 uint8_t *streaminfo;
 } FlacMuxerContext;
@@ -74,31 +83,138 @@ static int flac_write_block_comment(AVIOContext *pb, 
AVDictionary **m,
 return 0;
 }
 
-static int flac_write_header(struct AVFormatContext *s)
+static int flac_write_picture(struct AVFormatContext *s, AVPacket *pkt)
 {
-int ret;
-int padding = s->metadata_header_padding;
-AVCodecParameters *par = s->streams[0]->codecpar;
-FlacMuxerContext *c   = s->priv_data;
-
-if (!c->write_header)
+AVIOContext *pb = s->pb;
+const AVPixFmtDescriptor *pixdesc;
+const CodecMime *mime = ff_id3v2_mime_tags;
+AVDictionaryEntry *e;
+const char *mimetype = NULL, *desc = "";
+const AVStream *st = s->streams[pkt->stream_index];
+int i, mimelen, desclen, type = 0;
+
+if (!pkt->data)
 return 0;
 
-if (s->nb_streams > 1) {
-av_log(s, AV_LOG_ERROR, "only one stream is supported\n");
-return AVERROR(EINVAL);
+while (mime->id != AV_CODEC_ID_NONE) {
+if (mime->id == st->codecpar->codec_id) {
+mimetype = mime->str;
+break;
+}
+mime++;
 }
-if (par->codec_id != AV_CODEC_ID_FLAC) {
-av_log(s, AV_LOG_ERROR, "unsupported codec\n");
+if (!mimetype) {
+av_log(s, AV_LOG_ERROR, "No mimetype is known for stream %d, cannot "
+   "write an attached picture.\n", st->index);
 return AVERROR(EINVAL);
 }
+mimelen = strlen(mimetype);
+
+/* get the picture type */
+e = av_dict_get(st->metadata, "comment", NULL, 0);
+for (i = 0; e && i < FF_ARRAY_ELEMS(ff_id3v2_picture_types); i++) {
+if (!av_strcasecmp(e->value, ff_id3v2_picture_types[i])) {
+type = i;
+break;
+}
+}
+
+/* get the description */
+if ((e = av_dict_get(st->metadata, "title", NULL, 0)))
+desc = e->value;
+desclen = strlen(desc);
+
+avio_w8(pb, 0x06);
+avio_wb24(pb, 4 + 4 + mimelen + 4 + desclen + 4 + 4 + 4 + 4 + 4 + 
pkt->size);
+
+avio_wb32(pb, type);
+
+avio_wb32(pb, mimelen);
+avio_write(pb, mimetype, mimelen);
+
+avio_wb32(pb, desclen);
+avio_write(pb, desc, desclen);
 
+avio_wb32(pb, st->codecpar->width);
+avio_wb32(pb, st->codecpar->height);
+if ((pixdesc = av_pix_fmt_desc_get(st->codecpar->format)))
+avio_wb32(pb, av_get_bits_per_pixel(pixdesc));
+else
+avio_wb32(pb, 0);
+avio_wb32(pb, 0);
+
+avio_wb32(pb, pkt->size);
+avio_write(pb, pkt->data, pkt->size);
+return 0;
+}
+
+static int flac_finish_header(struct AVFormatContext *s)
+{
+FlacMuxerContext *c = s->priv_data;
+int i, ret, padding = s->metadata_header_padding;
 if (padding < 0)
 padding = 8192;
 /* The FLAC specification states that 24 bits are used to represent the
  * size of a metadata block so we must clip this value to 2^24-1. */
 padding = av_clip_uintp2(padding, 24);
 
+for (i = 0; i < c->nb_pics; i++) {
+ret = flac_write_picture(s, &c->pics[i]);
+if (ret)
+return ret;
+}
+
+ret = flac_write_block_comment(s->pb, &s->metadata, !padding,
+   s->flags & AVFMT_FLAG_BITEXACT);
+if (ret)
+return ret;
+
+/* The command line flac encoder defaults to placing a seekpoint
+ * every 10s.  So one might add padding to allow that later
+ * but there seems to be no simple way to get the duration here.
+ * So just add the amount requested by the user. */
+if (padding)
+flac_write_block_padding(s->pb, padding, 1);
+
+return 0;
+}
+
+static int flac_write_header(struct AVFormatContext *s)
+{
+int ret, i;
+AVCodecParameters *par;
+FlacMuxerContext *c = s->priv_data;
+
+c->audio_stream_idx = -1;
+for (i = 0; i < s->nb_streams; i++) {
+AVStream *st = s->streams[i];
+if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
+if (c->audio_stream_idx >= 0 || st->codecpar->codec_id != 
AV_C

[FFmpeg-devel] [PATCH 4/5] lavf/segment: copy stream dispositions in output

[Rodger Combs]

---
 libavformat/segment.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 9c766a5..5aec018 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -184,6 +184,7 @@ static int segment_mux_init(AVFormatContext *s)
 }
 st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio;
 st->time_base = s->streams[i]->time_base;
+st->disposition = s->streams[i]->disposition;
 av_dict_copy(&st->metadata, s->streams[i]->metadata, 0);
 }
 
-- 
2.9.0

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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

> $ ffmpeg -benchmark -f rawvideo -pix_fmt rgb24 
> -i /dev/zero -pix_fmt yuv420p -f null -vframes 1 -

This was missing an input resolution: -s hd1080
And 1000 frames should be enough.

Sorry, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

On Mon, 2016-07-04 at 16:30 +, Carl Eugen Hoyos wrote:
> Dan Parrot  mail.com> writes:
> 
> > > Did you test if using ffmpeg -benchmark -f rawvideo -i /dev/zero... 
> > > showed different results?
> > > I believe this should be both easier and faster to test.
> >
> > Sorry, I don't understand what that command line just above 
> > is trying to achieve. Could you elaborate?
> 
> Instead of running the whole fate suite that takes long and 
> does not test libswscale for most commands, just test an 
> ffmpeg command line that only tests libswscale:
> $ ffmpeg -benchmark -f rawvideo -pix_fmt rgb24 
> -i /dev/zero -pix_fmt yuv420p -f null -vframes 1 -
> vs
> 
> $ ffmpeg -cpuflags 0 -benchmark -f rawvideo -pix_fmt rgb24 
> -i /dev/zero -pix_fmt yuv420p -f null -vframes 1 -
> 
Ok. Thanks for the explanation. I will run those commands and post the
reported results.

> [...]
> 
> > Surprisingly, gcc is producing some badly suboptimal assembly.
> 
> Just to make sure I don't misunderstand:
> Does this mean intrinsics are suboptimal to write assembly 
> code?
Here's what I mean: All variables below are of type "vector int"

1. v0 = v2 * v3
2. v0 = v4 * v5 + v6 * v7 + v8 * v9

The first statement produces 1 multiply, 1 multiply-sum and 1 addition
instruction in assembly.

The second produces 6 multiply, 6 multiply-sum, and 10 addition
instructions in assembly! I expected 3, 3, 3 of each respective
operations from (1) plus 2 additions.

> 
> > > Can you confirm with START_TIMER / STOP_TIMER that there is no 
> > > gain?
> >
> > SystemTap probes provide identical functionality by measuring 
> > deltas between function entry and function return.
> 
> Sorry, I don't understand:
> Did you test with both methods to verify that they provide 
> the same results?
> 
> Note that if it turns out that START_TIMER / STOP_TIMER 
> cannot be used on ppc64 (le) this would be important 
> information for us.
> 
I'll insert these macros and inform of the results if the code compiles
and runs.


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

Re: [FFmpeg-devel] [PATCH 2/5] lavf/flacenc: support writing attached pictures

[James Almer]

On 7/4/2016 2:33 PM, Rodger Combs wrote:
> ---
>  libavformat/flacenc.c | 253 
> +++---
>  1 file changed, 218 insertions(+), 35 deletions(-)
> 

I sent a patch very much like this one a few years ago[1] and it was
blocked because i was asked for a common implementation of the audio
buffer code to be shared with mp3enc.
I don't think it's worth adding one just for these two muxers, so if
nobody complains this time then it should be good to go in.

[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2013-August/146869.html

> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c
> index 89b21e9..b7b3016 100644
> --- a/libavformat/flacenc.c
> +++ b/libavformat/flacenc.c
> @@ -21,10 +21,13 @@
>  
>  #include "libavutil/channel_layout.h"
>  #include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
>  #include "libavcodec/flac.h"
>  #include "avformat.h"
>  #include "avio_internal.h"
>  #include "flacenc.h"
> +#include "id3v2.h"
> +#include "internal.h"
>  #include "vorbiscomment.h"
>  #include "libavcodec/bytestream.h"
>  
> @@ -33,6 +36,12 @@ typedef struct FlacMuxerContext {
>  const AVClass *class;
>  int write_header;
>  
> +int audio_stream_idx;
> +AVPacket *pics;
> +int nb_pics, waiting_pics;
> +/* audio packets are queued here until we get all the attached pictures 
> */
> +AVPacketList *queue, *queue_end;
> +
>  /* updated streaminfo sent by the encoder at the end */
>  uint8_t *streaminfo;
>  } FlacMuxerContext;
> @@ -74,31 +83,138 @@ static int flac_write_block_comment(AVIOContext *pb, 
> AVDictionary **m,
>  return 0;
>  }
>  
> -static int flac_write_header(struct AVFormatContext *s)
> +static int flac_write_picture(struct AVFormatContext *s, AVPacket *pkt)
>  {
> -int ret;
> -int padding = s->metadata_header_padding;
> -AVCodecParameters *par = s->streams[0]->codecpar;
> -FlacMuxerContext *c   = s->priv_data;
> -
> -if (!c->write_header)
> +AVIOContext *pb = s->pb;
> +const AVPixFmtDescriptor *pixdesc;
> +const CodecMime *mime = ff_id3v2_mime_tags;
> +AVDictionaryEntry *e;
> +const char *mimetype = NULL, *desc = "";
> +const AVStream *st = s->streams[pkt->stream_index];
> +int i, mimelen, desclen, type = 0;
> +
> +if (!pkt->data)
>  return 0;
>  
> -if (s->nb_streams > 1) {
> -av_log(s, AV_LOG_ERROR, "only one stream is supported\n");
> -return AVERROR(EINVAL);
> +while (mime->id != AV_CODEC_ID_NONE) {
> +if (mime->id == st->codecpar->codec_id) {
> +mimetype = mime->str;
> +break;
> +}
> +mime++;
>  }
> -if (par->codec_id != AV_CODEC_ID_FLAC) {
> -av_log(s, AV_LOG_ERROR, "unsupported codec\n");
> +if (!mimetype) {
> +av_log(s, AV_LOG_ERROR, "No mimetype is known for stream %d, cannot "
> +   "write an attached picture.\n", st->index);
>  return AVERROR(EINVAL);
>  }
> +mimelen = strlen(mimetype);
> +
> +/* get the picture type */
> +e = av_dict_get(st->metadata, "comment", NULL, 0);
> +for (i = 0; e && i < FF_ARRAY_ELEMS(ff_id3v2_picture_types); i++) {
> +if (!av_strcasecmp(e->value, ff_id3v2_picture_types[i])) {
> +type = i;

There may only be one each of picture type 1 and 2 in a file, and
type 1 must be png.

https://xiph.org/flac/format.html#metadata_block_picture

> +break;
> +}
> +}
> +
> +/* get the description */
> +if ((e = av_dict_get(st->metadata, "title", NULL, 0)))
> +desc = e->value;
> +desclen = strlen(desc);
> +
> +avio_w8(pb, 0x06);
> +avio_wb24(pb, 4 + 4 + mimelen + 4 + desclen + 4 + 4 + 4 + 4 + 4 + 
> pkt->size);
> +
> +avio_wb32(pb, type);
> +
> +avio_wb32(pb, mimelen);
> +avio_write(pb, mimetype, mimelen);
> +
> +avio_wb32(pb, desclen);
> +avio_write(pb, desc, desclen);
>  
> +avio_wb32(pb, st->codecpar->width);
> +avio_wb32(pb, st->codecpar->height);
> +if ((pixdesc = av_pix_fmt_desc_get(st->codecpar->format)))
> +avio_wb32(pb, av_get_bits_per_pixel(pixdesc));
> +else
> +avio_wb32(pb, 0);

IMO, just don't mux gifs. Most players probably ignore this field
altogether, but it's not a good practice to mux files without
following the spec.

> +avio_wb32(pb, 0);
> +
> +avio_wb32(pb, pkt->size);
> +avio_write(pb, pkt->data, pkt->size);
> +return 0;
> +}
> +
> +static int flac_finish_header(struct AVFormatContext *s)
> +{
> +FlacMuxerContext *c = s->priv_data;
> +int i, ret, padding = s->metadata_header_padding;
>  if (padding < 0)
>  padding = 8192;
>  /* The FLAC specification states that 24 bits are used to represent the
>   * size of a metadata block so we must clip this value to 2^24-1. */
>  padding = av_clip_uintp2(padding, 24);
>  
> +for (i = 0; i < c->nb_pics; i++) {
> +ret = flac_write_picture(s, &c->pics[i]);
>

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

> > Just to make sure I don't misunderstand:
> > Does this mean intrinsics are suboptimal to write assembly 
> > code?
> Here's what I mean: All variables below are of type "vector int"
> 
> 1. v0 = v2 * v3
> 2. v0 = v4 * v5 + v6 * v7 + v8 * v9
> 
> The first statement produces 1 multiply, 1 multiply-sum and 1 addition
> instruction in assembly.
> 
> The second produces 6 multiply, 6 multiply-sum, and 10 addition
> instructions in assembly! I expected 3, 3, 3 of each respective
> operations from (1) plus 2 additions.

The operations counts given above were obtained using gcc 5.3.1 on
Fedora 22. I just created a simple test with those same statements and
compiled using gcc 6.1.1 on Fedora 24. The assembly operation counts are
what I had expected initially and more reasonable.

So, I'm going to move my ffmpeg development onto the Fedora 24 cloud
image and see if the SIMD performance there is better than was on Fedora
22. The reason I'm moving to Fedora 24 instead of trying to upgrade gcc
on Fedora 22 is that I've learned to prefer standard pre-installed
images to the wrecks I've managed to create doing my own sysadmin on the
POWER8 cloud.


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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Hendrik Leppkes]

On Mon, Jul 4, 2016 at 5:20 PM, Dan Parrot  wrote:
>> Why is this not faster?
> Surprisingly, gcc is producing some badly suboptimal assembly. I need to
> follow up with IBM's Linux Technology Center. The major issue is that
> multiplication of vector quantities in C is generating as many
> multiplications in assembly as would scalar multiplication in a loop. No
> way that should be occurring.
>

This is the reason why we generally don't allow intrinsic
optimizations and instead ask people to write full assembly instead.
It behaves more consistently everywhere.

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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

On Mon, 2016-07-04 at 20:55 +0200, Hendrik Leppkes wrote:
> On Mon, Jul 4, 2016 at 5:20 PM, Dan Parrot  wrote:
> >> Why is this not faster?
> > Surprisingly, gcc is producing some badly suboptimal assembly. I need to
> > follow up with IBM's Linux Technology Center. The major issue is that
> > multiplication of vector quantities in C is generating as many
> > multiplications in assembly as would scalar multiplication in a loop. No
> > way that should be occurring.
> >
> 
> This is the reason why we generally don't allow intrinsic
> optimizations and instead ask people to write full assembly instead.
> It behaves more consistently everywhere.

Is this then a requirement to abandon the use of intrinsics for PPC64
SIMD and instead re-implement in assembly?




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

[FFmpeg-devel] [PATCH] small fix in af_hdcd.c where gain was not bing adjusted for "attenuate slowly"

[Burt P]

Signed-off-by: Burt P 
---
 libavfilter/af_hdcd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 16bdcb0..92f3c9e 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -949,6 +949,7 @@ static int hdcd_envelope(int32_t *samples, int count, int 
stride, int gain, int
 int len = FFMIN(count, target_gain - gain);
 /* attenuate slowly */
 for (i = 0; i < len; i++) {
+++gain;
 APPLY_GAIN(*samples, gain);
 samples += stride;
 }
-- 
2.7.4

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

04.07.2016, 10:33, "Clément Bœsch" :
>  On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde  wrote:
>>   Hi,
>>
>>   https://bestpractices.coreinfrastructure.org/.
>>
>>   Thoughts on getting this done for FFmpeg?
>
>  Any thing we need to adjust in the project? I don't see much things to
>  change by looking at https://bestpractices.coreinfrastructure.org/projects/1


I could not either.
It was something I noticed a week back, judged low-hanging and of some benefit 
to the project.
I thus am willing to do it, provided there are no objections.

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Ronald S. Bultje]

Hi,

On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde  wrote:

> 04.07.2016, 10:33, "Clément Bœsch" :
> >  On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde 
> wrote:
> >>   Hi,
> >>
> >>   https://bestpractices.coreinfrastructure.org/.
> >>
> >>   Thoughts on getting this done for FFmpeg?
> >
> >  Any thing we need to adjust in the project? I don't see much things to
> >  change by looking at
> https://bestpractices.coreinfrastructure.org/projects/1
>
>
> I could not either.
> It was something I noticed a week back, judged low-hanging and of some
> benefit to the project.
> I thus am willing to do it, provided there are no objections.


I think if any changes are necessary to the website or documentation or
code, these would simply go through the relevant review process, right? Or
am I missing something?

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

04.07.2016, 15:36, "Ronald S. Bultje" :
> Hi,
>
> On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde  wrote:
>
>>  04.07.2016, 10:33, "Clément Bœsch" :
>>  > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde 
>>  wrote:
>>  >> Hi,
>>  >>
>>  >> https://bestpractices.coreinfrastructure.org/.
>>  >>
>>  >> Thoughts on getting this done for FFmpeg?
>>  >
>>  > Any thing we need to adjust in the project? I don't see much things to
>>  > change by looking at
>>  https://bestpractices.coreinfrastructure.org/projects/1
>>
>>  I could not either.
>>  It was something I noticed a week back, judged low-hanging and of some
>>  benefit to the project.
>>  I thus am willing to do it, provided there are no objections.
>
> I think if any changes are necessary to the website or documentation or
> code, these would simply go through the relevant review process, right? Or
> am I missing something?

True. At the moment, it seems like the relevant forms can be filled in directly 
from existing information,
and no changes are necessary.

I can send a screenshot of the filled out form before submitting if people want.

>
> Ronald
> ___
> 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] core infrastructure badge for FFmpeg

[Ronald S. Bultje]

Hi,

On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde  wrote:

>
>
> 04.07.2016, 15:36, "Ronald S. Bultje" :
> > Hi,
> >
> > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde 
> wrote:
> >
> >>  04.07.2016, 10:33, "Clément Bœsch" :
> >>  > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde 
> >>  wrote:
> >>  >> Hi,
> >>  >>
> >>  >> https://bestpractices.coreinfrastructure.org/.
> >>  >>
> >>  >> Thoughts on getting this done for FFmpeg?
> >>  >
> >>  > Any thing we need to adjust in the project? I don't see much things
> to
> >>  > change by looking at
> >>  https://bestpractices.coreinfrastructure.org/projects/1
> >>
> >>  I could not either.
> >>  It was something I noticed a week back, judged low-hanging and of some
> >>  benefit to the project.
> >>  I thus am willing to do it, provided there are no objections.
> >
> > I think if any changes are necessary to the website or documentation or
> > code, these would simply go through the relevant review process, right?
> Or
> > am I missing something?
>
> True. At the moment, it seems like the relevant forms can be filled in
> directly from existing information,
> and no changes are necessary.
>
> I can send a screenshot of the filled out form before submitting if people
> want.


Oh I see, I misunderstood. I personally don't have objections to that.

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

Re: [FFmpeg-devel] [PATCH]ffmpeg: Do not set too large bits_per_raw_sample

[Michael Niedermayer]

On Sun, May 01, 2016 at 05:11:08PM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch stops setting bits_per_raw_sample if it makes no sense as for 
> example in the wmall24 -> pcm_s16 case:
> Stream #0:0: Audio: pcm_s16le, 96000 Hz, stereo, s16 (24 bit), 3072 kb/s
> 
> Mostly tested with audio.
> 
> Please comment, Carl Eugen

>  ffmpeg.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 1a672d3fd9fe8e65d2ad9a4271fe5260a888e28a  patchrawsample.diff
> diff --git a/ffmpeg.c b/ffmpeg.c
> index adc3ff7..86bc518 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2859,7 +2859,6 @@ static int transcode_init(void)
>  dec_ctx = ist->dec_ctx;
>  
>  ost->st->disposition  = ist->st->disposition;
> -enc_ctx->bits_per_raw_sample= dec_ctx->bits_per_raw_sample;
>  enc_ctx->chroma_sample_location = 
> dec_ctx->chroma_sample_location;
>  } else {
>  for (j=0; jnb_streams; j++) {
> @@ -3100,6 +3099,9 @@ static int transcode_init(void)
>  switch (enc_ctx->codec_type) {
>  case AVMEDIA_TYPE_AUDIO:
>  enc_ctx->sample_fmt = 
> ost->filter->filter->inputs[0]->format;
> +if (dec_ctx)
> +enc_ctx->bits_per_raw_sample = 
> FFMIN(dec_ctx->bits_per_raw_sample,
> + 
> av_get_bytes_per_sample(enc_ctx->sample_fmt) << 3);
>  enc_ctx->sample_rate= 
> ost->filter->filter->inputs[0]->sample_rate;
>  enc_ctx->channel_layout = 
> ost->filter->filter->inputs[0]->channel_layout;
>  enc_ctx->channels   = 
> avfilter_link_get_channels(ost->filter->filter->inputs[0]);
> @@ -3140,6 +3142,9 @@ static int transcode_init(void)
> "Use -pix_fmt yuv420p for compatibility with 
> outdated media players.\n",
> 
> av_get_pix_fmt_name(ost->filter->filter->inputs[0]->format));
>  enc_ctx->pix_fmt = ost->filter->filter->inputs[0]->format;
> +if (dec_ctx)
> +enc_ctx->bits_per_raw_sample = 
> FFMIN(dec_ctx->bits_per_raw_sample,
> + 
> av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth);

these 2 are missing the stream copy case above


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

[FFmpeg-devel] [PATCH] Added Quadrox format

[smitbose]

---
 libavformat/riff.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/riff.c b/libavformat/riff.c
index 913b42d..2d54922 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -181,6 +181,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
 { AV_CODEC_ID_MJPEG,MKTAG('L', 'J', 'P', 'G') },
 { AV_CODEC_ID_MJPEG,MKTAG('d', 'm', 'b', '1') },
 { AV_CODEC_ID_MJPEG,MKTAG('m', 'j', 'p', 'a') },
+{ AV_CODEC_ID_MJPEG,MKTAG('J', 'R', '2', '4') }, /* Quadrox Mjpeg 
*/
 { AV_CODEC_ID_LJPEG,MKTAG('L', 'J', 'P', 'G') },
 /* Pegasus lossless JPEG */
 { AV_CODEC_ID_MJPEG,MKTAG('J', 'P', 'G', 'L') },
-- 
2.8.2

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Lou Logan]

On Mon, 04 Jul 2016 15:44:35 -0400, Ganesh Ajjanagadde wrote:

> True. At the moment, it seems like the relevant forms can be filled
> in directly from existing information, and no changes are necessary.

I didn't read all of the criteria [1], but if any changes are needed
feel free to send a patch of course.

> I can send a screenshot of the filled out form before submitting if
> people want.

I don't think that will be necessary. No objection from me either.

Thanks.

[1]

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

Re: [FFmpeg-devel] fate/pngdec : add test for rgba64 and interleaved rgb

[Michael Niedermayer]

On Sat, Jul 02, 2016 at 03:26:40PM +0200, Martin Vignali wrote:
> Hello,
> 
> In attach a patch to add fate test for png decoder for non interleaved
> rgba64
> and interleaved rgb
> 
> sample can be found here :
> https://we.tl/SNtjbUQqms
> 
> and need to be put inside ./fate-suite/png1
> 
> lena-rgba64.png is already in the fate samples but not used by image.mak
> 
> 
> Martin

>  fate/image.mak |5 -
>  ref/fate/png-int-rgb24 |6 ++
>  ref/fate/png-rgba64|6 ++
>  3 files changed, 16 insertions(+), 1 deletion(-)
> c03fa36fcf9ea04a6348d0873082e0ea91072bc2  
> 0001-fate-png-add-test-for-rgba64-and-interleaved-rgb.patch
> From 449ab70d87f4960c7e3cf015b173ab5466cc97e3 Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Sat, 2 Jul 2016 15:18:45 +0200
> Subject: [PATCH] fate/png : add test for rgba64 and interleaved rgb

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] fate/apng : add test for apng decoding

[Michael Niedermayer]

On Sat, Jul 02, 2016 at 05:49:57PM +0200, Martin Vignali wrote:
> 2016-07-02 16:50 GMT+02:00 James Almer :
> 
> > On 7/2/2016 11:12 AM, Martin Vignali wrote:
> > > Hello,
> > >
> > > In attach patch to add test for apng decoding
> > >
> > > based on these samples : http://littlesvr.ca/apng/samples.html
> > >
> > > can also be found here : https://we.tl/FNVAVl5dQs
> > >
> > > and need to be put inside ./fate-suite/apng (folder doesn't exist)
> > >
> > >
> > > Martin
> > >
> > >
> > > 0001-fate-apng-add-test-for-apng-decoding.patch
> > >
> > >
> > > From c7f7f7e945f5a1ffed76fe4e3f6a53523f1a2ba4 Mon Sep 17 00:00:00 2001
> > > From: Martin Vignali 
> > > Date: Sat, 2 Jul 2016 16:08:55 +0200
> > > Subject: [PATCH] fate/apng : add test for apng decoding
> > >
> > > ---
> > >  tests/Makefile  |  1 +
> > >  tests/ref/fate/apng-clock   | 45
> > +
> > >  tests/ref/fate/apng-osample | 11 +++
> > >  3 files changed, 57 insertions(+)
> > >  create mode 100644 tests/ref/fate/apng-clock
> > >  create mode 100644 tests/ref/fate/apng-osample
> > >
> > > diff --git a/tests/Makefile b/tests/Makefile
> > > index 019203c..895944d 100644
> > > --- a/tests/Makefile
> > > +++ b/tests/Makefile
> > > @@ -109,6 +109,7 @@ include $(SRC_PATH)/tests/fate/als.mak
> > >  include $(SRC_PATH)/tests/fate/amrnb.mak
> > >  include $(SRC_PATH)/tests/fate/amrwb.mak
> > >  include $(SRC_PATH)/tests/fate/api.mak
> > > +include $(SRC_PATH)/tests/fate/apng.mak
> >
> > You forgot to git add this file.
> >
> >
> > Sorry, new patch in attach
> 
> Martin

>  Makefile  |1 +
>  fate/apng.mak |   10 ++
>  ref/fate/apng-clock   |   45 +
>  ref/fate/apng-osample |   11 +++
>  4 files changed, 67 insertions(+)
> 4969cc4ebf6102c2366fb967ce7c524938ab3345  
> 0001-fate-apng-add-test-for-apng-decoding.patch
> From 7fcc33cf25b599399be4d06c2a260a440fff4c0d Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Sat, 2 Jul 2016 17:48:45 +0200
> Subject: [PATCH] fate/apng : add test for apng decoding

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

[FFmpeg-devel] [PATCH 0/6] dnxhr improvements

[Mark Reid]

hi,

I've been doing some work with dnxhr footage and would like to propose
adding separate codec id for it rather then using the dnxhd codec id.
The following patch series goes ahead and does that.

fate doesn't have a dnxhr mxf sample yet, so here is one.
https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/lb_uhd.mxf

The last patch also adds support for muxing apple quicktime compatible dnxhr 
mov files.
ffmpeg -i lb_uhd.mxf -vcodec copy out.mov
This should produce a mov that is playable in apple quicktime
provided you have avid le codecs installed.

Mark Reid (6):
  libavcodec/avcodec: add AV_CODEC_ID_DNXHR
  libavcodec/dnxhd: add dnxhr parser and decoder
  libavformat/dnxhd: add dnxhr probe and raw muxer
  libavformat/isom: use dnxhr codec id
  libavformat/mxf: add dnxhr codec ul
  libavformat/movenc: add dnxhr compatibility for apple players

 libavcodec/allcodecs.c|  2 ++
 libavcodec/avcodec.h  |  1 +
 libavcodec/codec_desc.c   |  7 +++
 libavcodec/dnxhd_parser.c |  7 +++
 libavcodec/dnxhddec.c | 14 ++
 libavcodec/version.h  |  2 +-
 libavformat/allformats.c  |  1 +
 libavformat/dnxhddec.c| 22 --
 libavformat/isom.c|  2 +-
 libavformat/movenc.c  | 34 +++---
 libavformat/mxf.c |  1 +
 libavformat/mxfdec.c  |  4 
 libavformat/rawenc.c  | 11 +++
 libavformat/version.h |  2 +-
 14 files changed, 94 insertions(+), 16 deletions(-)

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

[FFmpeg-devel] [PATCH 1/6] libavcodec/avcodec: add AV_CODEC_ID_DNXHR

[Mark Reid]

---
 libavcodec/avcodec.h| 1 +
 libavcodec/codec_desc.c | 7 +++
 libavcodec/version.h| 2 +-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 39713ed..df6a50e 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -386,6 +386,7 @@ enum AVCodecID {
 AV_CODEC_ID_DXV,
 AV_CODEC_ID_SCREENPRESSO,
 AV_CODEC_ID_RSCC,
+AV_CODEC_ID_DNXHR,
 
 AV_CODEC_ID_Y41P = 0x8000,
 AV_CODEC_ID_AVRP,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9d94b72..e0127aa 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -667,6 +667,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
 },
 {
+.id= AV_CODEC_ID_DNXHR,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "dnxhr",
+.long_name = NULL_IF_CONFIG_SMALL("DNxHR"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
+},
+{
 .id= AV_CODEC_ID_THP,
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "thp",
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 4f6423b..319becf 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVCODEC_VERSION_MAJOR  57
-#define LIBAVCODEC_VERSION_MINOR  48
+#define LIBAVCODEC_VERSION_MINOR  49
 #define LIBAVCODEC_VERSION_MICRO 101
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
-- 
2.7.3

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

[FFmpeg-devel] [PATCH 5/6] libavformat/mxf: add dnxhr codec ul

[Mark Reid]

---
 libavformat/mxf.c| 1 +
 libavformat/mxfdec.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index e9c48e8..db6ce7b 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -54,6 +54,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
 { { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x04,0x0A,0x00,0x00 
}, 14,AV_CODEC_ID_VC1 }, /* VC1 AP@L4 */
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x01,0x7F,0x00,0x00,0x00 
}, 13,   AV_CODEC_ID_RAWVIDEO }, /* uncompressed */
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x01,0x00 
}, 15,   AV_CODEC_ID_RAWVIDEO }, /* uncompressed 422 8-bit */
+{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x71,0x00,0x00,0x00 
}, 13,  AV_CODEC_ID_DNXHR }, /* DNxHR */
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x71,0x00,0x00,0x00 
}, 13,  AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x03,0x02,0x00,0x00 
}, 14,  AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,0x04,0x01,0x00 
}, 16,  AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD Legacy Avid Media Composer 
MXF */
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 0affca9..8f2f10a 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1098,6 +1098,10 @@ static int mxf_match_uid(const UID key, const UID uid, 
int len)
 static const MXFCodecUL *mxf_get_codec_ul(const MXFCodecUL *uls, UID *uid)
 {
 while (uls->uid[0]) {
+/* match version byte for dnxhr */
+if (uls->id == AV_CODEC_ID_DNXHR && !memcmp(uls->uid, *uid, 
uls->matching_len))
+break;
+
 if(mxf_match_uid(uls->uid, *uid, uls->matching_len))
 break;
 uls++;
-- 
2.7.3

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

[FFmpeg-devel] [PATCH 2/6] libavcodec/dnxhd: add dnxhr parser and decoder

[Mark Reid]

---
 libavcodec/allcodecs.c|  2 ++
 libavcodec/dnxhd_parser.c |  7 +++
 libavcodec/dnxhddec.c | 14 ++
 3 files changed, 23 insertions(+)

diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 54efaad..87196e2 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -158,6 +158,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(DFA,   dfa);
 REGISTER_DECODER(DIRAC, dirac);
 REGISTER_ENCDEC (DNXHD, dnxhd);
+REGISTER_DECODER(DNXHR, dnxhr);
 REGISTER_ENCDEC (DPX,   dpx);
 REGISTER_DECODER(DSICINVIDEO,   dsicinvideo);
 REGISTER_DECODER(DVAUDIO,   dvaudio);
@@ -656,6 +657,7 @@ void avcodec_register_all(void)
 REGISTER_PARSER(DCA,dca);
 REGISTER_PARSER(DIRAC,  dirac);
 REGISTER_PARSER(DNXHD,  dnxhd);
+REGISTER_PARSER(DNXHR,  dnxhr);
 REGISTER_PARSER(DPX,dpx);
 REGISTER_PARSER(DVAUDIO,dvaudio);
 REGISTER_PARSER(DVBSUB, dvbsub);
diff --git a/libavcodec/dnxhd_parser.c b/libavcodec/dnxhd_parser.c
index 033b8ee..312e994 100644
--- a/libavcodec/dnxhd_parser.c
+++ b/libavcodec/dnxhd_parser.c
@@ -113,3 +113,10 @@ AVCodecParser ff_dnxhd_parser = {
 .parser_parse   = dnxhd_parse,
 .parser_close   = ff_parse_close,
 };
+
+AVCodecParser ff_dnxhr_parser = {
+.codec_ids  = { AV_CODEC_ID_DNXHR },
+.priv_data_size = sizeof(DNXHDParserContext),
+.parser_parse   = dnxhd_parse,
+.parser_close   = ff_parse_close,
+};
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 1808080..4dde053 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -693,3 +693,17 @@ AVCodec ff_dnxhd_decoder = {
   AV_CODEC_CAP_SLICE_THREADS,
 .init_thread_copy = ONLY_IF_THREADS_ENABLED(dnxhd_decode_init_thread_copy),
 };
+
+AVCodec ff_dnxhr_decoder = {
+.name   = "dnxhr",
+.long_name  = NULL_IF_CONFIG_SMALL("DNxHR"),
+.type   = AVMEDIA_TYPE_VIDEO,
+.id = AV_CODEC_ID_DNXHR,
+.priv_data_size = sizeof(DNXHDContext),
+.init   = dnxhd_decode_init,
+.close  = dnxhd_decode_close,
+.decode = dnxhd_decode_frame,
+.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS |
+  AV_CODEC_CAP_SLICE_THREADS,
+.init_thread_copy = ONLY_IF_THREADS_ENABLED(dnxhd_decode_init_thread_copy),
+};
-- 
2.7.3

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

[FFmpeg-devel] [PATCH 4/6] libavformat/isom: use dnxhr codec id

[Mark Reid]

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

diff --git a/libavformat/isom.c b/libavformat/isom.c
index d412f06..e14d5af 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -246,7 +246,7 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
 
 { AV_CODEC_ID_DIRAC, MKTAG('d', 'r', 'a', 'c') },
 { AV_CODEC_ID_DNXHD, MKTAG('A', 'V', 'd', 'n') }, /* AVID DNxHD */
-{ AV_CODEC_ID_DNXHD, MKTAG('A', 'V', 'd', 'h') }, /* AVID DNxHR */
+{ AV_CODEC_ID_DNXHR, MKTAG('A', 'V', 'd', 'h') }, /* AVID DNxHR */
 { AV_CODEC_ID_H263,  MKTAG('H', '2', '6', '3') },
 { AV_CODEC_ID_MSMPEG4V3, MKTAG('3', 'I', 'V', 'D') }, /* 3ivx DivX Doctor 
*/
 { AV_CODEC_ID_RAWVIDEO,  MKTAG('A', 'V', '1', 'x') }, /* AVID 1:1x */
-- 
2.7.3

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

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

04.07.2016, 15:55, "Ronald S. Bultje" :
>  Hi,
>
>  On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde  wrote:
>
>>   04.07.2016, 15:36, "Ronald S. Bultje" :
>>   > Hi,
>>   >
>>   > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde 
>>   wrote:
>>   >
>>   >> 04.07.2016, 10:33, "Clément Bœsch" :
>>   >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde 
>>   >> wrote:
>>   >> >> Hi,
>>   >> >>
>>   >> >> https://bestpractices.coreinfrastructure.org/.
>>   >> >>
>>   >> >> Thoughts on getting this done for FFmpeg?
>>   >> >
>>   >> > Any thing we need to adjust in the project? I don't see much things
>>   to
>>   >> > change by looking at
>>   >> https://bestpractices.coreinfrastructure.org/projects/1
>>   >>
>>   >> I could not either.
>>   >> It was something I noticed a week back, judged low-hanging and of some
>>   >> benefit to the project.
>>   >> I thus am willing to do it, provided there are no objections.
>>   >
>>   > I think if any changes are necessary to the website or documentation or
>>   > code, these would simply go through the relevant review process, right?
>>   Or
>>   > am I missing something?
>>
>>   True. At the moment, it seems like the relevant forms can be filled in
>>   directly from existing information,
>>   and no changes are necessary.
>>
>>   I can send a screenshot of the filled out form before submitting if people
>>   want.
>
>  Oh I see, I misunderstood. I personally don't have objections to that.


Turns out that the first few pages are easy to fill and we already achieve them.
The last few are much harder, and FFmpeg does not currently meet all of them.

Here is the progress so far: 
https://bestpractices.coreinfrastructure.org/projects/235.

I have filled them to the best of my ability.
Here is a summary of where we fail to meet the criteria,
and some suggestions for what we could do.

The "MUST" constraints are the ones where FFmpeg needs to improve,
assuming the project wishes to get to 100%.

1. The project MUST have evidence that such tests are being added in the most 
recent major changes to the project.
Suggestion: enforce tests for all new filters, muxers, etc. At least 6 months 
back, this was not enforced for lavfi.

2. It is SUGGESTED that this policy on adding tests be documented in the 
instructions for change proposals.
Suggestion: Fix 1 above, and then make it unambiguous in the relevant docs.

3. It is SUGGESTED that projects be maximally strict with warnings, but this is 
not always practical.
Suggestion: don't bother, I have outlined the rationale on the page.

4. If the project software is an application or library, and its primary 
purpose is not to implement cryptography,
then it SHOULD only call on software specifically designed to implement 
cryptographic functions;
it SHOULD NOT re-implement its own. 
Note: This is one where I am personally interested as to why we fail; is it for 
performance reasons that we reimplement crypto?
Suggestion: No idea until I understand the above.

5. The project security mechanisms MUST use default keylengths that at least 
meet the NIST minimum requirements through the year 2030 (as stated in 2012).
Suggestion: add --enable-unsafe-crypt to configure, and by default not enable 
it.
Change API's and functions accordingly, document it.
Note: strictly speaking, per the sentence above, it is ok as we do not really 
have "default" keylengths.
But the extended rationale shows why we fail.

6. The default project security mechanisms MUST NOT depend on cryptographic 
algorithms that are broken
(e.g., MD4, MD5, single DES, RC4, or Dual_EC_DRBG).
Suggestion: same as 5 above.

7. The project security mechanisms SHOULD NOT by default depend on 
cryptographic algorithms with known serious weaknesses (e.g., SHA-1).
Suggestion: same as 5 above.

8. At least one static code analysis tool MUST be applied to any proposed major 
production release of the software before its release,
if there is at least one FLOSS tool that implements this criterion in the 
selected language.
Suggestion: force the use of coverity before release. AFAIK, we do not clean 
this up fully before releases.

9. All medium and high severity exploitable vulnerabilities discovered with 
static code analysis MUST be fixed in a timely way after they are confirmed.
Suggestion: this is related to 8, same idea.

10. It is SUGGESTED that static source code analysis occur on every commit or 
at least daily.
Suggestion: ignore, or if we have the resources and it is deemed worthy, get 
more regular coverity reports.

11. It is SUGGESTED that at least one dynamic analysis tool be applied to any 
proposed major production release of the software before its release.
Suggestion: agree upon some fuzzer, and run it on a variety of inputs before 
release. Can be a fate-fuzz.

12. It is SUGGESTED that if the software is application-level software written 
using a memory-unsafe language (e.g., C or C++)
then at least one dynamic tool (e.g., a fuzzer or web application scanner)
be

Re: [FFmpeg-devel] [PATCH 0/6] dnxhr improvements

[Rostislav Pehlivanov]

On 5 July 2016 at 02:06, Mark Reid  wrote:

> hi,
>
> I've been doing some work with dnxhr footage and would like to propose
> adding separate codec id for it rather then using the dnxhd codec id.
> The following patch series goes ahead and does that.
>
> fate doesn't have a dnxhr mxf sample yet, so here is one.
>
> https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/lb_uhd.mxf
>
> The last patch also adds support for muxing apple quicktime compatible
> dnxhr mov files.
> ffmpeg -i lb_uhd.mxf -vcodec copy out.mov
> This should produce a mov that is playable in apple quicktime
> provided you have avid le codecs installed.
>
> Mark Reid (6):
>   libavcodec/avcodec: add AV_CODEC_ID_DNXHR
>   libavcodec/dnxhd: add dnxhr parser and decoder
>   libavformat/dnxhd: add dnxhr probe and raw muxer
>   libavformat/isom: use dnxhr codec id
>   libavformat/mxf: add dnxhr codec ul
>   libavformat/movenc: add dnxhr compatibility for apple players
>
>  libavcodec/allcodecs.c|  2 ++
>  libavcodec/avcodec.h  |  1 +
>  libavcodec/codec_desc.c   |  7 +++
>  libavcodec/dnxhd_parser.c |  7 +++
>  libavcodec/dnxhddec.c | 14 ++
>  libavcodec/version.h  |  2 +-
>  libavformat/allformats.c  |  1 +
>  libavformat/dnxhddec.c| 22 --
>  libavformat/isom.c|  2 +-
>  libavformat/movenc.c  | 34 +++---
>  libavformat/mxf.c |  1 +
>  libavformat/mxfdec.c  |  4 
>  libavformat/rawenc.c  | 11 +++
>  libavformat/version.h |  2 +-
>  14 files changed, 94 insertions(+), 16 deletions(-)
>
> --
> 2.7.3
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Why would you want to have a separate codec ID for this? If it's handled by
the same decoder and there's not way to differentiate it outside the packet
it's pointless and makes things difficult for everyone else since they'd
have to treat it specially. Take a look at the Dirac decoder - it handles
both VC2 and regular Dirac files without having to have a separate codec ID.
As for muxing, the FOURCC codes and the mxf identifier for regular dnxhd
and dnxhr are identical so it's absolutely insane to have another codec id
for the sake of adding another codec id (also the lavc micro must be
bumped, on such, but that's another thing).
No point in treating dnxhr as special - it's simply not.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/6] libavformat/dnxhd: add dnxhr probe and raw muxer

[Mark Reid]

---
 libavformat/allformats.c |  1 +
 libavformat/dnxhddec.c   | 22 --
 libavformat/rawenc.c | 11 +++
 libavformat/version.h|  2 +-
 4 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d490cc4..0ee3b85 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -107,6 +107,7 @@ void av_register_all(void)
 REGISTER_DEMUXER (DFA,  dfa);
 REGISTER_MUXDEMUX(DIRAC,dirac);
 REGISTER_MUXDEMUX(DNXHD,dnxhd);
+REGISTER_MUXDEMUX(DNXHR,dnxhr);
 REGISTER_DEMUXER (DSF,  dsf);
 REGISTER_DEMUXER (DSICIN,   dsicin);
 REGISTER_DEMUXER (DSS,  dss);
diff --git a/libavformat/dnxhddec.c b/libavformat/dnxhddec.c
index 48c890d..081daaa 100644
--- a/libavformat/dnxhddec.c
+++ b/libavformat/dnxhddec.c
@@ -25,12 +25,13 @@
 #include "rawdec.h"
 #include "libavcodec/dnxhddata.h"
 
-static int dnxhd_probe(AVProbeData *p)
+static uint64_t dnxhd_probe_header(AVProbeData *p)
 {
 int w, h, compression_id;
+uint64_t header_prefix;
 if (p->buf_size < 0x2c)
 return 0;
-if (avpriv_dnxhd_parse_header_prefix(p->buf) == 0)
+if ((header_prefix = avpriv_dnxhd_parse_header_prefix(p->buf)) == 0)
 return 0;
 h = AV_RB16(p->buf + 0x18);
 w = AV_RB16(p->buf + 0x1a);
@@ -40,7 +41,24 @@ static int dnxhd_probe(AVProbeData *p)
 if ((compression_id < 1235 || compression_id > 1260) &&
 (compression_id < 1270 || compression_id > 1274))
 return 0;
+return header_prefix;
+}
+
+static int dnxhd_probe(AVProbeData *p)
+{
+  uint64_t header_prefix = dnxhd_probe_header(p);
+  if(header_prefix == DNXHD_HEADER_INITIAL || header_prefix == 
DNXHD_HEADER_444)
+return AVPROBE_SCORE_MAX;
+  return 0;
+}
+
+static int dnxhr_probe(AVProbeData *p)
+{
+  uint64_t header_prefix = dnxhd_probe_header(p);
+  if(header_prefix == DNXHD_HEADER_HR1 || header_prefix == DNXHD_HEADER_HR2)
 return AVPROBE_SCORE_MAX;
+  return 0;
 }
 
 FF_DEF_RAWVIDEO_DEMUXER(dnxhd, "raw DNxHD (SMPTE VC-3)", dnxhd_probe, NULL, 
AV_CODEC_ID_DNXHD)
+FF_DEF_RAWVIDEO_DEMUXER(dnxhr, "raw DNxHR", dnxhr_probe, NULL, 
AV_CODEC_ID_DNXHR)
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 4b8b41c..271400d 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -135,6 +135,17 @@ AVOutputFormat ff_dnxhd_muxer = {
 .write_packet  = ff_raw_write_packet,
 .flags = AVFMT_NOTIMESTAMPS,
 };
+
+AVOutputFormat ff_dnxhr_muxer = {
+.name  = "dnxhr",
+.long_name = NULL_IF_CONFIG_SMALL("raw DNxHR"),
+.extensions= "dnxhr",
+.audio_codec   = AV_CODEC_ID_NONE,
+.video_codec   = AV_CODEC_ID_DNXHR,
+.write_header  = force_one_stream,
+.write_packet  = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+};
 #endif
 
 #if CONFIG_DTS_MUXER
diff --git a/libavformat/version.h b/libavformat/version.h
index 47a8afb..3921ee5 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you belive might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  57
-#define LIBAVFORMAT_VERSION_MINOR  41
+#define LIBAVFORMAT_VERSION_MINOR  42
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
-- 
2.7.3

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

[FFmpeg-devel] [PATCH 6/6] libavformat/movenc: add dnxhr compatibility for apple players

[Mark Reid]

---
 libavformat/movenc.c | 34 +++---
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d614933..e97fb74 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -32,6 +32,7 @@
 #include "isom.h"
 #include "avc.h"
 #include "libavcodec/ac3_parser.h"
+#include "libavcodec/dnxhddata.h"
 #include "libavcodec/get_bits.h"
 #include "libavcodec/put_bits.h"
 #include "libavcodec/vc1_common.h"
@@ -1070,20 +1071,16 @@ static int mov_write_avid_tag(AVIOContext *pb, MOVTrack 
*track)
 int cid;
 
 if (track->vos_data && track->vos_len > 0x29) {
-if (track->vos_data[0] == 0x00 &&
-track->vos_data[1] == 0x00 &&
-track->vos_data[2] == 0x02 &&
-track->vos_data[3] == 0x80 &&
-(track->vos_data[4] == 0x01 || track->vos_data[4] == 0x02)) {
+if (avpriv_dnxhd_parse_header_prefix(track->vos_data) != 0) {
 /* looks like a DNxHD bit stream */
 interlaced = (track->vos_data[5] & 2);
 cid = AV_RB32(track->vos_data + 0x28);
 } else {
-av_log(NULL, AV_LOG_WARNING, "Could not locate DNxHD bit stream in 
vos_data\n");
+av_log(NULL, AV_LOG_WARNING, "Could not locate DNxHD/HR bit stream 
in vos_data\n");
 return 0;
 }
 } else {
-av_log(NULL, AV_LOG_WARNING, "Could not locate DNxHD bit stream, 
vos_data too small\n");
+av_log(NULL, AV_LOG_WARNING, "Could not locate DNxHD/HR bit stream, 
vos_data too small\n");
 return 0;
 }
 
@@ -1099,6 +1096,17 @@ static int mov_write_avid_tag(AVIOContext *pb, MOVTrack 
*track)
 }
 avio_wb32(pb, 0); /* unknown */
 
+if (track->par->codec_id == AV_CODEC_ID_DNXHR) {
+avio_wb32(pb, 32);
+ffio_wfourcc(pb, "ADHR");
+ffio_wfourcc(pb, "0001");
+avio_wb32(pb, cid);
+avio_wb32(pb, 0); /* unknown */
+avio_wb32(pb, 1); /* unknown */
+avio_wb32(pb, 0); /* unknown */
+avio_wb32(pb, 0); /* unknown */
+return 0;
+}
 avio_wb32(pb, 24); /* size */
 ffio_wfourcc(pb, "APRG");
 ffio_wfourcc(pb, "APRG");
@@ -1112,6 +1120,7 @@ static int mov_write_avid_tag(AVIOContext *pb, MOVTrack 
*track)
 ffio_wfourcc(pb, "0001");
 avio_wb32(pb, cid); /* dnxhd cid, some id ? */
 avio_wb32(pb, track->par->width);
+
 /* values below are based on samples created with quicktime and avid 
codecs */
 if (interlaced) {
 avio_wb32(pb, track->par->height / 2);
@@ -1763,7 +1772,7 @@ static int mov_write_video_tag(AVIOContext *pb, 
MOVMuxContext *mov, MOVTrack *tr
 track->par->codec_id == AV_CODEC_ID_SVQ3) {
 mov_write_extradata_tag(pb, track);
 avio_wb32(pb, 0);
-} else if (track->par->codec_id == AV_CODEC_ID_DNXHD) {
+} else if (track->par->codec_id == AV_CODEC_ID_DNXHD || 
track->par->codec_id == AV_CODEC_ID_DNXHR) {
 mov_write_avid_tag(pb, track);
 avid = 1;
 } else if (track->par->codec_id == AV_CODEC_ID_HEVC)
@@ -1788,7 +1797,8 @@ static int mov_write_video_tag(AVIOContext *pb, 
MOVMuxContext *mov, MOVTrack *tr
 
 if (track->par->codec_id != AV_CODEC_ID_H264 &&
 track->par->codec_id != AV_CODEC_ID_MPEG4 &&
-track->par->codec_id != AV_CODEC_ID_DNXHD) {
+track->par->codec_id != AV_CODEC_ID_DNXHD &&
+track->par->codec_id != AV_CODEC_ID_DNXHR) {
 int field_order = track->par->field_order;
 
 #if FF_API_LAVF_AVCTX
@@ -4666,7 +4676,7 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
 /* copy extradata if it exists */
 if (trk->vos_len == 0 && par->extradata_size > 0 &&
 !TAG_IS_AVCI(trk->tag) &&
-(par->codec_id != AV_CODEC_ID_DNXHD)) {
+(par->codec_id != AV_CODEC_ID_DNXHD || par->codec_id != 
AV_CODEC_ID_DNXHR)) {
 trk->vos_len  = par->extradata_size;
 trk->vos_data = av_malloc(trk->vos_len);
 if (!trk->vos_data) {
@@ -4740,6 +4750,7 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
 }
 
 if ((par->codec_id == AV_CODEC_ID_DNXHD ||
+ par->codec_id == AV_CODEC_ID_DNXHR ||
  par->codec_id == AV_CODEC_ID_AC3) && !trk->vos_len) {
 /* copy frame to create needed atoms */
 trk->vos_len  = size;
@@ -5626,7 +5637,8 @@ static int mov_write_header(AVFormatContext *s)
 if (st->codecpar->extradata_size) {
 if (st->codecpar->codec_id == AV_CODEC_ID_DVD_SUBTITLE)
 mov_create_dvd_sub_decoder_specific_info(track, st);
-else if (!TAG_IS_AVCI(track->tag) && st->codecpar->codec_id != 
AV_CODEC_ID_DNXHD) {
+else if (!TAG_IS_AVCI(track->tag) && (st->codecpar->codec_id != 
AV_CODEC_ID_DNXHD ||
+  st->codecpar->codec_id != 
AV_CODEC_ID_DNXHR)) {
 track->vos_len  = st->codecpar->extradata_size;
 track->vos_data

Re: [FFmpeg-devel] [PATCH 0/6] dnxhr improvements

[Rostislav Pehlivanov]

On 5 July 2016 at 02:20, Rostislav Pehlivanov  wrote:

>
>
> On 5 July 2016 at 02:06, Mark Reid  wrote:
>
>> hi,
>>
>> I've been doing some work with dnxhr footage and would like to propose
>> adding separate codec id for it rather then using the dnxhd codec id.
>> The following patch series goes ahead and does that.
>>
>> fate doesn't have a dnxhr mxf sample yet, so here is one.
>>
>> https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/lb_uhd.mxf
>>
>> The last patch also adds support for muxing apple quicktime compatible
>> dnxhr mov files.
>> ffmpeg -i lb_uhd.mxf -vcodec copy out.mov
>> This should produce a mov that is playable in apple quicktime
>> provided you have avid le codecs installed.
>>
>> Mark Reid (6):
>>   libavcodec/avcodec: add AV_CODEC_ID_DNXHR
>>   libavcodec/dnxhd: add dnxhr parser and decoder
>>   libavformat/dnxhd: add dnxhr probe and raw muxer
>>   libavformat/isom: use dnxhr codec id
>>   libavformat/mxf: add dnxhr codec ul
>>   libavformat/movenc: add dnxhr compatibility for apple players
>>
>>  libavcodec/allcodecs.c|  2 ++
>>  libavcodec/avcodec.h  |  1 +
>>  libavcodec/codec_desc.c   |  7 +++
>>  libavcodec/dnxhd_parser.c |  7 +++
>>  libavcodec/dnxhddec.c | 14 ++
>>  libavcodec/version.h  |  2 +-
>>  libavformat/allformats.c  |  1 +
>>  libavformat/dnxhddec.c| 22 --
>>  libavformat/isom.c|  2 +-
>>  libavformat/movenc.c  | 34 +++---
>>  libavformat/mxf.c |  1 +
>>  libavformat/mxfdec.c  |  4 
>>  libavformat/rawenc.c  | 11 +++
>>  libavformat/version.h |  2 +-
>>  14 files changed, 94 insertions(+), 16 deletions(-)
>>
>> --
>> 2.7.3
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Why would you want to have a separate codec ID for this? If it's handled
> by the same decoder and there's not way to differentiate it outside the
> packet it's pointless and makes things difficult for everyone else since
> they'd have to treat it specially. Take a look at the Dirac decoder - it
> handles both VC2 and regular Dirac files without having to have a separate
> codec ID.
> As for muxing, the FOURCC codes and the mxf identifier for regular dnxhd
> and dnxhr are identical so it's absolutely insane to have another codec id
> for the sake of adding another codec id (also the lavc micro must be
> bumped, on such, but that's another thing).
> No point in treating dnxhr as special - it's simply not.
>

Just saw the rest of the patches.
If you want to treat it dnxhr as special for the mov muxer you could
probably add dnxhr as a profile to the dnxhd code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

On Mon, 2016-07-04 at 16:30 +, Carl Eugen Hoyos wrote:
> Dan Parrot  mail.com> writes:
> 
> > > Did you test if using ffmpeg -benchmark -f rawvideo -i /dev/zero... 
> > > showed different results?
> > > I believe this should be both easier and faster to test.
> >
> > Sorry, I don't understand what that command line just above 
> > is trying to achieve. Could you elaborate?
> 
> Instead of running the whole fate suite that takes long and 
> does not test libswscale for most commands, just test an 
> ffmpeg command line that only tests libswscale:
> $ ffmpeg -benchmark -f rawvideo -pix_fmt rgb24 
> -i /dev/zero -pix_fmt yuv420p -f null -vframes 1 -
$ ./ffmpeg -benchmark -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero
-pix_fmt yuv420p -f null -vframes 1000 -

frame= 1000 fps= 16 q=-0.0 Lsize=N/A time=00:00:40.00 bitrate=N/A
speed=0.632x
video:477kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=62.794s
bench: maxrss=21184kB


> vs
> 
> $ ffmpeg -cpuflags 0 -benchmark -f rawvideo -pix_fmt rgb24 
> -i /dev/zero -pix_fmt yuv420p -f null -vframes 1 -

$ ./ffmpeg -cpuflags 0 -benchmark -f rawvideo -pix_fmt rgb24 -s hd1080
-i /dev/zero -pix_fmt yuv420p -f null -vframes 1000 -

frame= 1000 fps= 12 q=-0.0 Lsize=N/A time=00:00:40.00 bitrate=N/A
speed=0.479x
video:477kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=82.918s
bench: maxrss=21120kB

> [...]
> 
> > Surprisingly, gcc is producing some badly suboptimal assembly.
> 
> Just to make sure I don't misunderstand:
> Does this mean intrinsics are suboptimal to write assembly 
> code?
So, the latest version of GCC does produce more efficient assembly.

To recap: GCC 5.3.1 produces assembly that does not take full advantage
of PPC64 POWER8 SIMD instructions. GCC 6.1.1 is much better and produces
shorter sequences that do use SIMD assembly instructions.

> > > Can you confirm with START_TIMER / STOP_TIMER that there is no 
> > > gain?
> >
> > SystemTap probes provide identical functionality by measuring 
> > deltas between function entry and function return.
> 
> Sorry, I don't understand:
> Did you test with both methods to verify that they provide 
> the same results?

> Note that if it turns out that START_TIMER / STOP_TIMER 
> cannot be used on ppc64 (le) this would be important 
> information for us.
These start/stop macros are the last issue I have outstanding. I hope to
be done in a few hours.


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

Re: [FFmpeg-devel] [PATCH 0/6] dnxhr improvements

[Mark Reid]

On Mon, Jul 4, 2016 at 6:37 PM, Rostislav Pehlivanov
 wrote:
> On 5 July 2016 at 02:20, Rostislav Pehlivanov  wrote:
>
>>
>>
>> On 5 July 2016 at 02:06, Mark Reid  wrote:
>>
>>> hi,
>>>
>>> I've been doing some work with dnxhr footage and would like to propose
>>> adding separate codec id for it rather then using the dnxhd codec id.
>>> The following patch series goes ahead and does that.
>>>
>>> fate doesn't have a dnxhr mxf sample yet, so here is one.
>>>
>>> https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/lb_uhd.mxf
>>>
>>> The last patch also adds support for muxing apple quicktime compatible
>>> dnxhr mov files.
>>> ffmpeg -i lb_uhd.mxf -vcodec copy out.mov
>>> This should produce a mov that is playable in apple quicktime
>>> provided you have avid le codecs installed.
>>>
>>> Mark Reid (6):
>>>   libavcodec/avcodec: add AV_CODEC_ID_DNXHR
>>>   libavcodec/dnxhd: add dnxhr parser and decoder
>>>   libavformat/dnxhd: add dnxhr probe and raw muxer
>>>   libavformat/isom: use dnxhr codec id
>>>   libavformat/mxf: add dnxhr codec ul
>>>   libavformat/movenc: add dnxhr compatibility for apple players
>>>
>>>  libavcodec/allcodecs.c|  2 ++
>>>  libavcodec/avcodec.h  |  1 +
>>>  libavcodec/codec_desc.c   |  7 +++
>>>  libavcodec/dnxhd_parser.c |  7 +++
>>>  libavcodec/dnxhddec.c | 14 ++
>>>  libavcodec/version.h  |  2 +-
>>>  libavformat/allformats.c  |  1 +
>>>  libavformat/dnxhddec.c| 22 --
>>>  libavformat/isom.c|  2 +-
>>>  libavformat/movenc.c  | 34 +++---
>>>  libavformat/mxf.c |  1 +
>>>  libavformat/mxfdec.c  |  4 
>>>  libavformat/rawenc.c  | 11 +++
>>>  libavformat/version.h |  2 +-
>>>  14 files changed, 94 insertions(+), 16 deletions(-)
>>>
>>> --
>>> 2.7.3
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>> Why would you want to have a separate codec ID for this? If it's handled
>> by the same decoder and there's not way to differentiate it outside the
>> packet it's pointless and makes things difficult for everyone else since
>> they'd have to treat it specially. Take a look at the Dirac decoder - it
>> handles both VC2 and regular Dirac files without having to have a separate
>> codec ID.
>> As for muxing, the FOURCC codes and the mxf identifier for regular dnxhd
>> and dnxhr are identical so it's absolutely insane to have another codec id
>> for the sake of adding another codec id (also the lavc micro must be
>> bumped, on such, but that's another thing).
>> No point in treating dnxhr as special - it's simply not.
>>

Thanks for the quick feedback. I was a little hesitant on submitting
this for precisely that reason.

>
> Just saw the rest of the patches.
> If you want to treat it dnxhr as special for the mov muxer you could
> probably add dnxhr as a profile to the dnxhd code.

that sounds like a much better solution. I'll give that a go and
submit a new patch. thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] core infrastructure badge for FFmpeg

[Ronald S. Bultje]

Hi,

On Mon, Jul 4, 2016 at 9:15 PM, Ganesh Ajjanagadde  wrote:

> 04.07.2016, 15:55, "Ronald S. Bultje" :
> >  Hi,
> >
> >  On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde 
> wrote:
> >
> >>   04.07.2016, 15:36, "Ronald S. Bultje" :
> >>   > Hi,
> >>   >
> >>   > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde <
> gajja...@mit.edu>
> >>   wrote:
> >>   >
> >>   >> 04.07.2016, 10:33, "Clément Bœsch" :
> >>   >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde  >
> >>   >> wrote:
> >>   >> >> Hi,
> >>   >> >>
> >>   >> >> https://bestpractices.coreinfrastructure.org/.
> >>   >> >>
> >>   >> >> Thoughts on getting this done for FFmpeg?
> >>   >> >
> >>   >> > Any thing we need to adjust in the project? I don't see much
> things
> >>   to
> >>   >> > change by looking at
> >>   >> https://bestpractices.coreinfrastructure.org/projects/1
> >>   >>
> >>   >> I could not either.
> >>   >> It was something I noticed a week back, judged low-hanging and of
> some
> >>   >> benefit to the project.
> >>   >> I thus am willing to do it, provided there are no objections.
> >>   >
> >>   > I think if any changes are necessary to the website or
> documentation or
> >>   > code, these would simply go through the relevant review process,
> right?
> >>   Or
> >>   > am I missing something?
> >>
> >>   True. At the moment, it seems like the relevant forms can be filled in
> >>   directly from existing information,
> >>   and no changes are necessary.
> >>
> >>   I can send a screenshot of the filled out form before submitting if
> people
> >>   want.
> >
> >  Oh I see, I misunderstood. I personally don't have objections to that.
>
>
> Turns out that the first few pages are easy to fill and we already achieve
> them.
> The last few are much harder, and FFmpeg does not currently meet all of
> them.
>
> Here is the progress so far:
> https://bestpractices.coreinfrastructure.org/projects/235.
>
> I have filled them to the best of my ability.
> Here is a summary of where we fail to meet the criteria,
> and some suggestions for what we could do.
>
[..]

> 4. If the project software is an application or library, and its primary
> purpose is not to implement cryptography,
> then it SHOULD only call on software specifically designed to implement
> cryptographic functions;
> it SHOULD NOT re-implement its own.
> Note: This is one where I am personally interested as to why we fail; is
> it for performance reasons that we reimplement crypto?
> Suggestion: No idea until I understand the above.
>
> 5. The project security mechanisms MUST use default keylengths that at
> least meet the NIST minimum requirements through the year 2030 (as stated
> in 2012).
> Suggestion: add --enable-unsafe-crypt to configure, and by default not
> enable it.
> Change API's and functions accordingly, document it.
> Note: strictly speaking, per the sentence above, it is ok as we do not
> really have "default" keylengths.
> But the extended rationale shows why we fail.
>
> 6. The default project security mechanisms MUST NOT depend on
> cryptographic algorithms that are broken
> (e.g., MD4, MD5, single DES, RC4, or Dual_EC_DRBG).
> Suggestion: same as 5 above.


We don't use any of these for security purposes, we only use them for
checking frame hashes in automated tests. That should be totally fine.

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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

> > > > Can you confirm with START_TIMER / STOP_TIMER that there is no 
> > > > gain?
> > >
> > > SystemTap probes provide identical functionality by measuring 
> > > deltas between function entry and function return.
> > 
> > Sorry, I don't understand:
> > Did you test with both methods to verify that they provide 
> > the same results?
> > 
> > Note that if it turns out that START_TIMER / STOP_TIMER 
> > cannot be used on ppc64 (le) this would be important 
> > information for us.
> > 
> I'll insert these macros and inform of the results if the code compiles
> and runs.

These results for START_TIMER/STOP_TIMER are with ffmpeg compiled using
GCC 6.1.1

==
Existing non-SIMD version:

./ffmpeg -report -cpuflags 0 -benchmark -f rawvideo -pix_fmt rgb24 -s
hd1080 -i /dev/zero -pix_fmt yuv420p -f null -vframes 1000 -

  33770 UNITS in rgb24ToY_c,   1 runs,  0 skips
  33430 UNITS in rgb24ToY_c,   2 runs,  0 skips
  33292 UNITS in rgb24ToY_c,   4 runs,  0 skips
  33128 UNITS in rgb24ToY_c,   8 runs,  0 skips
  32848 UNITS in rgb24ToY_c,  16 runs,  0 skips
  32347 UNITS in rgb24ToY_c,  32 runs,  0 skips
  31831 UNITS in rgb24ToY_c,  64 runs,  0 skips
  31594 UNITS in rgb24ToY_c, 128 runs,  0 skips
  31513 UNITS in rgb24ToY_c, 256 runs,  0 skips
  31628 UNITS in rgb24ToY_c, 512 runs,  0 skips
  31466 UNITS in rgb24ToY_c,1024 runs,  0 skips
  31390 UNITS in rgb24ToY_c,2048 runs,  0 skips
  31411 UNITS in rgb24ToY_c,4096 runs,  0 skips
  31411 UNITS in rgb24ToY_c,8192 runs,  0 skipstrate=N/A
speed=0.522x
  31399 UNITS in rgb24ToY_c,   16384 runs,  0 skipstrate=N/A
speed=0.486x
  31416 UNITS in rgb24ToY_c,   32763 runs,  5 skipstrate=N/A
speed=0.467x
  31413 UNITS in rgb24ToY_c,   65530 runs,  6 skipstrate=N/A
speed=0.458x
  31421 UNITS in rgb24ToY_c,  131064 runs,  8 skipstrate=N/A
speed=0.454x
  31430 UNITS in rgb24ToY_c,  262131 runs, 13 skipstrate=N/A
speed=0.449x
  31422 UNITS in rgb24ToY_c,  524264 runs, 24 skipstrate=N/A
speed=0.449x
  31424 UNITS in rgb24ToY_c, 1048532 runs, 44 skipstrate=N/A
speed=0.45x 
frame= 1000 fps= 11 q=-0.0 Lsize=N/A time=00:00:40.00 bitrate=N/A
speed=0.449x
video:477kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=88.212s
bench: maxrss=21120kB
--
./ffmpeg -report -benchmark -f rawvideo -pix_fmt rgb24 -s hd1080
-i /dev/zero -pix_fmt yuv420p -f null -vframes 1000 -

  35440 UNITS in rgb24ToY_c,   1 runs,  0 skips
  34290 UNITS in rgb24ToY_c,   2 runs,  0 skips
  33670 UNITS in rgb24ToY_c,   4 runs,  0 skips
  33387 UNITS in rgb24ToY_c,   8 runs,  0 skips
  32786 UNITS in rgb24ToY_c,  16 runs,  0 skips
  32317 UNITS in rgb24ToY_c,  32 runs,  0 skips
  32008 UNITS in rgb24ToY_c,  64 runs,  0 skips
  31944 UNITS in rgb24ToY_c, 128 runs,  0 skips
  32049 UNITS in rgb24ToY_c, 256 runs,  0 skips
  31913 UNITS in rgb24ToY_c, 512 runs,  0 skips
  31822 UNITS in rgb24ToY_c,1024 runs,  0 skips
  31805 UNITS in rgb24ToY_c,2048 runs,  0 skips
  31841 UNITS in rgb24ToY_c,4096 runs,  0 skips
  31825 UNITS in rgb24ToY_c,8192 runs,  0 skips
  31803 UNITS in rgb24ToY_c,   16383 runs,  1 skipstrate=N/A
speed=0.649x
  31822 UNITS in rgb24ToY_c,   32766 runs,  2 skipstrate=N/A
speed=0.602x
  31816 UNITS in rgb24ToY_c,   65532 runs,  4 skipstrate=N/A
speed=0.59x 
  31811 UNITS in rgb24ToY_c,  131064 runs,  8 skipstrate=N/A
speed=0.584x
  31810 UNITS in rgb24ToY_c,  262133 runs, 11 skipstrate=N/A
speed=0.583x
  31811 UNITS in rgb24ToY_c,  524266 runs, 22 skipstrate=N/A
speed=0.583x
  31822 UNITS in rgb24ToY_c, 1048527 runs, 49 skipstrate=N/A
speed=0.582x
frame= 1000 fps= 15 q=-0.0 Lsize=N/A time=00:00:40.00 bitrate=N/A
speed=0.581x
video:477kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=68.211s
bench: maxrss=21120kB


SIMD version in patch submitted earlier in this message thread:

./ffmpeg -report -cpuflags 0 -benchmark -f rawvideo -pix_fmt rgb24 -s
hd1080 -i /dev/zero -pix_fmt yuv420p -f null -vframes 1000 - && ./ffmpeg
-report -benchmark -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero
-pix_fmt yuv420p -f null -vframes 1000

  23950 UNITS in rgb24ToY_c_vsx,   1 runs,  0 skips
  23175 UNITS in rgb24ToY_c_vsx,   2 runs,  0 skips
  22752 UNITS in rgb24ToY_c_vsx,   4 runs,  0 skips
  22401 UNITS in rgb24ToY_c_vsx,   8 runs,  0 skips
  22106 UNITS in rgb24ToY_c_vsx,  16 runs,  0 skips
  21585 UNITS in rgb24ToY_c_vsx,  32 runs,  0 skips
  21126 UNITS in rgb24ToY_c_vsx,  64 runs,  0 skips
  2

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

On Mon, 2016-07-04 at 09:20 +, Carl Eugen Hoyos wrote:
> Dan Parrot  mail.com> writes:
> 
> > The dataset used was the entire FATE regression suite.
> 
> I don't think this is a particularly useful testcase:
> It takes very long but mostly tests other things.
> 
> Did you test if using ffmpeg -benchmark -f rawvideo -i /dev/zero... 
> showed different results?
> I believe this should be both easier and faster to test.
> 
> > name: rgb24ToY_c_vsx. 
> > no. of calls: . min: 3832 ns. avg: 4709 ns. max: 37550 ns. 
> > total: 47093533 ns. 
> > 
> > name: rgb24ToY_c. 
> > no. of calls: . min: 3809 ns. avg: 4707 ns. max: 29041 ns. 
> > total: 47072923 ns.
> 
> Without any data, I would have thought that this is the most 
> important function (and "no. of calls" seems to confirm this).
> 
> Why is this not faster?
> Can you confirm with START_TIMER / STOP_TIMER that there is no 
> gain?
> 
> Thank you, Carl Eugen
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

Re: [FFmpeg-devel] [PATCH] PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD.

[Dan Parrot]

On Mon, 2016-07-04 at 23:31 -0500, Dan Parrot wrote:
> On Mon, 2016-07-04 at 09:20 +, Carl Eugen Hoyos wrote:
> > Dan Parrot  mail.com> writes:
> > 
> > > The dataset used was the entire FATE regression suite.
> > 
> > I don't think this is a particularly useful testcase:
> > It takes very long but mostly tests other things.
> > 
> > Did you test if using ffmpeg -benchmark -f rawvideo -i /dev/zero... 
> > showed different results?
> > I believe this should be both easier and faster to test.
> > 
> > > name: rgb24ToY_c_vsx. 
> > > no. of calls: . min: 3832 ns. avg: 4709 ns. max: 37550 ns. 
> > > total: 47093533 ns. 
> > > 
> > > name: rgb24ToY_c. 
> > > no. of calls: . min: 3809 ns. avg: 4707 ns. max: 29041 ns. 
> > > total: 47072923 ns.
> > 
> > Without any data, I would have thought that this is the most 
> > important function (and "no. of calls" seems to confirm this).
> > 
> > Why is this not faster?

I believe I have answered, in earlier posts, all the questions you
raised. Finally, just to satisfy my curiosity, I used SystemTap to probe
during a run of the entire FATE regression. Here are the same two
functions, this time with GCC 6.1.1 instead of 5.3.1 (it is
representative of all other functions)

name: rgb24ToY_c_vsx. 
no. of calls: . min: 3053 ns. avg: 3298 ns. max: 69359 ns. total:
32983050 ns.

name: rgb24ToY_c. 
no. of calls: . min: 3040 ns. avg: 4056 ns. max: 79159 ns. total:
40561568 ns.

Non-trivial improvement is seen for the SIMD code. So: would you accept
and apply the patch?


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

Re: [FFmpeg-devel] [PATCH 1/5] lavf: add cue sheet demuxer

[Nicolas George]

Le septidi 17 messidor, an CCXXIV, Rodger Combs a écrit :
> +- Cue sheet demuxer

This is interesting. Just a quick remark while I have time:

> +} else if (!strncmp(ptr, "FILE ", 5)) {
> +if (!cue->url || !*cue->url) {
> +char url[4096] = {0};
> +av_freep(&cue->url);
> +ff_make_absolute_url(url, sizeof(url), s->filename, 
> get_token(ptr + 5));
> +if (!(cue->url = av_strdup(url)))
> +return AVERROR(ENOMEM);
> +}

> +if ((ret = avformat_open_input(&cue->avf, cue->url, NULL, NULL)) < 0 ||
> +(ret = avformat_find_stream_info(cue->avf, NULL)) < 0) {
> +av_log(s, AV_LOG_ERROR, "Failed to open '%s'\n", cue->url);
> +avformat_close_input(&cue->avf);
> +return ret;
> +}

That makes yet another format that can open arbitrary URLs depending on
external contents: security issue.

The check for safe/unsafe URLs needs to be factored.

Also, there is the matter of the io_open() callback to check, I do not
remember how it works.

Regards,

-- 
  Nicolas George


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