Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary

[Nicolas George]

Le decadi 20 ventôse, an CCXXIII, wm4 a écrit :
> Why not fix the shortcomings in FFmpeg? (The option API.)

https://lists.libav.org/pipermail/libav-devel/2015-March/067929.html

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] Add ability to pause transcoding via keyboard interaction

[Jeremy Luce]

Useful where ffmpeg is used by applications that transcode on the fly and
want to provide some throttling (among other things)
From e2f3aa14979675a373a210bd9a028b01a5a0c7eb Mon Sep 17 00:00:00 2001
From: jluce50 
Date: Fri, 6 Mar 2015 17:13:40 -0600
Subject: [PATCH 1/4] Add pause/resume via keyboard interaction

---
 ffmpeg.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 6604ff0..edfd01d 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -120,6 +120,7 @@ const char *const forced_keyframes_const_names[] = {
 static void do_video_stats(OutputStream *ost, int frame_size);
 static int64_t getutime(void);
 static int64_t getmaxrss(void);
+static int64_t gettime_relative_minus_pause(void);
 
 static int run_as_daemon  = 0;
 static int nb_frames_dup = 0;
@@ -146,6 +147,9 @@ int nb_output_files   = 0;
 FilterGraph **filtergraphs;
 intnb_filtergraphs;
 
+int64_t paused_start = 0;
+int64_t paused_time = 0;
+
 #if HAVE_TERMIOS_H
 
 /* init terminal so that we can grab keys */
@@ -3268,6 +3272,14 @@ static int check_keyboard_interaction(int64_t cur_time)
 last_time = cur_time;
 }else
 key = -1;
+// if (key == 'u' && paused_start) {
+if (key != -1 && paused_start) { // Any valid key unpauses (backward compatibility)
+paused_time += (av_gettime_relative() - paused_start);
+paused_start = 0;
+}
+if (key == 'p' && !paused_start) {
+paused_start = av_gettime_relative();
+}
 if (key == 'q')
 return AVERROR_EXIT;
 if (key == '+') av_log_set_level(av_log_get_level()+10);
@@ -3346,7 +3358,9 @@ static int check_keyboard_interaction(int64_t cur_time)
 "C  Send/Que command to all matching filters\n"
 "D  cycle through available debug modes\n"
 "h  dump packets/hex press to cycle through the 3 states\n"
+"p  pause transcoding\n"
 "q  quit\n"
+"u  unpause transcoding"
 "s  Show QP histogram\n"
 );
 }
@@ -3778,6 +3792,11 @@ static int transcode_step(void)
 InputStream  *ist;
 int ret;
 
+if (paused_start) {
+av_usleep(1);
+return 0;
+}
+
 ost = choose_output();
 if (!ost) {
 if (got_eagain()) {
@@ -3838,7 +3857,7 @@ static int transcode(void)
 #endif
 
 while (!received_sigterm) {
-int64_t cur_time= av_gettime_relative();
+int64_t cur_time = av_gettime_relative();
 
 /* if 'q' pressed, exits */
 if (stdin_interaction)
@@ -3861,7 +3880,7 @@ static int transcode(void)
 }
 
 /* dump report by using the output first video and audio streams */
-print_report(0, timer_start, cur_time);
+print_report(0, timer_start, gettime_relative_minus_pause());
 }
 #if HAVE_PTHREADS
 free_input_threads();
@@ -3885,7 +3904,7 @@ static int transcode(void)
 }
 
 /* dump report by using the first video and audio streams */
-print_report(1, timer_start, av_gettime_relative());
+print_report(1, timer_start, gettime_relative_minus_pause());
 
 /* close each encoder */
 for (i = 0; i < nb_output_streams; i++) {
@@ -3934,6 +3953,11 @@ static int transcode(void)
 return ret;
 }
 
+static int64_t gettime_relative_minus_pause(void)
+{
+return av_gettime_relative() - paused_time -
+(paused_start ? av_gettime_relative() - paused_start : 0);
+}
 
 static int64_t getutime(void)
 {
-- 
1.9.1


From 0fb80c6d3df396119d06049f40d552d0f3a81d3b Mon Sep 17 00:00:00 2001
From: jluce50 
Date: Sat, 7 Mar 2015 10:03:39 -0600
Subject: [PATCH 2/4] Cleanup for pause/unpause

---
 ffmpeg.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index edfd01d..a505e46 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1451,7 +1451,6 @@ static void print_report(int is_last_report, int64_t timer_start, int64_t cur_ti
 last_time = cur_time;
 }
 
-
 oc = output_files[0]->ctx;
 
 total_size = avio_size(oc->pb);
@@ -3360,7 +3359,7 @@ static int check_keyboard_interaction(int64_t cur_time)
 "h  dump packets/hex press to cycle through the 3 states\n"
 "p  pause transcoding\n"
 "q  quit\n"
-"u  unpause transcoding"
+"u  unpause transcoding\n"
 "s  Show QP histogram\n"
 );
 }
@@ -3857,11 +3856,9 @@ static int transcode(void)
 #endif
 
 while (!received_sigterm) {
-int64_t cur_time = av_gettime_relative();
-
 /* if 'q' pressed, exits */
 if (stdin_interaction)
-if (check_keyboard_interaction(cur_time) < 0)
+if (check_keyboard_interaction(av_gettime_relative()) < 0)
 brea

Re: [FFmpeg-devel] [PATCH 2/4] x86: xvid_idct: port MMX IDCT to yasm

[James Almer]

On 11/03/15 11:29 AM, Christophe Gisquet wrote:
> Hi,
> 
> 2015-03-11 15:20 GMT+01:00 Michael Niedermayer :
>> personally iam in favor of more things being tested, but iam fine
>> with either
> 
> I'll see what the opinions are in ~30H then. It looks to be around
> 4.5KB more data, which isn't huge, and doesn't cause a noticeable
> increase in compile time.

As discussed before, mmx, mmxext and sse functions that have also an sse2 
version, and 
3dnow/3dnowext functions that have also an sse version, have no reason to exist 
in an 
x86_64 build.
They will not be used in any real world scenario.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Add ability to pause transcoding via keyboard interaction

[Jeremy Luce]

Resubmitting with [PATCH] tag and unified diff.

Adds functionality to pause transcoding with 'p' key and upause with 'u'
key over stdin. Pauses in the main transcode loop as well as the
input_thread loop.

-

diff --git a/ffmpeg.c b/ffmpeg.c
index 6604ff0..37b351a 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -120,6 +120,9 @@ const char *const forced_keyframes_const_names[] = {
 static void do_video_stats(OutputStream *ost, int frame_size);
 static int64_t getutime(void);
 static int64_t getmaxrss(void);
+static int64_t gettime_relative_minus_pause(void);
+static void pause_transcoding(void);
+static void unpause_transcoding(void);

 static int run_as_daemon  = 0;
 static int nb_frames_dup = 0;
@@ -146,6 +149,9 @@ int nb_output_files   = 0;
 FilterGraph **filtergraphs;
 intnb_filtergraphs;

+int64_t paused_start = 0;
+int64_t paused_time = 0;
+
 #if HAVE_TERMIOS_H

 /* init terminal so that we can grab keys */
@@ -1447,7 +1453,6 @@ static void print_report(int is_last_report,
int64_t timer_start, int64_t cur_ti
 last_time = cur_time;
 }

-
 oc = output_files[0]->ctx;

 total_size = avio_size(oc->pb);
@@ -3256,18 +3261,38 @@ static OutputStream *choose_output(void)
 return ost_min;
 }

+static void pause_transcoding(void)
+{
+if (!paused_start)
+paused_start = av_gettime_relative();
+}
+
+static void unpause_transcoding(void)
+{
+if (paused_start) {
+paused_time += av_gettime_relative() - paused_start;
+paused_start = 0;
+}
+}
+
 static int check_keyboard_interaction(int64_t cur_time)
 {
 int i, ret, key;
 static int64_t last_time;
-if (received_nb_signals)
+if (received_nb_signals) {
+unpause_transcoding();
 return AVERROR_EXIT;
+}
 /* read_key() returns 0 on EOF */
 if(cur_time - last_time >= 10 && !run_as_daemon){
 key =  read_key();
 last_time = cur_time;
 }else
 key = -1;
+// Reserve 'u' for unpausing a paused transcode, but allow any key to
+// unpause for backward compatibility
+if (key == 'u' || key != -1) unpause_transcoding();
+if (key == 'p') pause_transcoding();
 if (key == 'q')
 return AVERROR_EXIT;
 if (key == '+') av_log_set_level(av_log_get_level()+10);
@@ -3346,7 +3371,9 @@ static int check_keyboard_interaction(int64_t cur_time)
 "C  Send/Que command to all matching filters\n"
 "D  cycle through available debug modes\n"
 "h  dump packets/hex press to cycle
through the 3 states\n"
+"p  pause transcoding\n"
 "q  quit\n"
+"u  unpause transcoding\n"
 "s  Show QP histogram\n"
 );
 }
@@ -3361,6 +3388,10 @@ static void *input_thread(void *arg)
 int ret = 0;

 while (1) {
+if (paused_start) {
+av_usleep(1000); // Be more responsive to unpausing than
main thread
+continue;
+}
 AVPacket pkt;
 ret = av_read_frame(f->ctx, &pkt);

@@ -3778,6 +3809,11 @@ static int transcode_step(void)
 InputStream  *ist;
 int ret;

+if (paused_start) {
+av_usleep(1);
+return 0;
+}
+
 ost = choose_output();
 if (!ost) {
 if (got_eagain()) {
@@ -3838,11 +3874,11 @@ static int transcode(void)
 #endif

 while (!received_sigterm) {
-int64_t cur_time= av_gettime_relative();
+int64_t cur_time = gettime_relative_minus_pause();

 /* if 'q' pressed, exits */
 if (stdin_interaction)
-if (check_keyboard_interaction(cur_time) < 0)
+if (check_keyboard_interaction(av_gettime_relative()) < 0)
 break;

 /* check if there's any stream where output is still needed */
@@ -3885,7 +3921,7 @@ static int transcode(void)
 }

 /* dump report by using the first video and audio streams */
-print_report(1, timer_start, av_gettime_relative());
+print_report(1, timer_start, gettime_relative_minus_pause());

 /* close each encoder */
 for (i = 0; i < nb_output_streams; i++) {
@@ -3934,6 +3970,11 @@ static int transcode(void)
 return ret;
 }

+static int64_t gettime_relative_minus_pause(void)
+{
+return av_gettime_relative() - paused_time -
+(paused_start ? av_gettime_relative() - paused_start : 0);
+}

 static int64_t getutime(void)
 {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] x86: xvid_idct: port MMX IDCT to yasm

[Christophe Gisquet]

2015-03-11 2:26 GMT+01:00 Michael Niedermayer :
> this breaks
> make libavcodec/dct-test
> ...
> LD  libavcodec/dct-test
> libavcodec/dct-test.o:(.rodata+0xe8): undefined reference to 
> `ff_xvid_idct_mmx'
> libavcodec/dct-test.o:(.rodata+0x108): undefined reference to 
> `ff_xvid_idct_mmxext'

This is because they are no longer build for ARCH_X86_64. What would
be the preference here? Not testing them then, or keep testing them
(and therefore, do compile them)?

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

[FFmpeg-devel] [PATCH]doc: Fix alphabetic ordering for decklink input device

[Carl Eugen Hoyos]

Hi!

Attached patch improves the documentation imo, 
see http://ffmpeg.org/ffmpeg-devices.html

Please comment, Carl Eugen
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 79fec2e..dca0f51 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -150,6 +150,87 @@ $ ffmpeg -f avfoundation -pixel_format bgr0 -i 
"default:none" out.avi
 
 BSD video input device.
 
+@section decklink
+
+The decklink input device provides capture capabilities for Blackmagic
+DeckLink devices.
+
+To enable this input device, you need the Blackmagic DeckLink SDK and you
+need to configure with the appropriate @code{--extra-cflags}
+and @code{--extra-ldflags}.
+On Windows, you need to run the IDL files through @command{widl}.
+
+DeckLink is very picky about the formats it supports. Pixel format is
+uyvy422 or v210, framerate and video size must be determined for your device 
with
+@command{-list_formats 1}. Audio sample rate is always 48 kHz and the number
+of channels can be 2, 8 or 16.
+
+@subsection Options
+
+@table @option
+
+@item list_devices
+If set to @option{true}, print a list of devices and exit.
+Defaults to @option{false}.
+
+@item list_formats
+If set to @option{true}, print a list of supported formats and exit.
+Defaults to @option{false}.
+
+@item bm_v210
+If set to @samp{1}, video is captured in 10 bit v210 instead
+of uyvy422. Not all Blackmagic devices support this option.
+
+@item bm_channels 
+Number of audio channels, can be 2, 8 or 16
+
+@item bm_audiodepth 
+Audio bit depth, can be 16 or 32.
+
+@end table
+
+@subsection Examples
+
+@itemize
+
+@item
+List input devices:
+@example
+ffmpeg -f decklink -list_devices 1 -i dummy
+@end example
+
+@item
+List supported formats:
+@example
+ffmpeg -f decklink -list_formats 1 -i 'Intensity Pro'
+@end example
+
+@item
+Capture video clip at 1080i50 (format 11):
+@example
+ffmpeg -f decklink -i 'Intensity Pro@@11' -acodec copy -vcodec copy output.avi
+@end example
+
+@item
+Capture video clip at 1080i50 10 bit:
+@example
+ffmpeg -bm_v210 1 -f decklink -i 'UltraStudio Mini Recorder@@11' -acodec copy 
-vcodec copy output.avi
+@end example
+
+@item
+Capture video clip at 720p50 with 32bit audio:
+@example
+ffmpeg -bm_audiodepth 32 -f decklink -i 'UltraStudio Mini Recorder@@14' 
-acodec copy -vcodec copy output.avi
+@end example
+
+@item
+Capture video clip at 576i50 with 8 audio channels:
+@example
+ffmpeg -bm_channels 8 -f decklink -i 'UltraStudio Mini Recorder@@3' -acodec 
copy -vcodec copy output.avi
+@end example
+
+@end itemize
+
 @section dshow
 
 Windows DirectShow input device.
@@ -1118,86 +1199,5 @@ The syntax is:
 Set the grabbing region coordinates. They are expressed as offset from the top 
left
 corner of the X11 window. The default value is 0.
 
-@section decklink
-
-The decklink input device provides capture capabilities for Blackmagic
-DeckLink devices.
-
-To enable this input device, you need the Blackmagic DeckLink SDK and you
-need to configure with the appropriate @code{--extra-cflags}
-and @code{--extra-ldflags}.
-On Windows, you need to run the IDL files through @command{widl}.
-
-DeckLink is very picky about the formats it supports. Pixel format is
-uyvy422 or v210, framerate and video size must be determined for your device 
with
-@command{-list_formats 1}. Audio sample rate is always 48 kHz and the number
-of channels can be 2, 8 or 16.
-
-@subsection Options
-
-@table @option
-
-@item list_devices
-If set to @option{true}, print a list of devices and exit.
-Defaults to @option{false}.
-
-@item list_formats
-If set to @option{true}, print a list of supported formats and exit.
-Defaults to @option{false}.
-
-@item bm_v210
-If set to @samp{1}, video is captured in 10 bit v210 instead
-of uyvy422. Not all Blackmagic devices support this option.
-
-@item bm_channels 
-Number of audio channels, can be 2, 8 or 16
-
-@item bm_audiodepth 
-Audio bit depth, can be 16 or 32.
-
-@end table
-
-@subsection Examples
-
-@itemize
-
-@item
-List input devices:
-@example
-ffmpeg -f decklink -list_devices 1 -i dummy
-@end example
-
-@item
-List supported formats:
-@example
-ffmpeg -f decklink -list_formats 1 -i 'Intensity Pro'
-@end example
-
-@item
-Capture video clip at 1080i50 (format 11):
-@example
-ffmpeg -f decklink -i 'Intensity Pro@@11' -acodec copy -vcodec copy output.avi
-@end example
-
-@item
-Capture video clip at 1080i50 10 bit:
-@example
-ffmpeg -bm_v210 1 -f decklink -i 'UltraStudio Mini Recorder@@11' -acodec copy 
-vcodec copy output.avi
-@end example
-
-@item
-Capture video clip at 720p50 with 32bit audio:
-@example
-ffmpeg -bm_audiodepth 32 -f decklink -i 'UltraStudio Mini Recorder@@14' 
-acodec copy -vcodec copy output.avi
-@end example
-
-@item
-Capture video clip at 576i50 with 8 audio channels:
-@example
-ffmpeg -bm_channels 8 -f decklink -i 'UltraStudio Mini Recorder@@3' -acodec 
copy -vcodec copy output.avi
-@end example
-
-@end itemize
-
 
 @c man end INPUT DEVICES
___
ffmpeg-devel mailing list
f

Re: [FFmpeg-devel] DCA Decoder

[Kieran Kunhya]

On 11 March 2015 at 14:42, Marcus Johnson  wrote:
> I've been working on adding XLL for the last couple months, it's still not
> quite complete, basically I have to combine the Core and XLL samples before
> it's output, and I also have to finish the latter stages of decoding the
> XLL like channel decorreclation, and post processing.
>
> There are a few issues thought.
>
> 1: My code doesn't have the most recent chances from master, how do I fix
> this?
>
> 2: I read that you'd prefer for code to be small and self contained, but
> how can I do that when the later functions directly require earlier ones?
>
> 3: I've been using the variable names the white paper uses which doesn't
> match your guidelines, obviously they need to be renamed but I'm not sure
> what else you guys want me to do with that?
>
> 4: currently almost all of the variables are being stored in DCAContext and
> accessed in different functions this way, I assume this is looked down upon
> and you'll want me to change this style to use the variables in the
> disparate functions when it's called rather than passing it around the
> backend, is this correct?
>
> That said, I've rewritten the ExSS code, ExSS Asset Descriptor,  XLL, and
> XLL ChSet functions are completely ready to go.

I hope this doesn't make you feel bad for your effort but you know
there's a patch on libav-devel, right?

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

[FFmpeg-devel] [PATCH 1/2] Moved postprocessing routines from postprocess.c to seperate file

[Tucker DiNapoli]

This moves c functions to process blocks horozontally into a seperate
file, so that none of the postprocessing algorithms are in the main
postprecess.c file
---
 libpostproc/postprocess.c   | 352 +
 libpostproc/postprocess_c.c | 373 
 2 files changed, 374 insertions(+), 351 deletions(-)
 create mode 100644 libpostproc/postprocess_c.c

diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c
index 9d89782..86c0520 100644
--- a/libpostproc/postprocess.c
+++ b/libpostproc/postprocess.c
@@ -199,357 +199,7 @@ static inline void prefetcht2(const void *p)
 }
 #endif
 
-/* The horizontal functions exist only in C because the MMX
- * code is faster with vertical filters and transposing. */
-
-/**
- * Check if the given 8x8 Block is mostly "flat"
- */
-static inline int isHorizDC_C(const uint8_t src[], int stride, const PPContext 
*c)
-{
-int numEq= 0;
-int y;
-const int dcOffset= ((c->nonBQP*c->ppMode.baseDcDiff)>>8) + 1;
-const int dcThreshold= dcOffset*2 + 1;
-
-for(y=0; y c->ppMode.flatnessThreshold;
-}
-
-/**
- * Check if the middle 8x8 Block in the given 8x16 block is flat
- */
-static inline int isVertDC_C(const uint8_t src[], int stride, const PPContext 
*c)
-{
-int numEq= 0;
-int y;
-const int dcOffset= ((c->nonBQP*c->ppMode.baseDcDiff)>>8) + 1;
-const int dcThreshold= dcOffset*2 + 1;
-
-src+= stride*4; // src points to begin of the 8x8 Block
-for(y=0; y c->ppMode.flatnessThreshold;
-}
-
-static inline int isHorizMinMaxOk_C(const uint8_t src[], int stride, int QP)
-{
-int i;
-for(i=0; i<2; i++){
-if((unsigned)(src[0] - src[5] + 2*QP) > 4*QP) return 0;
-src += stride;
-if((unsigned)(src[2] - src[7] + 2*QP) > 4*QP) return 0;
-src += stride;
-if((unsigned)(src[4] - src[1] + 2*QP) > 4*QP) return 0;
-src += stride;
-if((unsigned)(src[6] - src[3] + 2*QP) > 4*QP) return 0;
-src += stride;
-}
-return 1;
-}
-
-static inline int isVertMinMaxOk_C(const uint8_t src[], int stride, int QP)
-{
-int x;
-src+= stride*4;
-for(x=0; x 
4*QP) return 0;
-if((unsigned)(src[1+x + 2*stride] - src[1+x + 7*stride] + 2*QP) > 
4*QP) return 0;
-if((unsigned)(src[2+x + 4*stride] - src[2+x + 1*stride] + 2*QP) > 
4*QP) return 0;
-if((unsigned)(src[3+x + 6*stride] - src[3+x + 3*stride] + 2*QP) > 
4*QP) return 0;
-}
-return 1;
-}
-
-static inline int horizClassify_C(const uint8_t src[], int stride, const 
PPContext *c)
-{
-if( isHorizDC_C(src, stride, c) ){
-return isHorizMinMaxOk_C(src, stride, c->QP);
-}else{
-return 2;
-}
-}
-
-static inline int vertClassify_C(const uint8_t src[], int stride, const 
PPContext *c)
-{
-if( isVertDC_C(src, stride, c) ){
-return isVertMinMaxOk_C(src, stride, c->QP);
-}else{
-return 2;
-}
-}
-
-static inline void doHorizDefFilter_C(uint8_t dst[], int stride, const 
PPContext *c)
-{
-int y;
-for(y=0; yQP){
-const int q=(dst[3] - dst[4])/2;
-const int leftEnergy=  5*(dst[2] - dst[1]) + 2*(dst[0] - dst[3]);
-const int rightEnergy= 5*(dst[6] - dst[5]) + 2*(dst[4] - dst[7]);
-
-int d= FFABS(middleEnergy) - FFMIN( FFABS(leftEnergy), 
FFABS(rightEnergy) );
-d= FFMAX(d, 0);
-
-d= (5*d + 32) >> 6;
-d*= FFSIGN(-middleEnergy);
-
-if(q>0)
-{
-d = FFMAX(d, 0);
-d = FFMIN(d, q);
-}
-else
-{
-d = FFMIN(d, 0);
-d = FFMAX(d, q);
-}
-
-dst[3]-= d;
-dst[4]+= d;
-}
-dst+= stride;
-}
-}
-
-/**
- * Do a horizontal low pass filter on the 10x8 block (dst points to middle 8x8 
Block)
- * using the 9-Tap Filter (1,1,2,2,4,2,2,1,1)/16 (C version)
- */
-static inline void doHorizLowPass_C(uint8_t dst[], int stride, const PPContext 
*c)
-{
-int y;
-for(y=0; yQP ? dst[-1] : dst[0];
-const int last= FFABS(dst[8] - dst[7]) < c->QP ? dst[8] : dst[7];
-
-int sums[10];
-sums[0] = 4*first + dst[0] + dst[1] + dst[2] + 4;
-sums[1] = sums[0] - first  + dst[3];
-sums[2] = sums[1] - first  + dst[4];
-sums[3] = sums[2] - first  + dst[5];
-sums[4] = sums[3] - first  + dst[6];
-sums[5] = sums[4] - dst[0] + dst[7];
-sums[6] = sums[5] - dst[1] + last;
-sums[7] = sums[6] - dst[2] + last;
-sums[8] = sums[7] - dst[3] + last;
-sums[9] = sums[8] - dst[4] + last;
-
-dst[0]= (sums[0] + sums[2] + 2*dst[0])>>4;
-dst[1]= (sums[1] + sums[3] + 2*dst[1])>>4;
-dst[2]= (sums[2] + sums[4] + 2*dst[2])>>4;
-dst[3]= (sums[3] + sums[5] + 2*dst[3])>>4;
-dst[4]= (sums[4] + sums[6] + 2*dst[4])>>4;
-dst[5]= (sums[5] + sums[7] + 2*dst[5])>>4;
-

[FFmpeg-devel] [PATCH 2/2] Moved templated c postprocessing routines into seperate file

[Tucker DiNapoli]

Currently different versions of the postprocessing routines are
generated from a template. Ultimately I intend to remove this by
replacing the inline assembly with seperate yasm files. The c routines
will still be needed, so they need to be moved to a seperate file.
The routines were added to the file introduced by the last commit.
---
 libpostproc/postprocess.c   |   7 +-
 libpostproc/postprocess_c.c | 829 
 2 files changed, 830 insertions(+), 6 deletions(-)

diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c
index 86c0520..2cdd988 100644
--- a/libpostproc/postprocess.c
+++ b/libpostproc/postprocess.c
@@ -198,14 +198,9 @@ static inline void prefetcht2(const void *p)
 );
 }
 #endif
-
+//Plain C versions
 #include "postprocess_c.c"
-
 //Note: we have C, MMX, MMX2, 3DNOW version there is no 3DNOW+MMX2 one
-//Plain C versions
-//we always compile C for testing which needs bitexactness
-#define TEMPLATE_PP_C 1
-#include "postprocess_template.c"
 
 #if HAVE_ALTIVEC
 #   define TEMPLATE_PP_ALTIVEC 1
diff --git a/libpostproc/postprocess_c.c b/libpostproc/postprocess_c.c
index bf22e95..5f9cb18 100644
--- a/libpostproc/postprocess_c.c
+++ b/libpostproc/postprocess_c.c
@@ -371,3 +371,832 @@ static av_always_inline void do_a_deblock_C(uint8_t *src, 
int step,
 STOP_TIMER("stepX")
 }*/
 }
+
+#define PAVGB(a,b) REAL_PAVGB(a,b)
+
+//FIXME? |255-0| = 1 (should not be a problem ...)
+
+/**
+ * Do a vertical low pass filter on the 8x16 block (only write to the 8x8 
block in the middle)
+ * using the 9-Tap Filter (1,1,2,2,4,2,2,1,1)/16
+ */
+static inline void doVertLowPass_C(uint8_t *src, int stride, PPContext *c)
+{
+const int l1= stride;
+const int l2= stride + l1;
+const int l3= stride + l2;
+const int l4= stride + l3;
+const int l5= stride + l4;
+const int l6= stride + l5;
+const int l7= stride + l6;
+const int l8= stride + l7;
+const int l9= stride + l8;
+int x;
+src+= stride*3;
+for(x=0; xQP ? src[0] : src[l1];
+const int last= FFABS(src[l8] - src[l9]) < c->QP ? src[l9] : src[l8];
+
+int sums[10];
+sums[0] = 4*first + src[l1] + src[l2] + src[l3] + 4;
+sums[1] = sums[0] - first  + src[l4];
+sums[2] = sums[1] - first  + src[l5];
+sums[3] = sums[2] - first  + src[l6];
+sums[4] = sums[3] - first  + src[l7];
+sums[5] = sums[4] - src[l1] + src[l8];
+sums[6] = sums[5] - src[l2] + last;
+sums[7] = sums[6] - src[l3] + last;
+sums[8] = sums[7] - src[l4] + last;
+sums[9] = sums[8] - src[l5] + last;
+
+src[l1]= (sums[0] + sums[2] + 2*src[l1])>>4;
+src[l2]= (sums[1] + sums[3] + 2*src[l2])>>4;
+src[l3]= (sums[2] + sums[4] + 2*src[l3])>>4;
+src[l4]= (sums[3] + sums[5] + 2*src[l4])>>4;
+src[l5]= (sums[4] + sums[6] + 2*src[l5])>>4;
+src[l6]= (sums[5] + sums[7] + 2*src[l6])>>4;
+src[l7]= (sums[6] + sums[8] + 2*src[l7])>>4;
+src[l8]= (sums[7] + sums[9] + 2*src[l8])>>4;
+
+src++;
+}
+}
+
+/**
+ * Experimental Filter 1
+ * will not damage linear gradients
+ * Flat blocks should look like they were passed through the 
(1,1,2,2,4,2,2,1,1) 9-Tap filter
+ * can only smooth blocks at the expected locations (it cannot smooth them if 
they did move)
+ * MMX2 version does correct clipping C version does not
+ */
+static inline void vertX1Filter_C(uint8_t *src, int stride, PPContext *co)
+{
+
+const int l1= stride;
+const int l2= stride + l1;
+const int l3= stride + l2;
+const int l4= stride + l3;
+const int l5= stride + l4;
+const int l6= stride + l5;
+const int l7= stride + l6;
+//const int l8= stride + l7;
+//const int l9= stride + l8;
+int x;
+
+src+= stride*3;
+for(x=0; x>1);
+d= FFMAX(d, 0);
+
+if(d < co->QP*2){
+int v = d * FFSIGN(-b);
+
+src[l2] +=v>>3;
+src[l3] +=v>>2;
+src[l4] +=(3*v)>>3;
+src[l5] -=(3*v)>>3;
+src[l6] -=v>>2;
+src[l7] -=v>>3;
+}
+src++;
+}
+}
+
+static inline void doVertDefFilter_C(uint8_t src[], int stride, PPContext *c)
+{
+const int l1= stride;
+const int l2= stride + l1;
+const int l3= stride + l2;
+const int l4= stride + l3;
+const int l5= stride + l4;
+const int l6= stride + l5;
+const int l7= stride + l6;
+const int l8= stride + l7;
+//const int l9= stride + l8;
+int x;
+src+= stride*3;
+for(x=0; xQP){
+const int q=(src[l4] - src[l5])/2;
+const int leftEnergy=  5*(src[l3] - src[l2]) + 2*(src[l1] - 
src[l4]);
+const int rightEnergy= 5*(src[l7] - src[l6]) + 2*(src[l5] - 
src[l8]);
+
+int d= FFABS(middleEnergy) - FFMIN( FFABS(leftEnergy), 
FFABS(rightEnergy) );
+d= FFMAX(d, 0);
+
+d= (5*d + 32) >> 6;
+d*= FFSIGN(-middleEnergy);
+
+

Re: [FFmpeg-devel] [PATCH] avcodec/h264_mb: Fix undefined shifts

[Ronald S. Bultje]

Hi,

On Wed, Mar 11, 2015 at 9:00 PM, Michael Niedermayer 
wrote:

> Found-by: Clang -fsanitize=shift
> Reported-by: Thierry Foucu 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264_mb.c |   14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
> index dd406c7..a4653aa 100644
> --- a/libavcodec/h264_mb.c
> +++ b/libavcodec/h264_mb.c
> @@ -213,7 +213,7 @@ static av_always_inline void mc_dir_part(H264Context
> *h, H264Picture *pic,
>  const int mx  = h->mv_cache[list][scan8[n]][0] + src_x_offset * 8;
>  int my= h->mv_cache[list][scan8[n]][1] + src_y_offset * 8;
>  const int luma_xy = (mx & 3) + ((my & 3) << 2);
> -ptrdiff_t offset  = ((mx >> 2) << pixel_shift) + (my >> 2) *
> h->mb_linesize;
> +ptrdiff_t offset  = (mx >> 2) * (1 << pixel_shift) + (my >> 2) *
> h->mb_linesize;


Why is this undefined?

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

Re: [FFmpeg-devel] [PATCH] avcodec/vp9: Fix undefined shifts in decode_frame_header()

[Ronald S. Bultje]

Hi,

On Wed, Mar 11, 2015 at 9:11 PM, Michael Niedermayer 
wrote:

> Found-by: Clang -fsanitize=shift
> Reported-by: Thierry Foucu 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vp9.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 265dc7e..0405c05 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -689,10 +689,10 @@ static int decode_frame_header(AVCodecContext *ctx,
>  for (j = 1; j < 4; j++) {
>  s->segmentation.feat[i].lflvl[j][0] =
>  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> - s->lf_delta.mode[0]) << sh), 6);
> + s->lf_delta.mode[0]) * (1 <<
> sh)), 6);
>  s->segmentation.feat[i].lflvl[j][1] =
>  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> - s->lf_delta.mode[1]) << sh), 6);
> + s->lf_delta.mode[1]) * (1 <<
> sh)), 6);


Same question: why is this undefined?

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

Re: [FFmpeg-devel] DCA Decoder

[Michael Niedermayer]

On Wed, Mar 11, 2015 at 09:44:22PM +, Derek Buitenhuis wrote:
> On 3/11/2015 9:36 PM, Michael Niedermayer wrote:
> > Thats analogous to saying "no its not important to put fuel in a
> > car, its important to drive the best car"
> 
> No what I propose is to look at both and decide which is best. Simply being
> submitted to FFmpeg first does not make it better.

you continue to talk about something completely unrelated to what i
said/meant.

you: take best code

I: for code to be ever in FFmpeg it must either be developed on top
of FFmpeg or it must be rebased/ merged/integrated at some point. Its
better if its developed and tested on top of FFmpeg in the first place
as this is less work and has a lower chance of bugs.

The difference here is the "question" that is awnsered
like in "there are 2 X implementations, which should we use" vs.
"I want to write a X implementation, on top of what codebase should
 i do the work"


> 
> > the 2nd is more work, so i suggest that new code is based on top of
> > FFmpeg already. Merge/rebase that patchset from Libav if you want
> > to work on top of it.
> 
> Yeah, merge one patchset in FFmpeg, and if it turns out the other functions
> better, the resulting mess is best summed up as "a clusterf*ck"...

you really are missunderstanding what i meant

I did not mean to suggest to push
something to main FFmpeg master, i suggested or intended to suggest,
that code be developeed on top of FFmpeg, code generally is developed
by a devloper locally on his box or in his own public repo.


> 
> > The more code is rebased and merged around the higher the risk of
> > bugs
> 
> This is a strawman argument (or perhaps just FUD).

From your point of view its indeed a strawman, and from my point of
view your arguments are a strawman because we just talk about 2
completely different things from the begin.


> 
> > Also if someone has testcases for all the new DCA features, i would
> > be interrested to have them so i can test these things if/when needed
> 
> From what I understand, neither of them implements fixed point yet in
> the core DCA decoder, which means neither is actually lossless or
> bit-exact.

ok, but do they implement something testable ?
and if so, how can this be tested ?
knowing this will be usefull to anyone working on the code

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] DCA Decoder

[Derek Buitenhuis]

On 3/12/2015 11:25 AM, Michael Niedermayer wrote:
> you continue to talk about something completely unrelated to what i
> said/meant.
> 
> you: take best code

[...]

> I: for code to be ever in FFmpeg it must either be developed on top
> of FFmpeg or it must be rebased/ merged/integrated at some point. Its
> better if its developed and tested on top of FFmpeg in the first place
> as this is less work and has a lower chance of bugs.

FUD as usual, and utter nonsense - see below.

> The difference here is the "question" that is awnsered
> like in "there are 2 X implementations, which should we use" vs.
> "I want to write a X implementation, on top of what codebase should
>  i do the work"

Except it's already written. "I want to" is not a part of the question,
for either implementations.

>> Yeah, merge one patchset in FFmpeg, and if it turns out the other functions
>> better, the resulting mess is best summed up as "a clusterf*ck"...
> 
> you really are missunderstanding what i meant
> 
> I did not mean to suggest to push
> something to main FFmpeg master, i suggested or intended to suggest,
> that code be developeed on top of FFmpeg, code generally is developed
> by a devloper locally on his box or in his own public repo.

Writing in full English sentences certainly would help my comprehension.

My point above was that both are already 'developed' to a usable point,
as far as I can tell. It's irrelevant which codebase they're on top of.
They both exist. They can both be merged in different ways.. Being developed
on top of one codebase or the other does not give an advantage, and does
not make it in any way special in any sense.

I am looking at what is the best end result for the *user*. The answer to that
is a *single* decoder, which works the best - regardless of the "effort" it. 
Yes,
I don't buy that merging one from Libav causes "more bugs" than independently
reviewing and pushing a different one.

I am sad to see that so many years later, these sorts of stupid tropes are still
being thrown around by everyone on both sides. Scaremongering and FUD, whether 
or
not you truly believe it to be the case or not. The users are the ones suffering
in the end.

>> This is a strawman argument (or perhaps just FUD).
> 
> From your point of view its indeed a strawman, and from my point of
> view your arguments are a strawman because we just talk about 2
> completely different things from the begin.

Yes, from my point of view. The view of someone who is associated with
neither project, and is a downstream user. Someone who doesn't care
about the past, or people being butthurt by someone else which I did
not witness. Someone who cares about how the end result will look.

Perhaps you should lay off the kool-aid. Even Jim Jones seems sane
in comparison to these two projects. Y'all are insane.

>> From what I understand, neither of them implements fixed point yet in
>> the core DCA decoder, which means neither is actually lossless or
>> bit-exact.
> 
> ok, but do they implement something testable ?
> and if so, how can this be tested ?
> knowing this will be usefull to anyone working on the code

I do not think DCA extensions are independently testable from the core,
but I may be misunderstanding.

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

Re: [FFmpeg-devel] DCA Decoder

[wm4]

On Thu, 12 Mar 2015 11:47:55 +
Derek Buitenhuis  wrote:

> I am looking at what is the best end result for the *user*. The answer to that
> is a *single* decoder, which works the best - regardless of the "effort" it. 
> Yes,
> I don't buy that merging one from Libav causes "more bugs" than independently
> reviewing and pushing a different one.
> 
> I am sad to see that so many years later, these sorts of stupid tropes are 
> still
> being thrown around by everyone on both sides. Scaremongering and FUD, 
> whether or
> not you truly believe it to be the case or not. The users are the ones 
> suffering
> in the end.

And it's definitely hurting both projects, not only the "other" one, as
some with impure intentions probably hope.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] DCA Decoder

[compn]

On Thu, 12 Mar 2015 11:47:55 +
Derek Buitenhuis  wrote:
> answer to that is a *single* decoder, which works the best -

just say it with less words. you dont want dual decoders like prores.

(i'm not going to make the argument that multiple users use different
prores versions because i dont want to talk about that haha.)

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

Re: [FFmpeg-devel] DCA Decoder

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 11:47:55AM +, Derek Buitenhuis wrote:
> On 3/12/2015 11:25 AM, Michael Niedermayer wrote:
> > you continue to talk about something completely unrelated to what i
> > said/meant.
> > 
> > you: take best code
> 
> [...]
> 
> > I: for code to be ever in FFmpeg it must either be developed on top
> > of FFmpeg or it must be rebased/ merged/integrated at some point. Its
> > better if its developed and tested on top of FFmpeg in the first place
> > as this is less work and has a lower chance of bugs.
> 
> FUD as usual, and utter nonsense - see below.
> 
> > The difference here is the "question" that is awnsered
> > like in "there are 2 X implementations, which should we use" vs.
> > "I want to write a X implementation, on top of what codebase should
> >  i do the work"
> 
> Except it's already written. "I want to" is not a part of the question,
> for either implementations.
> 
> >> Yeah, merge one patchset in FFmpeg, and if it turns out the other functions
> >> better, the resulting mess is best summed up as "a clusterf*ck"...
> > 
> > you really are missunderstanding what i meant
> > 
> > I did not mean to suggest to push
> > something to main FFmpeg master, i suggested or intended to suggest,
> > that code be developeed on top of FFmpeg, code generally is developed
> > by a devloper locally on his box or in his own public repo.
> 
> Writing in full English sentences certainly would help my comprehension.
> 
> My point above was that both are already 'developed' to a usable point,
> as far as I can tell. It's irrelevant which codebase they're on top of.
> They both exist. They can both be merged in different ways.. Being developed
> on top of one codebase or the other does not give an advantage, and does
> not make it in any way special in any sense.
> 
> I am looking at what is the best end result for the *user*. The answer to that
> is a *single* decoder, which works the best - regardless of the "effort" it. 
> Yes,
> I don't buy that merging one from Libav causes "more bugs" than independently
> reviewing and pushing a different one.
> 
> I am sad to see that so many years later, these sorts of stupid tropes are 
> still
> being thrown around by everyone on both sides. Scaremongering and FUD, 
> whether or
> not you truly believe it to be the case or not. The users are the ones 
> suffering
> in the end.
> 
> >> This is a strawman argument (or perhaps just FUD).
> > 
> > From your point of view its indeed a strawman, and from my point of
> > view your arguments are a strawman because we just talk about 2
> > completely different things from the begin.
> 
> Yes, from my point of view. The view of someone who is associated with
> neither project, and is a downstream user. Someone who doesn't care
> about the past, or people being butthurt by someone else which I did
> not witness. Someone who cares about how the end result will look.
> 
> Perhaps you should lay off the kool-aid. Even Jim Jones seems sane
> in comparison to these two projects. Y'all are insane.

Its interresting what kind of bizare replies one gets by stating on
the main FFmpeg development list that work should be based on FFmpeg
and should be tested. And then repeating a few times that this is
really what was meant and none of the implications others jumped to
are.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

[FFmpeg-devel] [PATCH 1/2] hevc: avoid unnecessary calls to get_format

[Rainer Hochecker]

---
 libavcodec/hevc.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index fdbaa28..b52e778 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -280,7 +280,7 @@ static int decode_lt_rps(HEVCContext *s, LongTermRPS *rps, 
GetBitContext *gb)
 return 0;
 }
 
-static int set_sps(HEVCContext *s, const HEVCSPS *sps)
+static int set_sps(HEVCContext *s, const HEVCSPS *sps, enum AVPixelFormat 
pix_fmt)
 {
 #define HWACCEL_MAX (CONFIG_HEVC_DXVA2_HWACCEL)
 enum AVPixelFormat pix_fmts[HWACCEL_MAX + 2], *fmt = pix_fmts;
@@ -304,13 +304,18 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps)
 #endif
 }
 
-*fmt++ = sps->pix_fmt;
-*fmt = AV_PIX_FMT_NONE;
+if (pix_fmt == AV_PIX_FMT_NONE) {
+*fmt++ = sps->pix_fmt;
+*fmt = AV_PIX_FMT_NONE;
 
-ret = ff_thread_get_format(s->avctx, pix_fmts);
-if (ret < 0)
-goto fail;
-s->avctx->pix_fmt = ret;
+ret = ff_thread_get_format(s->avctx, pix_fmts);
+if (ret < 0)
+goto fail;
+s->avctx->pix_fmt = ret;
+}
+else {
+s->avctx->pix_fmt = pix_fmt;
+}
 
 ff_set_sar(s->avctx, sps->vui.sar);
 
@@ -420,7 +425,7 @@ static int hls_slice_header(HEVCContext *s)
 sh->no_output_of_prior_pics_flag = 0;
 }
 ff_hevc_clear_refs(s);
-ret = set_sps(s, s->sps);
+ret = set_sps(s, s->sps, AV_PIX_FMT_NONE);
 if (ret < 0)
 return ret;
 
@@ -3334,7 +3339,7 @@ static int hevc_update_thread_context(AVCodecContext *dst,
 }
 
 if (s->sps != s0->sps)
-if ((ret = set_sps(s, s0->sps)) < 0)
+if ((ret = set_sps(s, s0->sps, src->pix_fmt)) < 0)
 return ret;
 
 s->seq_decode = s0->seq_decode;
@@ -3476,6 +3481,8 @@ static void hevc_decode_flush(AVCodecContext *avctx)
 {
 HEVCContext *s = avctx->priv_data;
 ff_hevc_flush_dpb(s);
+hevc_decode_free(avctx);
+s->context_initialized = 0;
 s->max_ra = INT_MAX;
 }
 
-- 
2.1.0

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

[FFmpeg-devel] [PATCH 2/2] hevc: delay ff_thread_finish_setup for hwaccel

[Rainer Hochecker]

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

diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index b52e778..998d58e 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -2605,7 +2605,8 @@ static int hevc_frame_start(HEVCContext *s)
 if (ret < 0)
 goto fail;
 
-ff_thread_finish_setup(s->avctx);
+if (!s->avctx->hwaccel)
+ff_thread_finish_setup(s->avctx);
 
 return 0;
 
-- 
2.1.0

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

[FFmpeg-devel] hevc: fixes for hwaccel when running frame threaded

[Rainer Hochecker]

The first patch avoids unnecessary calls to get_format. We open a new
hw decoder on every call to get_format. hevc seems to do something
different than h264. deleting any provious allocated hw decoders
at the application level results in heap corruption. There may be some other
issue left but the multiple and unnecessary calls to get_format already
bothered us with h264 which should be fixed too.

The second patch avoids a flicker when running dxva frame threaded
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] DCA Decoder

[Derek Buitenhuis]

On 3/12/2015 12:34 PM, Michael Niedermayer wrote:
> Its interresting what kind of bizare replies one gets by stating on
> the main FFmpeg development list that work should be based on FFmpeg
> and should be tested. And then repeating a few times that this is
> really what was meant and none of the implications others jumped to
> are.

Perhaps there has been a gross miscommunication but that's not what
I've been reading, nor others, from what I gather from asking.

Not much use in continuing flames, regardless.

If Marcus has not be scared off, I think the best course is to encourage
him to talk to Niels.

2 people working together is better than 2 parallel implementations.

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

Re: [FFmpeg-devel] [PATCH 1/2] hevc: avoid unnecessary calls to get_format

[Rainer Hochecker]

Rainer Hochecker  online.de> writes:

hevc_decode_flush(AVCodecContext *avctx)
>  {
>  HEVCContext *s = avctx->priv_data;
>  ff_hevc_flush_dpb(s);
> +hevc_decode_free(avctx);
> +s->context_initialized = 0;
>  s->max_ra = INT_MAX;
>  }
> 

this is a left over from debugging. does not belong to the patch




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

Re: [FFmpeg-devel] DCA Decoder

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 08:10:17AM -0400, compn wrote:
> On Thu, 12 Mar 2015 11:47:55 +
> Derek Buitenhuis  wrote:
> > answer to that is a *single* decoder, which works the best -
> 
> just say it with less words. you dont want dual decoders like prores.

i strongly want to avoid dual decoders and this is part of why i
ever replied to this thread

The situation ATM is that the dts/dca decoder in FFmpeg has
features that are missing in Libav.

If niels patch is rebased onto FFmpeg and
Marcus works on top of FFmpeg either before or after niels patch then
theres just one decoder that has all features and bugfixes

But if Marcus rebases his work on top of Niels work before this is
rebased onto FFmpeg then his work and Niels work will be on Libav
and the FFmpeg decoder will have features missing in Libav so we
will then have 2 decoders like in prores or someone will have to
merge them which will require at least testcases to test the
features, and thats why i asked for testcases

I want to avoid 2 decoders but whenever i mention "use FFmpeg" i get
accused of being "anti Libav" or "butthurt" or various other things

If people cooperate and produce 1 DCA/DTS decoder with all features
then we will have 1, otherwise there might be 2

I hope my mail is not misunderstood again

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_mb: Fix undefined shifts

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 07:14:54AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Mar 11, 2015 at 9:00 PM, Michael Niedermayer 
> wrote:
> 
> > Found-by: Clang -fsanitize=shift
> > Reported-by: Thierry Foucu 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/h264_mb.c |   14 +++---
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
> > index dd406c7..a4653aa 100644
> > --- a/libavcodec/h264_mb.c
> > +++ b/libavcodec/h264_mb.c
> > @@ -213,7 +213,7 @@ static av_always_inline void mc_dir_part(H264Context
> > *h, H264Picture *pic,
> >  const int mx  = h->mv_cache[list][scan8[n]][0] + src_x_offset * 8;
> >  int my= h->mv_cache[list][scan8[n]][1] + src_y_offset * 8;
> >  const int luma_xy = (mx & 3) + ((my & 3) << 2);
> > -ptrdiff_t offset  = ((mx >> 2) << pixel_shift) + (my >> 2) *
> > h->mb_linesize;
> > +ptrdiff_t offset  = (mx >> 2) * (1 << pixel_shift) + (my >> 2) *
> > h->mb_linesize;
> 
> 
> Why is this undefined?

Because C sucks

6.5.7 Bitwise shift operators
...
4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are 
filled with
  zeros. If E1 has an unsigned type, the value of the result is E1 * 2^E2 , 
reduced modulo
  one more than the maximum value representable in the result type. If E1 has a 
signed
  type and nonnegative value, and E1 * 2^E2 is representable in the result 
type, then that is
  the resulting value; otherwise, the behavior is undefined.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] avcodec/vp9: Fix undefined shifts in decode_frame_header()

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 07:15:47AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Mar 11, 2015 at 9:11 PM, Michael Niedermayer 
> wrote:
> 
> > Found-by: Clang -fsanitize=shift
> > Reported-by: Thierry Foucu 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/vp9.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index 265dc7e..0405c05 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -689,10 +689,10 @@ static int decode_frame_header(AVCodecContext *ctx,
> >  for (j = 1; j < 4; j++) {
> >  s->segmentation.feat[i].lflvl[j][0] =
> >  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> > - s->lf_delta.mode[0]) << sh), 6);
> > + s->lf_delta.mode[0]) * (1 <<
> > sh)), 6);
> >  s->segmentation.feat[i].lflvl[j][1] =
> >  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> > - s->lf_delta.mode[1]) << sh), 6);
> > + s->lf_delta.mode[1]) * (1 <<
> > sh)), 6);
> 
> 
> Same question: why is this undefined?

same awnser, left shifts of negative values are undefined in C
if that was by someone forgetting to define it or intentional or they
just didnt find a good definition in light of non twos-complement
i do not know

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] avcodec/vp9: Fix undefined shifts in decode_frame_header()

[Ronald S. Bultje]

Hi,

On Thu, Mar 12, 2015 at 9:41 AM, Michael Niedermayer 
wrote:

> On Thu, Mar 12, 2015 at 07:15:47AM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Wed, Mar 11, 2015 at 9:11 PM, Michael Niedermayer 
> > wrote:
> >
> > > Found-by: Clang -fsanitize=shift
> > > Reported-by: Thierry Foucu 
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/vp9.c |4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > > index 265dc7e..0405c05 100644
> > > --- a/libavcodec/vp9.c
> > > +++ b/libavcodec/vp9.c
> > > @@ -689,10 +689,10 @@ static int decode_frame_header(AVCodecContext
> *ctx,
> > >  for (j = 1; j < 4; j++) {
> > >  s->segmentation.feat[i].lflvl[j][0] =
> > >  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> > > - s->lf_delta.mode[0]) << sh),
> 6);
> > > + s->lf_delta.mode[0]) * (1 <<
> > > sh)), 6);
> > >  s->segmentation.feat[i].lflvl[j][1] =
> > >  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> > > - s->lf_delta.mode[1]) << sh),
> 6);
> > > + s->lf_delta.mode[1]) * (1 <<
> > > sh)), 6);
> >
> >
> > Same question: why is this undefined?
>
> same awnser, left shifts of negative values are undefined in C
> if that was by someone forgetting to define it or intentional or they
> just didnt find a good definition in light of non twos-complement
> i do not know


But the values aren't negative?

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

Re: [FFmpeg-devel] [PATCH 2/2] hevc: delay ff_thread_finish_setup for hwaccel

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 02:08:25PM +0100, Rainer Hochecker wrote:
> ---
>  libavcodec/hevc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

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] [PATCH] avcodec/h264_mb: Fix undefined shifts

[Ronald S. Bultje]

Hi,

On Thu, Mar 12, 2015 at 9:37 AM, Michael Niedermayer 
wrote:

> On Thu, Mar 12, 2015 at 07:14:54AM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Wed, Mar 11, 2015 at 9:00 PM, Michael Niedermayer 
> > wrote:
> >
> > > Found-by: Clang -fsanitize=shift
> > > Reported-by: Thierry Foucu 
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/h264_mb.c |   14 +++---
> > >  1 file changed, 7 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
> > > index dd406c7..a4653aa 100644
> > > --- a/libavcodec/h264_mb.c
> > > +++ b/libavcodec/h264_mb.c
> > > @@ -213,7 +213,7 @@ static av_always_inline void
> mc_dir_part(H264Context
> > > *h, H264Picture *pic,
> > >  const int mx  = h->mv_cache[list][scan8[n]][0] + src_x_offset
> * 8;
> > >  int my= h->mv_cache[list][scan8[n]][1] + src_y_offset
> * 8;
> > >  const int luma_xy = (mx & 3) + ((my & 3) << 2);
> > > -ptrdiff_t offset  = ((mx >> 2) << pixel_shift) + (my >> 2) *
> > > h->mb_linesize;
> > > +ptrdiff_t offset  = (mx >> 2) * (1 << pixel_shift) + (my >> 2) *
> > > h->mb_linesize;
> >
> >
> > Why is this undefined?
>
> Because C sucks
>
> 6.5.7 Bitwise shift operators
> ...
> 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
> are filled with
>   zeros. If E1 has an unsigned type, the value of the result is E1 * 2^E2
> , reduced modulo
>   one more than the maximum value representable in the result type. If E1
> has a signed
>   type and nonnegative value, and E1 * 2^E2 is representable in the result
> type, then that is
>   the resulting value; otherwise, the behavior is undefined.


Hm... I guess mx itself is unbounded; ok.

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

Re: [FFmpeg-devel] [PATCH] avcodec/vp9: Fix undefined shifts in decode_frame_header()

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 09:56:12AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Mar 12, 2015 at 9:41 AM, Michael Niedermayer 
> wrote:
> 
> > On Thu, Mar 12, 2015 at 07:15:47AM -0400, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Wed, Mar 11, 2015 at 9:11 PM, Michael Niedermayer 
> > > wrote:
> > >
> > > > Found-by: Clang -fsanitize=shift
> > > > Reported-by: Thierry Foucu 
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavcodec/vp9.c |4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > > > index 265dc7e..0405c05 100644
> > > > --- a/libavcodec/vp9.c
> > > > +++ b/libavcodec/vp9.c
> > > > @@ -689,10 +689,10 @@ static int decode_frame_header(AVCodecContext
> > *ctx,
> > > >  for (j = 1; j < 4; j++) {
> > > >  s->segmentation.feat[i].lflvl[j][0] =
> > > >  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> > > > - s->lf_delta.mode[0]) << sh),
> > 6);
> > > > + s->lf_delta.mode[0]) * (1 <<
> > > > sh)), 6);
> > > >  s->segmentation.feat[i].lflvl[j][1] =
> > > >  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> > > > - s->lf_delta.mode[1]) << sh),
> > 6);
> > > > + s->lf_delta.mode[1]) * (1 <<
> > > > sh)), 6);
> > >
> > >
> > > Same question: why is this undefined?
> >
> > same awnser, left shifts of negative values are undefined in C
> > if that was by someone forgetting to define it or intentional or they
> > just didnt find a good definition in light of non twos-complement
> > i do not know
> 
> 
> But the values aren't negative?

if i apply:
@@ -687,6 +687,10 @@ static int decode_frame_header(AVCodecContext *ctx,
 s->segmentation.feat[i].lflvl[0][1] =
 av_clip_uintp2(lflvl + (s->lf_delta.ref[0] << sh), 6);
 for (j = 1; j < 4; j++) {
+av_assert0((s->lf_delta.ref[j] +
+ s->lf_delta.mode[0]) >= 0);
+av_assert0((s->lf_delta.ref[j] +
+ s->lf_delta.mode[1]) >= 0);
 s->segmentation.feat[i].lflvl[j][0] =
 av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
  s->lf_delta.mode[0]) << sh), 6);

and run fate it fails all over the place

so i think they are <0

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_mb: Fix undefined shifts

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 09:57:44AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Mar 12, 2015 at 9:37 AM, Michael Niedermayer 
> wrote:
> 
> > On Thu, Mar 12, 2015 at 07:14:54AM -0400, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Wed, Mar 11, 2015 at 9:00 PM, Michael Niedermayer 
> > > wrote:
> > >
> > > > Found-by: Clang -fsanitize=shift
> > > > Reported-by: Thierry Foucu 
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavcodec/h264_mb.c |   14 +++---
> > > >  1 file changed, 7 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
> > > > index dd406c7..a4653aa 100644
> > > > --- a/libavcodec/h264_mb.c
> > > > +++ b/libavcodec/h264_mb.c
> > > > @@ -213,7 +213,7 @@ static av_always_inline void
> > mc_dir_part(H264Context
> > > > *h, H264Picture *pic,
> > > >  const int mx  = h->mv_cache[list][scan8[n]][0] + src_x_offset
> > * 8;
> > > >  int my= h->mv_cache[list][scan8[n]][1] + src_y_offset
> > * 8;
> > > >  const int luma_xy = (mx & 3) + ((my & 3) << 2);
> > > > -ptrdiff_t offset  = ((mx >> 2) << pixel_shift) + (my >> 2) *
> > > > h->mb_linesize;
> > > > +ptrdiff_t offset  = (mx >> 2) * (1 << pixel_shift) + (my >> 2) *
> > > > h->mb_linesize;
> > >
> > >
> > > Why is this undefined?
> >
> > Because C sucks
> >
> > 6.5.7 Bitwise shift operators
> > ...
> > 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
> > are filled with
> >   zeros. If E1 has an unsigned type, the value of the result is E1 * 2^E2
> > , reduced modulo
> >   one more than the maximum value representable in the result type. If E1
> > has a signed
> >   type and nonnegative value, and E1 * 2^E2 is representable in the result
> > type, then that is
> >   the resulting value; otherwise, the behavior is undefined.
> 
> 
> Hm... I guess mx itself is unbounded; ok.

applied

thanks

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] avcodec/vp9: Fix undefined shifts in decode_frame_header()

[Ronald S. Bultje]

Hi,

On Thu, Mar 12, 2015 at 10:16 AM, Michael Niedermayer 
wrote:

> On Thu, Mar 12, 2015 at 09:56:12AM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Thu, Mar 12, 2015 at 9:41 AM, Michael Niedermayer 
> > wrote:
> >
> > > On Thu, Mar 12, 2015 at 07:15:47AM -0400, Ronald S. Bultje wrote:
> > > > Hi,
> > > >
> > > > On Wed, Mar 11, 2015 at 9:11 PM, Michael Niedermayer <
> michae...@gmx.at>
> > > > wrote:
> > > >
> > > > > Found-by: Clang -fsanitize=shift
> > > > > Reported-by: Thierry Foucu 
> > > > > Signed-off-by: Michael Niedermayer 
> > > > > ---
> > > > >  libavcodec/vp9.c |4 ++--
> > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > > > > index 265dc7e..0405c05 100644
> > > > > --- a/libavcodec/vp9.c
> > > > > +++ b/libavcodec/vp9.c
> > > > > @@ -689,10 +689,10 @@ static int decode_frame_header(AVCodecContext
> > > *ctx,
> > > > >  for (j = 1; j < 4; j++) {
> > > > >  s->segmentation.feat[i].lflvl[j][0] =
> > > > >  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> > > > > - s->lf_delta.mode[0]) <<
> sh),
> > > 6);
> > > > > + s->lf_delta.mode[0]) *
> (1 <<
> > > > > sh)), 6);
> > > > >  s->segmentation.feat[i].lflvl[j][1] =
> > > > >  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> > > > > - s->lf_delta.mode[1]) <<
> sh),
> > > 6);
> > > > > + s->lf_delta.mode[1]) *
> (1 <<
> > > > > sh)), 6);
> > > >
> > > >
> > > > Same question: why is this undefined?
> > >
> > > same awnser, left shifts of negative values are undefined in C
> > > if that was by someone forgetting to define it or intentional or they
> > > just didnt find a good definition in light of non twos-complement
> > > i do not know
> >
> >
> > But the values aren't negative?
>
> if i apply:
> @@ -687,6 +687,10 @@ static int decode_frame_header(AVCodecContext *ctx,
>  s->segmentation.feat[i].lflvl[0][1] =
>  av_clip_uintp2(lflvl + (s->lf_delta.ref[0] << sh), 6);
>  for (j = 1; j < 4; j++) {
> +av_assert0((s->lf_delta.ref[j] +
> + s->lf_delta.mode[0]) >= 0);
> +av_assert0((s->lf_delta.ref[j] +
> + s->lf_delta.mode[1]) >= 0);
>  s->segmentation.feat[i].lflvl[j][0] =
>  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
>   s->lf_delta.mode[0]) << sh), 6);
>
> and run fate it fails all over the place
>
> so i think they are <0


Bleh, I was missing one bracket; the delta is indeed negative; lflvl itself
(and the sum) is not. So OK.

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

Re: [FFmpeg-devel] Adding Webvtt in hls muxer

[Deron]

On 2/26/15 4:26 AM, Anshul wrote:


On 02/25/2015 10:04 PM, Deron wrote:

On 2/21/15 8:05 AM, Deron wrote:

On 2/15/15 5:44 AM, Anshul wrote:


attached another cleaned patch.

-Anshul


Not sure if I should be posting here, privately, or do the user list 
since it is an unaccepted patch... This patch applies cleanly to 
ffmpeg git of that day, and with minor adjustment to current git, 
but either crashes the same for me right away. Here is the back 
trace from gdb:



Program received signal SIGSEGV, Segmentation fault.
__GI___libc_realloc (oldmem=0x70, bytes=8) at malloc.c:2977
2977malloc.c: No such file or directory.
(gdb) bt
#0  __GI___libc_realloc (oldmem=0x70, bytes=8) at malloc.c:2977
#1  0x77609b99 in avformat_new_stream (s=s@entry=0xe2dbc0, 
c=c@entry=0x0) at libavformat/utils.c:3655
#2  0x775451c4 in hls_mux_init (s=0x6787c0) at 
libavformat/hlsenc.c:194

#3  hls_write_header (s=0x6787c0) at libavformat/hlsenc.c:490
#4  0x775999ec in avformat_write_header (s=s@entry=0x6787c0, 
options=0x6a9948) at libavformat/mux.c:406

#5  0x00424c00 in transcode_init () at ffmpeg.c:3096
#6  0x00407581 in transcode () at ffmpeg.c:3815
#7  main (argc=13, argv=0x7fffe5a8) at ffmpeg.c:4022


The command (I've tried all sorts of combinations. If I don't 
provide a subtitle stream, it does not crash. Otherwise it does. 
Unpatched can generate a webvtt from the subtitle stream without 
crashing.)


ffmpeg -loglevel debug -f lavfi -i movie=out.ts\[out0+subcc\] -f hls 
-hls_segment_filename /var/www/html/stream/kota/v.low.%d.ts 
-hls_subtitle_path /var/www/html/stream/kota/ -y 
/var/www/html/stream/kota/v.low.m3u8




I did find the problem. The patch does not properly initialize 
hls->vtt_oformat (etc) if you provide the "-hls_segment_filename" 
parameter as I have done.


Deron

I have attached new patch with correctly initializing the webvtt, can 
you please check this patch again.


-Anshul 


Besides needing some minor changes to apply to git head, this works.  
I'm not sure that the CC is 100% correct, but I have not sat down and 
compared to any other output yet. Certainly close, it just seems a 
little off and I can't put my finger on it. Not a timing issue, just 
seems jumpy and hard to read. Could just be the Apple player, or could 
be that the segmenter is not duplicating items that span multiple segments.


I do have a couple requests, but once this is accepted I think I can 
make the patch. One is the support m3u8 rename like the mpegts segments 
do, and the other is to support WebVTT segmenting on a subtitle only 
stream. I'd like to see/submit an audio only stream segmenter patch as 
well, but that is well outside this patch :-)


Either way, thanks!

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

Re: [FFmpeg-devel] [PATCH] avcodec/vp9: Fix undefined shifts in decode_frame_header()

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 10:26:55AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Thu, Mar 12, 2015 at 10:16 AM, Michael Niedermayer 
> wrote:
> 
> > On Thu, Mar 12, 2015 at 09:56:12AM -0400, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Thu, Mar 12, 2015 at 9:41 AM, Michael Niedermayer 
> > > wrote:
> > >
> > > > On Thu, Mar 12, 2015 at 07:15:47AM -0400, Ronald S. Bultje wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, Mar 11, 2015 at 9:11 PM, Michael Niedermayer <
> > michae...@gmx.at>
> > > > > wrote:
> > > > >
> > > > > > Found-by: Clang -fsanitize=shift
> > > > > > Reported-by: Thierry Foucu 
> > > > > > Signed-off-by: Michael Niedermayer 
> > > > > > ---
> > > > > >  libavcodec/vp9.c |4 ++--
> > > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > > > > > index 265dc7e..0405c05 100644
> > > > > > --- a/libavcodec/vp9.c
> > > > > > +++ b/libavcodec/vp9.c
> > > > > > @@ -689,10 +689,10 @@ static int decode_frame_header(AVCodecContext
> > > > *ctx,
> > > > > >  for (j = 1; j < 4; j++) {
> > > > > >  s->segmentation.feat[i].lflvl[j][0] =
> > > > > >  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> > > > > > - s->lf_delta.mode[0]) <<
> > sh),
> > > > 6);
> > > > > > + s->lf_delta.mode[0]) *
> > (1 <<
> > > > > > sh)), 6);
> > > > > >  s->segmentation.feat[i].lflvl[j][1] =
> > > > > >  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> > > > > > - s->lf_delta.mode[1]) <<
> > sh),
> > > > 6);
> > > > > > + s->lf_delta.mode[1]) *
> > (1 <<
> > > > > > sh)), 6);
> > > > >
> > > > >
> > > > > Same question: why is this undefined?
> > > >
> > > > same awnser, left shifts of negative values are undefined in C
> > > > if that was by someone forgetting to define it or intentional or they
> > > > just didnt find a good definition in light of non twos-complement
> > > > i do not know
> > >
> > >
> > > But the values aren't negative?
> >
> > if i apply:
> > @@ -687,6 +687,10 @@ static int decode_frame_header(AVCodecContext *ctx,
> >  s->segmentation.feat[i].lflvl[0][1] =
> >  av_clip_uintp2(lflvl + (s->lf_delta.ref[0] << sh), 6);
> >  for (j = 1; j < 4; j++) {
> > +av_assert0((s->lf_delta.ref[j] +
> > + s->lf_delta.mode[0]) >= 0);
> > +av_assert0((s->lf_delta.ref[j] +
> > + s->lf_delta.mode[1]) >= 0);
> >  s->segmentation.feat[i].lflvl[j][0] =
> >  av_clip_uintp2(lflvl + ((s->lf_delta.ref[j] +
> >   s->lf_delta.mode[0]) << sh), 6);
> >
> > and run fate it fails all over the place
> >
> > so i think they are <0
> 
> 
> Bleh, I was missing one bracket; the delta is indeed negative; lflvl itself
> (and the sum) is not. So OK.

applied

thanks

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_mb: Fix undefined shifts

[Christophe Gisquet]

Hi,

2015-03-12 14:37 GMT+01:00 Michael Niedermayer :
>> >  const int mx  = h->mv_cache[list][scan8[n]][0] + src_x_offset * 8;
>> >  int my= h->mv_cache[list][scan8[n]][1] + src_y_offset * 8;
>> >  const int luma_xy = (mx & 3) + ((my & 3) << 2);
>> > -ptrdiff_t offset  = ((mx >> 2) << pixel_shift) + (my >> 2) *
>> > h->mb_linesize;
>> > +ptrdiff_t offset  = (mx >> 2) * (1 << pixel_shift) + (my >> 2) *
>> > h->mb_linesize;
>>
>>
>> Why is this undefined?
>
> Because C sucks

I actually have an equivalent question to Ronald's. Is there a valid
input that causes the undefined behaviour? For an invalid input (e.g.
DoS tentative), is the behaviour worsened?

More in (uninformed) details:

mx is probably already constrained by AVC specifications. Another
limit to its validness is mx being a bit more than 4 times as large as
the image width. In that case, what would the image width be to cause
this undefined behaviour? It looks to me like for anything vaguely
sensible, it would not fall within the undefined behaviour.

For invalid inputs (where in particular the content of mv_cache was
not properly validated), let's say you get something that is larger
than the image. So what we get is a correctly computed value, yet
still invalid. I'm probably overlooking this here.

I'd prefer some fuzzing to actually yield a crash scenario before
acting on such reports (which are not clear to me as actually causing
a degradation). Otherwise, some of those issues are mostly pedantic.
On the other hand, we are only loosing 3 cycles out of several
hundreds.

If we are going to overengineer such issues, we could have something like:
#if HAVE_FSANITIZED_SHIFT_PLEASURING
# define LEGAL_SHIFT(a, b, type) ( (a) * (((type)1) << (b) )
#else
# define LEGAL_SHIFT(a, b, type) ( (a) << (b) )
#endif

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_mb: Fix undefined shifts

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 03:39:51PM +0100, Christophe Gisquet wrote:
> Hi,
> 
> 2015-03-12 14:37 GMT+01:00 Michael Niedermayer :
> >> >  const int mx  = h->mv_cache[list][scan8[n]][0] + src_x_offset * 
> >> > 8;
> >> >  int my= h->mv_cache[list][scan8[n]][1] + src_y_offset * 
> >> > 8;
> >> >  const int luma_xy = (mx & 3) + ((my & 3) << 2);
> >> > -ptrdiff_t offset  = ((mx >> 2) << pixel_shift) + (my >> 2) *
> >> > h->mb_linesize;
> >> > +ptrdiff_t offset  = (mx >> 2) * (1 << pixel_shift) + (my >> 2) *
> >> > h->mb_linesize;
> >>
> >>
> >> Why is this undefined?
> >
> > Because C sucks
> 
> I actually have an equivalent question to Ronald's. Is there a valid
> input that causes the undefined behaviour? For an invalid input (e.g.
> DoS tentative), is the behaviour worsened?

i belive any motion vector that points left outside the picture will
trigger this one, its also happening with multiple fate samples
This issue is about undefined behavor according to the C specification
not about current gcc generating actually bad code from it AFAIK


> 
> More in (uninformed) details:
> 
> mx is probably already constrained by AVC specifications. Another
> limit to its validness is mx being a bit more than 4 times as large as
> the image width. In that case, what would the image width be to cause
> this undefined behaviour? It looks to me like for anything vaguely
> sensible, it would not fall within the undefined behaviour.
> 
> For invalid inputs (where in particular the content of mv_cache was
> not properly validated), let's say you get something that is larger
> than the image. So what we get is a correctly computed value, yet
> still invalid. I'm probably overlooking this here.
> 

> I'd prefer some fuzzing to actually yield a crash scenario before
> acting on such reports (which are not clear to me as actually causing
> a degradation). Otherwise, some of those issues are mostly pedantic.
> On the other hand, we are only loosing 3 cycles out of several
> hundreds.

the compiler should optimize the extra operation out, ive
confirmed this before posting the patch in some cases but i didnt
check all


> 
> If we are going to overengineer such issues, we could have something like:
> #if HAVE_FSANITIZED_SHIFT_PLEASURING
> # define LEGAL_SHIFT(a, b, type) ( (a) * (((type)1) << (b) )
> #else
> # define LEGAL_SHIFT(a, b, type) ( (a) << (b) )
> #endif

that could be done it would make the code less readable though

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

Re: [FFmpeg-devel] [PATCH]doc: Fix alphabetic ordering for decklink input device

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 09:52:08AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch improves the documentation imo, 
> see http://ffmpeg.org/ffmpeg-devices.html
> 
> Please comment, Carl Eugen

probably ok

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_mb: Fix undefined shifts

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 04:17:30PM +0100, Michael Niedermayer wrote:
> On Thu, Mar 12, 2015 at 03:39:51PM +0100, Christophe Gisquet wrote:
> > Hi,
> > 
> > 2015-03-12 14:37 GMT+01:00 Michael Niedermayer :
> > >> >  const int mx  = h->mv_cache[list][scan8[n]][0] + src_x_offset 
> > >> > * 8;
> > >> >  int my= h->mv_cache[list][scan8[n]][1] + src_y_offset 
> > >> > * 8;
> > >> >  const int luma_xy = (mx & 3) + ((my & 3) << 2);
> > >> > -ptrdiff_t offset  = ((mx >> 2) << pixel_shift) + (my >> 2) *
> > >> > h->mb_linesize;
> > >> > +ptrdiff_t offset  = (mx >> 2) * (1 << pixel_shift) + (my >> 2) *
> > >> > h->mb_linesize;
> > >>
> > >>
> > >> Why is this undefined?
> > >
> > > Because C sucks
> > 
> > I actually have an equivalent question to Ronald's. Is there a valid
> > input that causes the undefined behaviour? For an invalid input (e.g.
> > DoS tentative), is the behaviour worsened?
> 
> i belive any motion vector that points left outside the picture will
> trigger this one, its also happening with multiple fate samples
> This issue is about undefined behavor according to the C specification
> not about current gcc generating actually bad code from it AFAIK

also a compiler could very easily generate bad code from this, that
is it would be both allowed in C and make sense for it to do so
consider
((mx >> 2) << pixel_shift)
...
const int full_mx= mx >> 2;

if (full_mx<  0 - extra_width  ||


from "(mx >> 2) << pixel_shift)" a compiler could imply that
(mx >> 2) is >= 0 as the alterantive is undefined
that makes full_mx >= 0
at this point the only way for full_mx < - extra_width is a non
zero extra_width and that is impossible on the else path to
"if (mx & 7)" above so the compiler could optimize this check out
in that case

luckily gcc is not smart enough to do that

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_mb: Fix undefined shifts

[Christophe Gisquet]

Hi,

2015-03-12 16:29 GMT+01:00 Michael Niedermayer :
> from "(mx >> 2) << pixel_shift)" a compiler could imply that
> (mx >> 2) is >= 0 as the alterantive is undefined

Well, (mvx >> 2) is implementation-defined, according to 6.5.7. But
gcc produces the same instruction, so...

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_mb: Fix undefined shifts

[Christophe Gisquet]

Hi,

2015-03-12 16:17 GMT+01:00 Michael Niedermayer :
> i belive any motion vector that points left outside the picture will
> trigger this one

OK I thought it was a magnitude issue, it's actually mvx being
negative. That's indeed mighty weird and didn't know about this.

> the compiler should optimize the extra operation out, ive
> confirmed this before posting the patch in some cases but i didnt
> check all

Funny that it actually restores the original operation. I really
wonder what architecture would have this undefined (excluding overflow
situations)

>> If we are going to overengineer such issues, we could have something like:
>> #if HAVE_FSANITIZED_SHIFT_PLEASURING
>> # define LEGAL_SHIFT(a, b, type) ( (a) * (((type)1) << (b) )
>> #else
>> # define LEGAL_SHIFT(a, b, type) ( (a) << (b) )
>> #endif
>
> that could be done it would make the code less readable though

Let's not do this, it seems that's what the compiler already does,
so... But I'd be curious to know what theorical compilers and/or
theorical archictures are affected.

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

Re: [FFmpeg-devel] [PATCH v3] mips/asmdefs: use _ABI64 as defined by gcc

[Michael Niedermayer]

On Wed, Mar 11, 2015 at 02:59:28PM +, James Cowgill wrote:
> Unfortunately android < api 21 (lollipop) doesn't have the sgidefs.h header,
> the easiest way around this is to just use the preprocessor definitions from
> gcc / clang.
> 
> Signed-off-by: James Cowgill 
> ---
> Hi,
> 
> Sorry I forgot about this a little.
> 
> I think that doing it this way is better than messing around with different
> headers which may not exist. I know it works on GCC and Clang.
> 
> Thanks,
> James
> 
>  libavutil/mips/asmdefs.h | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

applied

thanks

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

It is what and why we do it that matters, not just one of them.


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

[FFmpeg-devel] [PATCH] mxfenc: ensure mxf->body_partition_offset is not NULL before using it

[Andreas Cadhalpun]

This fixes a crash, when trying to mux h264 into mxf_opatom.

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/mxfenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 898951c..2891f5d 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2358,7 +2358,7 @@ static int mxf_write_footer(AVFormatContext *s)
 mxf_write_random_index_pack(s);

 if (s->pb->seekable) {
-if (s->oformat == &ff_mxf_opatom_muxer){
+if (s->oformat == &ff_mxf_opatom_muxer && mxf->body_partition_offset){
 /* rewrite body partition to update lengths */
 avio_seek(pb, mxf->body_partition_offset[0], SEEK_SET);
 if ((err = mxf_write_opatom_body_partition(s)) < 0)
-- 2.1.4

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

[FFmpeg-devel] [PATCH] hevcdsp: fix compilation for arm and aarch64

[James Almer]

Also add av_cold to ff_hevcdsp_init_arm.

Signed-off-by: James Almer 
---
Untested as i lack the hardware (or qemu).

 libavcodec/arm/Makefile|  1 +
 libavcodec/arm/hevcdsp_arm.h   | 26 ++
 libavcodec/arm/hevcdsp_init_arm.c  | 32 
 libavcodec/arm/hevcdsp_init_neon.c | 13 ++---
 libavcodec/hevcdsp.c   |  2 +-
 5 files changed, 62 insertions(+), 12 deletions(-)
 create mode 100644 libavcodec/arm/hevcdsp_arm.h
 create mode 100644 libavcodec/arm/hevcdsp_init_arm.c

diff --git a/libavcodec/arm/Makefile b/libavcodec/arm/Makefile
index 1fea3b8..2f87396 100644
--- a/libavcodec/arm/Makefile
+++ b/libavcodec/arm/Makefile
@@ -37,6 +37,7 @@ OBJS-$(CONFIG_DCA_DECODER) += 
arm/dcadsp_init_arm.o
 OBJS-$(CONFIG_FLAC_DECODER)+= arm/flacdsp_init_arm.o\
   arm/flacdsp_arm.o
 OBJS-$(CONFIG_FLAC_ENCODER)+= arm/flacdsp_init_arm.o
+OBJS-$(CONFIG_HEVC_DECODER)+= arm/hevcdsp_init_arm.o
 OBJS-$(CONFIG_MLP_DECODER) += arm/mlpdsp_init_arm.o
 OBJS-$(CONFIG_VC1_DECODER) += arm/vc1dsp_init_arm.o
 OBJS-$(CONFIG_VORBIS_DECODER)  += arm/vorbisdsp_init_arm.o
diff --git a/libavcodec/arm/hevcdsp_arm.h b/libavcodec/arm/hevcdsp_arm.h
new file mode 100644
index 000..7735df9
--- /dev/null
+++ b/libavcodec/arm/hevcdsp_arm.h
@@ -0,0 +1,26 @@
+/*
+ * 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
+ */
+
+#ifndef AVCODEC_ARM_HEVCDSP_ARM_H
+#define AVCODEC_ARM_HEVCDSP_ARM_H
+
+#include "libavcodec/hevcdsp.h"
+
+void ff_hevcdsp_init_neon(HEVCDSPContext *c, const int bit_depth);
+
+#endif /* AVCODEC_ARM_HEVCDSP_ARM_H */
diff --git a/libavcodec/arm/hevcdsp_init_arm.c 
b/libavcodec/arm/hevcdsp_init_arm.c
new file mode 100644
index 000..36500f5
--- /dev/null
+++ b/libavcodec/arm/hevcdsp_init_arm.c
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2014 Seppo Tomperi 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/attributes.h"
+#include "libavutil/arm/cpu.h"
+#include "libavcodec/hevcdsp.h"
+#include "hevcdsp_arm.h"
+
+av_cold void ff_hevcdsp_init_arm(HEVCDSPContext *c, const int bit_depth)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_neon(cpu_flags))
+ff_hevcdsp_init_neon(c, bit_depth);
+}
diff --git a/libavcodec/arm/hevcdsp_init_neon.c 
b/libavcodec/arm/hevcdsp_init_neon.c
index 61e6462..5591807 100644
--- a/libavcodec/arm/hevcdsp_init_neon.c
+++ b/libavcodec/arm/hevcdsp_init_neon.c
@@ -21,6 +21,7 @@
 #include "libavutil/attributes.h"
 #include "libavutil/arm/cpu.h"
 #include "libavcodec/hevcdsp.h"
+#include "hevcdsp_arm.h"
 
 void ff_hevc_v_loop_filter_luma_neon(uint8_t *_pix, ptrdiff_t _stride, int 
_beta, int *_tc, uint8_t *_no_p, uint8_t *_no_q);
 void ff_hevc_h_loop_filter_luma_neon(uint8_t *_pix, ptrdiff_t _stride, int 
_beta, int *_tc, uint8_t *_no_p, uint8_t *_no_q);
@@ -141,9 +142,8 @@ void ff_hevc_put_qpel_bi_neon_wrapper(uint8_t *dst, 
ptrdiff_t dststride, uint8_t
 put_hevc_qpel_uw_neon[my][mx](dst, dststride, src, srcstride, width, 
height, src2, MAX_PB_SIZE);
 }
 
-static av_cold void hevcdsp_init_neon(HEVCDSPContext *c, const int bit_depth)
+av_cold void ff_hevcdsp_init_neon(HEVCDSPContext *c, const int bit_depth)
 {
-#if HAVE_NEON
 if (bit_depth == 8) {
 int x;
 c->hevc_v_loop_filter_luma = ff_hevc_v_loop_filter_luma_neon;
@@ -221,13 +221,4 @@ static av_cold void hevcdsp_init_neon(HEVCDSPContext *c, 
const int bit_depth)
 

Re: [FFmpeg-devel] [PATCH 1/4] x86: xvid: port SSE2 idct to yasm

[Christophe Gisquet]

Hi,

2015-03-11 3:46 GMT+01:00 James Almer :
> Should be YASM-OBJS, and moved to the end of the file.
> Also, related to the build failure Michael mentioned for the second patch, 
> this is
> missing an inline -> external change in libavcodec/x86/dct-test.c

Here you are.

Passes fate-xvid-idct and dct-test builds and runs on both Win32 and Win64.

-- 
Christophe
From 86da5a1f111f9f36318daa906c3245d6b883feb3 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet 
Date: Tue, 10 Mar 2015 23:11:51 +
Subject: [PATCH 1/4] x86: xvid_idct: port SSE2 iDCT to yasm

The main difference consists in renaming properly labels, and
letting yasm select the gprs for skipping 1D transforms.
---
 libavcodec/x86/Makefile|   4 +-
 libavcodec/x86/dct-test.c  |   4 +-
 libavcodec/x86/xvididct.asm| 379 ++
 libavcodec/x86/xvididct_init.c |  18 +-
 libavcodec/x86/xvididct_sse2.c | 406 -
 5 files changed, 398 insertions(+), 413 deletions(-)
 create mode 100644 libavcodec/x86/xvididct.asm
 delete mode 100644 libavcodec/x86/xvididct_sse2.c

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 6b9164a..f46c7d5 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -73,8 +73,7 @@ MMX-OBJS-$(CONFIG_FDCTDSP) += x86/fdct.o
 MMX-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct.o
 
 # decoders/encoders
-MMX-OBJS-$(CONFIG_MPEG4_DECODER)   += x86/xvididct_mmx.o\
-  x86/xvididct_sse2.o
+MMX-OBJS-$(CONFIG_MPEG4_DECODER)   += x86/xvididct_mmx.o
 MMX-OBJS-$(CONFIG_SNOW_DECODER)+= x86/snowdsp.o
 MMX-OBJS-$(CONFIG_SNOW_ENCODER)+= x86/snowdsp.o
 MMX-OBJS-$(CONFIG_VC1_DECODER) += x86/vc1dsp_mmx.o
@@ -141,6 +140,7 @@ YASM-OBJS-$(CONFIG_HEVC_DECODER)   += x86/hevc_mc.o \
   x86/hevc_res_add.o\
   x86/hevc_sao.o
 YASM-OBJS-$(CONFIG_MLP_DECODER)+= x86/mlpdsp.o
+YASM-OBJS-$(CONFIG_MPEG4_DECODER)  += x86/xvididct.o
 YASM-OBJS-$(CONFIG_PNG_DECODER)+= x86/pngdsp.o
 YASM-OBJS-$(CONFIG_PRORES_DECODER) += x86/proresdsp.o
 YASM-OBJS-$(CONFIG_PRORES_LGPL_DECODER) += x86/proresdsp.o
diff --git a/libavcodec/x86/dct-test.c b/libavcodec/x86/dct-test.c
index 3414cb0..e14ce9a 100644
--- a/libavcodec/x86/dct-test.c
+++ b/libavcodec/x86/dct-test.c
@@ -67,9 +67,9 @@ static const struct algo idct_tab_arch[] = {
 #if HAVE_MMXEXT_INLINE
 { "XVID-MMXEXT", ff_xvid_idct_mmxext, FF_IDCT_PERM_NONE,   AV_CPU_FLAG_MMXEXT, 1 },
 #endif
-#if HAVE_SSE2_INLINE
+#if HAVE_SSE2_EXTERNAL
 { "XVID-SSE2",   ff_xvid_idct_sse2,   FF_IDCT_PERM_SSE2,   AV_CPU_FLAG_SSE2,   1 },
-#if ARCH_X86_64 && HAVE_YASM
+#if ARCH_X86_64
 { "PR-SSE2", ff_prores_idct_put_10_sse2_wrap, FF_IDCT_PERM_TRANSPOSE, AV_CPU_FLAG_SSE2, 1 },
 #endif
 #endif
diff --git a/libavcodec/x86/xvididct.asm b/libavcodec/x86/xvididct.asm
new file mode 100644
index 000..d16db34
--- /dev/null
+++ b/libavcodec/x86/xvididct.asm
@@ -0,0 +1,379 @@
+; XVID MPEG-4 VIDEO CODEC
+; - SSE2 inverse discrete cosine transform -
+;
+; Copyright(C) 2003 Pascal Massimino 
+;
+; Conversion to gcc syntax with modifications
+; by Alexander Strange 
+;
+; Originally from dct/x86_asm/fdct_sse2_skal.asm in Xvid.
+;
+; This file is part of FFmpeg.
+;
+; Vertical pass is an implementation of the scheme:
+;  Loeffler C., Ligtenberg A., and Moschytz C.S.:
+;  Practical Fast 1D DCT Algorithm with Eleven Multiplications,
+;  Proc. ICASSP 1989, 988-991.
+;
+; Horizontal pass is a double 4x4 vector/matrix multiplication,
+; (see also Intel's Application Note 922:
+;  http://developer.intel.com/vtune/cbts/strmsimd/922down.htm
+;  Copyright (C) 1999 Intel Corporation)
+;
+; More details at http://skal.planet-d.net/coding/dct.html
+;
+; FFmpeg is free software; you can redistribute it and/or
+; modify it under the terms of the GNU Lesser General Public
+; License as published by the Free Software Foundation; either
+; version 2.1 of the License, or (at your option) any later version.
+;
+; FFmpeg is distributed in the hope that it will be useful,
+; but WITHOUT ANY WARRANTY; without even the implied warranty of
+; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+; Lesser General Public License for more details.
+;
+; You should have received a copy of the GNU Lesser General Public License
+; along with FFmpeg; if not, write to the Free Software Foundation,
+; Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+
+%include "libavutil/x86/x86util.asm"
+
+SECTION_RODATA
+tan1:   times 8 dw 13036
+tan2:   times 8 dw 27146
+tan3:   times 8 dw 43790
+sqrt2:  times 8 dw 23170
+
+iTab1:  dw 0x4000, 0x539f, 0xc000, 0xac61, 0x4000, 0xdd5d, 0x4000, 0xdd5d
+dw 0x4000, 0x22a3, 0x4000, 0x22a3, 0xc000, 0x539f, 0x4000, 0xac61
+dw 0x3249, 0x11a8, 0x4b42, 0xee58, 0x11

[FFmpeg-devel] GSoC Introduction

[Anand Dhoot]

Hi,

My name is Anand Dhoot. I am an undergraduate student and keen on taking up
the project on "HTTP/2" for GSoC 2015. This would be my first opportunity
to contribute to the Open Source Community.

I am a beginner and have coding experience in C and C++. Currently, I am
involved in network-related programming and I am keen on taking up this
project. I am currently working to rework current HTTP/1 client code to
make it input-driven and support non-blocking mode. I have already
downloaded a Git clone and read up the basics.

Looking forward for an exciting project!

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

Re: [FFmpeg-devel] [PATCH 2/4] x86: xvid_idct: port MMX IDCT to yasm

[Christophe Gisquet]

Hi,

2015-03-11 17:06 GMT+01:00 James Almer :
> As discussed before, mmx, mmxext and sse functions that have also an sse2 
> version, and
> 3dnow/3dnowext functions that have also an sse version, have no reason to 
> exist in an
> x86_64 build.

I think the reason may have been someone tinkering on some parts, and
testing them, could still see he broke the MMX versions.

On the other hand, that someone should really test on the appropriate
platform, which is easy on x86.

> They will not be used in any real world scenario.

Agreed, so I left the restriction.

Patch updated because of the dct-test stuff.

Incidentally, I found other issues with dct-test, but they are outside
the scope of this patch series.

-- 
Christophe
From 866b481ecab3369712ff854ce6c0857b875b50e6 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet 
Date: Tue, 10 Mar 2015 23:11:52 +
Subject: [PATCH 2/4] x86: xvid_idct: port MMX iDCT to yasm

Also reduce the table duplication with SSE2 code, remove duplicated
macro parameters.
---
 libavcodec/x86/Makefile|   1 -
 libavcodec/x86/dct-test.c  |   8 +-
 libavcodec/x86/xvididct.asm| 450 -
 libavcodec/x86/xvididct_init.c |  40 ++-
 libavcodec/x86/xvididct_mmx.c  | 549 -
 5 files changed, 484 insertions(+), 564 deletions(-)
 delete mode 100644 libavcodec/x86/xvididct_mmx.c

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index f46c7d5..87985f2 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -73,7 +73,6 @@ MMX-OBJS-$(CONFIG_FDCTDSP) += x86/fdct.o
 MMX-OBJS-$(CONFIG_IDCTDSP) += x86/simple_idct.o
 
 # decoders/encoders
-MMX-OBJS-$(CONFIG_MPEG4_DECODER)   += x86/xvididct_mmx.o
 MMX-OBJS-$(CONFIG_SNOW_DECODER)+= x86/snowdsp.o
 MMX-OBJS-$(CONFIG_SNOW_ENCODER)+= x86/snowdsp.o
 MMX-OBJS-$(CONFIG_VC1_DECODER) += x86/vc1dsp_mmx.o
diff --git a/libavcodec/x86/dct-test.c b/libavcodec/x86/dct-test.c
index e14ce9a..3a4c0df 100644
--- a/libavcodec/x86/dct-test.c
+++ b/libavcodec/x86/dct-test.c
@@ -60,11 +60,9 @@ static const struct algo idct_tab_arch[] = {
 #if HAVE_MMX_INLINE
 { "SIMPLE-MMX",  ff_simple_idct_mmx,  FF_IDCT_PERM_SIMPLE, AV_CPU_FLAG_MMX },
 #endif
-#if CONFIG_MPEG4_DECODER
-#if HAVE_MMX_INLINE
+#if CONFIG_MPEG4_DECODER && HAVE_YASM
+#if ARCH_X86_32
 { "XVID-MMX",ff_xvid_idct_mmx,FF_IDCT_PERM_NONE,   AV_CPU_FLAG_MMX,1 },
-#endif
-#if HAVE_MMXEXT_INLINE
 { "XVID-MMXEXT", ff_xvid_idct_mmxext, FF_IDCT_PERM_NONE,   AV_CPU_FLAG_MMXEXT, 1 },
 #endif
 #if HAVE_SSE2_EXTERNAL
@@ -73,7 +71,7 @@ static const struct algo idct_tab_arch[] = {
 { "PR-SSE2", ff_prores_idct_put_10_sse2_wrap, FF_IDCT_PERM_TRANSPOSE, AV_CPU_FLAG_SSE2, 1 },
 #endif
 #endif
-#endif /* CONFIG_MPEG4_DECODER */
+#endif /* CONFIG_MPEG4_DECODER && HAVE_YASM */
 { 0 }
 };
 
diff --git a/libavcodec/x86/xvididct.asm b/libavcodec/x86/xvididct.asm
index d16db34..4c52bf1 100644
--- a/libavcodec/x86/xvididct.asm
+++ b/libavcodec/x86/xvididct.asm
@@ -1,5 +1,9 @@
 ; XVID MPEG-4 VIDEO CODEC
-; - SSE2 inverse discrete cosine transform -
+;
+; Conversion from gcc syntax to x264asm syntax with modifications
+; by Christophe Gisquet 
+;
+; === SSE2 inverse discrete cosine transform ===
 ;
 ; Copyright(C) 2003 Pascal Massimino 
 ;
@@ -8,8 +12,6 @@
 ;
 ; Originally from dct/x86_asm/fdct_sse2_skal.asm in Xvid.
 ;
-; This file is part of FFmpeg.
-;
 ; Vertical pass is an implementation of the scheme:
 ;  Loeffler C., Ligtenberg A., and Moschytz C.S.:
 ;  Practical Fast 1D DCT Algorithm with Eleven Multiplications,
@@ -22,6 +24,32 @@
 ;
 ; More details at http://skal.planet-d.net/coding/dct.html
 ;
+; === MMX and XMM forward discrete cosine transform ===
+;
+; Copyright(C) 2001 Peter Ross 
+;
+; Originally provided by Intel at AP-922
+; http://developer.intel.com/vtune/cbts/strmsimd/922down.htm
+; (See more app notes at http://developer.intel.com/vtune/cbts/strmsimd/appnotes.htm)
+; but in a limited edition.
+; New macro implements a column part for precise iDCT
+; The routine precision now satisfies IEEE standard 1180-1990.
+;
+; Copyright(C) 2000-2001 Peter Gubanov 
+; Rounding trick Copyright(C) 2000 Michel Lespinasse 
+;
+; http://www.elecard.com/peter/idct.html
+; http://www.linuxvideo.org/mpeg2dec/
+;
+; These examples contain code fragments for first stage iDCT 8x8
+; (for rows) and first stage DCT 8x8 (for columns)
+;
+; conversion to gcc syntax by Michael Niedermayer
+;
+; ==
+;
+; 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
@@ -39,11 +67,13 @@
 %include "libavutil/x86/x86util.asm"
 
 SECTION_RODATA
+; Similar to tg_1_16 in MMX code
 tan1:   times 8 dw 13036
 tan

Re: [FFmpeg-devel] [PATCH 3/4] x86: xvid_idct: merged idct_put SSE2 versions

[Christophe Gisquet]

2015-03-11 0:11 GMT+01:00 Christophe Gisquet :
> ---
>  libavcodec/x86/xvididct.asm| 202 
> -
>  libavcodec/x86/xvididct_init.c |   8 +-
>  2 files changed, 140 insertions(+), 70 deletions(-)

Not sure it needed a refresh, but here is one.

-- 
Christophe
From 2bebf8537cbc0562ed6f6bfeb5b33fda72926969 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet 
Date: Tue, 10 Mar 2015 23:11:53 +
Subject: [PATCH 3/4] x86: xvid_idct: merged idct_put SSE2 versions

---
 libavcodec/x86/xvididct.asm| 202 -
 libavcodec/x86/xvididct_init.c |   8 +-
 2 files changed, 140 insertions(+), 70 deletions(-)

diff --git a/libavcodec/x86/xvididct.asm b/libavcodec/x86/xvididct.asm
index 4c52bf1..58ffb11 100644
--- a/libavcodec/x86/xvididct.asm
+++ b/libavcodec/x86/xvididct.asm
@@ -292,13 +292,13 @@ SECTION .text
 %define TAN3  xmm13
 %define TAN1  xmm14
 %else
-%define ROW0  [r0 + 0*16]
+%define ROW0  [BLOCK + 0*16]
 %define REG0  xmm4
-%define ROW2  [r0 + 2*16]
+%define ROW2  [BLOCK + 2*16]
 %define REG2  xmm4
-%define ROW4  [r0 + 4*16]
+%define ROW4  [BLOCK + 4*16]
 %define REG4  xmm6
-%define ROW6  [r0 + 6*16]
+%define ROW6  [BLOCK + 6*16]
 %define REG6  xmm6
 %define XMMS  xmm2
 %define SREG2 xmm7
@@ -369,8 +369,71 @@ SECTION .text
 movdqa   TAN1, [tan1]
 %endmacro
 
+%macro FIRST_HALF 2  ; %1=dct  %2=type(normal,add,put)
+psrawxmm5, 6
+psrawREG0, 6
+psrawTAN3, 6
+psrawxmm3, 6
+; dct coeffs must still be written for AC prediction
+%if %2 == 0
+movdqa   [%1+1*16], TAN3
+movdqa   [%1+2*16], xmm3
+movdqa   [%1+5*16], REG0
+movdqa   [%1+6*16], xmm5
+%else
+; Must now load args as gprs are no longer used for masks
+; DEST is set to where address of dest was loaded
+%if ARCH_X86_32
+%xdefine DEST r2q ; BLOCK is r0, stride r1
+movifnidn DEST, destm
+movifnidn strideq, stridem
+%else
+%xdefine DEST r0q
+%endif
+lea  r3q, [3*strideq]
+%if %2 == 1
+packuswb TAN3, xmm3
+packuswb xmm5, REG0
+movq [DEST + strideq], TAN3
+movhps   [DEST + 2*strideq], TAN3
+; REG0 and TAN3 are now available (and likely used in second half)
+%else
+%warning Unimplemented
+%endif
+%endif
+%endmacro
+
+%macro SECOND_HALF 6 ; %1=dct  %2=type(normal,add,put) 3-6: xmms
+psraw%3, 6
+psraw%4, 6
+psraw%5, 6
+psraw%6, 6
+; dct coeffs must still be written for AC prediction
+%if %2 == 0
+movdqa   [%1+0*16], %3
+movdqa   [%1+3*16], %5
+movdqa   [%1+4*16], %6
+movdqa   [%1+7*16], %4
+%elif %2 == 1
+packuswb %3, %5
+packuswb %6, %4
+; address of dest may have been loaded
+movq [DEST], %3
+movhps   [DEST + r3q], %3
+lea  DEST, [DEST + 4*strideq]
+movq [DEST], %6
+movhps   [DEST + r3q], %6
+; and now write remainder of first half
+movq [DEST + 2*strideq], xmm5
+movhps   [DEST + strideq], xmm5
+%elif %2 == 2
+%warning Unimplemented
+%endif
+%endmacro
+
+
 ; IDCT pass on columns.
-%macro iLLM_PASS  1  ;dct
+%macro iLLM_PASS  2  ; %1=dct  %2=type(normal,add,put)
 movdqa   xmm1, TAN3
 movdqa   xmm3, TAN1
 pmulhw   TAN3, xmm4
@@ -407,7 +470,7 @@ SECTION .text
 psubsw   xmm5, REG6
 MOV32ROW0, REG0
 MOV32ROW4, REG4
-MOV32TAN1, [r0]
+MOV32TAN1, [BLOCK]
 movdqa   XMMS, REG0
 psubsw   REG0, REG4
 paddsw   REG4, XMMS
@@ -423,33 +486,22 @@ SECTION .text
 movdqa   XMMS, REG0
 psubsw   REG0, xmm3
 paddsw   xmm3, XMMS
-MOV32[r0], TAN1
-psrawxmm5, 6
-psrawREG0, 6
-psrawTAN3, 6
-psrawxmm3, 6
-movdqa   [%1+1*16], TAN3
-movdqa   [%1+2*16], xmm3
-movdqa   [%1+5*16], REG0
-movdqa   [%1+6*16], xmm5
+MOV32[BLOCK], TAN1
+
+FIRST_HALF %1, %2
+
 movdqa   xmm0, xmm7
 movdqa   xmm4, REG4
 psubsw   xmm7, xmm1
 psubsw   REG4, TAN1
 paddsw   xmm1, xmm0
 paddsw   TAN1, xmm4
-psrawxmm1, 6
-psrawxmm7, 6
-psrawTAN1, 6
-psrawREG4, 6
-movdqa   [%1+0*16], xmm1
-movdqa   [%1+3*16], TAN1
-movdqa   [%1+4*16], REG4
-movdqa   [%1+7*16], xmm7
+
+SECOND_HALF %1, %2, xmm1, xmm7, TAN1, REG4
 %endmacro
 
 ; IDCT pass on columns, assuming rows 4-7 are zero
-%macro iLLM_PASS_SPARSE   1 ;dct
+%macro iLLM_PASS_SPARSE   2 ; %1=dct   %2=type(normal,put,add)
 pmulhw   TAN3, xmm4
 paddsw   TAN3, xmm4
 movdqa   xmm3, xmm6
@@ -475,7 +527,7 @@ SECTION .text
 movdqa   xmm6, REG0
 psubsw   xmm6, SREG2
 paddsw  SREG2, REG0
-MOV32TAN1, [r0]
+MOV32TAN1, [BLOCK]
 movdqa   XMMS, REG0
 psubsw   REG0, xmm5
 paddsw   xmm5, XMMS
@@ -485,70 +537,92 @@ SECTION .text
 movdqa   XMMS, REG0
 psubsw   REG0, xmm3
 paddsw   xmm3, XMMS
-MOV32[r0], TAN1
-psrawxmm5, 6
-psrawREG0, 6
-psrawTAN3, 6
-  

Re: [FFmpeg-devel] [PATCH 3/4] x86: xvid_idct: merged idct_put SSE2 versions

[Christophe Gisquet]

Hi,

2015-03-12 20:14 GMT+01:00 Christophe Gisquet :
> Not sure it needed a refresh, but here is one.

btw, the incorrect %warning code is actually dead, placeholder code
for the following patch 4/4 of the series.

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

Re: [FFmpeg-devel] [PATCH 4/4] x86: xvid_idct: SSE2 merged add version

[Christophe Gisquet]

2015-03-11 0:11 GMT+01:00 Christophe Gisquet :
> ---
>  libavcodec/x86/xvididct.asm| 92 
> --
>  libavcodec/x86/xvididct_init.c |  9 +
>  2 files changed, 91 insertions(+), 10 deletions(-)

Another refresh.
From 6044cf0ac09c93d363b4a5cf1496d1e330a2fe9b Mon Sep 17 00:00:00 2001
From: Christophe Gisquet 
Date: Tue, 10 Mar 2015 23:11:54 +
Subject: [PATCH 4/4] x86: xvid_idct: SSE2 merged add version

---
 libavcodec/x86/xvididct.asm| 92 --
 libavcodec/x86/xvididct_init.c |  9 +
 2 files changed, 91 insertions(+), 10 deletions(-)

diff --git a/libavcodec/x86/xvididct.asm b/libavcodec/x86/xvididct.asm
index 58ffb11..0220885 100644
--- a/libavcodec/x86/xvididct.asm
+++ b/libavcodec/x86/xvididct.asm
@@ -384,6 +384,12 @@ SECTION .text
 ; Must now load args as gprs are no longer used for masks
 ; DEST is set to where address of dest was loaded
 %if ARCH_X86_32
+%if %2 == 2 ; Not enough xmms, store
+movdqa   [%1+1*16], TAN3
+movdqa   [%1+2*16], xmm3
+movdqa   [%1+5*16], REG0
+movdqa   [%1+6*16], xmm5
+%endif
 %xdefine DEST r2q ; BLOCK is r0, stride r1
 movifnidn DEST, destm
 movifnidn strideq, stridem
@@ -397,8 +403,6 @@ SECTION .text
 movq [DEST + strideq], TAN3
 movhps   [DEST + 2*strideq], TAN3
 ; REG0 and TAN3 are now available (and likely used in second half)
-%else
-%warning Unimplemented
 %endif
 %endif
 %endmacro
@@ -427,7 +431,88 @@ SECTION .text
 movq [DEST + 2*strideq], xmm5
 movhps   [DEST + strideq], xmm5
 %elif %2 == 2
-%warning Unimplemented
+pxorxmm0, xmm0
+%if ARCH_X86_32
+; free: m3 REG0=m4 m5
+; input: m1, m7, m2, m6
+movqxmm3, [DEST+0*strideq]
+movqxmm4, [DEST+1*strideq]
+punpcklbw   xmm3, xmm0
+punpcklbw   xmm4, xmm0
+paddsw  xmm3, %3
+paddsw  xmm4, [%1 + 1*16]
+movq  %3, [DEST+2*strideq]
+movqxmm5, [DEST+  r3q]
+punpcklbw %3, xmm0
+punpcklbw   xmm5, xmm0
+paddsw%3, [%1 + 2*16]
+paddsw  xmm5, %5
+packuswbxmm3, xmm4
+packuswb  %3, xmm5
+movq[DEST+0*strideq], xmm3
+movhps  [DEST+1*strideq], xmm3
+movq[DEST+2*strideq], %3
+movhps  [DEST+  r3q], %3
+lea DEST, [DEST+4*strideq]
+movqxmm3, [DEST+0*strideq]
+movqxmm4, [DEST+1*strideq]
+movq  %3, [DEST+2*strideq]
+movqxmm5, [DEST+  r3q]
+punpcklbw   xmm3, xmm0
+punpcklbw   xmm4, xmm0
+punpcklbw %3, xmm0
+punpcklbw   xmm5, xmm0
+paddsw  xmm3, %6
+paddsw  xmm4, [%1 + 5*16]
+paddsw%3, [%1 + 6*16]
+paddsw  xmm5, %4
+packuswbxmm3, xmm4
+packuswb  %3, xmm5
+movq[DEST+0*strideq], xmm3
+movhps  [DEST+1*strideq], xmm3
+movq[DEST+2*strideq], %3
+movhps  [DEST+  r3q], %3
+%else
+; l1:TAN3=m13  l2:m3  l5:REG0=m8 l6=m5
+; input: m1, m7/SREG2=m9, TAN1=m14, REG4=m10
+movqxmm2, [DEST+0*strideq]
+movqxmm4, [DEST+1*strideq]
+movq   xmm12, [DEST+2*strideq]
+movq   xmm11, [DEST+  r3q]
+punpcklbw   xmm2, xmm0
+punpcklbw   xmm4, xmm0
+punpcklbw  xmm12, xmm0
+punpcklbw  xmm11, xmm0
+paddsw  xmm2, %3
+paddsw  xmm4, TAN3
+paddsw xmm12, xmm3
+paddsw xmm11, %5
+packuswbxmm2, xmm4
+packuswb   xmm12, xmm11
+movq[DEST+0*strideq], xmm2
+movhps  [DEST+1*strideq], xmm2
+movq[DEST+2*strideq], xmm12
+movhps  [DEST+  r3q], xmm12
+lea DEST, [DEST+4*strideq]
+movqxmm2, [DEST+0*strideq]
+movqxmm4, [DEST+1*strideq]
+movq   xmm12, [DEST+2*strideq]
+movq   xmm11, [DEST+  r3q]
+punpcklbw   xmm2, xmm0
+punpcklbw   xmm4, xmm0
+punpcklbw  xmm12, xmm0
+punpcklbw  xmm11, xmm0
+paddsw  xmm2, %6
+paddsw  xmm4, REG0
+paddsw xmm12, xmm5
+paddsw xmm11, %4
+packuswbxmm2, xmm4
+packuswb   xmm12, xmm11
+movq[DEST+0*strideq], xmm2
+movhps  [DEST+1*strideq], xmm2
+movq[DEST+2*strideq], xmm12
+movhps  [DEST+  r3q], xmm12
+%endif
 %endif
 %endmacro
 
@@ -623,6 +708,7 @@ cglobal xvid_idct_add, 0, NUM_GPRS, 8+7*ARCH_X86_64, dest, stride, block
 INIT_XMM sse2
 IDCT_SSE2 0
 IDCT_SSE2 1
+IDCT_SSE2 2
 
 %if ARCH_X86_32
 
diff --git a/libavcodec/x86/xvididct_init.c b/libavcodec/x86/xvididct_init.c
index 2530d7a..57f6ed6 100644
--- a/libavcodec/x86/xvididct_init.c
+++ b/libavcodec/x86/xvididct_init.c
@@ -27,12 +27,7 @@
 #include "xvididct.h"
 
 void ff_xvid_idct_put_sse2(uint8_t *dest, int line_size, short *block);
-
-static void xvid_idct_sse2_add(uint8_t *dest, int line_size, short *block)
-{
-ff_xvid_idct_sse2(block);
-ff_add_pixels_clamped(block, dest, line_size);
-}
+void ff_xvid_idct_add_sse2

Re: [FFmpeg-devel] [PATCH] hevcdsp: fix compilation for arm and aarch64

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 03:35:05PM -0300, James Almer wrote:
> Also add av_cold to ff_hevcdsp_init_arm.
> 
> Signed-off-by: James Almer 
> ---
> Untested as i lack the hardware (or qemu).
> 
>  libavcodec/arm/Makefile|  1 +
>  libavcodec/arm/hevcdsp_arm.h   | 26 ++
>  libavcodec/arm/hevcdsp_init_arm.c  | 32 
>  libavcodec/arm/hevcdsp_init_neon.c | 13 ++---
>  libavcodec/hevcdsp.c   |  2 +-
>  5 files changed, 62 insertions(+), 12 deletions(-)
>  create mode 100644 libavcodec/arm/hevcdsp_arm.h
>  create mode 100644 libavcodec/arm/hevcdsp_init_arm.c

applied

thanks

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

[FFmpeg-devel] [PATCH] flvdec: use flv_data_packet for TYPE_ONTEXTDATA

[Andreas Cadhalpun]

This was lost in commit ae48547a.

It fixes the following compiler warning:
warning: 'flv_data_packet' defined but not used

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/flvdec.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 1701f76..a51016e 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -832,8 +832,11 @@ static int flv_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 stream_type=FLV_STREAM_TYPE_DATA;
 if (size > 13 + 1 + 4 && dts == 0) { // Header-type metadata stuff
 meta_pos = avio_tell(s->pb);
-if (flv_read_metabody(s, next) <= 0) {
+ret = flv_read_metabody(s, next);
+if (ret <= 0) {
 goto skip;
+} else if (ret == TYPE_ONTEXTDATA) {
+return flv_data_packet(s, pkt, dts, next);
 }
 avio_seek(s->pb, meta_pos, SEEK_SET);
 }
-- 
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] GSoC '15 Introduction

[Ilinca Andrei]

Hello,

This is my first qualification task submit for the *d**irectshow digital
video capture *project. In this  link there
is my screenshot proving that I successfully made a filter graph using
"graphstudionext" that captures the video stream from a webcam and show it
on the screen . I am now working on the second part of the qual task, which
is adding an IPersistStream option to and from file for the dshow code base
for video module.

Roger Pack, thanks a lot for helping me out with this, your feedback has
been very useful!

Regards,
Andrei

On Thu, Mar 12, 2015 at 10:40 PM, Ilinca Andrei 
wrote:

> Hello,
>
> This is my first qualification task submit for the *d**irectshow digital
> video capture *project. I attached below a screenshot proving that I
> successfully made a filter graph using "graphstudionext" that captures the
> video stream from a webcam and show it on the screen . I am now working on
> the second part of the qual task, which is adding an IPersistStream
> option to and from file for the dshow code base for video module.
>
> Roger Pack, thanks a lot for helping me out with this, your feedback has
> been very useful!
>
> Regards,
> Andrei
>
> On Tue, Mar 10, 2015 at 12:14 AM, Ilinca Andrei  > wrote:
>
>> Hi,
>>
>> I'm currently working on* dshow digital video capture* and it's really
>> interesting, even if I' m making slow progress, as I' m not familiar with
>> "graphstudionext" and DShow principles .
>>
>> I decided to apply for another project as well, the *MPEG-4 ALS encoder**
>> project, *for two reasons, as suggested by a developer on IRC: it
>> involves more mathematical work and signal processing as well as giving
>> mentors more flexibilty and improving my understanding of ffmpeg.
>>
>> I will start with the links in the project description and work my way up
>> . Any thoughts/ advices are welcome .
>>
>> Regards,
>> Andrei
>>
>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/formats: replace non functional av_realloc() check by assert

[Michael Niedermayer]

Simply returning on failure without indicating failure does not work
it instead crashes later, its better to fail immedeately until the
failure is handled.

Signed-off-by: Michael Niedermayer 
---
 libavfilter/formats.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index f25328c..9e19613 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -416,8 +416,7 @@ AVFilterChannelLayouts *ff_all_channel_counts(void)
 do { \
 *ref = f;\
 f->refs = av_realloc(f->refs, sizeof(*f->refs) * ++f->refcount); \
-if (!f->refs)\
-return;  \
+av_assert0(f->refs); \
 f->refs[f->refcount-1] = ref;\
 } while (0)
 
-- 
1.7.9.5

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

[FFmpeg-devel] GSoC Unmentored Project Question

[Wes]

Hello,
I'm interested in participating in GSoC this year and the "Subtitles"
project sounds very interesting. However, I noticed this project idea
doesn't have a mentor currently, but Nicolas George is listed as a
potential backup mentor. If a mentor is not found, will he be promoted to
mentor? Also, should I begin working on the qualification task for this
idea, or should I wait until a mentor is found?


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

Re: [FFmpeg-devel] [PATCH] avfilter/formats: replace non functional av_realloc() check by assert

[Clément Bœsch]

On Thu, Mar 12, 2015 at 11:04:57PM +0100, Michael Niedermayer wrote:
> Simply returning on failure without indicating failure does not work
> it instead crashes later, its better to fail immedeately until the
> failure is handled.
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavfilter/formats.c |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavfilter/formats.c b/libavfilter/formats.c
> index f25328c..9e19613 100644
> --- a/libavfilter/formats.c
> +++ b/libavfilter/formats.c
> @@ -416,8 +416,7 @@ AVFilterChannelLayouts *ff_all_channel_counts(void)
>  do { \
>  *ref = f;\
>  f->refs = av_realloc(f->refs, sizeof(*f->refs) * ++f->refcount); \
> -if (!f->refs)\
> -return;  \
> +av_assert0(f->refs); \
>  f->refs[f->refcount-1] = ref;\
>  } while (0)
>  

this macro (FORMATS_REF) is used in ff_channel_layouts_ref() and
ff_formats_ref().

Both of these are currently returning void, but both of them are also
private, so there is nothing (AFAICT) that prevents changing their
prototype and making them return int / AVERROR(ENOMEM).

Asserting on the result of an alloc? Yeah, please don't. This sounds
fixable properly without that much more efforts.

-- 
Clément B.


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

Re: [FFmpeg-devel] GSoC Unmentored Project Question

[Nicolas George]

Le duodi 22 ventôse, an CCXXIII, Wes a écrit :
> I'm interested in participating in GSoC this year and the "Subtitles"
> project sounds very interesting. However, I noticed this project idea
> doesn't have a mentor currently, but Nicolas George is listed as a
> potential backup mentor. If a mentor is not found, will he be promoted to
> mentor?

There are currently three persons already working tasks for the
network-related project that I proposed, and I feel I am near the limit my
spare time allow me to to handle. I hope someone else will step up.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] avfilter/formats: proper error handling in ff_channel_layouts_ref() and ff_formats_ref()

[Clément Bœsch]

Also make sure the allocation and its check are properly done.
---
 libavfilter/formats.c | 20 +++-
 libavfilter/formats.h |  6 +++---
 2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index eb3b87a..47b20a4 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -411,19 +411,21 @@ AVFilterChannelLayouts *ff_all_channel_counts(void)
 return ret;
 }
 
-#define FORMATS_REF(f, ref)  \
-do { \
-*ref = f;\
-f->refs = av_realloc(f->refs, sizeof(*f->refs) * ++f->refcount); \
-f->refs[f->refcount-1] = ref;\
-} while (0)
-
-void ff_channel_layouts_ref(AVFilterChannelLayouts *f, AVFilterChannelLayouts 
**ref)
+#define FORMATS_REF(f, ref)
 \
+void *tmp = av_realloc_array(f->refs, sizeof(*f->refs), f->refcount + 1);  
 \
+if (!tmp)  
 \
+return AVERROR(ENOMEM);
 \
+f->refs = tmp; 
 \
+f->refs[f->refcount++] = ref;  
 \
+*ref = f;  
 \
+return 0
+
+int ff_channel_layouts_ref(AVFilterChannelLayouts *f, AVFilterChannelLayouts 
**ref)
 {
 FORMATS_REF(f, ref);
 }
 
-void ff_formats_ref(AVFilterFormats *f, AVFilterFormats **ref)
+int ff_formats_ref(AVFilterFormats *f, AVFilterFormats **ref)
 {
 FORMATS_REF(f, ref);
 }
diff --git a/libavfilter/formats.h b/libavfilter/formats.h
index 468eac8..f94855d 100644
--- a/libavfilter/formats.h
+++ b/libavfilter/formats.h
@@ -159,8 +159,8 @@ int ff_add_channel_layout(AVFilterChannelLayouts **l, 
uint64_t channel_layout);
 /**
  * Add *ref as a new reference to f.
  */
-void ff_channel_layouts_ref(AVFilterChannelLayouts *f,
-AVFilterChannelLayouts **ref);
+int ff_channel_layouts_ref(AVFilterChannelLayouts *f,
+   AVFilterChannelLayouts **ref);
 
 /**
  * Remove a reference to a channel layouts list.
@@ -233,7 +233,7 @@ AVFilterFormats *ff_merge_formats(AVFilterFormats *a, 
AVFilterFormats *b,
  *  | || || ||
  *  |||
  */
-void ff_formats_ref(AVFilterFormats *formats, AVFilterFormats **ref);
+int ff_formats_ref(AVFilterFormats *formats, AVFilterFormats **ref);
 
 /**
  * If *ref is non-NULL, remove *ref as a reference to the format list
-- 
2.3.2

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

Re: [FFmpeg-devel] [PATCH] avfilter/formats: proper error handling in ff_channel_layouts_ref() and ff_formats_ref()

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 11:39:12PM +0100, Clément Bœsch wrote:
> Also make sure the allocation and its check are properly done.
> ---
>  libavfilter/formats.c | 20 +++-
>  libavfilter/formats.h |  6 +++---
>  2 files changed, 14 insertions(+), 12 deletions(-)

LGTM

thanks

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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] flvdec: use flv_data_packet for TYPE_ONTEXTDATA

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 08:57:10PM +0100, Andreas Cadhalpun wrote:
> This was lost in commit ae48547a.
> 
> It fixes the following compiler warning:
> warning: 'flv_data_packet' defined but not used
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/flvdec.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

please see
[FFmpeg-devel] [PATCH 2/2] avformat/flvdec: re enable flv_data_packet() and use 
AVMEDIA_TYPE_SUBTITLE

also review for above linked patch is welcome


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 1/4] x86: xvid: port SSE2 idct to yasm

[Michael Niedermayer]

On Thu, Mar 12, 2015 at 08:09:35PM +0100, Christophe Gisquet wrote:
> Hi,
> 
> 2015-03-11 3:46 GMT+01:00 James Almer :
> > Should be YASM-OBJS, and moved to the end of the file.
> > Also, related to the build failure Michael mentioned for the second patch, 
> > this is
> > missing an inline -> external change in libavcodec/x86/dct-test.c
> 
> Here you are.
> 
> Passes fate-xvid-idct and dct-test builds and runs on both Win32 and Win64.
> 
> -- 
> Christophe

>  b/libavcodec/x86/Makefile|4 
>  b/libavcodec/x86/dct-test.c  |4 
>  b/libavcodec/x86/xvididct.asm|  379 
>  b/libavcodec/x86/xvididct_init.c |   18 +
>  libavcodec/x86/xvididct_sse2.c   |  406 
> ---
>  5 files changed, 398 insertions(+), 413 deletions(-)
> f0d22fc5a505e06184d1c88c3632c1d357d0f576  
> 0001-x86-xvid_idct-port-SSE2-iDCT-to-yasm.patch
> From 86da5a1f111f9f36318daa906c3245d6b883feb3 Mon Sep 17 00:00:00 2001
> From: Christophe Gisquet 
> Date: Tue, 10 Mar 2015 23:11:51 +
> Subject: [PATCH 1/4] x86: xvid_idct: port SSE2 iDCT to yasm

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH] [PATCH] lavfi: add inverse telecine filter

[Carl Eugen Hoyos]

Himangi Saraogi  gmail.com> writes:

> I am collecting suitable test samples

You should only test the filter with samples 
created with the telecine filter.

To test the start point in the telecine 
sequence, use -ss 0.x -vcodec copy (or 
similar options) to cut away the first 
frames.

The qualification task for the VDPAU 
filter is not to write a new telecine 
detection algorithm: If we hadn't 
already two filters, this would be a 
whole GSoC project.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]doc: Fix alphabetic ordering for decklink input device

[Carl Eugen Hoyos]

Michael Niedermayer  gmx.at> writes:

> > Attached patch improves the documentation imo, 
> > see http://ffmpeg.org/ffmpeg-devices.html
> > 
> > Please comment, Carl Eugen

Patch applied.

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]Print number of reference frames if debug level >= verbose

[Carl Eugen Hoyos]

Hi!

On Wednesday 11 March 2015 04:03:27 am Michael Niedermayer wrote:
> On Tue, Mar 10, 2015 at 03:27:20PM +0100, Carl Eugen Hoyos wrote:
> > +if (av_log_get_level() >= AV_LOG_VERBOSE && enc->refs)
> > +snprintf(buf + strlen(buf), buf_size - strlen(buf),
> > ", %d reference frame(s)", enc->refs);
>
> this should only be printed for video and the "s" should only be
> printed for refs > 1

New patch attached.

Thank you, Carl Eugen
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 5b28496..d739047 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3024,6 +3024,12 @@ void avcodec_string(char *buf, int buf_size, 
AVCodecContext *enc, int encode)
 
 if (profile)
 snprintf(buf + strlen(buf), buf_size - strlen(buf), " (%s)", profile);
+if (   enc->codec_type == AVMEDIA_TYPE_VIDEO
+&& av_log_get_level() >= AV_LOG_VERBOSE
+&& enc->refs)
+snprintf(buf + strlen(buf), buf_size - strlen(buf),
+ ", %d reference frame%s",
+ enc->refs, enc->refs > 1 ? "s" : "");
 
 if (enc->codec_tag) {
 char tag_buf[32];
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]Do not list mov codecs in riff.c

[Carl Eugen Hoyos]

Hi!

Attached patch fixes a regression caused by randomly added 
prores code-points in riff.c (similar to ticket #4307). As 
a side-effect, it shows a warning for such (probably 
invalid) files).

Please comment, Carl Eugen
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 5c9443a..00f0037 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -36,6 +36,7 @@
 #include "riff.h"
 #include "libavcodec/bytestream.h"
 #include "libavcodec/exif.h"
+#include "libavformat/isom.h"
 
 typedef struct AVIStream {
 int64_t frame_offset;   /* current frame (video) or byte (audio) counter
@@ -773,6 +774,12 @@ static int avi_read_header(AVFormatContext *s)
 st->codec->codec_tag  = tag1;
 st->codec->codec_id   = ff_codec_get_id(ff_codec_bmp_tags,
 tag1);
+if (!st->codec->codec_id) {
+st->codec->codec_id = 
ff_codec_get_id(ff_codec_movvideo_tags,
+  tag1);
+if (st->codec->codec_id)
+   av_log(s, AV_LOG_WARNING, "mov tag found in avi\n");
+}
 /* This is needed to get the pict type which is necessary
  * for generating correct pts. */
 st->need_parsing = AVSTREAM_PARSE_HEADERS;
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 399523c..edc6347 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -362,8 +362,6 @@ const AVCodecTag ff_codec_bmp_tags[] = {
 { AV_CODEC_ID_G2M,  MKTAG('G', '2', 'M', '4') },
 { AV_CODEC_ID_G2M,  MKTAG('G', '2', 'M', '5') },
 { AV_CODEC_ID_FIC,  MKTAG('F', 'I', 'C', 'V') },
-{ AV_CODEC_ID_PRORES,   MKTAG('A', 'P', 'C', 'N') },
-{ AV_CODEC_ID_PRORES,   MKTAG('A', 'P', 'C', 'H') },
 { AV_CODEC_ID_QTRLE,MKTAG('r', 'l', 'e', ' ') },
 { AV_CODEC_ID_HQX,  MKTAG('C', 'H', 'Q', 'X') },
 { AV_CODEC_ID_NONE, 0 }
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]Do not list mov codecs in riff.c

[Carl Eugen Hoyos]

On Friday 13 March 2015 02:36:00 am Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes a regression caused by randomly added
> prores code-points in riff.c (similar to ticket #4307). As
> a side-effect, it shows a warning for such (probably
> invalid) files).

Updated patch attached.

Carl Eugen
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 5c9443a..00f0037 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -36,6 +36,7 @@
 #include "riff.h"
 #include "libavcodec/bytestream.h"
 #include "libavcodec/exif.h"
+#include "libavformat/isom.h"
 
 typedef struct AVIStream {
 int64_t frame_offset;   /* current frame (video) or byte (audio) counter
@@ -773,6 +774,12 @@ static int avi_read_header(AVFormatContext *s)
 st->codec->codec_tag  = tag1;
 st->codec->codec_id   = ff_codec_get_id(ff_codec_bmp_tags,
 tag1);
+if (!st->codec->codec_id) {
+st->codec->codec_id = 
ff_codec_get_id(ff_codec_movvideo_tags,
+  tag1);
+if (st->codec->codec_id)
+   av_log(s, AV_LOG_WARNING, "mov tag found in avi\n");
+}
 /* This is needed to get the pict type which is necessary
  * for generating correct pts. */
 st->need_parsing = AVSTREAM_PARSE_HEADERS;
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 399523c..696b06b 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -362,9 +362,6 @@ const AVCodecTag ff_codec_bmp_tags[] = {
 { AV_CODEC_ID_G2M,  MKTAG('G', '2', 'M', '4') },
 { AV_CODEC_ID_G2M,  MKTAG('G', '2', 'M', '5') },
 { AV_CODEC_ID_FIC,  MKTAG('F', 'I', 'C', 'V') },
-{ AV_CODEC_ID_PRORES,   MKTAG('A', 'P', 'C', 'N') },
-{ AV_CODEC_ID_PRORES,   MKTAG('A', 'P', 'C', 'H') },
-{ AV_CODEC_ID_QTRLE,MKTAG('r', 'l', 'e', ' ') },
 { AV_CODEC_ID_HQX,  MKTAG('C', 'H', 'Q', 'X') },
 { AV_CODEC_ID_NONE, 0 }
 };
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]Do not list mov codecs in riff.c

[Michael Niedermayer]

On Fri, Mar 13, 2015 at 02:46:32AM +0100, Carl Eugen Hoyos wrote:
> On Friday 13 March 2015 02:36:00 am Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes a regression caused by randomly added
> > prores code-points in riff.c (similar to ticket #4307). As
> > a side-effect, it shows a warning for such (probably
> > invalid) files).
> 
> Updated patch attached.
> 
> Carl Eugen

>  avidec.c |7 +++
>  riff.c   |3 ---
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 7c301d00fc64be53584b4f6a2f54461bb85447e7  patchproresavi.diff
> diff --git a/libavformat/avidec.c b/libavformat/avidec.c
> index 5c9443a..00f0037 100644

LGTM


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

Re: [FFmpeg-devel] GSoC Unmentored Project Question

[Philip Langdale]

On Thu, 12 Mar 2015 23:17:54 +0100
Nicolas George  wrote:

> Le duodi 22 ventôse, an CCXXIII, Wes a écrit :
> > I'm interested in participating in GSoC this year and the
> > "Subtitles" project sounds very interesting. However, I noticed
> > this project idea doesn't have a mentor currently, but Nicolas
> > George is listed as a potential backup mentor. If a mentor is not
> > found, will he be promoted to mentor?
> 
> There are currently three persons already working tasks for the
> network-related project that I proposed, and I feel I am near the
> limit my spare time allow me to to handle. I hope someone else will
> step up.
> 
> Regards,
> 

There is a different subtitle related project that does have a
mentor. :-D

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

Re: [FFmpeg-devel] [PATCH]Print number of reference frames if debug level >= verbose

[Michael Niedermayer]

On Fri, Mar 13, 2015 at 02:11:54AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> On Wednesday 11 March 2015 04:03:27 am Michael Niedermayer wrote:
> > On Tue, Mar 10, 2015 at 03:27:20PM +0100, Carl Eugen Hoyos wrote:
> > > +if (av_log_get_level() >= AV_LOG_VERBOSE && enc->refs)
> > > +snprintf(buf + strlen(buf), buf_size - strlen(buf),
> > > ", %d reference frame(s)", enc->refs);
> >
> > this should only be printed for video and the "s" should only be
> > printed for refs > 1
> 
> New patch attached.
> 
> Thank you, Carl Eugen

>  utils.c |6 ++
>  1 file changed, 6 insertions(+)
> eaa8592e1307e4ed33bd65dbfd422b76d54b7029  patchrefs.diff
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 5b28496..d739047 100644

LGTM

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] [PATCH] lavfi: Add support to process_command in vf_eq.c

[arwa arif]

I have added the variable options. I have not done the refactoring part yet.
From 00052c1bbe5fe87d86fcff6f5e810290468d0251 Mon Sep 17 00:00:00 2001
From: Arwa Arif 
Date: Fri, 13 Mar 2015 11:37:40 +0530
Subject: [PATCH] Add variables to process_command in vf_eq

---
 doc/filters.texi|   16 +--
 libavfilter/vf_eq.c |   55 ++-
 libavfilter/vf_eq.h |   36 -
 3 files changed, 64 insertions(+), 43 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index dbcd391..cf482c8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4402,6 +4402,19 @@ Default is @code{1.0}.
 
 @end table
 
+These options accept the following parameters:
+
+@table
+@item n
+Frame count of the input frame starting from 0.
+
+@item r
+Frame rate of the input video, NAN if the input frame rate is unknown.
+
+@item t
+Timestamp expressed in seconds, NAN if the input timestamp is unknown.
+@end table
+
 @subsection Commands
 The filter supports the following commands:
 
@@ -4538,8 +4551,7 @@ The number of seconds for which the fade effect has to last. At the end of the
 fade-in effect the output video will have the same intensity as the input video,
 at the end of the fade-out transition the output video will be filled with the
 selected @option{color}.
-If both duration and nb_frames are specified, duration is used. Default is 0
-(nb_frames is used by default).
+If both duration and nb_frames are specified, duration is used. Default is 0.
 
 @item color, c
 Specify the color of the fade. Default is "black".
diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
index 980e9ca..4cbe617 100644
--- a/libavfilter/vf_eq.c
+++ b/libavfilter/vf_eq.c
@@ -27,11 +27,6 @@
  * very simple video equalizer
  */
 
-/**
- * TODO:
- * - Add support to process_command
- */
-
 #include "libavfilter/internal.h"
 #include "libavutil/common.h"
 #include "libavutil/imgutils.h"
@@ -111,16 +106,16 @@ static void check_values(EQParameters *param, EQContext *eq)
 
 static void set_contrast(EQContext *eq)
 {
-eq->var_values[VAR_CONTRAST] = av_clipf(av_expr_eval(eq->contrast_pexpr, eq->var_values, eq),-2.0, 2.0);
-eq->param[0].contrast = eq->var_values[VAR_CONTRAST];
+eq->contrast = av_clipf(av_expr_eval(eq->contrast_pexpr, eq->var_values, eq),-2.0, 2.0);
+eq->param[0].contrast = eq->contrast;
 eq->param[0].lut_clean = 0;
 check_values(&eq->param[0], eq);
 }
 
 static void set_brightness(EQContext *eq)
 {
-eq->var_values[VAR_BRIGHTNESS] =  av_clipf(av_expr_eval(eq->brightness_pexpr, eq->var_values, eq), -1.0, 1.0);
-eq->param[0].brightness = eq->var_values[VAR_BRIGHTNESS];
+eq->brightness =  av_clipf(av_expr_eval(eq->brightness_pexpr, eq->var_values, eq), -1.0, 1.0);
+eq->param[0].brightness = eq->brightness;
 eq->param[0].lut_clean = 0;
 check_values(&eq->param[0], eq);
 }
@@ -129,18 +124,18 @@ static void set_gamma(EQContext *eq)
 {
 int i;
 
-eq->var_values[VAR_GAMMA]=  av_clipf(av_expr_eval(eq->gamma_pexpr,eq->var_values, eq),  0.1, 10.0);
-eq->var_values[VAR_GAMMA_R]  =  av_clipf(av_expr_eval(eq->gamma_r_pexpr,  eq->var_values, eq),  0.1, 10.0);
-eq->var_values[VAR_GAMMA_G]  =  av_clipf(av_expr_eval(eq->gamma_g_pexpr,  eq->var_values, eq),  0.1, 10.0);
-eq->var_values[VAR_GAMMA_B]  =  av_clipf(av_expr_eval(eq->gamma_b_pexpr,  eq->var_values, eq),  0.1, 10.0);
-eq->var_values[VAR_GAMMA_WEIGHT] =  av_clipf(av_expr_eval(eq->gamma_weight_pexpr, eq->var_values, eq),  0.0,  1.0);
+eq->gamma=  av_clipf(av_expr_eval(eq->gamma_pexpr,eq->var_values, eq),  0.1, 10.0);
+eq->gamma_r  =  av_clipf(av_expr_eval(eq->gamma_r_pexpr,  eq->var_values, eq),  0.1, 10.0);
+eq->gamma_g  =  av_clipf(av_expr_eval(eq->gamma_g_pexpr,  eq->var_values, eq),  0.1, 10.0);
+eq->gamma_b  =  av_clipf(av_expr_eval(eq->gamma_b_pexpr,  eq->var_values, eq),  0.1, 10.0);
+eq->gamma_weight =  av_clipf(av_expr_eval(eq->gamma_weight_pexpr, eq->var_values, eq),  0.0,  1.0);
 
-eq->param[0].gamma = eq->var_values[VAR_GAMMA] * eq->var_values[VAR_GAMMA_G];
-eq->param[1].gamma = sqrt(eq->var_values[VAR_GAMMA_B] / eq->var_values[VAR_GAMMA_G]);
-eq->param[2].gamma = sqrt(eq->var_values[VAR_GAMMA_R] / eq->var_values[VAR_GAMMA_G]);
+eq->param[0].gamma = eq->gamma * eq->gamma_g;
+eq->param[1].gamma = sqrt(eq->gamma_b / eq->gamma_g);
+eq->param[2].gamma = sqrt(eq->gamma_r / eq->gamma_g);
 
 for (i = 0; i < 3; i++) {
-eq->param[i].gamma_weight = eq->var_values[VAR_GAMMA_WEIGHT];
+eq->param[i].gamma_weight = eq->gamma_weight;
 eq->param[i].lut_clean = 0;
 check_values(&eq->param[i], eq);
 }
@@ -150,10 +145,10 @@ static void set_saturation(EQContext *eq)
 {
 int i;
 
-eq->var_values[VAR_SATURATION] = av_clipf(av_expr_eval(eq->saturation_pexpr, eq->var_values, eq), 0.0, 3.0);