Quoting Michael Niedermayer (2023-07-04 01:50:57)
> On Mon, Jul 03, 2023 at 11:09:54PM +0200, Anton Khirnov wrote:
> > Quoting Marton Balint (2023-07-03 22:54:41)
> > > On Mon, 3 Jul 2023, Anton Khirnov wrote:
> > > My patch use av_get_random_seed() which uses what the underlying OS
> > >
Prevent the fifo used in encoding VPx videos from filling up and stopping
encode when it reaches 21845 items, which happens when the video has more
than
that number of frames.
This problem occurs when performing the first pass of a 2-pass encode, as
otherwise, the fifo is properly drained,
+1
On Mon, Jul 3, 2023 at 19:32 Tomas Härdin wrote:
> tis 2023-07-04 klockan 01:00 +0200 skrev Michael Niedermayer:
> > Suggested-by: Anton
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/developer.texi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
Tyrants and dictators.
___
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 with subject "unsubscribe".
On Mon, Jul 03, 2023 at 11:09:54PM +0200, Anton Khirnov wrote:
> Quoting Marton Balint (2023-07-03 22:54:41)
> > On Mon, 3 Jul 2023, Anton Khirnov wrote:
> > My patch use av_get_random_seed() which uses what the underlying OS
> > provides, BCrypt for Windows, /dev/urandom for Linux, arc4random()
tis 2023-07-04 klockan 01:00 +0200 skrev Michael Niedermayer:
> Suggested-by: Anton
>
> Signed-off-by: Michael Niedermayer
> ---
> doc/developer.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 0c2f2cd7d1..67f7f78e86
Lynne schrieb am Di., 4. Juli 2023, 00:54:
> Jul 4, 2023, 00:08 by tmund...@gmail.com:
>
> > Am So., 2. Juli 2023 um 20:58 Uhr schrieb Lynne :
> >
> >> Jul 2, 2023, 20:41 by tmund...@gmail.com:
> >>
> >> > Am So., 2. Juli 2023 um 18:57 Uhr schrieb Lynne :
> >> >
> >> >> Jul 2, 2023, 18:54 by
Suggested-by: Anton
Signed-off-by: Michael Niedermayer
---
doc/developer.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/developer.texi b/doc/developer.texi
index 0c2f2cd7d1..67f7f78e86 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -806,7 +806,7 @@
Jul 4, 2023, 00:08 by tmund...@gmail.com:
> Am So., 2. Juli 2023 um 20:58 Uhr schrieb Lynne :
>
>> Jul 2, 2023, 20:41 by tmund...@gmail.com:
>>
>> > Am So., 2. Juli 2023 um 18:57 Uhr schrieb Lynne :
>> >
>> >> Jul 2, 2023, 18:54 by d...@lynne.ee:
>> >>
>> >> > The issue is that clipping the
On 3 Jul 2023, at 20:02, Andreas Rheinhardt wrote:
> Marvin Scholz:
>>
>>
>> On 3 Jul 2023, at 2:18, Andreas Rheinhardt wrote:
>>
>>> Marvin Scholz:
This new API allows to remove an entry and obtain ownership of the
key/value that was associated with the removed entry.
---
The error handler for POLLERRs assumes that the timeout is only zero
when v4l2_dequeue_v4l2buf is called by v4l2_getfree_v4l2buf. This
assumption is incorrect, as ff_v4l2_context_dequeue_frame also calls
this function with a timeout of zero. Do not check for unavailable
buffers if the buffers are
Also fix a couple of possible overflows while at it.
Fixes the negative initial timestamps in ticket #10358.
Signed-off-by: Marton Balint
---
fftools/ffmpeg.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
Am Mo., 3. Juli 2023 um 10:27 Uhr schrieb John Cox :
> On Mon, 3 Jul 2023 00:12:46 +0300 (EEST), you wrote:
>
> >On Sun, 2 Jul 2023, Thomas Mundt wrote:
> >
> >> Am So., 2. Juli 2023 um 14:34 Uhr schrieb John Cox :
> >> Add an optional filter_line3 to the available optimisations.
> >>
> >>
Am So., 2. Juli 2023 um 20:58 Uhr schrieb Lynne :
> Jul 2, 2023, 20:41 by tmund...@gmail.com:
>
> > Am So., 2. Juli 2023 um 18:57 Uhr schrieb Lynne :
> >
> >> Jul 2, 2023, 18:54 by d...@lynne.ee:
> >>
> >> > The issue is that clipping the interpolated temporal sample against
> >> > the spatially
On Mon, 3 Jul 2023, Anton Khirnov wrote:
Quoting Marton Balint (2023-07-03 22:54:41)
On Mon, 3 Jul 2023, Anton Khirnov wrote:
My patch use av_get_random_seed() which uses what the underlying OS
provides, BCrypt for Windows, /dev/urandom for Linux, arc4random() for
BSD/Mac.
IOW it's a
Quoting Marton Balint (2023-07-03 22:54:41)
> On Mon, 3 Jul 2023, Anton Khirnov wrote:
> My patch use av_get_random_seed() which uses what the underlying OS
> provides, BCrypt for Windows, /dev/urandom for Linux, arc4random() for
> BSD/Mac.
IOW it's a jungle of various paths, some of which are
On Mon, 3 Jul 2023, Anton Khirnov wrote:
Quoting James Almer (2023-07-03 21:33:04)
On 7/2/2023 4:30 PM, Marton Balint wrote:
It should be OK to use av_get_random_seed() to generate the key instead of
using openSSL/Gcrypt functions. This removes the hard dependancy of those libs
for key
On Mon, 3 Jul 2023, James Almer wrote:
On 7/2/2023 4:30 PM, Marton Balint wrote:
It should be OK to use av_get_random_seed() to generate the key instead of
using openSSL/Gcrypt functions. This removes the hard dependancy of those
libs
for key generation functionality.
Fixes ticket
Quoting James Almer (2023-07-03 21:33:04)
> On 7/2/2023 4:30 PM, Marton Balint wrote:
> > It should be OK to use av_get_random_seed() to generate the key instead of
> > using openSSL/Gcrypt functions. This removes the hard dependancy of those
> > libs
> > for key generation functionality.
> >
>
Le maanantaina 3. heinäkuuta 2023, 18.52.13 EEST Khem Raj a écrit :
> > *Hopefully* LLVM gets their act together by release 16, and ship a usable
> > assembler, rather than tell us to use automatic RVV vectorisation (which
> > *is* a release 16 feature, though it was half-baked last time I tried).
On 7/2/2023 4:30 PM, Marton Balint wrote:
It should be OK to use av_get_random_seed() to generate the key instead of
using openSSL/Gcrypt functions. This removes the hard dependancy of those libs
for key generation functionality.
Fixes ticket #10441.
Signed-off-by: Marton Balint
---
Do it from ff_decode_get_packet() rather than from
avcodec_send_packet(). This way all nontrivial stages of the decoding
pipeline (i.e. other than just placing a packet at its entrance) are
pull-based rather than a mix of push an pull.
---
libavcodec/decode.c | 37
It does not need to be visible outside of encode.c.
---
libavcodec/encode.c | 13 ++---
libavcodec/internal.h | 6 --
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 6da5d86ea0..58eab5b001 100644
---
This way decoding errors will not be returned when the user starts
draining the decoder, avoiding confusion over whether draining did or
did not start.
Fixes failures of fate-h264-attachment-631 for certain numbers of frame
threads (e.g. 5).
---
libavcodec/decode.c | 2 +-
1 file changed, 1
It will be useful in other places.
---
libavcodec/bsf.c | 11 +--
libavcodec/packet_internal.h | 2 ++
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index 42cc1b5ab0..1e710f7d4a 100644
--- a/libavcodec/bsf.c
+++
Move AVCodecInternal.nb_draining_errors to it, should should not be
visible outside of decode.c.
---
libavcodec/avcodec.c | 4 +++-
libavcodec/avcodec_internal.h | 2 ++
libavcodec/decode.c | 21 +++--
libavcodec/internal.h | 3 ---
Move AVCodecInternal.intra_only_flag to it, should should not be visible
outside of encode.c.
---
libavcodec/avcodec.c | 2 +-
libavcodec/avcodec_internal.h | 1 +
libavcodec/encode.c | 26 --
libavcodec/internal.h | 7 ---
4 files
Decoding pipeline has multiple stages, some of which may have their own
delay (e.g. bitstream filters). The code currently uses
AVCodecInternal.draining to track all of them, but they do not have to
all be in sync.
---
libavcodec/decode.c | 15 ---
1 file changed, 12 insertions(+), 3
---
libavcodec/decode.c | 10 +-
libavcodec/encode.c | 8
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 01ac35bf34..3115282923 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1745,13 +1745,13 @@ void
The goal is to distinguish between APIs provided by the generic layer to
individual codecs and APIs internal to the generic layer.
Start by moving ff_{decode,encode}_receive_frame() and
ff_{decode,encode}_preinit() into this new header, as those functions
are called from generic code and should
Will allow making some state private to encoding/decoding in the future.
---
libavcodec/avcodec.c | 17 +++--
libavcodec/avcodec_internal.h | 3 +++
libavcodec/decode.c | 15 +++
libavcodec/encode.c | 10 ++
4 files changed, 31
* using IS_EMPTY() as suggested by James;
* use a different pattern for allocating private data, as suggested by
Andreas
* rebased against master
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Mon, 3 Jul 2023, Steven Liu wrote:
Marton Balint 于2023年7月3日周一 03:30写道：
It should be OK to use av_get_random_seed() to generate the key instead of
using openSSL/Gcrypt functions. This removes the hard dependancy of those libs
for key generation functionality.
Fixes ticket #10441.
Quoting Andreas Rheinhardt (2023-06-24 21:34:58)
> > diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> > index dceae182c0..b672092ac4 100644
> > --- a/libavcodec/internal.h
> > +++ b/libavcodec/internal.h
> > @@ -49,7 +49,14 @@
> > # define STRIDE_ALIGN 8
> > #endif
> >
> >
On Mon, 3 Jul 2023, Devin Heitmueller wrote:
Changes were made between in the last two years to periodically
send PCR-only packets on all PIDs, but for cases where the stream
may send packets very infrequently (like SCTE-35), this results in
extra TR101290 errors because it fails the PCR
Fix the fact that ffprobe no longer detects m3u8 in a data url correctly.
For example,
ffprobe
data:application/vnd.apple.mpegurl;base64,I0VYVE0zVQojRVhULVgtVkVSU0lPTjozCiNFWFQtWC1UQVJHRVREVVJBVElPTjozMAojRVhUSU5GOjMwLApodHRwczovL2Rvd25sb2FkLnNhbXBsZWxpYi5jb20vbXA0L3NhbXBsZS0zMHMubXA0
This
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 28 ++
libavfilter/aarch64/vf_bwdif_neon.S | 272
2 files changed, 300 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 21 ++
libavfilter/aarch64/vf_bwdif_neon.S | 208
libavfilter/bwdif.h | 5 +
libavfilter/vf_bwdif.c | 10 +-
4 files changed, 239 insertions(+),
Add an optional filter_line3 to the available optimisations.
filter_line3 is equivalent to filter_line, memcpy, filter_line
filter_line shares quite a number of loads and some calculations in
common with its next iteration and testing shows that using aarch64
neon filter_line3s performance is
Adds clip and spatial macros for aarch64 neon
Exports C filter_edge needed for tail fixup of neon code
Adds neon for filter_edge
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 20 +++
libavfilter/aarch64/vf_bwdif_neon.S | 177
Signed-off-by: John Cox
---
tests/checkasm/vf_bwdif.c | 54 +++
1 file changed, 54 insertions(+)
diff --git a/tests/checkasm/vf_bwdif.c b/tests/checkasm/vf_bwdif.c
index 034bbabb4c..5fdba09fdc 100644
--- a/tests/checkasm/vf_bwdif.c
+++
Adds an outline for aarch neon functions
Adds common macros and consts for aarch64 neon
Exports C filter_intra needed for tail fixup of neon code
Adds neon for filter_intra
Signed-off-by: John Cox
---
libavfilter/aarch64/Makefile| 2 +
Signed-off-by: John Cox
---
tests/checkasm/vf_bwdif.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/checkasm/vf_bwdif.c b/tests/checkasm/vf_bwdif.c
index 46224bb575..034bbabb4c 100644
--- a/tests/checkasm/vf_bwdif.c
+++
Also adds a filter_line3 method which on aarch64 neon yields approx 30%
speedup over 2xfilter_line and a memcpy
Differences from v2:
coeffs moved into const segment
number of patches reduced
John Cox (7):
tests/checkasm: Add test for vf_bwdif filter_intra
avfilter/vf_bwdif: Add neon for
Marvin Scholz:
>
>
> On 3 Jul 2023, at 2:18, Andreas Rheinhardt wrote:
>
>> Marvin Scholz:
>>> This new API allows to remove an entry and obtain ownership of the
>>> key/value that was associated with the removed entry.
>>> ---
>>>
>>> Changes since v1:
>>> - Clarify documentation about av_free
Because SCTE-35 messages are represented in TS streams as sections
rather than PES packets, we cannot rely on ffmpeg's standard
mechanisms to adjust PTS values if reclocking the stream.
This filter will leverage the SCTE-35 pts_adjust field to
compensate for any change in the PTS values in the
Changes were made between in the last two years to periodically
send PCR-only packets on all PIDs, but for cases where the stream
may send packets very infrequently (like SCTE-35), this results in
extra TR101290 errors because it fails the PCR interval test.
I am not quite sure what the "right"
Introduce the ability to pass through SCTE-35 packets when creating
MPEG transport streams. Note that this patch makes no effort to
change the PTS values in the SCTE-35 packets, and thus only works
when not reclocking the stream (i.e. using -copyts). A subsequent
patch includes a BSF to
In order to properly process SCTE-35 packets, we need the original
PTS value from the demux (i.e. not mangled by the application or
reclocked for the output). This allows us to set the pts_adjustment
field in an BSF on the output side.
Introduce a new side data type to store the original PTS.
Properly set up the MPEG-TS mux and recalculate the pts_adjust field
in SCTE_35 packets, such that a user can transparently pass through
SCTE-35 streams when both the input and output are MPEG-TS.
This patch series updated to add a time_base field to the new side-data
type, as well as various
We need the original PTS value in order to do subsequent processing,
so set it as packet side data.
Signed-off-by: Devin Heitmueller
---
libavformat/mpegts.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index
On Wed, 2023-06-21 at 15:57 +, Carotti, Elias wrote:
> Hi all,
> please find the second part of the patch set.
> Best,
> Elias
Hi all,
please find the second part of the patch, updating libavcodec/libx264.c
to use the AVVideoHint side data. This should use the block_size field
to scan the
On Mon, Jul 3, 2023 at 1:00 AM Rémi Denis-Courmont wrote:
>
> Hi,
>
> The diff is ok. I even have a slight incline in favour thereof for the sake
> of consistency. Yet, I may be vainly pedantic but I do have problems with the
> description.
>
> Le 3 juillet 2023 05:44:12 GMT+03:00, Khem Raj a
On Sat, 2023-07-01 at 10:33 +0200, Anton Khirnov wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> Sorry to still nag you, but I just noticed that unlike
>
On Thu, 29 Jun 2023 at 19:39, James Almer wrote:
> On 3/21/2023 12:01 PM, Thomas Siedel wrote:
> > This patch set adds H266/VVC support.
> > This includes parsing, muxing, demuxing, decoding and encoding.
> > Decoding is done using the external library VVdeC
> >
On Mon, Jul 3, 2023 at 7:28 AM James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_h2645.c| 18 ++
> libavcodec/cbs_h266.h | 10 ++
> libavcodec/cbs_h266_syntax_template.c | 24
>
On Mon, Jul 03, 2023 at 10:54:05AM +0200, Paul B Mahol wrote:
> On Mon, Jul 3, 2023 at 7:48 AM Michael Niedermayer
> wrote:
>
> > Hi
> >
> > the new libavradio in its new repository needs some changes the problem
> > is that maintaining it in a separate repository AND seperate directory is
> >
Hi Anton,
On Sat, Jul 1, 2023 at 4:14 AM Anton Khirnov wrote:
>
> IIUC the only source of bar data after this set is the new filter you're
> adding. Is there supposed to be some other demuxer or decoder that
> produces it?
I have support in my tree for the H.264 and HEVC decoders, but I still
Small update:
And this command also does not work correctly. The video is cannot be converted
for YouTube servers:
After video upload on YouTube I see error message, that video is no possible process, if I create video from this command:
ffmpeg -r 1 -i 22.jpg -i 22.mp3 -c:a copy -r 1 -c:v
On Sat, Jul 1, 2023 at 4:11 AM Anton Khirnov wrote:
> > /**
> > + * Bar data - used by side data for avcodec and avframe. Defines the
> > location
> > + * of horizontal or vertical black bars (i.e. letterbox/pillar bars)
> > + */
> > +typedef struct AVBarData {
> > +int top_bottom; /*
On 3 Jul 2023, at 14:13, Matej Marko wrote:
> Create video from one picture and one audio file
>
> Hello,
>
You already sent your email once before, do not re-send the
same thing please. If you have things to add, reply to your previously
sent e-mail so it is properly threaded.
> This
Create video from one picture and one audio file
Hello,
This command not work correct. Video is longer than audio file
ffmpeg -loop 1 -framerate 2/60 -i 22.jpg -i 22.mp3 -c:v libvpx-vp9 -c:a copy
-shortest -r 2 video-vystup2.mkv
This command not work correct too. Video is no possible
Hello,
official way of ffmpeg bug report actually not work correct. I created
alternative way of bug report here.
This command not worg correct. Video is longer than audio file
ffmpeg -loop 1 -framerate 2/60 -i 22.jpg -i 22.mp3 -c:v libvpx-vp9 -c:a copy
-shortest -r 2 video-vystup2.mkv
On Mon, Jul 3, 2023 at 1:56 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Paul B Mahol:
> > Will apply this soon as there are no more comments.
>
> My objection still stands.
>
Your objections are invalid, also you tend to object just to object.
>
> - Andreas
>
>
On 3 Jul 2023, at 2:18, Andreas Rheinhardt wrote:
> Marvin Scholz:
>> This new API allows to remove an entry and obtain ownership of the
>> key/value that was associated with the removed entry.
>> ---
>>
>> Changes since v1:
>> - Clarify documentation about av_free having to be used.
>> - Fix
On Mon, Jul 3, 2023 at 12:25 PM Dai, Jianhui J
wrote:
>
> Should set "number of frames" to bytes 24-27 of IVF header, not
> duration.
> It is described by [1], and confirmed by parsing all IVF files in [2].
>
> This commit also updates the md5sum of refs to pass fate-cbs.
>
> [1] Duck IVF -
On Mon, Jul 3, 2023 at 7:48 AM Michael Niedermayer
wrote:
> Hi
>
> the new libavradio in its new repository needs some changes the problem
> is that maintaining it in a separate repository AND seperate directory is
> not
> so simple
> But let me show this in numbers, this is the stats of the
On Mon, 3 Jul 2023 00:09:52 +0300 (EEST), you wrote:
>On Sun, 2 Jul 2023, John Cox wrote:
>
>> Also adds a filter_line3 method which on aarch64 neon yields approx 30%
>> speedup over 2xfilter_line and a memcpy
>>
>> Differences from v1:
>> .align 16 corrected to .balign 16
>> SXTW tolower
>> Mac
On Mon, 3 Jul 2023 00:02:27 +0300 (EEST), you wrote:
>On Sun, 2 Jul 2023, Martin Storsjö wrote:
>
>> On Sun, 2 Jul 2023, John Cox wrote:
>>
>>> On Sun, 2 Jul 2023 00:35:14 +0300 (EEST), you wrote:
>>>
On Thu, 29 Jun 2023, John Cox wrote:
> Add macros for dual scalar half->single
On Mon, 3 Jul 2023 00:12:46 +0300 (EEST), you wrote:
>On Sun, 2 Jul 2023, Thomas Mundt wrote:
>
>> Am So., 2. Juli 2023 um 14:34 Uhr schrieb John Cox :
>> Add an optional filter_line3 to the available optimisations.
>>
>> filter_line3 is equivalent to filter_line, memcpy, filter_line
Hi,
The diff is ok. I even have a slight incline in favour thereof for the sake of
consistency. Yet, I may be vainly pedantic but I do have problems with the
description.
Le 3 juillet 2023 05:44:12 GMT+03:00, Khem Raj a écrit :
>Add missing operand
The spec does explicitly make the mask and
71 matches
Mail list logo
