From: Bernard Boulay
With various formats/protocols - for example fragmented mp4 over
HTTP - success/failure might not appear right away. The header and
first packet might get successfully written into the muxer, but
a response of failure might appear only N packets later.
In such a case, a reco
From: Jan Ekström
This way discontinuities backwards could also get handled (albeit
they generally tend to be incorrect to begin with on this layer of
avformat).
Signed-off-by: Jan Ekström
---
libavformat/fifo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/
From: Jan Ekström
Otherwise each new attempt will leave its connection open.
Signed-off-by: Jan Ekström
---
libavformat/fifo.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 9fc524adbdf..bc363e458cd 100644
--- a/liba
From: Jan Ekström
As this is a meta muxer and the same flag is set with the fifo
meta muxer, there is really no reason not to have this set here
as well.
Signed-off-by: Jan Ekström
---
libavformat/tee.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/tee.c b/lib
Jan Ekström (12020-12-07):
> From: Jan Ekström
>
> As this is a meta muxer and the same flag is set with the fifo
> meta muxer, there is really no reason not to have this set here
> as well.
>
> Signed-off-by: Jan Ekström
> ---
> libavformat/tee.c | 2 +-
> 1 file changed, 1 insertion(+), 1 de
From: Jan Ekström
The API client has no visibility into the values provided by the
underlying muxer, so we either do this always, or when an option
is presented.
In this case, we do it unconditionally, as this is probably more
useful.
Signed-off-by: Jan Ekström
---
libavformat/fifo.c | 12 +++
From: Jan Ekström
Until now the proper diff between last_recovery_ts and packet's pts
was only done when last_recovery_ts was AV_NOPTS_VALUE. This is
kind of an oxymoron as the result of comparing that difference to
AV_NOPTS_VALUE most likely always be relatively large.
Thus, move the immediate
The primary parts of this are patches 1,4,5. 2 and 3 were just noticed when
poking at the recovery timestamp logic, where the stream-time comparison logic
seemed somewhat weird (such as comparing the pts to last_recovery_ts only if
last_recovery_ts == AV_NOPTS_VALUE). If they seem incorrectly under
Signed-off-by: Harry Mallon
---
libavcodec/dpx.c | 25 -
tests/ref/fate/dpx-probe | 4 ++--
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 51428459ef..577171258a 100644
--- a/libavcodec/dpx.c
+++ b/libavco
Signed-off-by: Harry Mallon
---
libavcodec/dpx.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 7b18141f97..bd431ccbcb 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -167,7 +167,7 @@ static int decode_frame(AVCodec
Signed-off-by: Harry Mallon
---
libavcodec/dpx.c | 29 +
tests/ref/fate/dpx-probe | 7 +++
2 files changed, 36 insertions(+)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 7e3ac0af2e..51428459ef 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
Signed-off-by: Harry Mallon
---
libavcodec/dpx.c | 127 +--
tests/ref/fate/dpx-probe | 8 +--
2 files changed, 127 insertions(+), 8 deletions(-)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 577171258a..7b18141f97 100644
--- a/libavcodec/dpx
Signed-off-by: Harry Mallon
---
tests/fate/image.mak | 4 ++
tests/ref/fate/dpx-probe | 85
2 files changed, 89 insertions(+)
create mode 100644 tests/ref/fate/dpx-probe
diff --git a/tests/fate/image.mak b/tests/fate/image.mak
index 22072a62f1..d180
Signed-off-by: Harry Mallon
---
libavcodec/dpx.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index b1833ed9ef..7e3ac0af2e 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -216,10 +216,23 @@ static int decode_frame(
On Mon, Dec 7, 2020 at 12:14 PM Nicolas George wrote:
>
> Jan Ekström (12020-12-07):
> > From: Jan Ekström
> >
> > As this is a meta muxer and the same flag is set with the fifo
> > meta muxer, there is really no reason not to have this set here
> > as well.
> >
> > Signed-off-by: Jan Ekström
>
On Sun, Dec 6, 2020 at 4:20 AM Mark Reid wrote:
> On Sun, Nov 22, 2020 at 8:32 PM wrote:
>
> > From: Mark Reid
> >
> > Hi,
> > This patch handles NaNs more like the offical implentation handles them,
> > preserving
> > the original bits.
> >
> >
> >
> https://github.com/AcademySoftwareFoundatio
Will apply soon with few leaks on the allocation error fixed.
On Fri, Dec 4, 2020 at 6:03 PM Paul B Mahol wrote:
> Previous filter output was incorrect. New one actually follows
> graph in comments described on side of filter taps.
>
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/af_earwax.
From: Linjie Fu
According to 7.3.2.2.3 in T-REC-H.265-201911.
Signed-off-by: Linjie Fu
Signed-off-by: Haihao Xiang
---
libavcodec/hevc.h| 3 +++
libavcodec/hevc_ps.c | 44 +---
libavcodec/hevc_ps.h | 15 +++
3 files changed, 59 insertio
From: Linjie Fu
Signed-off-by: Linjie Fu
Signed-off-by: Haihao Xiang
---
libavcodec/hevc_ps.c | 70 +++-
libavcodec/hevc_ps.h | 17 +++
2 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
ind
From: Linjie Fu
uint8_t is big enough and keep consistent with the definition in
cbs_h265.h.
Signed-off-by: Linjie Fu
---
libavcodec/hevcdec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 1164af2862..464eb7cd3c 100644
---
Screen Content Coding allows non-intra slice in an IDR frame, and would
mark the current decoded picture as "used for long-term reference", no
matter TwoVersionsOfCurrDecPicFlag(8.1.3), hence some previous restricts
are not suitable any more.
Constructe RefPicListTemp and RefPicList according to 8
From: Linjie Fu
Signed-off-by: Linjie Fu
---
libavcodec/avcodec.h | 1 +
libavcodec/hevc_ps.c | 2 ++
libavcodec/profiles.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 20af3ef00d..2e853bfdef 100644
--- a/libavcodec/avcodec.h
+++ b/li
There are 3 functions reporting the same log, which is not straight
forward enough for users:
- hevc_parse_slice_header()
- ff_hevc_decode_nal_pps()
- hls_slice_header()
Provide detailed logs to distinguish from "out of range PPS id" and
"empty pps_list[pps_id]".
Before:
PPS id out of range: 0
Add parsing support and reference management for HEVC SCC, as part of
the fully decoding support for hardware(vaapi).
v3:
- addressed the hang issue in multi-threads
- prompted more logs to prompt scc is not fully supported
- PPS overread is kind of weird, would reply separately in previous
From: Linjie Fu
Signed-off-by: Linjie Fu
---
libavcodec/hevcdec.c | 6 ++
libavcodec/hevcdec.h | 4
2 files changed, 10 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 699c13bbcc..7074a0760a 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -
On Tue, Sep 29, 2020 at 10:03 PM Mark Thompson wrote:
> On 10/09/2020 07:42, Haihao Xiang wrote:
> > Resend Linjie's patchset with the updates.
> >
> > As a part of the support for VA-API HEVC SCC decoding (gen12, Tiger
> > Lake+).
> >
> > The full support could be accessed in:
> > https://github
Jan Ekström (12020-12-04):
> From: Stefano Sabatini
>
> ---
> libavutil/avstring.h | 1 +
> libavutil/bprint.c | 14 ++
> tools/ffescape.c | 1 +
> 3 files changed, 16 insertions(+)
Good idea.
But I do not like that we are escaping characters that do not need to
(except > f
Jan Ekström (12020-12-04):
> From: Jan Ekström
>
> Signed-off-by: Jan Ekström
> ---
> fftools/ffprobe.c | 29 -
> 1 file changed, 8 insertions(+), 21 deletions(-)
Should be ok.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
From: Linjie Fu
According to 7.3.6.1, use_integer_mv_flag should be parsed if
motion_vector_resolution_control_idc equals to 2.
Otherwise wrong parameters in the subsequent parsing procedures
would be got.
Signed-off-by: Linjie Fu
---
libavcodec/hevcdec.c | 8
libavcodec/hevcdec.h |
Jan Ekström:
> From: Jan Ekström
>
> Enables encoding of other subtitle formats into TTML and writing
> them out as such documents.
>
> Signed-off-by: Jan Ekström
> ---
> Changelog | 1 +
> doc/general_contents.texi | 1 +
> libavcodec/Makefile| 1 +
> libavcode
Andreas Rheinhardt:
> Jan Ekström:
>> From: Jan Ekström
>>
>> Enables encoding of other subtitle formats into TTML and writing
>> them out as such documents.
>>
>> Signed-off-by: Jan Ekström
>> ---
>> Changelog | 1 +
>> doc/general_contents.texi | 1 +
>> libavcodec/Makefi
On 12/6/2020 8:15 PM, Jan Ekström wrote:
On Sun, Dec 6, 2020 at 5:43 PM James Almer wrote:
Signed-off-by: James Almer
LGTM
Applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubs
On 12/6/2020 8:34 PM, Jan Ekström wrote:
On Mon, Dec 7, 2020 at 1:23 AM Jan Ekström wrote:
On Sun, Dec 6, 2020 at 5:44 PM James Almer wrote:
Create a local one instead from a byte buffer input argument.
Signed-off-by: James Almer
The actual change mentioned in the commit message is LGTM
Hi all,
Here are the notes from the FFmpeg developer meeting of the 5th of December
2020, 15:00 UTC:
# Notes
A recording of the call and IRC logs are available on YouTube and the Wiki
respectively:
- https://youtu.be/1EjIdYuWXEM
- https://trac.ffmpeg.org/wiki/FFmeeting/2020-12
Some extra topi
On Mon, Dec 7, 2020 at 3:56 PM Andreas Rheinhardt
wrote:
>
> Jan Ekström:
> > From: Jan Ekström
> >
> > Enables encoding of other subtitle formats into TTML and writing
> > them out as such documents.
> >
> > Signed-off-by: Jan Ekström
> > ---
> > Changelog | 1 +
> > doc/g
On Mon, Dec 7, 2020 at 4:03 PM Andreas Rheinhardt
wrote:
> >
> > You are not copying the terminating NUL; and you also don't account for
> > it in the above check. Is this intended?
> >
>
> The srt encoder does it like you, the ass encoder is careful only to
> output a NUL terminated string (with
Jan Ekström:
> On Mon, Dec 7, 2020 at 4:03 PM Andreas Rheinhardt
> wrote:
>>>
>>> You are not copying the terminating NUL; and you also don't account for
>>> it in the above check. Is this intended?
>>>
>>
>> The srt encoder does it like you, the ass encoder is careful only to
>> output a NUL term
On Sun, 15. Nov 13:20, Andriy Gelman wrote:
> From: Andriy Gelman
>
> Signed-off-by: Andriy Gelman
> ---
> libavformat/rtsp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index d9832bbf1f..2ef75f50e3 100644
> --- a/libav
> On Dec 8, 2020, at 12:08 PM, Andriy Gelman wrote:
>
> On Sun, 15. Nov 13:20, Andriy Gelman wrote:
>> From: Andriy Gelman
>>
>> Signed-off-by: Andriy Gelman
>> ---
>> libavformat/rtsp.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/rtsp.c b/liba
Friendly ping to check if the patch has been pushed.
Thanks,
Vignesh
On Fri, Dec 4, 2020 at 8:04 AM Steven Liu wrote:
>
>
> > 2020年12月1日 下午6:10，Vignesh Ravichandran
> 写道：
> >
> > Bug ID: 8989
> >
> > This is is due to the following behavior in the current code:
> > 1. The initial_prog_date_tim
On 08-12-2020 12:19 pm, Vignesh Ravichandran wrote:
Friendly ping to check if the patch has been pushed.
No. You can check its status at
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201201101040.28338-1-vignesh.ravichandra...@gmail.com/
State will be 'Accepted' when pushed.
Regards,
---
doc/encoders.texi | 32 +
libavcodec/libvpxenc.c | 79 ++
2 files changed, 111 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 0b1c69e982..aa3a2221b6 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -
42 matches
Mail list logo
