On Sat, Jun 5, 2021 at 10:41 PM Gustav Grusell
wrote:
> Before, seeking in hls streams would always seek to the next keyframe
> after the given timestamp.
> With this fix, if AVSEEK_FLAG_BACKWARD is set, seeking will be to the
> first keyframe of the
> segment containing the given timestamp. This
Since commit 89ffcd1, the status pts of the output link is set to a
value in the input link time base, not in the output link time base when
EOF is reached. Usually this pst value is larger than the required one
because the output link time base is more greater than the input link
time base. When "
The time base used for compressed bitstream and video frame in the SDK
is { 1, 9 }. [1][2]
This can avoid the error message below from the muxer.
$> ffmpeg -hwaccel qsv -c:v hevc_qsv -i input.h265 -f null -
...
[null @ 0x561c24f6f2f0] Application provided invalid, non monotonically
increasing
>
> Jun 10, 2021, 12:27 by d...@lynne.ee:
>
> > Jun 10, 2021, 03:38 by wenbin.c...@intel.com:
> >
> >>> Jun 8, 2021, 07:38 by wenbin.c...@intel.com:
> >>>
> >>> >> Apr 29, 2021, 03:52 by d...@lynne.ee:
> >>> >>
> >>> >> > This patch allows for alternative loader implementations.
> >>> >> >
> >
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Shubhanshu Saxena
> Sent: 2021年6月6日 2:08
> To: ffmpeg-devel@ffmpeg.org
> Cc: Shubhanshu Saxena
> Subject: [FFmpeg-devel] [PATCH V2 5/5] lavfi/dnn: Fill Task using Common
> Function
>
> This commit adds a common function for filli
Mohammad Izadi:
> HDR10+ metadata is stored in the bit stream for HEVC. The story is different
> for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
> passed to packet side data an stored in the container (mkv) for VP9.
>
> This CL is taking HDR10+ from AVFrame side data in
чт, 10 июн. 2021 г., 20:33 James Zern :
> On Thu, Jun 10, 2021 at 9:26 AM Валерий Заподовников
> wrote:
> >
> > >This doesn't match the check in libdav1d.c.
> >
> > I do not really care what libdav1d.c does, since it uses internal to AV1
> spec DAV1D_MC_IDENTITY (and frame->colorspace). This shou
Add () to avoid undefined behavior
Fixes: signed integer overflow: 9223372036854775790 + 57 cannot be represented
in type 'long'
Fixes:
34983/clusterfuzz-testcase-minimized-ffmpeg_dem_RPL_fuzzer-5765822923538432
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master
On Mon, Jun 7, 2021 at 8:09 PM Jan Ekström wrote:
>
> From: zheng qian
>
> Writes a general ARIB stream identifier descriptor, as well
> as a data component descriptor which also includes a
> pre-defined additional_arib_caption_info structure.
>
> Signed-off-by: zheng qian
> ---
Applied as f384
Hi again,
some of you might have realized that I've removed Valerii Zapodovnikov from our
mailing list after [1].
I did this in my function as a mailing list admin because I think our
guidelines for the mailing list are mandatory for everyone to be welcome here.
Plain rejection of these guide
Applied, thanks!
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org w
Hi all,
some of you might have realized that I've removed Valerii Zapodovnikov from our
mailing list after [1].
I did this in my function as a mailing list admin because I think our
guidelines for the mailing list are mandatory for everyone to be welcome here.
Plain rejection of these guideline
Am 10.06.21 um 20:26 schrieb Balling:
> чт, 10 июн. 2021 г., 20:33 James Zern :
>
>> On Thu, Jun 10, 2021 at 9:26 AM Валерий Заподовников
>> wrote:
>>>
This doesn't match the check in libdav1d.c.
>>>
>>> I do not really care what libdav1d.c does, since it uses internal to AV1
>> spec DAV1D_M
On 6/10/2021 3:18 PM, Michael Niedermayer wrote:
On Wed, Jun 09, 2021 at 03:07:41PM -0300, James Almer wrote:
It can be useful to library users, and is currently being used by ffmpeg.c
Suggested-by: Hendrik Leppkes
Signed-off-by: James Almer
---
doc/APIchanges | 3 +++
libavformat
On Wed, Jun 09, 2021 at 03:07:41PM -0300, James Almer wrote:
> It can be useful to library users, and is currently being used by ffmpeg.c
>
> Suggested-by: Hendrik Leppkes
> Signed-off-by: James Almer
> ---
> doc/APIchanges | 3 +++
> libavformat/avformat.h | 17 +++--
> li
On Wed, Jun 09, 2021 at 03:07:41PM -0300, James Almer wrote:
> It can be useful to library users, and is currently being used by ffmpeg.c
>
> Suggested-by: Hendrik Leppkes
> Signed-off-by: James Almer
> ---
> doc/APIchanges | 3 +++
> libavformat/avformat.h | 17 +++--
> li
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
On Tue, Jun 8, 2021 at 12:01 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Andreas Rheinhardt:
> > Mohammad Izadi:
> >> HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should be pass
Quoting Michael Niedermayer (2021-06-01 15:02:27)
> On Mon, May 31, 2021 at 09:55:11AM +0200, Anton Khirnov wrote:
> > Currently existing sws_scale() accepts as input a user-determined slice
> > of input data and produces an indeterminate number of output lines.
>
> swscale() should return the num
That function pointer is now used only for unscaled conversion.
---
libswscale/aarch64/swscale_unscaled.c | 2 +-
libswscale/arm/swscale_unscaled.c | 6 +--
libswscale/ppc/yuv2yuv_altivec.c | 4 +-
libswscale/swscale.c | 5 +-
libswscale/swscale_internal.h |
On 6/10/2021 12:01 PM, Anton Khirnov wrote:
Quoting James Almer (2021-05-31 13:56:20)
On 5/31/2021 6:26 AM, Anton Khirnov wrote:
There seems to be no compelling reason for it to be inline.
---
libavutil/mem.c | 18 ++
libavutil/mem.h | 19 +--
2 files chan
Quoting James Almer (2021-05-31 13:56:20)
> On 5/31/2021 6:26 AM, Anton Khirnov wrote:
> > There seems to be no compelling reason for it to be inline.
> > ---
> > libavutil/mem.c | 18 ++
> > libavutil/mem.h | 19 +--
> > 2 files changed, 19 insertions(+), 18 del
Fixes: Timeout
Fixes:
34950/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5686764151898112
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/faxcompr.c | 5 -
1 file changed,
Fixes: signed integer overflow: 9223126845747118112 - -2594073385365397472
cannot be represented in type 'long'
Fixes:
34936/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-6739888002170880
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ff
Fixes: Timeout
Fixes:
34950/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5686764151898112
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/faxcompr.c | 2 ++
1 file changed, 2
Let me respond on two levels.
Before exploring the design space of a separation of libavdevice and
libavformat below, I think it is important to first comment on the
current state (and whether the AVDevice Capabilities part of my patch
series should be blocked by this discussion).
Importantly, I
Compared to gmtime and localtime, rtctime has higher resolution.
For example, it can be used to show the end-to-end latency. On
the same host, publish a stream by:
./ffmpeg \
-re -f lavfi -i "color=color=blue:size=1280x720:rate=60" \
-c:v libx264 \
-tune zerolatency \
-vf "drawtext
---
libavfilter/vf_drawtext.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index c4c09894e4..f7b9c25e62 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -1052,7 +1052,7 @@ static int func_strftime
"zhilizhao(赵志立)" 于2021年6月10日周四 下午12:15写道：
>
> Ping.
>
> > On Apr 27, 2021, at 1:09 PM, Zhao Zhili wrote:
> >
> > From: zhilizhao
> >
> > Simple test results:
> >
> > Command:
> > ./ffmpeg -y -hwaccel videotoolbox -hwaccel_output_format videotoolbox_vld \
> > -i test.mp4 -an -c:v h264_videotoolb
Jun 10, 2021, 12:27 by d...@lynne.ee:
> Jun 10, 2021, 03:38 by wenbin.c...@intel.com:
>
>>> Jun 8, 2021, 07:38 by wenbin.c...@intel.com:
>>>
>>> >> Apr 29, 2021, 03:52 by d...@lynne.ee:
>>> >>
>>> >> > This patch allows for alternative loader implementations.
>>> >> >
>>> >> > Patch attached.
>>>
Jun 10, 2021, 03:38 by wenbin.c...@intel.com:
>> Jun 8, 2021, 07:38 by wenbin.c...@intel.com:
>>
>> >> Apr 29, 2021, 03:52 by d...@lynne.ee:
>> >>
>> >> > This patch allows for alternative loader implementations.
>> >> >
>> >> > Patch attached.
>> >> >
>> >>
>> >> Forgot to fix a flag, v2 attached
On Thu, Jun 10, 2021 at 11:39 AM Diederick C. Niehorster
wrote:
> So in av_opt_get(), I'd do something like this:
> AVBPrint buf;
> av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOMATIC);
> // 1. call internal print function, with &buf
> // ...
> // 2. provide output to caller
> if (!av_bprint_is_compl
(NB: I have reorganized your reply a bit to make it for me to respond to)
On Wed, Jun 9, 2021 at 1:54 PM Nicolas George wrote:
>
> The critical part is the API of the new public function, because this we
> cannot fix later.
>
> Unfortunately, to get a good API, you will not be able to reuse the
>
Quoting Andreas Rheinhardt (2021-06-06 19:20:38)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2021-06-06 11:13:00)
> >> Anton Khirnov:
> >>> Memory ordering constraints other than the default (sequentially
> >>> consistent) can behave in very unintuitive and unexpected ways, and so
> >>> should
34 matches
Mail list logo
