On 16/5/21 7:59 am, Zane van Iperen wrote:
Fixes build failure on older SDKs without it.
Fixes #9242
Signed-off-by: Zane van Iperen
---
libavcodec/videotoolboxenc.c | 4
1 file changed, 4 insertions(+)
NB: This is untested, I do not have a Mac to try it on.
Ping, will apply tomor
On Mon, May 10, 2021 at 11:58:23 +1000, Peter Ross wrote:
> * _snprintf/_vsnprintf() to workaround this problem.
> - * See http://msdn.microsoft.com/en-us/library/1kt27hek(v=vs.80).aspx */
> + * See
> https://web.archive.org/web/20151214111935/http://msdn.microsoft.com/en-us/library/
On Tue, May 18, 2021 at 5:55 AM Wang, Fei W wrote:
>
> On Mon, 2021-05-17 at 11:59 +0300, Jan Ekström wrote:
> > On Mon, May 17, 2021 at 4:50 AM Fei Wang
> > wrote:
> > >
> > > Set all tiles size to create slice data buffer, hardware will use
> > > slice_data_offset/slice_data_size in slice param
Signed-off-by: Ubaldo Porcheddu
---
doc/muxers.texi | 7 +++-
libavformat/mpegtsenc.c | 100 +---
2 files changed, 101 insertions(+), 6 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index e1c6ad0829..e77055e7ef 100644
--- a/doc/
---
There is no good use case yet. Patch 2/2 is only used for test.
libavformat/libsrt.c | 35 +++
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index c1e96f700e..a05921d9f0 100644
--- a/libavformat/libsr
---
Test with:
./ffplay -listen 1 rtmpsrt://127.0.0.1:
./ffmpeg -re -i bunny.mp4 -c copy -f flv rtmpsrt://127.0.0.1:
configure | 2 +
libavformat/Makefile| 2 +
libavformat/protocols.c | 2 +
libavformat/rtmpproto.c | 11 ++-
libavformat/rtmpsrt.c | 167
Hi,
from my understand "ffrtmpsrt" combines rtmp (with flv (de-)muxing),
which demands by design for a transmission without packet loss, with a
transmission protocol based on UDP, which can have packet loss. So, I am
not sure if we actually should add something like this to our source code.
Best
> On May 19, 2021, at 12:19 AM, Thomas Volkert wrote:
>
> Hi,
>
> from my understand "ffrtmpsrt" combines rtmp (with flv (de-)muxing),
> which demands by design for a transmission without packet loss, with a
> transmission protocol based on UDP, which can have packet loss. So, I am
> not sure
On Sun, May 16, 2021 at 10:37:26PM +0200, Marton Balint wrote:
>
>
> On Sun, 16 May 2021, Michael Niedermayer wrote:
>
> > Fixes: CID1464151 Dereference after null check
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/fifo.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 delet
Michael Fabian 'Xaymar' Dirks (12021-05-18):
> while tracking some time stamp issues unique to FFmpeg I noticed
> AV_Time_BASE(_Q) being present quite often, which appears to be a
> value to define time stamps in milliseconds. Tracking it back to its
> origin I could find very little to no informat
On Mon, May 17, 2021 at 11:27:49PM +0530, Vedaa wrote:
> Hi,
> I have removed the tests for overflow & reduced the number of bits read
> to 32-bit to avoid overflow.
>
> Best regards
> ---
> Makefile | 2 ++
> libavutil/tests/integer.c | 21 ++
> libavutil/tests/
Fixes: CID1396258 Dereference null return value
Signed-off-by: Michael Niedermayer
---
libavformat/ftp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/ftp.c b/libavformat/ftp.c
index caeea42920..69caa7670c 100644
--- a/libavformat/ftp.c
+++ b/libavformat/ftp.c
@@ -972,6 +972,
Fixes: CID1398579 Dereference before null check
Signed-off-by: Michael Niedermayer
---
libavfilter/avfiltergraph.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index ed54d3dc11..5389d82d9f 100644
--- a/libavfilt
Fixes: CID1466601 Dereference null return value
Signed-off-by: Michael Niedermayer
---
libavcodec/j2kenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 82ad3284b5..2ebef53388 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/
Hello,
while tracking some time stamp issues unique to FFmpeg I noticed
AV_Time_BASE(_Q) being present quite often, which appears to be a value to
define time stamps in milliseconds. Tracking it back to its origin I could find
very little to no information about why this value was chosen. All
On 5/18/2021 8:47 PM, michael.di...@xaymar.com wrote:
From: Michael Fabian 'Xaymar' Dirks
Increases the time stamp precision to 1 microsecond, the same as
AV_TIME_BASE. This hopefully prevents demuxers from being confused on
the number of frames/samples we actually have per second, and should
m
On Thu, Feb 18, 2021 at 11:39 AM Philip-Dylan Gleonec
wrote:
>
> Here is the reworked patch properly attached.
> Sorry about the duplicate mail, I just noticed I had a mishap with my
> mail client and the previous patch was scrubbed.
>
> Signed-off-by: Philip-Dylan Gleonec
>
> Co-developed-by: S
On 2021-05-18 22:09, Nicolas George wrote:
Michael Fabian 'Xaymar' Dirks (12021-05-18):
while tracking some time stamp issues unique to FFmpeg I noticed
AV_Time_BASE(_Q) being present quite often, which appears to be a
value to define time stamps in milliseconds. Tracking it back to its
origin I
On Tue, 2021-05-18 at 12:26 +0300, Jan Ekström wrote:
> On Tue, May 18, 2021 at 5:55 AM Wang, Fei W
> wrote:
> >
> > On Mon, 2021-05-17 at 11:59 +0300, Jan Ekström wrote:
> > > On Mon, May 17, 2021 at 4:50 AM Fei Wang
> > > wrote:
> > > >
> > > > Set all tiles size to create slice data buffer,
Previously, only the size of a given tile was passed, making the
offset and size marked in VASliceParameterBufferAV1 invalid with
multiple tiles.
Signed-off-by: Fei Wang
---
Change:
1. update commit message.
libavcodec/vaapi_av1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
On 2021-05-18 22:04, Michael Fabian 'Xaymar' Dirks wrote:
Hello,
while tracking some time stamp issues unique to FFmpeg I noticed
AV_Time_BASE(_Q) being present quite often, which appears to be a value to
define time stamps in milliseconds. Tracking it back to its origin I could find
very lit
From: Michael Fabian 'Xaymar' Dirks
Increases the time stamp precision to 1 microsecond, the same as
AV_TIME_BASE. This hopefully prevents demuxers from being confused on
the number of frames/samples we actually have per second, and should
mark all future Matroska/WebM content as being constant r
On 2021-05-19 01:47, michael.di...@xaymar.com wrote:
From: Michael Fabian 'Xaymar' Dirks
Increases the time stamp precision to 1 microsecond, the same as
AV_TIME_BASE. This hopefully prevents demuxers from being confused on
the number of frames/samples we actually have per second, and should
ma
On 2021-05-19 02:06, James Almer wrote:
You should make this an user set AVOption, like it was done with movenc,
keeping the existing value as the default.
I will adjust it to do that.
Also, in your other mail you mentioned this applies to 4.2. Patches should be
made for the master branch.
From: Michael Fabian 'Xaymar' Dirks
Adds the "timestamp_precision" option to matroskaenc, which allows users
to increase the time stamp precision up to 1 nanosecond. This aids with
certain demuxers being unable to detect constant rate. It is a work
around fix for the problems reported in 259, 640
On 2021-05-19 03:44, michael.di...@xaymar.com wrote:
From: Michael Fabian 'Xaymar' Dirks
Adds the "timestamp_precision" option to matroskaenc, which allows users
to increase the time stamp precision up to 1 nanosecond. This aids with
certain demuxers being unable to detect constant rate. It is
26 matches
Mail list logo
