From a45b0ade691816d8037c846f2b773d0ddab74cbe Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Sun, 5 Aug 2018 12:34:21 +0530
Subject: [PATCH] ffmpeg: correct units for raw pts in -progress report
PTS is in microseconds.
Fixes #7345
---
fftools/ffmpeg.c | 2 +-
1 file changed, 1 insertion(+), 1
> Am 05.08.2018 um 09:10 schrieb Gyan Doshi :
>
> <0001-ffmpeg-correct-units-for-raw-pts-in-progress-report.patch>
> av_bprintf(&buf_script, "out_time_ms=N/A\n");
If the patch is a good idea you should also change this line.
Thank you, Carl Eugen
_
On 8/5/18, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 9342/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-4795990841229312
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> --
> Am 05.08.2018 um 08:09 schrieb Gyan Doshi :
>
> Don't know if micro bump is needed.
You may (should) always bump micro when the behaviour changes, if this counts
as a change is up to you (the options you remove didn’t work before afaiu).
Carl Eugen
_
On 05-08-2018 01:46 PM, Carl Eugen Hoyos wrote:
av_bprintf(&buf_script, "out_time_ms=N/A\n");
If the patch is a good idea you should also change this line.
Fixed locally.
Will push soon, if nothing else.
Thanks,
Gyan
___
ffmpeg-devel mailing
Gyan Doshi (2018-08-05):
> Will push soon, if nothing else.
Have you considered you may be breaking some user's scripts?
Carl Eugen's comment was in no way an approval of your patch. Pushing a
patch without a second positive opinion in less than half a day...
Regards,
--
Nicolas George
sig
On 05-08-2018 01:49 PM, Carl Eugen Hoyos wrote:
Am 05.08.2018 um 08:09 schrieb Gyan Doshi :
Don't know if micro bump is needed.
You may (should) always bump micro when the behaviour changes, if this counts
as a change is up to you (the options you remove didn’t work before afaiu).
At
On 05-08-2018 02:17 PM, Nicolas George wrote:
Gyan Doshi (2018-08-05):
Will push soon, if nothing else.
Have you considered you may be breaking some user's scripts?
Ah yes, Sorry, this is used for parsing. What protocol do you suggest
for correcting this?
Regards,
Gyan
_
Our documentation for demuxers/muxers/decoders/encoders is incomplete
and only feature a few.
I propose we cover all or, at least, many more of them.
Thoughts?
Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mai
V1: - check return value of setsockopt in network/tcp.
- move log_net_error as ff_log_net_error for udp/tcp error log reuse.
Jun Zhao (4):
lavf/network: add a ff_log_net_error function.
lavf/network: check return value of setsockopt.
lavf/tcp: check return value of setsockopt.
lavf/udp
add a ff_log_net_error function for error log.
Signed-off-by: Jun Zhao
---
libavformat/network.c |7 +++
libavformat/network.h |2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/libavformat/network.c b/libavformat/network.c
index d5c82e9..21c836a 100644
--- a/libav
Signed-off-by: Jun Zhao
---
libavformat/network.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/network.c b/libavformat/network.c
index 21c836a..4bae7e2 100644
--- a/libavformat/network.c
+++ b/libavformat/network.c
@@ -194,8 +194,11 @@ int ff_socket(i
> Am 05.08.2018 um 13:39 schrieb Gyan Doshi :
>
>
> Our documentation for demuxers/muxers/decoders/encoders is incomplete and
> only feature a few.
>
> I propose we cover all or, at least, many more of them.
>
> Thoughts?
Patch welcome!
Carl Eugen
__
when setsockopt fail, use ff_log_net_error to dump the string
describing for error number.
Signed-off-by: Jun Zhao
---
libavformat/tcp.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index 499e365..8bff9a3 100644
--
Signed-off-by: Jun Zhao
---
libavformat/udp.c | 41 +
1 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 0dde035..bbdeda0 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -150,20 +150,13 @
> I'm attaching a new patch that resolves all of these issues, while still
> resolving this bug for VOD playlists.
>
> Can you please review?
>
> <0001-libavformat-hlsenc-Fix-HLS-Manifest-Generation-from-.patch>
Hi Steven,
Can you please have a look at the updated patch and tell me what you t
On 7/16/2018 4:21 AM, hwren wrote:
> +AVCodecParser ff_avs2_parser = {
> +.codec_ids = { AV_CODEC_ID_AVS2 },
> +.priv_data_size = sizeof(ParseContext),
> +.parser_parse = avs2_parse,
> +.parser_close = ff_parse_close,
> +.split = ff_mpeg4video_split,
If the in
On Sun, 5 Aug 2018, Gyan Doshi wrote:
Our documentation for demuxers/muxers/decoders/encoders is incomplete
and only feature a few.
I propose we cover all or, at least, many more of them.
Thoughts?
I agree. If nothing else, at least the component list should be complete
and the availab
Signed-off-by: Michael Niedermayer
---
libavcodec/gdv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
index 1efc64b1dc..595d8ff4e4 100644
--- a/libavcodec/gdv.c
+++ b/libavcodec/gdv.c
@@ -85,8 +85,7 @@ static void rescale(GDVContext *gdv
Divisions tend to be slower than shifts unless the compiler optimizes them out.
And some of these are in inner loops.
Signed-off-by: Michael Niedermayer
---
libavcodec/gdv.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
i
Possibly fixes: null pointer dereference
Possibly fixes:
9352/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MP3ADUFLOAT_fuzzer-5146068961460224
Fixes: Heap-use-after-free
Fixes:
9453/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MP3ADUFLOAT_fuzzer-5137954375729152
Found-by: continuous fu
Signed-off-by: Michael Niedermayer
---
libavcodec/gdv.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
index 595d8ff4e4..aea15a88ef 100644
--- a/libavcodec/gdv.c
+++ b/libavcodec/gdv.c
@@ -85,9 +85,15 @@ static void rescale(GDVContex
This also replaces some loops by memcpy()
Signed-off-by: Michael Niedermayer
---
libavcodec/gdv.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
index 79ca157dde..274552a7be 100644
--- a/libavcodec/gdv.c
+++ b
Signed-off-by: Michael Niedermayer
---
libavcodec/gdv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
index aea15a88ef..1623febd1a 100644
--- a/libavcodec/gdv.c
+++ b/libavcodec/gdv.c
@@ -479,9 +479,7 @@ static int gdv_decode_frame(AVCo
Simplifies code
Signed-off-by: Michael Niedermayer
---
libavcodec/gdv.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
index 274552a7be..1efc64b1dc 100644
--- a/libavcodec/gdv.c
+++ b/libavcodec/gdv.c
@@ -80,11 +80,11 @@ st
Signed-off-by: Michael Niedermayer
---
libavcodec/gdv.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
index 1623febd1a..d497f76157 100644
--- a/libavcodec/gdv.c
+++ b/libavcodec/gdv.c
@@ -481,8 +481,12 @@ static int gdv_decode_fram
Fixes: Timeout (with the previous commits to gdv.c)
Fixes:
9422/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5143490001371136
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/gd
On 8/5/2018 5:29 PM, Michael Niedermayer wrote:
> Divisions tend to be slower than shifts unless the compiler optimizes them
> out.
> And some of these are in inner loops.
This patch makes the code slightly less readable, IMO. What compiler
doesn't optimize out an integer division by 2 into a rig
James Almer (2018-08-05):
> This patch makes the code slightly less readable, IMO. What compiler
> doesn't optimize out an integer division by 2 into a right shift?
Any compiler that cannot figure out that x is positive in this
convoluted loop. Signed divisions cannot be optimized as shifts. Make
On Sun, Aug 05, 2018 at 10:08:31AM +0200, Paul B Mahol wrote:
> On 8/5/18, Michael Niedermayer wrote:
> > Fixes: Timeout
> > Fixes:
> > 9342/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-4795990841229312
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss
On Sun, Aug 05, 2018 at 11:37:24PM +0200, Nicolas George wrote:
> James Almer (2018-08-05):
> > This patch makes the code slightly less readable, IMO. What compiler
> > doesn't optimize out an integer division by 2 into a right shift?
>
> Any compiler that cannot figure out that x is positive in t
Michael Niedermayer (2018-08-05):
> thats done in the next patch
Indeed, except for the part where the variable are turned to unsigned to
let the compiler optimize the division. Sorry to have missed that.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
__
On Sun, Aug 05, 2018 at 06:19:01PM -0300, James Almer wrote:
> On 8/5/2018 5:29 PM, Michael Niedermayer wrote:
> > Divisions tend to be slower than shifts unless the compiler optimizes them
> > out.
> > And some of these are in inner loops.
>
> This patch makes the code slightly less readable, IM
On 8/5/2018 6:58 PM, Michael Niedermayer wrote:
> On Sun, Aug 05, 2018 at 06:19:01PM -0300, James Almer wrote:
>> On 8/5/2018 5:29 PM, Michael Niedermayer wrote:
>>> Divisions tend to be slower than shifts unless the compiler optimizes them
>>> out.
>>> And some of these are in inner loops.
>>
>>
On Sat, Aug 04, 2018 at 10:19:45AM +, lee ju wrote:
> ---
> libavcodec/frame_thread_encoder.c | 17 +
> 1 file changed, 17 insertions(+)
probably ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or r
Signed-off-by: James Almer
---
fftools/ffmpeg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 55faec8ede..2459374f08 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -724,11 +724,11 @@ static void write_packet(OutputFile *
> 在 2018年8月4日，上午2:17，Ronak 写道：
>
>>> I have read this patch some problem for this patch.
>>>
>>> 1. maybe there will have a problem when duration is not same when every
>>> fragment, for example:
>>> liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -v quiet -i
>>> ~/Movies/Test
On 05-08-2018 02:12 PM, Gyan Doshi wrote:
Will push soon, if nothing else.
Pushed as 076b19660e7c9466d2d78ff9ae66b97ff2b6aa1e
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 05-08-2018 02:28 PM, Gyan Doshi wrote:
Ah yes, Sorry, this is used for parsing. What protocol do you suggest
for correcting this?
Any thoughts on this?
I see that there were two changes made to value fields of the progress
report earlier this year - a194e9c4159 and 1322b00060
Regards,
LGTM
Hi Michael, I think Shiyou will look after Loongson optimizations.
Again, Copying David Lau from MIPS if he has any objections to raise.
David, please assign appropriate maintainer for MIPS work (apart from
Loongson). The procedure is to send a patch modifying MAINTAINERS file from
ffmpeg
On 31/07/2018 17:19, James Almer wrote:
On 7/31/2018 3:37 AM, Steve Lhomme wrote:
On 30/07/2018 17:13, James Almer wrote:
On 7/30/2018 2:03 AM, Steve Lhomme wrote:
On 26/07/2018 03:11, James Almer wrote:
Make sure to not write forbidden OBUs to CodecPrivate, and do the same
with
unnecessary O
41 matches
Mail list logo
