Signed-off-by: Steven Liu
---
libavformat/dashdec.c | 32
1 file changed, 32 insertions(+)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index eed149cd1a..b6394403b9 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1161,6 +1161,36
Currently the strftime option generate timestamp based on generation
time. The new option would calcualte timestamp from source's
start_realtime and pkt->pts, try to generate a timestamp matches the
source starting time.
---
doc/muxers.texi | 4
libavformat/img2enc.c | 39
On 15-04-2019 12:17 AM, James Almer wrote:
On 4/14/2019 3:29 PM, Hendrik Leppkes wrote:
On Sun, Apr 14, 2019 at 6:50 PM Gyan wrote:
Implemented this patch
http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241733.html
in libavcodec as suggested by Michael
This sure adds a lot of
2019-04-15 8:26 GMT+02:00, Steven Liu :
> Signed-off-by: Steven Liu
> ---
> libavformat/dashdec.c | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index eed149cd1a..b6394403b9 100644
> ---
This isn't likely to be a huge problem, but it allows us to reason more
about run-in. It also exposes my gripe about klv_read_packet() using
mxf_read_sync()
/TomasFrom c2d66c4aa3105e33f8485234ca760da699cdfb4d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Sun, 14 Apr 2019
2019-04-15 10:30 GMT+02:00, Tomas Härdin :
> This isn't likely to be a huge problem, but it allows us to reason more
> about run-in. It also exposes my gripe about klv_read_packet() using
> mxf_read_sync()
Does this patch have an effect on one of our samples?
Carl Eugen
Signed-off-by: Lance.Gao
---
libavformat/flvdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index b531a39..bc63dd2 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1003,6 +1003,8 @@ static int flv_read_packet(AVFormatContext
2019-04-15 9:42 GMT+02:00, Liu Steven :
>
>
>> 在 2019年4月11日，下午12:03，Liu Steven 写道：
>>
>>
>>
>>> 在 2019年4月11日，上午11:55，Jun Li 写道：
>>> ...
>>>
>>> Ping.
>> LGTM
>
> Pushed
Who wrote the patch that you pushed?
Carl Eugen
___
ffmpeg-devel mailing list
Carl Eugen Hoyos 于2019年4月15日周一 下午6:59写道：
>
> 2019-04-15 8:26 GMT+02:00, Steven Liu :
> > Signed-off-by: Steven Liu
> > ---
> > libavformat/dashdec.c | 32
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> >
Hendrik Leppkes 于2019年4月15日周一 下午7:48写道：
>
> On Mon, Apr 15, 2019 at 12:46 PM Carl Eugen Hoyos wrote:
> >
> > 2019-04-15 9:42 GMT+02:00, Liu Steven :
> > >
> > >
> > >> 在 2019年4月11日，下午12:03，Liu Steven 写道：
> > >>
> > >>
> > >>
> > >>> 在 2019年4月11日，上午11:55，Jun Li 写道：
> > >>> ...
> > >>>
> > >>>
> 在 2019年4月11日，下午12:03，Liu Steven 写道：
>
>
>
>> 在 2019年4月11日，上午11:55，Jun Li 写道：
>> ...
>>
>> Ping.
> LGTM
Pushed
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe,
Carl Eugen Hoyos 于2019年4月15日周一 下午6:46写道：
>
> 2019-04-15 9:42 GMT+02:00, Liu Steven :
> >
> >
> >> 在 2019年4月11日，下午12:03，Liu Steven 写道：
> >>
> >>
> >>
> >>> 在 2019年4月11日，上午11:55，Jun Li 写道：
> >>> ...
> >>>
> >>> Ping.
> >> LGTM
> >
> > Pushed
>
> Who wrote the patch that you pushed?
>
Wow, thanks
On Mon, Apr 15, 2019 at 12:46 PM Carl Eugen Hoyos wrote:
>
> 2019-04-15 9:42 GMT+02:00, Liu Steven :
> >
> >
> >> 在 2019年4月11日，下午12:03，Liu Steven 写道：
> >>
> >>
> >>
> >>> 在 2019年4月11日，上午11:55，Jun Li 写道：
> >>> ...
> >>>
> >>> Ping.
> >> LGTM
> >
> > Pushed
>
> Who wrote the patch that you
On Mon, Apr 15, 2019 at 8:17 AM Gyan wrote:
>
>
>
> On 15-04-2019 12:17 AM, James Almer wrote:
> > On 4/14/2019 3:29 PM, Hendrik Leppkes wrote:
> >> On Sun, Apr 14, 2019 at 6:50 PM Gyan wrote:
> >>> Implemented this patch
> >>> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241733.html
Signed-off-by: Steven Liu
---
libavformat/dashdec.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index eed149cd1a..6e3e7e4f1e 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1161,6 +1161,34 @@
2019-04-12 13:20 GMT+02:00, Jun Zhao :
> From: Jun Zhao
>
> Cleanup the applehttp as demuxer name, when use the command :
>
> ffmpeg -formats, get the confused information like:
> "
> E hls Apple HTTP Live Streaming
> D hls,applehttp Apple HTTP Live Streaming
> "
> we don't use
Fixes: Timeout (158sec -> 36sec)
Fixes:
14214/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DSICINVIDEO_fuzzer-5633569034076160
This is untested with valid cin files as none of the files i found cover the
changed
codepath
Found-by: continuous fuzzing process
On Mon, Apr 15, 2019 at 09:58:30AM +0800, Jun Zhao wrote:
> From: Jun Zhao
>
> The spec in https://xiph.org/vorbis/doc/v-comment.html states that
> the metadata keys are case-insensitive, so don't change the case
> and update the fate test case.
>
> Fix #7784
>
> Signed-off-by: Jun Zhao
> ---
This allows users to specify an upper limit on the size of outgoing packets
when publishing via RTSP.
Signed-off-by: Martin Storsjö
---
libavformat/rtsp.c | 6 +-
libavformat/rtsp.h | 1 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
On Mon, 15 Apr 2019, Tomas Härdin wrote:
This isn't likely to be a huge problem, but it allows us to reason more
about run-in. It also exposes my gripe about klv_read_packet() using
mxf_read_sync()
I would allow 65536 bytes as well for run-in, even if that is against the
standard. The MXF
On Tue, 9 Apr 2019, Marton Balint wrote:
Fixes ticket #7789.
Pushed the series.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On Mon, Apr 15, 2019 at 04:15:50PM +0800, Lance.Gao wrote:
> Signed-off-by: Lance.Gao
> ---
> libavformat/flvdec.c | 2 ++
> 1 file changed, 2 insertions(+)
"fix the problem of packet mismatch while reading rtmp stream"
this is too vague, its not clear what problem this is about, or how this
mån 2019-04-15 klockan 23:03 +0200 skrev Marton Balint:
>
> On Mon, 15 Apr 2019, Tomas Härdin wrote:
>
> > This isn't likely to be a huge problem, but it allows us to reason more
> > about run-in. It also exposes my gripe about klv_read_packet() using
> > mxf_read_sync()
>
> I would allow 65536
2019-04-15 23:56 GMT+02:00, Michael Niedermayer :
> On Sun, Apr 14, 2019 at 10:57:35PM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch removes two unused macros as a preparation for a new patch
>> to silence a clang warning.
>>
>> Please comment, Carl Eugen
>
>> vf_fspp.h |2 --
>>
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 15 +++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_lagfun.c | 252 +++
4 files changed, 269 insertions(+)
create mode 100644 libavfilter/vf_lagfun.c
diff
On Sun, Apr 14, 2019 at 10:57:35PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch removes two unused macros as a preparation for a new patch
> to silence a clang warning.
>
> Please comment, Carl Eugen
> vf_fspp.h |2 --
> 1 file changed, 2 deletions(-)
>
2019-04-14 1:02 GMT+02:00, Michael Niedermayer :
> On Sat, Apr 13, 2019 at 07:25:54PM -0300, James Almer wrote:
>> On 4/13/2019 7:04 PM, Carl Eugen Hoyos wrote:
>> > Hi!
>> >
>> > Attached patch silences two warnings shown when compiling with clang:
>> > libavfilter/vf_fspp.h:51:42: warning:
On 14/04/2019 05:27, Jarek Samic wrote:
> This is a direct port of the CPU filter.
>
> Signed-off-by: Jarek Samic
> ---
> I've made the changes requested from the first patch. I also investigated
> splitting the kernel into two kernels in order to remove the blending if
> branch; I noticed
Signed-off-by: James Almer
---
libavcodec/cbs_h2645.c | 20
1 file changed, 20 insertions(+)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index e74f8dce81..a205293b3c 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -255,6 +255,8 @@ static
The spec defines it as an array of signed values, inferred to 0 when not
present.
Signed-off-by: James Almer
---
Couldn't find any sample using it.
libavcodec/cbs_h265.h | 2 +-
libavcodec/cbs_h265_syntax_template.c | 7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
The spec defines it as a signed value.
Signed-off-by: James Almer
---
The only sample i could find with time_offset values it's in the fate suite,
and in all cases it's 0.
libavcodec/cbs_h264.h | 2 +-
libavcodec/cbs_h264_syntax_template.c | 5 +++--
2 files changed, 4
Signed-off-by: James Almer
---
libavcodec/cbs.c | 79 +++
libavcodec/cbs_internal.h | 20 +-
2 files changed, 98 insertions(+), 1 deletion(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index c388be896b..726bd582f5 100644
---
Signed-off-by: James Almer
---
The sample https://0x0.st/sljR.webm appears to be parsed the exact same way
after this patch.
libavcodec/cbs_av1.c | 68 ++--
1 file changed, 8 insertions(+), 60 deletions(-)
diff --git a/libavcodec/cbs_av1.c
mån 2019-04-15 klockan 12:40 +0200 skrev Carl Eugen Hoyos:
> > 2019-04-15 10:30 GMT+02:00, Tomas Härdin :
> > This isn't likely to be a huge problem, but it allows us to reason more
> > about run-in. It also exposes my gripe about klv_read_packet() using
> > mxf_read_sync()
>
> Does this patch
2019-04-16 0:00 GMT+02:00, Tomas Härdin :
> mån 2019-04-15 klockan 12:40 +0200 skrev Carl Eugen Hoyos:
>> > 2019-04-15 10:30 GMT+02:00, Tomas Härdin :
>> > This isn't likely to be a huge problem, but it allows us to reason more
>> > about run-in. It also exposes my gripe about klv_read_packet()
This allows users to specify an upper limit on the size of outgoing packets
when publishing via RTSP.
Signed-off-by: Martin Storsjö
---
libavformat/rtsp.c | 5 -
libavformat/rtsp.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
On Tue, Apr 16, 2019 at 2:55 AM Jan Ekström wrote:
>
> On Sat, Apr 13, 2019 at 5:36 PM der richter wrote:
> >
> > From: fumoboy007
> >
> > this patch was originally posted on issue #7704 and was slightly
> > adjusted to check for the availability of the pixel format.
> > ---
>
> Functionally
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Tuesday, April 2, 2019 7:40 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 5/9] lavc/qsvdec: Add VP9 decoder
> support
>
> From: Zhong Li
>
> VP9 decoder is supported on
On Sat, Apr 13, 2019 at 5:36 PM der richter wrote:
>
> From: fumoboy007
>
> this patch was originally posted on issue #7704 and was slightly
> adjusted to check for the availability of the pixel format.
> ---
Functionally tested on a macOS 10.13.x + XCode 10.1, as well as
forcibly made the
the patch 1 to patch 7 of this patch set asks for review and push.
patch 8 (this patch) asks for comments, thanks.
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Guo, Yejun
> Sent: Tuesday, April 02, 2019 10:30 PM
> To:
On Tue, Apr 16, 2019 at 5:51 AM Michael Niedermayer
wrote:
>
> On Mon, Apr 15, 2019 at 09:58:30AM +0800, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > The spec in https://xiph.org/vorbis/doc/v-comment.html states that
> > the metadata keys are case-insensitive, so don't change the case
> > and
On Mon, Apr 15, 2019 at 11:02 PM Carl Eugen Hoyos wrote:
>
> 2019-04-12 13:20 GMT+02:00, Jun Zhao :
> > From: Jun Zhao
> >
> > Cleanup the applehttp as demuxer name, when use the command :
> >
> > ffmpeg -formats, get the confused information like:
> > "
> > E hls Apple HTTP Live
Up until now, a block's relative offset has been reported as the offset
in the log messages output when writing blocks; given that it is
impossible to know the real offset from the beginning of the file at
this point due to the fact that it is not yet known how many bytes will
be used for the
From: Jun Zhao
commit abfeba9 "lavf/hls: Cleanup the applehttp" missed
the version bump and Changelog entry.
Signed-off-by: Jun Zhao
---
Changelog |1 +
libavformat/version.h |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Changelog b/Changelog
index
44 matches
Mail list logo
