On 19-07-2019 11:04 PM, Linjie Fu wrote:
Currently, ffmpeg inserts scale filter by default in the filter graph
to force the whole decoded stream to scale into the same size with the
first frame. It's not quite make sense in resolution changing cases if
user wants the rawvideo without any
Am 20.07.19 um 00:37 schrieb Hendrik Leppkes:
>> $1 The captain is always right.
>>
>> $2 If the captain fails, see $1.
>>
>> 0 against 327 fails in 2500 frames is a "slightly more favorable
>> result". See my last post from 22:23 CEST.
>>
> The entire point is that your change is not a fix, its
---
libavfilter/opencl.c | 10 +++
libavfilter/opencl.h | 142 +--
2 files changed, 146 insertions(+), 6 deletions(-)
diff --git a/libavfilter/opencl.c b/libavfilter/opencl.c
index 95f0bfc604..8e96543467 100644
--- a/libavfilter/opencl.c
+++
This filter is the subject of my GSoC project.
This is a video stabilization / deshake filter (name undetermined, feel free to
discuss) that uses feature
point matching and RANSAC to determine a camera path, smooths the camera path
with a gaussian filter, and
then applies the new path to the
---
libavfilter/transform.c | 13 ++---
libavfilter/transform.h | 30 +++---
libavfilter/vf_deshake.c | 7 +--
3 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/libavfilter/transform.c b/libavfilter/transform.c
index f92fc4d42f..f65de965cd
Fixes: signed integer overflow: 65313 * 65313 cannot be represented in type
'int'
Fixes:
15740/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DVBSUB_fuzzer-5641749164195840
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
On Fri, Jul 19, 2019 at 11:49:04PM +0200, Nicolas George wrote:
> Michael Niedermayer (12019-07-19):
> > > +if ((whence & AVSEEK_SIZE))
> > redundant ()
>
> I use it as a marker that it is not a mistake for &&. IIRC, gcc (with
> some options) warns about "if (a & b)" but accepts "if ((a &
On Fri, Jul 19, 2019 at 09:23:24PM +0200, Marton Balint wrote:
>
>
> On Fri, 19 Jul 2019, lance.lmw...@gmail.com wrote:
>
> >From: Limin Wang
> >
> >Below is the tested results for the new added pixel format without autoscale
> >to rgb24:
> >1. AV_PIX_FMT_YUVJ420P
> >time ./ffprobe -of
Am 20.07.19 um 00:06 schrieb Ulf Zibis:
> Am 19.07.19 um 22:46 schrieb Hendrik Leppkes:
>> This has absolutely nothing to do with "rounding", since there is no
>> rounding being performed, but all to do with that floating point
>> arithmetic is just always inaccurate.
> Floating point
On Sat, Jul 20, 2019 at 12:06 AM Ulf Zibis wrote:
>
>
> Am 19.07.19 um 22:46 schrieb Hendrik Leppkes:
> > This has absolutely nothing to do with "rounding", since there is no
> > rounding being performed, but all to do with that floating point
> > arithmetic is just always inaccurate.
>
>
On Fri, Jul 19, 2019 at 09:26:06PM +0200, Marton Balint wrote:
>
>
> On Fri, 19 Jul 2019, lance.lmw...@gmail.com wrote:
>
> >From: Limin Wang
> >
> >This patch haven't make other pixel format usable yet to make sure the test
> >result is same with rgb32 format.
> >
> >Signed-off-by: Limin Wang
Hendrik Leppkes (12019-07-20):
> That seems like a particularly dumb compiler "feature". Checking
> bitmasks for a set bit seems like a rather standard if condition.
Maybe, to each their own, but it saved me a few times, so personally I
like it, especially since the double-parentheses is an
Am 19.07.19 um 22:46 schrieb Hendrik Leppkes:
> This has absolutely nothing to do with "rounding", since there is no
> rounding being performed, but all to do with that floating point
> arithmetic is just always inaccurate.
Floating point representation and arithmetic *is* "aproximating
On Fri, Jul 19, 2019 at 11:49 PM Nicolas George wrote:
>
> Michael Niedermayer (12019-07-19):
> > > +if ((whence & AVSEEK_SIZE))
> > redundant ()
>
> I use it as a marker that it is not a mistake for &&. IIRC, gcc (with
> some options) warns about "if (a & b)" but accepts "if ((a & b))", and
Michael Niedermayer (12019-07-19):
> > +if ((whence & AVSEEK_SIZE))
> redundant ()
I use it as a marker that it is not a mistake for &&. IIRC, gcc (with
some options) warns about "if (a & b)" but accepts "if ((a & b))", and
that is the preferred way. We already have a few instances in the
Michael Niedermayer (12019-07-08):
> On Sat, Jun 22, 2019 at 01:29:33AM +0200, Michael Niedermayer wrote:
> > Fixes: signed integer overflow: 6494225984479297536 - -6043795377581187040
> > cannot be represented in type 'long'
> > Fixes:
> >
On Fri, Jul 19, 2019 at 7:44 PM Ulf Zibis wrote:
>
>
> Am 19.07.19 um 19:23 schrieb Nicolas George:
> > Ulf Zibis (12019-07-19):
> >> So please give an alternative theory than a rounding issue, why I
> >> actually experience a different result.
> > Code with doubles is very fragile, changing
Am 19.07.19 um 20:01 schrieb Nicolas George:
> Ulf Zibis (12019-07-19):
>> May be, but I believe single rounding over twice rounding is less fragile.
> Yes. And two plastic bags will slow your fall more than one when you
> jump from a plane.
>
>> Try this:
>> printf("single rounding:
On Fri, Jul 19, 2019 at 03:36:43PM +0200, Paul B Mahol wrote:
> On 7/19/19, Michael Niedermayer wrote:
> > On Thu, Jun 27, 2019 at 09:32:44AM +0200, Paul B Mahol wrote:
> >> On 6/27/19, Michael Niedermayer wrote:
> >> > Fixes: signed integer overflow: 61 + 2147483647 cannot be represented
> >> >
On Fri, Jul 19, 2019 at 10:00:52 +0200, Nicolas George wrote:
> I do not judge whether this filter would be useful and should be
> included, but if so, then I would appreciate that the output be done
> using AVIO, so that it can go to any supported protocol.
The metadata filter has a nice example
On Fri, Jul 19, 2019 at 03:54:19PM +0200, Paul B Mahol wrote:
> On 7/19/19, Michael Niedermayer wrote:
> > On Sat, Jun 22, 2019 at 01:29:36AM +0200, Michael Niedermayer wrote:
> >> Fixes: Timeout (40sec -> 13sec)
> >> Fixes:
> >>
On Mon, Jul 01, 2019 at 12:16:49AM +0200, Michael Niedermayer wrote:
> Fixes: left shift of 1 by 31 places cannot be represented in type 'int'
> Fixes:
> 15328/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5637545171353600
>
> Found-by: continuous fuzzing process
>
On Thu, Jun 13, 2019 at 01:09:34PM +0200, Michael Niedermayer wrote:
> Such a failure should not be fatal and its worth testing this path too
>
> Signed-off-by: Michael Niedermayer
> ---
> tools/target_dem_fuzzer.c | 2 --
> 1 file changed, 2 deletions(-)
will apply
[...]
--
Michael
On Fri, 19 Jul 2019, lance.lmw...@gmail.com wrote:
From: Limin Wang
This patch haven't make other pixel format usable yet to make sure the test
result is same with rgb32 format.
Signed-off-by: Limin Wang
---
libavfilter/f_select.c | 34 ++
1 file changed, 30
On Fri, 19 Jul 2019, lance.lmw...@gmail.com wrote:
From: Limin Wang
Below is the tested results for the new added pixel format without autoscale to
rgb24:
1. AV_PIX_FMT_YUVJ420P
time ./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact
-f lavfi \
On Fri, Jul 19, 2019 at 02:23:53PM +0200, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> libavformat/aviobuf.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 6a5cd97b0a..750326f62d 100644
> ---
On Fri, Jul 19, 2019 at 12:36:48PM +, Pawlowski, Slawomir wrote:
> From 3ce39207e95eb4697abb0fbaccd37cc451559e49 Mon Sep 17 00:00:00 2001
> From: Slawomir Pawlowski
> Date: Fri, 19 Jul 2019 13:16:16 +0200
> Subject: [PATCH] Add multithreading for swscale filter.
>
> Use with option
Ulf Zibis (12019-07-19):
> May be, but I believe single rounding over twice rounding is less fragile.
Yes. And two plastic bags will slow your fall more than one when you
jump from a plane.
> Try this:
> printf("single rounding: %.40f\n", 130560LL * 1 / (double)12800);
> printf("twice
Am 19.07.19 um 19:23 schrieb Nicolas George:
> Ulf Zibis (12019-07-19):
>> So please give an alternative theory than a rounding issue, why I
>> actually experience a different result.
> Code with doubles is very fragile, changing anything in the structure of
> your formula will give slightly
Currently, ffmpeg inserts scale filter by default in the filter graph
to force the whole decoded stream to scale into the same size with the
first frame. It's not quite make sense in resolution changing cases if
user wants the rawvideo without any scale.
Using autoscale/noautoscale to indicate
Ulf Zibis (12019-07-19):
> So please give an alternative theory than a rounding issue, why I
> actually experience a different result.
Code with doubles is very fragile, changing anything in the structure of
your formula will give slightly different results. You were just lucky
that this change
Am 19.07.19 um 18:57 schrieb Nicolas George:
>
>> avfilter/select: avoid twice rounding
> Maybe I a missing something, I see no change in rounding in this code.
So please give an alternative theory than a rounding issue, why I
actually experience a different result.
> I suspect your diagnosis
> -Original Message-
> From: Nicolas George [mailto:geo...@nsup.org]
> Sent: Saturday, July 20, 2019 00:37
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie ; Eoff, Ullysses A
>
> Subject: Re: [FFmpeg-devel] [PATCH, v3 2/2] doc/ffmpeg.texi: update docs
>
Hi Tomas
> On Jul 19, 2019, at 8:48 AM, Tomas Härdin wrote:
>
> tor 2019-07-18 klockan 11:39 -0700 skrev Baptiste Coudurier:
>> ---
>> libavformat/mxfenc.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> index
Ulf Zibis (12019-07-19):
> >From f14142a22d340cba48b3e2352a33026590dec3a5 Mon Sep 17 00:00:00 2001
> From: Ulf Zibis
> Date: 19.07.2019, 18:27:51
>
> avfilter/select: avoid twice rounding
Maybe I a missing something, I see no change in rounding in this code. I
suspect your diagnosis is wrong.
Hi,
I have seen, that filter select sometimes doesn't catch a frame
determined by t as cause of floating point rounding. I could experience
less problems after removing 2 times rounding in filter select. I'm
aware that there still is a chance to miss a catch, but I believe it
should be much more
Andreas Rheinhardt (12019-07-19):
> The commit title is wrong: It's AVSEEK_SIZE.
Locally fixed, thanks.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Linjie Fu (12019-07-20):
> Add docs for autoscale.
In the same patch. Why would you want to separate?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
> -Original Message-
> From: Fu, Linjie
> Sent: Friday, July 19, 2019 05:35
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [PATCH] lavc/phtread_frame: update hwaccel_priv_data in time for
> multithread
>
> When resolution/format changes, hwaccel_uninit/hwaccel_init will
> be
Nicolas George:
> Andreas Rheinhardt (12019-07-15):
>> Up until now, when performing a SEEK_END seek, the subfile protocol
>> ignored the desired position (relative to EOF) and used the current
>> absolute offset in the input file instead.
>>
>> And when performing a SEEK_CUR seek, the current
The commit title is wrong: It's AVSEEK_SIZE.
Nicolas George:
> Signed-off-by: Nicolas George
> ---
> libavformat/concat.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/concat.c b/libavformat/concat.c
> index 19c83c309a..ea3bc1dfde 100644
> ---
Add docs for autoscale.
Update information for autorotate according to ffplay.
Signed-off-by: U. Artie Eoff
Signed-off-by: Linjie Fu
---
doc/ffmpeg.texi | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index
Currently, ffmpeg inserts scale filter by default in the filter graph
to force the whole decoded stream to scale into the same size with the
first frame. It's not quite make sense in resolution changing cases if
user wants the rawvideo without any scale.
Using autoscale/noautoscale to indicate
On Sun, Jul 07, 2019 at 03:18:13PM +0200, Michael Niedermayer wrote:
> Fixes: memleaks on error paths during init
> Fixes:
> 15548/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLASHSV2_fuzzer-6324019382452224
>
> Found-by: continuous fuzzing process
>
On Sun, Jul 07, 2019 at 03:18:12PM +0200, Michael Niedermayer wrote:
> Fixes: memleaks on error paths during init
> Fixes:
> 15533/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLASHSV_fuzzer-5647977168764928
>
> Found-by: continuous fuzzing process
>
On Fri, Jul 05, 2019 at 01:28:33AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 9151595917793558550 + 297519050751678697
> cannot be represented in type 'long'
> Fixes:
> 15496/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5722866475073536
>
> Found-by: continuous
tor 2019-07-18 klockan 11:39 -0700 skrev Baptiste Coudurier:
> ---
> libavformat/mxfenc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index b677f6af8e..2e54320cf0 100644
> --- a/libavformat/mxfenc.c
> +++
Am Fr., 19. Juli 2019 um 14:37 Uhr schrieb Pawlowski, Slawomir
:
> -res = alloc_slice(>slice[0], c->srcFormat, c->srcH, c->chrSrcH,
> c->chrSrcHSubSample, c->chrSrcVSubSample, 0);
> -if (res < 0) goto cleanup;
> +if(!c->parent) {
> +res = alloc_slice(>slice[0], c->srcFormat,
On 7/19/19, Michael Niedermayer wrote:
> On Sat, Jun 22, 2019 at 01:29:36AM +0200, Michael Niedermayer wrote:
>> Fixes: Timeout (40sec -> 13sec)
>> Fixes:
>> 15417/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLIC_fuzzer-5679812615602176
>>
>> Found-by: continuous fuzzing process
>>
On 7/19/19, Nicolas George wrote:
> Pawlowski, Slawomir (12019-07-19):
>> From 3ce39207e95eb4697abb0fbaccd37cc451559e49 Mon Sep 17 00:00:00 2001
>> From: Slawomir Pawlowski
>> Date: Fri, 19 Jul 2019 13:16:16 +0200
>> Subject: [PATCH] Add multithreading for swscale filter.
>>
>> Use with option
On 7/19/19, Michael Niedermayer wrote:
> On Thu, Jun 27, 2019 at 09:32:44AM +0200, Paul B Mahol wrote:
>> On 6/27/19, Michael Niedermayer wrote:
>> > Fixes: signed integer overflow: 61 + 2147483647 cannot be represented
>> > in
>> > type 'int'
>> > Fixes:
>> >
On 7/19/19, Nicolas George wrote:
> Pawlowski, Slawomir (12019-07-19):
>> From 3ce39207e95eb4697abb0fbaccd37cc451559e49 Mon Sep 17 00:00:00 2001
>> From: Slawomir Pawlowski
>> Date: Fri, 19 Jul 2019 13:16:16 +0200
>> Subject: [PATCH] Add multithreading for swscale filter.
>>
>> Use with option
Am 03.07.19 um 10:52 schrieb Michael Niedermayer:
>
>> I too thought on that, but the existing functions too rely on
>> float/double. Should I anyway provide a solution with integer arithmetic?
> its indepedant of your patch but i think all these should use integers
> unless its too messy
Now
Michael Niedermayer (12019-07-15):
> Fixes: division by zero
> Fixes:
> 15725/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5641231956180992
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael
Andreas Rheinhardt (12019-07-19):
> This is only allowed after AVSEEK_SIZE is allowed to be usable from
> outside, i.e. your first two patches should be swapped.
It will only print "unknown". And with dynamic linking plus the fact
that it was a public API, it is good to know what happens when
Pawlowski, Slawomir (12019-07-19):
> From 3ce39207e95eb4697abb0fbaccd37cc451559e49 Mon Sep 17 00:00:00 2001
> From: Slawomir Pawlowski
> Date: Fri, 19 Jul 2019 13:16:16 +0200
> Subject: [PATCH] Add multithreading for swscale filter.
>
> Use with option "-filter_scale_threads "
> Split slice in
Pawlowski, Slawomir (12019-07-19):
> From 3ce39207e95eb4697abb0fbaccd37cc451559e49 Mon Sep 17 00:00:00 2001
> From: Slawomir Pawlowski
> Date: Fri, 19 Jul 2019 13:16:16 +0200
> Subject: [PATCH] Add multithreading for swscale filter.
>
> Use with option "-filter_scale_threads "
> Split slice in
From 3ce39207e95eb4697abb0fbaccd37cc451559e49 Mon Sep 17 00:00:00 2001
From: Slawomir Pawlowski
Date: Fri, 19 Jul 2019 13:16:16 +0200
Subject: [PATCH] Add multithreading for swscale filter.
Use with option "-filter_scale_threads "
Split slice in scaler in to parts.
Signed-off-by: Slawomir
Nicolas George:
> For now: print the input size as detected by AVSEEK_SIZE.
>
> Signed-off-by: Nicolas George
> ---
> tools/aviocat.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/tools/aviocat.c b/tools/aviocat.c
> index 2aa08b92ed..7dca4f52b5
Best regards,
Sławomir Pawłowski
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 |
Andreas Rheinhardt (12019-07-15):
> Up until now, when performing a SEEK_END seek, the subfile protocol
> ignored the desired position (relative to EOF) and used the current
> absolute offset in the input file instead.
>
> And when performing a SEEK_CUR seek, the current position has been
>
Signed-off-by: Nicolas George
---
libavformat/concat.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/concat.c b/libavformat/concat.c
index 19c83c309a..ea3bc1dfde 100644
--- a/libavformat/concat.c
+++ b/libavformat/concat.c
@@ -38,6 +38,7 @@ struct
Signed-off-by: Nicolas George
---
libavformat/aviobuf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 6a5cd97b0a..750326f62d 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -255,6 +255,9 @@ int64_t
For now: print the input size as detected by AVSEEK_SIZE.
Signed-off-by: Nicolas George
---
tools/aviocat.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/aviocat.c b/tools/aviocat.c
index 2aa08b92ed..7dca4f52b5 100644
--- a/tools/aviocat.c
+++
From: Limin Wang
Below is the tested results for the new added pixel format without autoscale to
rgb24:
1. AV_PIX_FMT_YUVJ420P
time ./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact
-f lavfi \
On Thu, Jun 27, 2019 at 09:32:44AM +0200, Paul B Mahol wrote:
> On 6/27/19, Michael Niedermayer wrote:
> > Fixes: signed integer overflow: 61 + 2147483647 cannot be represented in
> > type 'int'
> > Fixes:
> > 15311/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_fuzzer-5742552826773504
> >
From: Limin Wang
why change .4 to .25, it's for:
one scenecut(pkt_pts=20040) isn't detected by 0.4 threshold
why not change to 0.25 instead of .3:
it'll cause this scenecut(pkt_pts=20040) failed to detect after applied the next
patch which enable yuvj420
for fate testing, it's better to catch
From: Limin Wang
This patch haven't make other pixel format usable yet to make sure the test
result is same with rgb32 format.
Signed-off-by: Limin Wang
---
libavfilter/f_select.c | 34 ++
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git
On Thu, Jun 27, 2019 at 02:35:33AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 14 + 2147483647 cannot be represented in type
> 'int'
> Fixes:
> 14794/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5677380695228416
>
> Found-by: continuous fuzzing process
On Sat, Jun 22, 2019 at 01:29:36AM +0200, Michael Niedermayer wrote:
> Fixes: Timeout (40sec -> 13sec)
> Fixes:
> 15417/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLIC_fuzzer-5679812615602176
>
> Found-by: continuous fuzzing process
>
On 17-07-2019 02:23 PM, Carl Eugen Hoyos wrote:
Am 08.07.2019 um 14:05 schrieb Gyan :
On 25-04-2019 01:48 PM, Gyan wrote:
On 25-04-2019 01:23 PM, Ali KIZIL wrote:
There are also Dolby Codecs (ac3 & eac3). Will it also throw error for
these codecs ?
AC3 is supported before
On Wed, Jul 17, 2019 at 05:35:00PM +0800, Shiyou Yin wrote:
> Replace STnxm_UB and LDnxm_SH with new macros ST_{H/W/D}{1/2/4/8}.
> The old macros are difficult to use because they don't follow the same
> parameter passing rules.
> Changing details as following:
> 1. remove LD4x4_SH.
> 2. replace
Juan De León (12019-07-17):
> +FILE *stats_file;
I do not judge whether this filter would be useful and should be
included, but if so, then I would appreciate that the output be done
using AVIO, so that it can go to any supported protocol.
Regards,
--
Nicolas George
signature.asc
On 7/19/19, Aman Gupta wrote:
> From: Aman Gupta
>
> When using `ffprobe -show_format -show_streams -show_packets`,
> it makes more sense to omit static data about the file format
> and streams before the long list of packets instead of at the
> end.
>
> Signed-off-by: Aman Gupta
> ---
>
Aman Gupta (12019-07-18):
> From: Aman Gupta
>
> When using `ffprobe -show_format -show_streams -show_packets`,
> it makes more sense to omit static data about the file format
> and streams before the long list of packets instead of at the
> end.
>
> Signed-off-by: Aman Gupta
> ---
>
On Sun, Jul 14, 2019 at 08:17:03PM +0200, Matthieu Bouron wrote:
> On Thu, Jul 04, 2019 at 03:43:48PM +0200, Matthieu Bouron wrote:
> > ---
> > libavcodec/mediacodec_wrapper.c | 10 --
> > 1 file changed, 10 deletions(-)
> >
> > diff --git a/libavcodec/mediacodec_wrapper.c
> >
On Fri, Jul 19, 2019 at 11:08:00 +0800, leozhang wrote:
> change history:
> 1. Use normal descriptor string instead of base64 encoded
> 2. Add example to muxers.texi
> 3. Change descriptor char * and allocate it dynamically
>
> Please review, thanks
Please take care, the above text has become
77 matches
Mail list logo
