2018-07-06 11:35 GMT+02:00, Gyan Doshi :
> +@item KEEP
> +Set to @samp{1} to keep temp files generated by fate test(s) when test is
> successful.
> +Default is @samp{0}, which removes these files. Files are always kept when a
> test
> +fails.
Sorry for the late comment:
Shouldn't this be -1
Test command:
ffplay -f lavfi -i "color,\
drawtext=fontfile='arial.ttf':fontcolor=white:fontsize=H/5:\
text='A string of characters':\
box=1:boxcolor=green:boxborderw=5:\
x='w-w*t/5':y=-th+h*t/10"
From b98969d12b3f6959ab1a036f20ba649951bcd1ea Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date:
2018-07-05 13:00 GMT+02:00, hwren :
> Signed-off-by: hwren
> ---
> libavformat/riff.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/riff.c b/libavformat/riff.c
> index 8911725..4153372 100644
> --- a/libavformat/riff.c
> +++ b/libavformat/riff.c
> @@ -369,6 +369,7 @@ const
On 10-07-2018 05:40 PM, Carl Eugen Hoyos wrote:
Shouldn't this be -1 for keep if fail, 0 for always delete, 1 for keep?
$keep is checked only when $err = 0 i.e.
a) passed test or
b) failed test and GEN != no
In the 2nd case, since user has decided to overwrite existing ref, I
assume the
2018-05-26 8:50 GMT+02:00, hwren :
> diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
> index 272e2be..b37db3c 100644
> --- a/libavformat/mpegts.h
> +++ b/libavformat/mpegts.h
> @@ -55,6 +55,7 @@
> #define STREAM_TYPE_VIDEO_H264 0x1b
> #define STREAM_TYPE_VIDEO_HEVC 0x24
>
2018-07-10 14:50 GMT+02:00, Carl Eugen Hoyos :
> 2018-07-05 13:00 GMT+02:00, hwren :
>> Signed-off-by: hwren
>> ---
>> libavformat/riff.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/riff.c b/libavformat/riff.c
>> index 8911725..4153372 100644
>> ---
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Moritz Barsnick
> Sent: Thursday, July 5, 2018 9:20 PM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_qsv: fix log level for
>
Thanks for the explanation Nicolas.
When the matrix is not explicitly provided, lswr computes it. For that,
> it needs the channel layout, because you do not mix a rear channel the
> same way as a subwoofer. This patch absolutely needs to be tested under
> these circumstances too.
>
This patch
Hi Michael,
I think I know where the misunderstanding could be.
The main changes in my patch are:
rematrix.c:389 and rematrix_int.c:36:
Before:
int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout)
After:
int nb_in = s->in_ch_layout != 0
?
Hi,
I suffered a problem that when I decoded the HEVC WPP video with
ffmpeg 4.0 with the option "-thread_type slice", there was something wrong
with the output stream. Please find the attachment for the screenshot.
This is the command: ffmpeg.exe -thread_type slice -threads 16 -i
---
Sending updated patch based on Mark's review
1) added RGBA/BGRA
2) in case is device_ctx is set there is only the device hw format will be
allowed as input and output
3) extended amf properties removed for now to have usual for ffmpeg
scaler converter interface
4) input frame colorspace is
---
libavcodec/amfenc.c| 247 +
libavcodec/amfenc.h| 27 +---
libavutil/Makefile | 2 +
libavutil/hwcontext.c | 4 +
libavutil/hwcontext.h | 1 +
libavutil/hwcontext_amf.c | 271
Hi,
Patch attached.
-Umair
0001-avformat-lrcdec-fix-losing-opening-bracket.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
Sorry for the slow response; life is hectic.
On Tue, Jun 19, 2018 at 8:32 PM, Michael Niedermayer
wrote:
> The absolute values define the bitstream and have to be used
OK, I was unaware.
> with a count of 4, mjpeg is coded in MCUs of 4 8x8 blocks in that direction
> all buffers must be
Hi,
Apologies for commenting on this so many months after it was pushed.
> ffmpeg | branch: master | Sasi Inguva |
> Mon Dec 18 15:31:16 2017 -0800| [58a25aeb8e69532aae6ed1762fe7e0b260990010] |
> committer: Michael Niedermayer
>
> lavf/mov.c: Guess video codec delay based on PTS while parsing
Plan to push in a day if no objections.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi Marton et al,
I am revisiting this now that I have access to the BlackMagic DeckLink Duo
again. I see what made it into master and had a few questions.
1) Can you please explain more about storing the timecodes as side packet data
in each video packet? Basically is there some convention
Ping - What about this one? I tested it with about 20 files and it works
perfectly
for all of them - except one which has tag/padding. In its case, playback
quality
is virtually the same as without the patch, i.e. no harm done.
Cheers, Karsten
> Am 07.07.2018 um 19:41 schrieb Karsten Otto :
>
On Tue, Jul 10, 2018 at 11:31:39AM -0400, Derek Buitenhuis wrote:
> Hi,
>
> Apologies for commenting on this so many months after it was pushed.
>
> > ffmpeg | branch: master | Sasi Inguva |
> > Mon Dec 18 15:31:16 2017 -0800| [58a25aeb8e69532aae6ed1762fe7e0b260990010]
> > | committer:
On Tue, Jul 10, 2018 at 05:30:15PM +0300, Alexander Kravchenko wrote:
> ---
> Sending updated patch based on Mark's review
> 1) added RGBA/BGRA
> 2) in case is device_ctx is set there is only the device hw format will be
> allowed as input and output
> 3) extended amf properties removed for now
0.266 <- 0.299 sec (this is time ffmpeg so containing alot other things)
Sample for benchmark was: ffmpeg -f rawvideo -pix_fmt yuv420p -s 32x32 -i
/dev/zero -t 24:00:00.00 out.mp4
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
0.324 <-0.491 sec
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1346ffe480..aabf06de12 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3310,13
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 67b3e11eb9..951a337cca 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3310,13 +3310,12 @@ static void
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index aabf06de12..67b3e11eb9 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3301,25 +3301,22 @@
2018-07-10 17:31 GMT+02:00, Derek Buitenhuis :
> On an example file (24h long, warm runs):
>
> Before Patch
>
> 4446217810 decicycles in mov_build_index, 1 runs, 0 skips
> 4603125860 decicycles in mov_build_index, 2 runs, 0 skips
>
> After
2018-07-10 17:31 GMT+02:00, Derek Buitenhuis :
> On an example file (24h long, warm runs):
>
> Before Patch
>
> 4446217810 decicycles in mov_build_index, 1 runs, 0 skips
> 4603125860 decicycles in mov_build_index, 2 runs, 0 skips
>
> After
2018-07-11 0:37 GMT+02:00, Jun Zhao :
> use pixelutils API for sad in motion estimation.
Some performance number make sense for the commit message imo.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
This codec is already capable of depacking some combinations of pixel
formats and depth as defined in the RFC4175. The only difference between
progressive and interlace is that either a packet will contain the whole
frame, or only a field of the frame.
There is no mechanism for interlaced frames
From: Damien Riegel
In order to handle the interlaced formats, the demuxer has only a few
things to do:
- parse the SDP correctly and propagate the information
- check the field bit in the RFC4175 header, and pass that information
to the decoder
In interlaced mode, received data only
Ancillary data can carry various side data that can't be transmitted in
bitstreams. For now, this struct includes interlaced field flags and
the must be attached to an AVPacket as side data.
Signed-off-by: Patrick Keroulas
---
Changes v7 -> v8:
* Merge the definition of AVAncillaryData and its
add sad_32x32 in pixelutils API, and update the fate.
Signed-off-by: Jun Zhao
---
libavutil/pixelutils.c |2 ++
libavutil/tests/pixelutils.c |2 +-
tests/ref/fate/pixelutils| 12
3 files changed, 15 insertions(+), 1 deletions(-)
diff --git
2018-07-10 16:30 GMT+02:00, Alexander Kravchenko :
> 1) added RGBA/BGRA
> +static const enum AVPixelFormat input_pix_fmts[] = {
> +AV_PIX_FMT_NV12,
> +AV_PIX_FMT_0RGB,
> +AV_PIX_FMT_BGR0,
> +AV_PIX_FMT_RGB0,
> +AV_PIX_FMT_GRAY8,
> +
use pixelutils API for sad in motion estimation.
Signed-off-by: Jun Zhao
---
libavfilter/motion_estimation.c | 12 +---
libavfilter/motion_estimation.h |2 ++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavfilter/motion_estimation.c
add ff_pixelutils_sad_32x32_sse2, ff_pixelutils_sad_{a,u}_32x32_sse2,
ff_pixelutils_sad_32x32_avx22, ff_pixelutils_sad_{a,u}_32x32_avx2
Signed-off-by: Jun Zhao
---
libavutil/x86/pixelutils.asm| 220 +++
libavutil/x86/pixelutils_init.c | 30 ++
2
On Tue, Jul 10, 2018 at 4:46 PM, Carl Eugen Hoyos wrote:
> Is it possible to produce such a sample with FFmpeg?
The slow down happens with all MP4 and MOV files, but if you just want
a long sample that makes it obvious, yes ffmpeg can make it.
Probably something like (untested):
ffmpeg -f
On Wed, Jul 11, 2018 at 7:47 AM Carl Eugen Hoyos wrote:
>
> 2018-07-11 0:37 GMT+02:00, Jun Zhao :
> > use pixelutils API for sad in motion estimation.
>
> Some performance number make sense for the commit message imo.
>
> Carl Eugen
Will update performance number in next version, Thanks
On Wed, Jul 11, 2018 at 06:37:37AM +0800, Jun Zhao wrote:
> use pixelutils API for sad in motion estimation.
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/motion_estimation.c | 12 +---
> libavfilter/motion_estimation.h |2 ++
> 2 files changed, 11 insertions(+), 3 deletions(-)
Steven Liu 于2018年7月9日周一 下午5:12写道：
>
> fix ticket: 7305
> vs->sequence - hls->start_sequence - vs->nb_entries is the
> after_init_list_dur fragment numbers
> fix the wrong compute way vs->sequence - vs->nb_entries
>
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 2 +-
> 1 file
On Wed, Jul 11, 2018 at 8:31 AM Michael Niedermayer
wrote:
>
> On Wed, Jul 11, 2018 at 06:37:37AM +0800, Jun Zhao wrote:
> > use pixelutils API for sad in motion estimation.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavfilter/motion_estimation.c | 12 +---
> >
39 matches
Mail list logo
