This provides an alternative to retry counters.
Useful if there is no reasonable maximum number of iterations and
no ordering that naturally avoids loops.
Signed-off-by: Michael Niedermayer
---
doc/APIchanges| 3 ++
libavutil/Makefile| 1 +
libavutil/loop_detector.h | 71
Marton Balint (12019-08-07):
> The function returns an int so it can't signal writing longer strings that
> that.
Yet, replacing an arbitrary limit by another arbitrary limit, however
high, seems very wrong.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
Fixes: Timeout (Infinite -> 26ms)
Fixes:
15706/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5114674904825856
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tiff.c | 6 ++
Alexander Strasser (12019-08-08):
> Maybe others have better suggestions.
setpts or setts, similar to lavfi.
Although in lavfi I have a vague intention of merging all the set*
filters into a single one.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
Hi Nicolas,
‐‐‐ Original Message ‐‐‐
On Thursday, 8 de August de 2019 10:46, Nicolas George wrote:
> Alexander Strasser (12019-08-08):
>
> > Maybe others have better suggestions.
>
> setpts or setts, similar to lavfi.
Then I proposse these two alternatives:
1) "editpts_bsf"
2)
On 08-08-2019 02:16 PM, Nicolas George wrote:
Alexander Strasser (12019-08-08):
Maybe others have better suggestions.
setpts or setts, similar to lavfi.
This BSF only allows to apply a fixed offset whereas the setpts filter
allows arbitrary expressions. Unless someone is planning to
On Thu, 8 Aug 2019, Nicolas George wrote:
Marton Balint (12019-08-07):
The function returns an int so it can't signal writing longer strings that
that.
Yet, replacing an arbitrary limit by another arbitrary limit, however
high, seems very wrong.
Current 4k limit is definitely causing
On Thu, Aug 8, 2019 at 10:43 AM Nicolas George wrote:
> Marton Balint (12019-08-07):
> > The function returns an int so it can't signal writing longer strings
> that
> > that.
>
> Yet, replacing an arbitrary limit by another arbitrary limit, however
> high, seems very wrong.
>
>
But function
On Thu, Aug 08, 2019 at 09:49:35AM +0800, 顾希伟 wrote:
> > 发件人: "Michael Niedermayer"
> > 发送时间: 2019-08-08 07:05:13 (星期四)
> > 收件人: "FFmpeg development discussions and patches"
> > 抄送:
> > 主题: Re: [FFmpeg-devel] [PATCH v4] avutil/mips: refine msa macros CLIP_*.
> >
> > On Wed, Aug 07, 2019 at
Hello Anthony,
I'm not really the best to answer your questions, as I'm also a fairly new
contributor (my patches seem to be languishing due to a lack of feedback
and a lack of time on my part pushing the issue). I've been working on
getting support into mpegts for ATSC compliant descriptors of
From: Andriy Gelman
This patch avoids a read past the end of the input buffer in memcpy since the
size
of the received zmq message is recv_buf_size - 1.
---
tools/zmqsend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/zmqsend.c b/tools/zmqsend.c
index
On Thu, Aug 8, 2019 at 4:44 PM Andriy Gelman
wrote:
> From: Andriy Gelman
>
> This patch avoids a read past the end of the input buffer in memcpy since
> the size
> of the received zmq message is recv_buf_size - 1.
> ---
> tools/zmqsend.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> You argue that it does not NEED to be in lavu, but not that it SHOULD
> note.
>
> > Plus, its not really common av code, and don't let its name mislead
> > you, its more of a hack.
>
> I will disregard the insulting subtext of this sentence.
>
There is nothing insulting about this sentence.
From: Nick Renieris
Samples:
- Embedded JPEG images in the DNG images here:
https://www.photographyblog.com/previews/pentax_k1_photos
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mjpegdec.c
From: Nick Renieris
Inited to (2^BitsPerSample)-1 as per the DNG Specification
This fixes decoding for "X7 CinemaDNG" samples here:
- https://www.dji.com/gr/zenmuse-x7/info#downloads
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Nick Renieris
This enables decoding of DNG images generated by the 'DJI Zenmuse X7'
digital camera
Samples: https://www.dji.com/gr/zenmuse-x7/info#downloads
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 61 +++
1 file changed, 51
The MPEG-TS muxer had a serious bug related to the use of multiple programs:
in that case, the PCR pid selection was incomplete for all services except one.
This patch solves this problem and selects a stream to become PCR for each
service, preferably the video stream.
This patch also moves pcr
Signed-off-by: Cameron Cawley
---
doc/general.texi| 1 +
libavcodec/Makefile | 1 +
libavcodec/adpcm.c | 14 ++
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +++
libavcodec/utils.c | 1 +
7 files changed, 26
---
libavformat/rpl.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavformat/rpl.c b/libavformat/rpl.c
index 6afd373810..d31c7f09ad 100644
--- a/libavformat/rpl.c
+++ b/libavformat/rpl.c
@@ -121,6 +121,7 @@ static int rpl_read_header(AVFormatContext *s)
PCR generation was based on counting packets for both CBR and VBR streams.
Couting packets might have worked for CBR streams (when muxrate was specified)
but it only took into account the packets of a service (or the packets of the
PCR stream lately), so even that was problematic for multi program
Maybe we should use service ID instead of increasing numbers?
Signed-off-by: Marton Balint
---
libavformat/mpegtsenc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 68af45d8b5..f4c1bb4717 100644
---
Signed-off-by: Marton Balint
---
libavformat/mpegtsenc.c | 50 -
1 file changed, 24 insertions(+), 26 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 13fdb6ff97..68af45d8b5 100644
--- a/libavformat/mpegtsenc.c
+++
Deprecated since 2014.
Signed-off-by: Marton Balint
---
doc/muxers.texi | 4
libavformat/mpegtsenc.c | 13 -
2 files changed, 17 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index f9e8b60517..846b5f41db 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
Signed-off-by: Marton Balint
---
libavformat/mpegtsenc.c | 66 +++--
1 file changed, 25 insertions(+), 41 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 661aa4066d..13fdb6ff97 100644
--- a/libavformat/mpegtsenc.c
+++
From: Nick Renieris
Some JPEGs [1] have incorrect DHT entries that map 2 codes to
the same value.
The second (last) mapping does not ever actually appear in the
code stream, therefore ignoring any mappings after the first one
fixes this.
Without this, an "mjpeg_decode_dc: bad vlc: 0:0" error
From: Nick Renieris
Sample file:
https://drive.google.com/open?id=0B4JyRT3Lth5HVndyOTVOdWktM3J4TFEydTk1MnY3RWlpSzVB
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/libavcodec/tiff.c
From: Nick Renieris
In an image [1], the height was equal to the tile length (full-height
tile) and after `height % tile_length` was applied to them with the
current code, it resulted in the operating tile_length to be 0. This
commit makes this leftover logic only applies if it's necessary.
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 37fda15162..174ca168c6 100644
--- a/libavcodec/tiff.c
+++
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 174ca168c6..9d20763186 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -1038,6 +1038,18 @@ static int
From: Nick Renieris
DNG samples here can now be decoded:
- https://www.photographyblog.com/previews/pentax_k1_photos
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 73 +++
1 file changed, 42 insertions(+), 31 deletions(-)
diff --git
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 6391107f78..94cf73549d 100644
--- a/libavcodec/mjpegdec.c
+++
Added linux support for amf encoder through vulkan.
To use h.264(AMD VCE) encoder on linux amdgru-pro version 19.20+ and
amf-amdgpu-pro package(amdgru-pro contains, but does not install automatically)
are required.
This driver can be installed using amdgpu-pro-install script in official amd
Any feedback on this patch?
On Mon, 5 Aug 2019 at 00:18, Ross Nicholson wrote:
> Example stream that does not work: rtsp://
> 184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
>
> Extending the condition allows the stream to be processed correctly.
>
> On Mon, 5 Aug 2019 at 08:17, Ross Nicholson
Some broken apps generate files that have a fake box named 'hoov'
instead of a proper 'moov' one. This is speculation but it seems like
this box contains data to be modified later (eg as file grows in size,
data gets re-written) and its name is supposed to be changed to 'moov'
once it can be used
From: Nick Renieris
Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
This commit adds support for:
- DNG tiles
- DNG tile huffman lossless JPEG decoding
- DNG 8-bpp ("packed" as dcraw calls it) decoding
- DNG color scaling [1]
- LinearizationTable tag
- BlackLevel tag
From: Nick Renieris
Main image data in DNGs is usually comprised of tiles, each of which is a
Huffman-encoded lossless JPEG.
Tested for ljpeg regressions with:
`ffmpeg -f lavfi -i testsrc=d=1 -vcodec ljpeg test.avi`
`ffmpeg test.avi out.avi`
The modified code in ljpeg_decode_rgb_scan runs
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index d5673abb19..a118c37c41 100644
--- a/libavcodec/tiff.c
+++
From: Nick Renieris
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index a118c37c41..4620508d53 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@
Thanks for the review Michael, pushing fixes and a commit that makes
some more images compatible.
Στις Πέμ, 8 Αυγ 2019 στις 1:22 π.μ., ο/η Michael Niedermayer
έγραψε:
>
> On Wed, Aug 07, 2019 at 06:27:14PM +0300, velocit...@gmail.com wrote:
> > From: Nick Renieris
> >
> > Signed-off-by: Nick
>Look at spdif in wav.
Indeed, I missed that, spdif and s337m are very similar technically, and it
means I have to rework my patch for the integration of s337m in wavdec, but I
still do not catch why another demuxer should be created : spdifdec.c is
actually quite similar to the existing
Hi Nicolas!
On 2019-08-08 11:43 +0200, Nicolas George wrote:
> Andreas Håkon (12019-08-08):
> > > setpts or setts, similar to lavfi.
>
> > Then I proposse these two alternatives:
> >
> > 1) "editpts_bsf"
> > 2) "setpts_bsf"
> >
> > The "_bsf" is not real, only to differenciate (here) from other
On Wed, Aug 07, 2019 at 09:25:07PM +0200, Thilo Borgmann wrote:
> Am 07.08.19 um 21:18 schrieb Michael Niedermayer:
> > The awnser which most people will seek is put first
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/fate.texi | 4
> > 1 file changed, 4 insertions(+)
> >
> >
If all tables are skipped it would be impossible to encode any
"non black" video.
Fixes: Timeout (78sec -> 1ms)
Fixes:
15821/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMACKER_fuzzer-5652598838788096
Found-by: continuous fuzzing process
On Fri, Aug 9, 2019 at 10:36 AM wrote:
>
> From: Limin Wang
>
> show real information instead of the unknown side data type message for HDR10
> stream
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_showinfo.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git
Fixes: signed integer overflow: 2088795537 + 2147254401 cannot be represented
in type 'int'
Fixes: signed integer overflow: -1500363496 + -1295351808 cannot be represented
in type 'int'
Fixes: signed integer overflow: -79560 * 32640 cannot be represented in type
'int'
Fixes: signed integer
Fixes: signed integer overflow: 393215 * 14594 cannot be represented in type
'int'
Fixes:
15728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3IMAGE_fuzzer-5661588893204480
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
This may break some valid tiff files, it appears the specification does not
require
the offsets to be increasing. They increase in the 2 test files i have though
except
the last offset which is 0 (an end marker) and for which a special case is
added to
avoid asking for a sample for that end
Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes:
15764/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-5102101203517440
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
From: Limin Wang
show real information instead of the unknown side data type message for HDR10
stream
Signed-off-by: Limin Wang
---
libavfilter/vf_showinfo.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index
From: Raphaël Zumer
Internally, this adds an EBU3213 alias to JEDEC_P22,
and changes the name string to match ITU-T H.273.
---
libavcodec/options_table.h | 2 +-
libavfilter/vf_colorspace.c | 2 +-
libavfilter/vf_setparams.c | 2 +-
libavfilter/vf_zscale.c | 2 +-
libavutil/pixdesc.c
On Thu, Aug 08, 2019 at 03:38:58PM +0100, Kieran Kunhya wrote:
> >
> > You argue that it does not NEED to be in lavu, but not that it SHOULD
> > note.
> >
> > > Plus, its not really common av code, and don't let its name mislead
> > > you, its more of a hack.
> >
> > I will disregard the insulting
On 8/8/2019 9:01 PM, rzu...@tebako.net wrote:
> From: Raphaël Zumer
>
> Internally, this adds an EBU3213 alias to JEDEC_P22,
> and changes the name string to match ITU-T H.273.
> ---
> libavcodec/options_table.h | 2 +-
> libavfilter/vf_colorspace.c | 2 +-
> libavfilter/vf_setparams.c | 2 +-
From: Raphaël Zumer
This matches a name change in avutil/pixdesc.
Signed-off-by: Raphaël Zumer
---
libavcodec/options_table.h | 2 +-
libavcodec/version.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index
Andreas Rheinhardt:
> 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
> ignored.
>
>
From: Raphaël Zumer
This is an alias for JEDEC P22.
The name associated with the value is also changed
from "jedec-p22" to "ebu3213" to match ITU-T H.273.
Signed-off-by: Raphaël Zumer
---
doc/APIchanges | 3 +++
libavutil/pixdesc.c | 2 +-
libavutil/pixfmt.h | 1 +
libavutil/version.h
From: Raphaël Zumer
This matches a name change in avutil/pixdesc.
Signed-off-by: Raphaël Zumer
---
libavfilter/version.h | 2 +-
libavfilter/vf_colorspace.c | 2 +-
libavfilter/vf_setparams.c | 2 +-
libavfilter/vf_zscale.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
On Fri, Aug 09, 2019 at 10:50:10AM +0800, myp...@gmail.com wrote:
> On Fri, Aug 9, 2019 at 10:36 AM wrote:
> >
> > From: Limin Wang
> >
> > show real information instead of the unknown side data type message for
> > HDR10 stream
> >
> > Signed-off-by: Limin Wang
> > ---
> >
Andreas Håkon (12019-08-08):
> > setpts or setts, similar to lavfi.
> Then I proposse these two alternatives:
>
> 1) "editpts_bsf"
> 2) "setpts_bsf"
>
> The "_bsf" is not real, only to differenciate (here) from other filters.
> Which one do you prefer?
editpts has no similarity with lavfi.
---
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
From: tomajsjiang
fix error like "offset 0x1f85: partial file", the root cause is when
read the mp4 file from http, and the moov in the end of the mp4 file,
reconfig the buffer will drop some data.
Signed-off-by: Jun Zhao
Signed-off-by: Zhongxing Jiang
---
libavformat/utils.c |8 +++-
>> +int avpriv_s337m_probe_stream(void *avc, AVIOContext *pb, AVStream **st,
>> int size);
>Sorry for not commenting earlier:
You're welcome, a few days is not that much, particularly in the middle of the
summer!
>This is to the best of my knowledge not acceptable (to have a public function
Lynne (12019-08-08):
> Its niche, we have very few places where there's a chance a loop will
> become infinite. Even then, they're likely all in lavc, and you can
> just put a non-public header there if there's more than a few. And
> right now, there's only one.
You argue that it does not NEED to
Am Mi., 7. Aug. 2019 um 19:39 Uhr schrieb Daniel Kolesa :
>
> While this technically compiles in current ffmpeg, this is only
> because ffmpeg is compiled in strict ISO C mode, which disables
> the builtin 'vector' keyword for AltiVec/VSX. Instead this gets
> replaced with a macro inside
Am Fr., 2. Aug. 2019 um 09:00 Uhr schrieb Paul B Mahol :
> patches attached.
I see nice and reasonable results, only tested with both patches applied.
(Roughly doubled decoding speed at roughly twice cpu load, very little
slowdown for -threads 1 compared to unpatched FFmpeg)
Thank you, Carl
---
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
+++
Lynne (12019-08-08):
> That's very niche and I don't think it belongs to lavu.
That's a single header with no compiled code.
> Having codec specific code is better.
Why? Why risk bug duplication and maintenance burden?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
Am Di., 6. Aug. 2019 um 17:08 Uhr schrieb Nicolas Gaullier
:
>
> ---
> libavformat/s337m.c | 64
> -
> libavformat/s337m.h | 64
> +
> 2 files changed, 117 insertions(+), 11 deletions(-)
>
>Ah, so it's time and not phase? Renaming the #defines to make that clearer
>would be nice. Other than that, this isn't a huge issue
I assume the start of the packet to be synched with the start of "a" video
frame, I think there is no use case where pcm and video are not synced, at
least when
Am Do., 8. Aug. 2019 um 14:18 Uhr schrieb Gaullier Nicolas
:
>
> >> +int avpriv_s337m_probe_stream(void *avc, AVIOContext *pb, AVStream **st,
> >> int size);
> > This is to the best of my knowledge not acceptable (to have a public
> > function for a particular
> > format), instead create a new
From: tomajsjiang
Add new API ffio_realloc_buf for AVIO buffer realloc.
Signed-off-by: Zhongxing Jiang
---
libavformat/avio_internal.h |9 +
libavformat/aviobuf.c | 31 +++
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git
Hello here,
Just a mail to ping this patch
Have a nice day,
Olivier
On Thu, Jul 25, 2019 at 11:34 PM Michael Niedermayer
wrote:
> On Wed, Jul 24, 2019 at 10:20:14AM +0200, Olivier Maignial wrote:
> > === PROBLEM ===
> >
> > I was trying to record h264 + aac streams from an RTSP server to mp4
Aug 8, 2019, 11:36 AM by geo...@nsup.org:
> Lynne (12019-08-08):
>
>> That's very niche and I don't think it belongs to lavu.
>>
>
> That's a single header with no compiled code.
>
>> Having codec specific code is better.
>>
>
> Why? Why risk bug duplication and maintenance burden?
>
Its niche,
I'm sorry I almost missed this email. Thanks for your review.
At 2019-07-23 03:42:20, "Marton Balint" wrote:
>
>
>On Sat, 13 Jul 2019, hwren wrote:
>
>>
>> At 2019-07-13 01:38:55, "Marton Balint" wrote:
>>>
>>>
>>> On Fri, 12 Jul 2019, hwrenx wrote:
>>>
Can effectivly improved decoding
---
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..f4f9e0a47d
On Thu, Aug 8, 2019, at 15:23, Daniel Kolesa wrote:
> On Thu, Aug 8, 2019, at 14:32, Carl Eugen Hoyos wrote:
> > Am Mi., 7. Aug. 2019 um 19:39 Uhr schrieb Daniel Kolesa
> > :
> > >
> > > While this technically compiles in current ffmpeg, this is only
> > > because ffmpeg is compiled in strict ISO
Michael Niedermayer (12019-08-08):
> This provides an alternative to retry counters.
> Useful if there is no reasonable maximum number of iterations and
> no ordering that naturally avoids loops.
>
> Signed-off-by: Michael Niedermayer
> ---
> doc/APIchanges| 3 ++
>
Hi,
I'm currently doing my first contribution to ffmpeg by adding EPG support
in the mpegts format.
For now, i succeeded to add support for EIT table and majority of its
descriptors and can read/export EPG
events in a .csv file.
But I don't know on how to organize it now. Do I make a new codec
>> +if (pos < size - 9 && pos >= S337M_PROBE_GUARDBAND_MIN_BYTES)
>I think this 9 should be an 11 or 12..
Indeed, thank you, my mistake.
>This isn't quite what I meant by turning it into an integer test :) this will
>likely just be rounded to zero. I meant that things could likely be
tor 2019-08-08 klockan 10:28 + skrev Gaullier Nicolas:
> > > +if (pos < size - 9 && pos >=
> > > S337M_PROBE_GUARDBAND_MIN_BYTES)
> > I think this 9 should be an 11 or 12..
> Indeed, thank you, my mistake.
>
> > This isn't quite what I meant by turning it into an integer test :)
> >
On Thu, Aug 8, 2019, at 14:32, Carl Eugen Hoyos wrote:
> Am Mi., 7. Aug. 2019 um 19:39 Uhr schrieb Daniel Kolesa
> :
> >
> > While this technically compiles in current ffmpeg, this is only
> > because ffmpeg is compiled in strict ISO C mode, which disables
> > the builtin 'vector' keyword for
>.. this won't compile if S377m is disabled. Just go with the old #if
>solution, sorry for causing confusion
My mistake but I think it is a good idea to get rid of some bulky #if... Do you
think a mixed usage of if and #if would be acceptable ? I think the following
would be the best :
if
Aug 8, 2019, 9:36 AM by mich...@niedermayer.cc:
> This provides an alternative to retry counters.
> Useful if there is no reasonable maximum number of iterations and
> no ordering that naturally avoids loops.
>
That's very niche and I don't think it belongs to lavu.
Having codec specific code is
82 matches
Mail list logo
