On 2021-07-30 00:00, Andreas Rheinhardt wrote:
Gyan Doshi:
---
doc/bitstream_filters.texi | 64 ---
libavcodec/noise_bsf.c | 161 +
tests/fate/matroska.mak| 2 +-
3 files changed, 199 insertions(+), 28 deletions(-)
diff --git
Hi,
Our RTSP video server reply two streams in SDP are UDP and RTP/AVP/UDP.
>> m=video 0 UDP 33
>> m=video 0 RTP/AVP/UDP 33
ffmpeg now setup twice with the same transport "RTP/AVP/UDP"
The first time is
>> SETUP rtsp://192.168.1.100:554/MOV_12353521.mpg RTSP/1.0
>> Transport:
The function ff_qsvvpp_filter_frame should return a FFmpeg error code if
there is an error. However it might return a SDK error code without this
patch.
---
libavfilter/qsvvpp.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavfilter/qsvvpp.c
James Almer:
> Since we can't blindly trust the keyframe flag in packets and assume its
> contents are a valid Sync Sample, do some basic bitstream parsing to build the
> Sync Sample table in addition to a Random Access Recovery Point table.
>
> Suggested-by: ffm...@fb.com
> Signed-off-by: James
Andreas Rheinhardt:
> Michael Niedermayer:
>> Fixes: reading over the end
>> Fixes:
>> 36346/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ARGO_fuzzer-5366943107383296
>>
>> Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>
On 7/29/2021 2:31 AM, ffmpegandmahanstreamer@e.email wrote:
> I always meant to ask what is meaning of your profile picture?
What?
I don't know which picture you're referring to, but it doesn't matter.
This is neither the appropriate place nor thread.
- Derek
On 7/29/2021 1:39 AM, James Almer wrote:
> It's not a problem for AV1 (we correctly tag all packets that should be
> sync samples).
I meant for the rest of the boxes ;)
> I'm not going to bother with HEVC right now, but this all can be
> simplified once we introduce a new parser API that
Michael Niedermayer:
> Fixes: reading over the end
> Fixes:
> 36346/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ARGO_fuzzer-5366943107383296
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
>
Fixes: reading over the end
Fixes:
36346/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ARGO_fuzzer-5366943107383296
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/argo.c | 2 ++
1 file
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index b61a189b07..428180273b 100755
--- a/configure
+++ b/configure
@@ -4869,10 +4869,10 @@ if $ar 2>&1 | grep -q Microsoft; then
arflags="-nologo"
ar_o='-out:$@'
elif $ar 2>&1 |
On Wed, 28 Jul 2021, Nicolas George wrote:
Marton Balint (12021-07-27):
You should mention the relevant rfc - RFC8089.
Locally added.
Also there are a couple of common deviations/extensions from the normative
standard, referenced in the RFC:
Since we can't blindly trust the keyframe flag in packets and assume its
contents are a valid Sync Sample, do some basic bitstream parsing to build the
Sync Sample table in addition to a Random Access Recovery Point table.
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
Ensure instead that it's the correct value.
Signed-off-by: James Almer
---
libavformat/movenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 57062f45c5..fedc9c0e18 100644
--- a/libavformat/movenc.c
+++
On Sat, 24 Jul 2021, Pierre-Anthony Lemieux wrote:
Great. Let me know if you need anything else to process the patch,
which is necessary to process MXF files used by the Interoperable
Master Format (IMF, SMPTE ST 2067).
Thanks, applied.
Regards,
Marton
On Sun, Jul 18, 2021 at 1:03 PM
On Fri, 23 Jul 2021, emco...@ffastrans.com wrote:
Am 2021-07-04 20:31, schrieb emco...@ffastrans.com:
Am 2021-07-04 20:28, schrieb emco...@ffastrans.com:
Am 2021-07-04 17:28, schrieb Marton Balint:
On Sat, 3 Jul 2021, Tomas Härdin wrote:
lör 2021-07-03 klockan 15:13 +0200 skrev
This allow to specify additional parameters with
`./configure -ar='ar -...`.
Previously this resulted in an error (no operation specified).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
Gyan Doshi:
> ---
> doc/bitstream_filters.texi | 64 ---
> libavcodec/noise_bsf.c | 161 +
> tests/fate/matroska.mak| 2 +-
> 3 files changed, 199 insertions(+), 28 deletions(-)
>
> diff --git a/doc/bitstream_filters.texi
On 7/29/2021 2:58 PM, Michael Niedermayer wrote:
On Tue, Jul 27, 2021 at 10:08:20AM -0300, James Almer wrote:
Since we can't blindly trust the keyframe flag in packets and assume its
contents are a valid Sync Sample, do some basic bitstream parsing to build the
Sync Sample table in addition to
On Thu, Jul 29, 2021 at 01:07:39AM +0200, Lynne wrote:
> 9 Jul 2021, 12:59 by d...@lynne.ee:
>
> > 8 Jul 2021, 22:32 by stefa...@gmail.com:
> >
> >> On Mon, Jun 28, 2021 at 2:50 AM Lynne wrote:
> >>
> >>>
> >>> 27 Jun 2021, 19:33 by kier...@obe.tv:
> >>>
> >>> >>
> >>> >> I'm thinking of getting
On Tue, Jul 27, 2021 at 10:08:20AM -0300, James Almer wrote:
> Since we can't blindly trust the keyframe flag in packets and assume its
> contents are a valid Sync Sample, do some basic bitstream parsing to build the
> Sync Sample table in addition to a Random Access Recovery Point table.
>
>
On Thu, Jul 22, 2021 at 9:02 PM Christopher Degawa
wrote:
> these fields are only available past svt-av1 0.8.7
>
> Signed-off-by: Christopher Degawa
> ---
> libavcodec/libsvtav1.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/libavcodec/libsvtav1.c
On 2021-07-29 15:31, Gyan Doshi wrote:
On 2021-07-29 02:33, Michael Niedermayer wrote:
On Wed, Jul 28, 2021 at 09:56:35AM +0530, Gyan Doshi wrote:
---
doc/bitstream_filters.texi | 64 ---
libavcodec/noise_bsf.c | 161
+
Nicolas George:
> It was only still supported for subfile and only used by dvd2concat.
>
The latter statement is not true: This is public API; anyone can have
used it for any purpose. Your 2/5 adds a replacement for using it with
dvd2concat, but there are other usages, too; e.g. concatenating
在2021年7月29日七月 下午5:29，yinshiyou...@loongson.cn写道：
> > -原始邮件-
> > 发件人: "Jiaxun Yang"
> > 发送时间: 2021-07-29 14:32:35 (星期四)
> > 收件人: ffmpeg-devel@ffmpeg.org
> > 抄送: yinshiyou...@loongson.cn, "Jiaxun Yang"
> > 主题: [PATCH] avcodec/mips: Support old style mmi instruction mnemonics
> >
> >
James Almer:
> On 7/28/2021 7:43 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Since we can't blindly trust the keyframe flag in packets and assume its
>>> contents are a valid Sync Sample, do some basic bitstream parsing to
>>> build the
>>> Sync Sample table in addition to a Random Access
On 2021-07-29 02:33, Michael Niedermayer wrote:
On Wed, Jul 28, 2021 at 09:56:35AM +0530, Gyan Doshi wrote:
---
doc/bitstream_filters.texi | 64 ---
libavcodec/noise_bsf.c | 161 +
tests/fate/matroska.mak| 2 +-
3 files changed,
> -原始邮件-
> 发件人: "Jiaxun Yang"
> 发送时间: 2021-07-29 14:32:35 (星期四)
> 收件人: ffmpeg-devel@ffmpeg.org
> 抄送: yinshiyou...@loongson.cn, "Jiaxun Yang"
> 主题: [PATCH] avcodec/mips: Support old style mmi instruction mnemonics
>
> Loongson had renamed serval instruction mnemonics to distinguish
>
---
doc/examples/qsvdec.c | 45 +--
1 file changed, 9 insertions(+), 36 deletions(-)
diff --git a/doc/examples/qsvdec.c b/doc/examples/qsvdec.c
index 7415eefca5..571d868f93 100644
--- a/doc/examples/qsvdec.c
+++ b/doc/examples/qsvdec.c
@@ -44,38 +44,10 @@
This allows user set hw_device_ctx instead of hw_frames_ctx for QSV
decoders, hence we may remove the ad-hoc libmfx setup code from FFmpeg.
"-hwaccel_output_format format" is applied to QSV decoders after
removing the ad-hoc libmfx code. To keep compatibility with old
commandlines, the default
On Thu, 2021-06-24 at 01:33 +, Xiang, Haihao wrote:
> On Wed, 2021-06-23 at 16:41 +, Soft Works wrote:
> >
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Haihao
> > Xiang
> > Sent: Mittwoch, 23. Juni 2021 05:04
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Haihao Xiang
> >
On Wed, Jul 28, 2021 at 4:16 PM Haihao Xiang wrote:
>
> User may get color properties from the SDK via VIDEO_SIGNAL_INFO extbuf
> ---
> libavcodec/qsvdec.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
>
if client start the capture queue without waiting the source change
event,
there may be some timing issues.
For example, in client, the sequence is:
capture streamon -> source change -> capture streamoff -> capture
streamon.
but in driver side, the sequence may be:
source change -> capture
client need to resume the decoding process
after it dequeues the source change event.
no matter what's the return value of v4l2_resolution_changed().
if the client doesn't resume the decoding process,
the decoder may keep waiting
in documentation of v4l2 stateful decoder, we can see the following
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
34 matches
Mail list logo
