Re: [FFmpeg-devel] [PATCH 2/4] x86: xvid_idct: port MMX IDCT to yasm
On 11/03/15 11:29 AM, Christophe Gisquet wrote: Hi, 2015-03-11 15:20 GMT+01:00 Michael Niedermayer michae...@gmx.at: 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
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
2015-03-11 2:26 GMT+01:00 Michael Niedermayer michae...@gmx.at: 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
Re: [FFmpeg-devel] DCA Decoder
On 11 March 2015 at 14:42, Marcus Johnson bumblebritche...@gmail.com 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]doc: Fix alphabetic ordering for decklink input device
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 CHANNELS
+Number of audio channels, can be 2, 8 or 16
+
+@item bm_audiodepth BITDEPTH
+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 CHANNELS
-Number of audio channels, can be 2, 8 or 16
-
-@item bm_audiodepth BITDEPTH
-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] [PATCH 2/2] Moved templated c postprocessing routines into seperate file
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; xBLOCK_SIZE; x++){
+const int first= FFABS(src[0] - src[l1]) c-QP ? 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; xBLOCK_SIZE; x++){
+int a= src[l3] - src[l4];
+int b= src[l4] - src[l5];
+int c= src[l5] - src[l6];
+
+int d= FFABS(b) - ((FFABS(a) + FFABS(c))1);
+d= FFMAX(d, 0);
+
+if(d co-QP*2){
+int v = d * FFSIGN(-b);
+
+src[l2] +=v3;
+src[l3] +=v2;
+src[l4] +=(3*v)3;
+src[l5] -=(3*v)3;
+src[l6] -=v2;
+src[l7] -=v3;
+}
+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; xBLOCK_SIZE; x++){
+const int middleEnergy= 5*(src[l5] - src[l4]) + 2*(src[l3] - src[l6]);
+if(FFABS(middleEnergy) 8*c-QP){
+const int q=(src[l4] - src[l5])/2;
+const int leftEnergy=
[FFmpeg-devel] [PATCH 1/2] Moved postprocessing routines from postprocess.c to seperate file
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; yBLOCK_SIZE; y++){
-numEq += ((unsigned)(src[0] - src[1] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[1] - src[2] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[2] - src[3] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[3] - src[4] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[4] - src[5] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[5] - src[6] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[6] - src[7] + dcOffset)) dcThreshold;
-src+= stride;
-}
-return numEq 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; yBLOCK_SIZE-1; y++){
-numEq += ((unsigned)(src[0] - src[0+stride] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[1] - src[1+stride] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[2] - src[2+stride] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[3] - src[3+stride] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[4] - src[4+stride] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[5] - src[5+stride] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[6] - src[6+stride] + dcOffset)) dcThreshold;
-numEq += ((unsigned)(src[7] - src[7+stride] + dcOffset)) dcThreshold;
-src+= stride;
-}
-return numEq c-ppMode.flatnessThreshold;
-}
-
-static inline int isHorizMinMaxOk_C(const uint8_t src[], int stride, int QP)
-{
-int i;
-for(i=0; i2; 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; xBLOCK_SIZE; x+=4){
-if((unsigned)(src[ x + 0*stride] - src[ x + 5*stride] + 2*QP)
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; yBLOCK_SIZE; y++){
-const int middleEnergy= 5*(dst[4] - dst[3]) + 2*(dst[2] - dst[5]);
-
-if(FFABS(middleEnergy) 8*c-QP){
-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(q0)
-
Re: [FFmpeg-devel] [PATCH] avcodec/vp9: Fix undefined shifts in decode_frame_header()
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 tfo...@google.com
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
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
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
Re: [FFmpeg-devel] [PATCH] avcodec/vp9: Fix undefined shifts in decode_frame_header()
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 michae...@gmx.at
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 michae...@gmx.at
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 tfo...@google.com
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
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
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 michae...@gmx.at wrote: Found-by: Clang -fsanitize=shift Reported-by: Thierry Foucu tfo...@google.com Signed-off-by: Michael Niedermayer michae...@gmx.at --- 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/h264_mb: Fix undefined shifts
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 michae...@gmx.at 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 michae...@gmx.at wrote: Found-by: Clang -fsanitize=shift Reported-by: Thierry Foucu tfo...@google.com Signed-off-by: Michael Niedermayer michae...@gmx.at --- 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()
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 michae...@gmx.at
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 tfo...@google.com
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
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] DCA Decoder
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
[FFmpeg-devel] [PATCH 1/2] hevc: avoid unnecessary calls to get_format
---
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
--- 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
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] [PATCH] avcodec/h264_mb: Fix undefined shifts
Hi, On Thu, Mar 12, 2015 at 9:37 AM, Michael Niedermayer michae...@gmx.at 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 michae...@gmx.at wrote: Found-by: Clang -fsanitize=shift Reported-by: Thierry Foucu tfo...@google.com Signed-off-by: Michael Niedermayer michae...@gmx.at --- 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/h264_mb: Fix undefined shifts
Hi, 2015-03-12 14:37 GMT+01:00 Michael Niedermayer michae...@gmx.at: 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/vp9: Fix undefined shifts in decode_frame_header()
Hi,
On Thu, Mar 12, 2015 at 9:41 AM, Michael Niedermayer michae...@gmx.at
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 tfo...@google.com
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
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 1/2] hevc: avoid unnecessary calls to get_format
Rainer Hochecker fernetmenta at 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
On Thu, Mar 12, 2015 at 08:10:17AM -0400, compn wrote: On Thu, 12 Mar 2015 11:47:55 + Derek Buitenhuis derek.buitenh...@gmail.com 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 2/2] hevc: delay ff_thread_finish_setup for hwaccel
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/vp9: Fix undefined shifts in decode_frame_header()
Hi,
On Thu, Mar 12, 2015 at 10:16 AM, Michael Niedermayer michae...@gmx.at
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 michae...@gmx.at
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 tfo...@google.com
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
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
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]Do not list mov codecs in riff.c
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] [PATCH]Print number of reference frames if debug level = verbose
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] avcodec/h264_mb: Fix undefined shifts
On Thu, Mar 12, 2015 at 03:39:51PM +0100, Christophe Gisquet wrote: Hi, 2015-03-12 14:37 GMT+01:00 Michael Niedermayer michae...@gmx.at: 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 v3] mips/asmdefs: use _ABI64 as defined by gcc
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 james...@cowgill.org.uk --- 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
Re: [FFmpeg-devel] [PATCH 2/4] x86: xvid_idct: port MMX IDCT to yasm
Hi,
2015-03-11 17:06 GMT+01:00 James Almer jamr...@gmail.com:
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 christophe.gisq...@gmail.com
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 christophe.gisq...@gmail.com
+;
+; === SSE2 inverse discrete cosine transform ===
;
; Copyright(C) 2003 Pascal Massimino s...@planet-d.net
;
@@ -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 pr...@xvid.org
+;
+; 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 pe...@elecard.net.ru
+; Rounding trick Copyright(C) 2000 Michel Lespinasse wal...@zoy.org
+;
+; 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 @@
Re: [FFmpeg-devel] [PATCH 3/4] x86: xvid_idct: merged idct_put SSE2 versions
2015-03-11 0:11 GMT+01:00 Christophe Gisquet christophe.gisq...@gmail.com: --- 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 christophe.gisq...@gmail.com 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 -
Re: [FFmpeg-devel] GSoC '15 Introduction
Hello, This is my first qualification task submit for the *d**irectshow digital video capture *project. In this http://i.imgur.com/zd47rP3.png 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 andrei.ilinc...@gmail.com 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 andrei.ilinc...@gmail.com 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
Re: [FFmpeg-devel] [PATCH] hevcdsp: fix compilation for arm and aarch64
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 jamr...@gmail.com --- 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
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 andreas.cadhal...@googlemail.com
---
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] [PATCH 1/4] x86: xvid: port SSE2 idct to yasm
Hi,
2015-03-11 3:46 GMT+01:00 James Almer jamr...@gmail.com:
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 christophe.gisq...@gmail.com
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 s...@planet-d.net
+;
+; Conversion to gcc syntax with modifications
+; by Alexander Strange astra...@ithinksw.com
+;
+; 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,
Re: [FFmpeg-devel] [PATCH 4/4] x86: xvid_idct: SSE2 merged add version
2015-03-11 0:11 GMT+01:00 Christophe Gisquet christophe.gisq...@gmail.com:
---
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 christophe.gisq...@gmail.com
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);
-
Re: [FFmpeg-devel] [PATCH 3/4] x86: xvid_idct: merged idct_put SSE2 versions
Hi, 2015-03-12 20:14 GMT+01:00 Christophe Gisquet christophe.gisq...@gmail.com: 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
[FFmpeg-devel] GSoC Introduction
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 1/4] x86: xvid: port SSE2 idct to yasm
On Thu, Mar 12, 2015 at 08:09:35PM +0100, Christophe Gisquet wrote: Hi, 2015-03-11 3:46 GMT+01:00 James Almer jamr...@gmail.com: 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 christophe.gisq...@gmail.com 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
Himangi Saraogi himangi774 at 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
[FFmpeg-devel] [PATCH] avfilter/formats: replace non functional av_realloc() check by assert
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 michae...@gmx.at
---
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
Re: [FFmpeg-devel] [PATCH] avfilter/formats: replace non functional av_realloc() check by assert
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 michae...@gmx.at
---
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
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] GSoC Unmentored Project Question
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
[FFmpeg-devel] [PATCH] avfilter/formats: proper error handling in ff_channel_layouts_ref() and ff_formats_ref()
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] avcodec/h264_mb: Fix undefined shifts
Hi, On Wed, Mar 11, 2015 at 9:00 PM, Michael Niedermayer michae...@gmx.at wrote: Found-by: Clang -fsanitize=shift Reported-by: Thierry Foucu tfo...@google.com Signed-off-by: Michael Niedermayer michae...@gmx.at --- 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] DCA Decoder
On Thu, 12 Mar 2015 11:47:55 + Derek Buitenhuis derek.buitenh...@gmail.com 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
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
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
On Thu, 12 Mar 2015 11:47:55 + Derek Buitenhuis derek.buitenh...@gmail.com 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] [PATCH] avfilter/formats: proper error handling in ff_channel_layouts_ref() and ff_formats_ref()
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
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 andreas.cadhal...@googlemail.com --- 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]Print number of reference frames if debug level = verbose
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
Re: [FFmpeg-devel] [PATCH]doc: Fix alphabetic ordering for decklink input device
Michael Niedermayer michaelni at 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
[FFmpeg-devel] [PATCH]Do not list mov codecs in riff.c
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
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]Add one CRLF to http headers if necessary
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
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 jeremyl...@gmail.com
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 jeremyl...@gmail.com
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)
