On 2021-07-17 04:50, ffmpegandmahanstreamer@e.email wrote:
Put the fact that -re is equivalent to -readrate 1 in the deprecated message so
people know what to switch to.
It's already in the docs for -re as well as the ffmpeg -h description.
Regards,
Gyan
___
Put the fact that -re is equivalent to -readrate 1 in the deprecated message so
people know what to switch to.
Other than that looks good to me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To u
Stream with AV_DISPOSITION_URGENT disposition flag could be NOPTS.
Signed-off-by: zheng qian
---
fftools/ffmpeg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 1ac2e48600..a3b720748b 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffm
Signed-off-by: zheng qian
---
libavformat/mpegtsenc.c | 40 +++-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 98dac17994..b5d2938c4a 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat
Recognize ARIB superimpose stream through ARIB data coding descriptor,
and re-use AV_CODEC_ID_ARIB_CAPTION codec id with an extra disposition
flag AV_DISPOSITION_URGENT.
Signed-off-by: zheng qian
---
libavformat/mpegts.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions
This patchset introduces AV_DISPOSITION_URGENT disposition flag for
marking stuffs which is expected to be shown immediately as received,
and adds recognization/remuxing support for ARIB superimpose stream.
ARIB superimpose is almost same as ARIB caption but is utilized to
transmit emergency alert
For what it's worth, I'm moving to e.email. I will see how the delay
dynamic works over there as well. So far it also seems like a good
option that I would recommend.
I do know that Yandex has a very long delay (if its even sent at all)
because I tried that and it didn't even get the confirmat
Signed-off-by: James Almer
---
fftools/cmdutils.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 6e875104fd..a3b6b78d50 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -856,28 +856,15 @@ in
On Fri, Jul 16, 2021 at 9:51 AM Thilo Borgmann
wrote:
> Am 04.07.21 um 21:23 schrieb Michael Niedermayer:
> > On Sun, Jun 20, 2021 at 09:48:29PM +0200, Thilo Borgmann wrote:
> >> Hi,
> >>
> >> adds a new variant to the -force_key_frames option "source_no_drop" to
> make
> >> sure whenever a key f
This could also be moved into a separate file.
Signed-off-by: Michael Niedermayer
---
libavcodec/encode.c | 47 +
1 file changed, 47 insertions(+)
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index a569904f2c..ecf0e6e4bd 100644
--- a/libavco
On 7/16/2021 1:55 PM, Michael Niedermayer wrote:
On Thu, Jul 15, 2021 at 05:55:51PM -0300, James Almer wrote:
On 7/15/2021 5:23 PM, Michael Niedermayer wrote:
On Wed, Jul 14, 2021 at 11:33:59AM -0300, James Almer wrote:
It will be used to allow parsers to be more liberal when tagging packets a
16 Jul 2021, 19:56 by mnite...@gmail.com:
> Benchmarks: A53A72
> h264_h_loop_filter_chroma422_10bpp_c: 293.0 116.7
> h264_h_loop_filter_chroma422_10bpp_neon: 283.7 126.2
> h264_h_loop_filter_chroma_10bpp_c:
On Thu, Jul 15, 2021 at 2:48 AM Stephen Hutchinson wrote:
> Fixes http://trac.ffmpeg.org/ticket/9219
> ---
> libavformat/isom_tags.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
> index 1666b9d4a5..e2e589b658 100644
> --- a/libavfor
correct implementation of 'cenc' encryption scheme to support decryption of
partial cipher blocks at the end of subsamples
https://www.iso.org/standard/68042.html
Signed-off-by: Nachiket Tarate
---
libavformat/isom.h | 2 +
libavformat/mov.c | 246 +++
Benchmarks: A53A72
h264_h_loop_filter_chroma422_10bpp_c: 293.0 116.7
h264_h_loop_filter_chroma422_10bpp_neon: 283.7 126.2
h264_h_loop_filter_chroma_10bpp_c: 165.2 58.5
h264_h_loop_filter_chroma_10
transpose_4x8H was declared in vp9lpf_16bpp_neon, however this macro is
not unique to vp9 and could be used elsewhere.
Signed-off-by: Mikhail Nitenko
---
libavcodec/aarch64/neon.S | 13 +
libavcodec/aarch64/vp9lpf_16bpp_neon.S | 12
2 files changed, 13 inser
Signed-off-by: Nachiket Tarate
---
libavformat/hls.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 022dae0391..7e457281f4 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2051,23 +2051
These will be used by HLS demuxer in case of sample decryption.
Signed-off-by: Nachiket Tarate
---
libavcodec/adts_header.c | 1 +
libavcodec/adts_header.h | 14 ++
libavcodec/adts_parser.c | 28
3 files changed, 43 insertions(+)
diff --git a/libavcodec
On Fri, Jul 16, 2021, at 10:06 PM, Timo Rothenpieler wrote:
-- snip --
> Can you explain the logic this follows some more? I'm quite confused
> what exactly changed, and how it broke this.
> How do you trigger a flush, if calling flush does nothing?
Since https://github.com/ffmpeg/ffmpeg/commit
Apple HTTP Live Streaming Sample Encryption:
https://developer.apple.com/library/ios/documentation/AudioVideo/Conceptual/HLS_Sample_Encryption
Signed-off-by: Nachiket Tarate
---
libavformat/Makefile| 2 +-
libavformat/hls.c | 128 +++--
libavformat/hls_sa
On Thu, Jul 15, 2021 at 05:55:51PM -0300, James Almer wrote:
> On 7/15/2021 5:23 PM, Michael Niedermayer wrote:
> > On Wed, Jul 14, 2021 at 11:33:59AM -0300, James Almer wrote:
> > > It will be used to allow parsers to be more liberal when tagging packets
> > > as
> > > keyframes.
> > >
> > > Sig
On 16.07.2021 18:09, Jai Luthra wrote:
Recent encode API restructure (827d6fe73d) removed some state - which broke
the API for flushing without closing the encoder.
This functionality was originally added in 3ea7057677 and is useful for
segmented video, where we don't want to do expensive re-ini
On Mon, Jul 12, 2021 at 01:07:03PM +0200, Anton Khirnov wrote:
> ---
> Makefile | 2 +
> tests/Makefile| 1 +
> tests/fate/libswscale.mak | 11 +++
> tools/Makefile| 3 +-
> tools/scale_slice_test.c | 190 ++
> 5
Recent encode API restructure (827d6fe73d) removed some state - which broke
the API for flushing without closing the encoder.
This functionality was originally added in 3ea7057677 and is useful for
segmented video, where we don't want to do expensive re-init of HW sessions
for every segment.
---
v
Recent encode API restructure (827d6fe73d) removed some state - which broke
the API for flushing without closing the encoder.
This functionality was originally added in 3ea7057677 and is useful for
segmented video, where we don't want to do expensive re-init of HW sessions
for every segment.
-
On 7/16/2021 11:46 AM, Alan Kelly wrote:
On Fri, Jul 16, 2021 at 4:02 PM James Almer wrote:
On 7/16/2021 10:44 AM, Alan Kelly wrote:
Broadwell and later and Zen3 and later have fast gather instructions.
---
Haswell is now excluded from EXTERNAL_AVX2_FAST as discussed in the
email thread
On Fri, Jul 16, 2021 at 4:02 PM James Almer wrote:
> On 7/16/2021 10:44 AM, Alan Kelly wrote:
> > Broadwell and later and Zen3 and later have fast gather instructions.
> > ---
> > Haswell is now excluded from EXTERNAL_AVX2_FAST as discussed in the
> > email thread.
>
> I was very explicit abo
Benchmarks:A53 A72
pred8x8_dc_10_c: 64.249.5
pred8x8_dc_10_neon:62.754.5
pred8x8_dc_128_10_c: 26.015.5
pred8x8_dc_128_10_neon:28.216.0
pred8x8_horizontal_10_c: 60.027.7
pred8x8_hori
On 7/16/2021 10:44 AM, Alan Kelly wrote:
Broadwell and later and Zen3 and later have fast gather instructions.
---
Haswell is now excluded from EXTERNAL_AVX2_FAST as discussed in the
email thread.
I was very explicit about this not being ok. We're not disabling all ymm
usage for Haswell ju
These functions replace all ff_hscale8to15_*_ssse3 when avx2 is available.
---
EXTERNAL_AVX2_FAST is now used instead of EXTERNAL_AVX2_FAST_GATHER as
discussed in the email thread for part 1 of this patch.
Benchmark results on Skylake and Haswell:
Skylake Haswell
h
Broadwell and later and Zen3 and later have fast gather instructions.
---
Haswell is now excluded from EXTERNAL_AVX2_FAST as discussed in the
email thread.
libavutil/cpu.h | 1 +
libavutil/x86/cpu.c | 11 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavutil/c
On 6/6/2021 7:44 AM, Thilo Borgmann wrote:
Hi,
Am 05.06.21 um 16:33 schrieb Anton Khirnov:
Quoting Thilo Borgmann (2021-06-05 14:29:05)
Hi,
add an option to override auto-detection of cpu count. Defaults to
auto-detection, of course.
-Thilo
From 38612f3e1339354dbaa6be4f36072320ff71c707 Mo
Allows to read inputs at arbitrary rates.
-re is equivalent to -readrate 1
Tested with -copyts {+ start_at_zero}, -ss, streamcopied & decoded streams.
---
doc/ffmpeg.texi | 18 +++---
fftools/ffmpeg.c | 13 ++---
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_opt.c | 19
in the v4l2 stateful video document, we can see the following
description:
During the resolution change sequence, the OUTPUT queue must remain
streaming. Calling VIDIOC_STREAMOFF() on the OUTPUT queue would
abort the sequence and initiate a seek.
In principle, the OUTPUT queue oper
Am 04.07.21 um 14:31 schrieb Thilo Borgmann:
> Hi,
>
add an option to override auto-detection of cpu count. Defaults to
auto-detection, of course.
-Thilo
>>>
doc/fftools-common-opts.texi | 7 +++
fftools/cmdutils.c | 27 +
Am 04.07.21 um 21:23 schrieb Michael Niedermayer:
> On Sun, Jun 20, 2021 at 09:48:29PM +0200, Thilo Borgmann wrote:
>> Hi,
>>
>> adds a new variant to the -force_key_frames option "source_no_drop" to make
>> sure whenever a key frame in the source is dropped, we choose the next frame
>> in the outp
Hi,
>>> when transcoding 608 cc, the cc stream frame pts is set to the same value
>>> as its container frame's pts. However, the time_base is always set to
>>> 1/9 (default) in the initialization stage. Which causes timing issues
>>> when the container time_base is actually not 1/9.
>>
applied
___
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".
38 matches
Mail list logo
