When the flag AV_CODEC_FLAG_OUTPUT_CORRUPT or AV_CODEC_FLAG2_SHOW_ALL
is set, ignore any out of order POC's as they may still be valid
frames.
---
Apologies for the non-inlined patch but for some reason patchwork
doesn't apply it correctly.
This is the same patch as
https://ffmpeg.org/pipermail/ff
you can provide.
On Tue, Sep 17, 2024 at 8:15 AM Anton Khirnov wrote:
>
> Quoting Kevin Wang (2024-09-16 06:26:34)
> > When the flag AV_CODEC_FLAG_OUTPUT_CORRUPT or AV_CODEC_FLAG2_SHOW_ALL
> > is set, ignore any out of order POC's as they may still be valid
> > frames.
When the flag AV_CODEC_FLAG_OUTPUT_CORRUPT or AV_CODEC_FLAG2_SHOW_ALL
is set, ignore any out of order POC's as they may still be valid
frames.
---
Reformat with more lines so the patch is better.
libavcodec/h264_slice.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libav
When the flag AV_CODEC_FLAG_OUTPUT_CORRUPT or AV_CODEC_FLAG2_SHOW_ALL
is set, ignore any out of order POC's as they may still be valid
frames.
---
Fixes the patch formatting.
libavcodec/h264_slice.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_slice.c b/li
It seems that my patch didn't get picked up by patchwork :( Did I miss
a formatting step?
On Fri, Sep 13, 2024 at 1:40 AM wrote:
>
> From: Kevin Wang
>
> When the flag AV_CODEC_FLAG_OUTPUT_CORRUPT or AV_CODEC_FLAG2_SHOW_ALL
> is set, ignore any out of order POC's a
s.
We've recently seen a similar issue with vscode bumping glibc
dependencies https://github.com/microsoft/vscode/issues/203375 though
switching glibc versions is a lot more awkward than a compiler
requirement.
Kevin
___
ffmpeg-devel mailing list
ff
Is there an API to get the bitrate from libavformat muxers that support it?
Many streaming protocols now offer some sort of bandwidth estimation,
wondering if there is a common way to get the outbound link capacity
through libavformat so it can be passed to the encoder easily.
Kevin
Hi, ping on this patch? It's quite simple, happy to answer any questions.
On Tue, Mar 22, 2022 at 2:25 PM wrote:
> From: Kevin Wang
>
> 7-bit PictureIDs are not supported by WebRTC:
> https://groups.google.com/g/discuss-webrtc/c/333-L02vuWA
>
> In practice, 15-bit
From: Kevin Wang
7-bit PictureIDs are not supported by WebRTC:
https://groups.google.com/g/discuss-webrtc/c/333-L02vuWA
In practice, 15-bit PictureIDs offer better compatibility.
Signed-off-by: Kevin Wang
---
libavformat/rtpenc_vp8.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
set, but manually?
I'm looking for an example of how to manually configure the AVFormatContext to
consume RTP packets without an SDP and setting up a UDP port listener.
Thanks,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
Any feedback on this?
On Jun 24, 2021, 8:58 AM -0400, Kevin LaFlamme , wrote:
> In streaming mode when using a segment list, the current segment should
> be listed so that clients can immediately request it even before
> complete. Without this, even though the segment is being written i
Thanks! Yes I saw your comment on v2 and agree that patch can be closed/ignored.
On Jul 14, 2021, 10:47 AM -0400, Jeyapal, Karthick , wrote:
>
>
> On 7/14/21, 7:46 PM, "Kevin LaFlamme" wrote:
>
> > Any feedback on this?
> Thanks for the reminder. I have pushed th
Ah I didn’t realize the SegmentTemplate was actually required in the spec for
streaming mode. This should be closed then, thanks.
On Jul 14, 2021, 10:45 AM -0400, Jeyapal, Karthick , wrote:
>
>
> On 6/24/21, 6:28 PM, "Kevin LaFlamme" wrote:
>
> > In streaming mode wh
Any feedback on this?
On Jun 24, 2021, 8:58 AM -0400, Kevin LaFlamme , wrote:
> When streaming mode is enabled, the DASH manifest is written on the
> first packet for the segment so that the segment can be advertised
> immediately to clients. It was also still writing the manifest at the
In streaming mode when using a segment list, the current segment should
be listed so that clients can immediately request it even before
complete. Without this, even though the segment is being written in a
way that it can be requested while still writing, clients won't know
it's available.
---
li
When streaming mode is enabled, the DASH manifest is written on the
first packet for the segment so that the segment can be advertised
immediately to clients. It was also still writing the manifest at the
end of the segment leading to two duplicate writes.
---
libavformat/dashenc.c | 7 +--
1
Does my last explanation make sense or if not could you point me to
where this reasoning is incorrect?
Kevin LaFlamme
Director of Engineering (Front End)
774.265.0382 (m)
aiera.com
On Jun 8, 2021, 8:52 PM -0400, Kevin LaFlamme , wrote:
> I just realized there’s probably a more straightforw
the spec and the
behaviors I've witnessed so far.
Kevin LaFlamme
Director of Engineering (Front End)
774.265.0382 (m)
aiera.com
On Jun 8, 2021, 4:03 PM -0400, Kevin LaFlamme , wrote:
> To serve it in a truly streaming way does require some special purpose server
> or configuration, but th
manifest), the client wouldn’t be respecting the DASH
spec.
Kevin LaFlamme
Director of Engineering (Front End)
774.265.0382 (m)
aiera.com
On Jun 8, 2021, 3:34 PM -0400, Timo Rothenpieler , wrote:
> On 08.06.2021 21:24, Kevin LaFlamme wrote:
> > For streaming mode with fragmented MP4 the int
ent with the “-lhls” handling below,
but happy to make changes if there is something else I’m missing.
Kevin LaFlamme
Director of Engineering (Front End)
774.265.0382 (m)
aiera.com
On Jun 8, 2021, 3:10 PM -0400, Timo Rothenpieler , wrote:
> On 08.06.2021 21:03, Kevin LaFlamme wrote:
> > Wh
When streaming mode is enabled with fMP4/CMAF for DASH output, the
segment files are available to read by players as soon as the first byte
is written instead of only after the file is fully written. The DASH
manifest currently only gets written when the final write to the segment
file occurs. This
This is quite similar to my patch suggestion from last year:
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261088.html
mine was missing some docs updates, and I followed the existing naming
scheme of prefixing the argument as 'mov_' rather than movie, but
otherwise is quite simi
On Mon, Apr 12, 2021 at 12:22 PM wrote:
>
> From: Kevin Wheatley
>
> This fix moves the potential definition of _GNU_SOURCE prior to
> any includes of system header files as required by the documentation
> https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Ma
From: Kevin Wheatley
This fix moves the potential definition of _GNU_SOURCE prior to
any includes of system header files as required by the documentation
https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
This corrects the CPU_COUNT macro availability, resulting in
What is limited range RGB ? what would the ranges of R,G,B be and where
> > is that specified ?
EBU only describes full range for 'file' based images
https://tech.ebu.ch/docs/r/r103.pdf
but ITU
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2100-2-20180
Signed-off-by: Kevin Wheatley
---
libavformat/movenc.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7d79eca..508fa73 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2879,7 +2879,7
combines the video stream time
bases to compute an accurate answer if possible.
In cases when the first stream result falls outside
MOV_MAX_AUTO_TIMESCALE or if a non-integer video stream is
encounted, then the first stream's time_base will be used as the
base.
Signed-off-by: Kevin Whe
up, the stts table is smaller and no rounding issues
occur.
Kevin
Kevin Wheatley (3):
avformat/movenc: Add command line option to set base mov file
timescale
avformat/movenc: Use base container timescale, instead of hard coded
default
avformat/movenc: Add an automatic timescale comp
Signed-off-by: Kevin Wheatley
---
libavformat/movenc.c | 1 +
libavformat/movenc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 253cff8..7d79eca 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -91,6 +91,7 @@ static const
nting it using OCIO (as suggested
https://github.com/AcademySoftwareFoundation/tac/tree/master/gsoc), or
extending the current 3D LUT code to read Cinespace or other 3D LUT
formats that support a pre-shaper and handle the float->integer
conversion that way.
Kevin
__
smpte_concat_600.mov
ffprobe smpte_concat_600.mov
The durations all line up, the stts table is smaller and no rounding
issues occur.
Kevin
Kevin Wheatley (3):
avformat/movenc: Add command line option to set base mov file
timescale
avformat/movenc: Use base container timescale, inste
rates, I guess a computation would be needed for
other things.
Finally what about the default behaviour, would it be the old use a
fixed setting or would we change the default to be automatic with the
option of explicitly passing in 1000 to mimic the previous behaviour
if required (plus a
smpte_concat_600.mov
ffprobe smpte_concat_600.mov
The durations all line up, the stts table is smaller and no rounding
issues occur.
Kevin Wheatley (2):
avformat/movenc: Add command line option to set base mov file
timescale
avformat/movenc: Use base container timescale, instead of hard c
ut where those
numbers came from as they didn't come out of the EBU document, guess
I'll have to ask next time I bump into somebody from the ITU or EBU,
the EBU numbers do come with allowable tolerances, but the blue
co-ordinate appears to fall outside
, { 0.630, 0.340, 0.295, 0.605,
0.155, 0.077 } },
Kevin
On Fri, Aug 9, 2019 at 1:48 AM James Almer wrote:
>
> 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 na
or encoding the output image, although it appears it is the only
option listed in the structure.
What is that gamma parameter in the colour space structure supposed to
represent?
Thanks
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
htt
change its behaviour. The other messy option would be to
have a compatibility mode flag.
I don't think any of this is perfect!
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I came across a similar discussion here:
https://github.com/OpenImageIO/oiio/pull/1412
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
OK, that makes sense I had wondered if it was a typo with d and x
being close to each other on the keyboard. and might be better written
as one line. Obviously not!
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman
On Wed, Nov 14, 2018 at 4:40 PM James Almer wrote:
> +colorconstancy filter
> +AVS2 video decoder via libdavs2
[snip]
> +AVS2 video encoder via libxavs2
This line is in twice.
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@f
to use it, the vmaf code is more likely to work. I'm happy to not
write a test if that is preferred!
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
t can then feed into the vmaf invocation of
ffmpeg. Is there a set of inputs I can just reuse from what fate would
normally run so that the test need only run ffmpeg to compute the
output of vmaf, (or is the preference for every test to generate its
own input?)
Thanks
Following on from my report in the user list here is a better than a
quick hack suggestion to avoid trying to join on an invalid thread id.
This may not be the best solution, but it does avoid the SEGV on linux
when calling pthread_join()
Kevin
From a94d0cb7ff4202487ea980a029fa613c58d6d7c3 Mon
values.
My usage of the feature is to write the atom when I need to by
explicitly enabling it on the command line and I also explicitly set
the metadata either from the input file, or by overriding on the
command line.
Kevin
On Mon, Nov 20, 2017 at 4:52 PM, Derek Buitenhuis
wrote:
> On 11/20/2
Hi Ronald,
On Sat, Sep 23, 2017 at 11:54 AM, Ronald S. Bultje wrote:
>
> Yes, -E works on Mac.
Thanks! Are there any remaining blockers for a potential merge?
Best regards,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmp
Hey Ronald,
Was this able to solve the issue for you?
On Mon, Jul 24, 2017 at 6:27 AM, Kevin Mark wrote:
> Hi Ronald,
>
> On Wed, Jul 19, 2017 at 3:44 AM, Ronald S. Bultje wrote:
>> But my grep (Mac) has no -P option... I'd encourage you to keep things
>> simple
On Tue, Jun 6, 2017 at 1:17 PM, Kevin Mark wrote:
> It also works with BSD grep 2.5.1-FreeBSD included in macOS if you use
> the -E option instead of -P.
Thanks,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello all,
Just wondering if anyone had any thoughts on the grepability issue,
which I believe is the only potential issue/breaking change with this
patch.
Thanks,
Kevin
On Sun, Jun 11, 2017 at 9:59 PM, Kevin Mark wrote:
> Hi Michael,
>
> Hoping to get your thoughts on the grepabil
Ping :)
On Mon, Jun 12, 2017 at 1:08 AM, Kevin Mark wrote:
> I've been using this patch for the past week now and I believe it's
> good to go. Does someone want to take a second look before merging?
>
> On Mon, Jun 5, 2017 at 6:55 AM, Kevin Mark wrote:
>> The scale2
ut it was suggested that I ask by another project member
with push access so I assumed things might be different here. It
doesn't appear that is the case so it may be best to withdraw my
request. I'm open to any further suggestions.
Thanks,
Kevin
_
Ronald Bultje via IRC recommended I ask on the mailing list for push access
to the FFmpeg repository so that I may push my own patches once approved.
If someone with the access to do so could please consider this request it
would be greatly appreciated.
Thank you,
Kevin
s
not need to handle 0 input. w/h will always be > 0 or < 0.
The second explicit (int) cast ensures that ow/oh appear as integers
as a user might expect when dealing with pixel dimensions.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 13 +
1 file changed, 5 insertions(+
On Tue, Jun 13, 2017 at 10:04 PM, Michael Niedermayer
wrote:
> ok, makes sense
> i agree the 2nd cast seems a good idea
Great, thanks Michael. I'll submit an updated patch with the additional cast.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
not truncate to 415 so this is an example of a
place where the lack of truncation for ow/oh does change the outcome.
I hope this clears it up. Perhaps that code should just be entirely
refactored to be a little more clear?
Thanks,
Kevin
___
ffmpeg-devel m
Still interested in thoughts on this patch/discussion.
Thanks,
Kevin
On Wed, Jun 7, 2017 at 3:54 AM, Kevin Mark wrote:
> I also have to wonder if it would be advantageous to add the cast on
> the right side as well. That way the var_values variables will have
> the proper truncated
s
not need to handle 0 input. w/h will always be > 0 or < 0.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index 03745ddcb8..a6c32e3978 100644
--- a/libavfilter/s
umentation for the zscale filter has also been updated since the
behavior is identical.
Signed-off-by: Kevin Mark
---
doc/filters.texi | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 65eef89d
I screwed up my git-send-email. Please ignore this patch as I already
submitted what should be an identical one on June 7th. My apologies.
On Mon, Jun 12, 2017 at 1:51 AM, Kevin Mark wrote:
> The input width and height is known at parse time so there's no
> reason ow/oh should not be
I've been using this patch for the past week now and I believe it's
good to go. Does someone want to take a second look before merging?
On Mon, Jun 5, 2017 at 6:55 AM, Kevin Mark wrote:
> The scale2ref filter will now maintain the DAR of the main input and
> not the DAR of the
scale and scale2ref)
and I can't find a case of my own where the regex I proposed would be
troublesome.
Thanks,
Kevin
On Tue, Jun 6, 2017 at 4:17 PM Kevin Mark wrote:
> On Tue, Jun 6, 2017 at 11:49 AM, Michael Niedermayer
> wrote:
> > yes but its much harder to grep for as its not
I also have to wonder if it would be advantageous to add the cast on
the right side as well. That way the var_values variables will have
the proper truncated values on future evaluations. Open to comments on
that.
On Wed, Jun 7, 2017 at 3:45 AM, Kevin Mark wrote:
> -eval_w = var_val
s
not need to handle 0 input. w/h will always be > 0 or < 0.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index 03745ddcb8..a6c32e3978 100644
--- a/libavfilter/s
Unfortunately I have to withdraw this patch. I'll be submitting an
updated one shortly. The below lines allow through values that are 0
when casted/truncated to an integer but are not zero as doubles (like
-0.1).
On Wed, Jun 7, 2017 at 2:11 AM, Kevin Mark wrote:
> -eval_w = va
s
not need to handle 0 input. w/h will always be > 0 or < 0.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index 03745ddcb8..cc2bea5caf 100644
--- a/libavfilter/s
s being set to 0 as previously detailed.
-
I noticed the z-scale documentation is very similar. I might need to
look at that too.
Thanks,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Lpa/1
Is there a special property that makes single lines much easier to
grep? Something specific to bash? I wouldn't think bash would have any
problems looping over this by line.
Thanks,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
According to libavfilter/scale.c, if the width and height are both
less than or equal to 0 then the input size is used for both
dimensions. It does not need to be -1. -1:-1 is the same as 0:0 which
is the same as -10:-42, etc.
if (w < 0 && h < 0)
eval_w = eval_h = 0;
Signed
We have floor, ceil, and trunc. Let's add round.
Signed-off-by: Kevin Mark
---
doc/utils.texi | 3 +++
libavutil/eval.c | 5 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/doc/utils.texi b/doc/utils.texi
index 1734439459..d65bdf0b0e 100644
--- a/doc/utils.texi
+++
* 320) / (160 * 240)) * (1 / 1) = 1 / 1
DAR: (160 / 120) * (1 / 1) = 4 / 3
(main out same DAR as main in)
The scale2ref FATE test has also been updated.
Signed-off-by: Kevin Mark
---
libavfilter/vf_scale.c | 6 +++---
tests/ref/fate/filter-scale2ref_keep_aspect | 2 +-
2
rgb24 sar:1/1 flags:0xc
New format for scale2ref:
in w:320 h:240 fmt:rgb24 sar:1/1
ref w:640 h:360 fmt:rgb24 sar:1/1
out w:160 h:120 fmt:rgb24 sar:4/3 flags:0x2
The increase in clarity is self-evident.
Signed-off-by: Kevin Mark
---
libavfilter/vf_scale.c | 15 ---
1 fil
On Sun, Jun 4, 2017 at 4:19 AM, Gyan wrote:
> Now that this feature has been applied, it may be helpful to check if one
> of the W/H arguments is of the form '-n' and log a warning that this will
> force the ref's display aspect ratio. The warning should also convey the
> expression to use: 'oh*m
On Thu, Jun 1, 2017 at 5:37 PM, Michael Niedermayer
wrote:
> applied
>
> can you add a fate test that uses the new identifers ?
>
> Thanks
Certainly. Submitted a patch for a scale2ref-specific test.
Thanks,
Kevin
___
ffmpeg-devel mail
nt.
This is currently the only test for scale2ref.
Signed-off-by: Kevin Mark
---
tests/fate/filter-video.mak | 4
tests/filtergraphs/scale2ref_keep_aspect| 5 +
tests/ref/fate/filter-scale2ref_keep_aspect | 14 ++
3 files changed, 23 insertions(+
scale2ref check that
makes certain two inputs are actually available before attempting to
access the second one.
Thanks to James Almer for reporting this bug. This should fix the 820
Valgrind tests I single-handedly managed to break.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 2 +-
1
On Fri, Jun 2, 2017 at 9:37 PM, Kevin Mark wrote:
> On Fri, Jun 2, 2017 at 9:16 PM, James Almer wrote:
>> This broke 820 tests with Valgrind.
Patch has been submitted. Thanks again for the report!
___
ffmpeg-devel mailing list
ffmpeg-devel@f
On Fri, Jun 2, 2017 at 9:16 PM, James Almer wrote:
> This broke 820 tests with Valgrind. All of them seem to point to
>
> ==1253== Invalid read of size 8
> ==1253==at 0x697ECA: ff_scale_eval_dimensions (scale.c:118)
scale.c:118:
const char scale2ref = outlink->src->inputs[1] == inlink;
I be
The applicable documentation has also been updated.
Signed-off-by: Kevin Mark
---
doc/filters.texi| 26 ++-
libavfilter/scale.c | 72 ++---
2 files changed, 93 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi
On Tue, May 30, 2017 at 10:40 AM, Kevin Mark wrote:
> +const AVFilterLink *main;
Unfortunately that line results in a warning on GCC (but not LLVM):
libavfilter/scale.c: In function ‘ff_scale_eval_dimensions’:
libavfilter/scale.c:121:25: warning: ‘main’ is usually a function [-Wm
e want it to do. This workflow is all new to me so I'm
open to being told the proper way of doing things.
Thanks,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
The applicable documentation has also been updated.
Signed-off-by: Kevin Mark
---
doc/filters.texi| 26 ++-
libavfilter/scale.c | 72 ++---
2 files changed, 93 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi
nging the
scale2ref=iw/6:iw/(6*main_a) [main][ref]
example to
scale2ref=iw/6:iw/(6*mdar) [main][ref]
correct?
Thanks,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Or should
I just reply to this thread with attachments from git format-patch?
Although now that I'm looking at it, git send-email has an
--in-reply-to option that could potentially do the trick of submitting
the revised patch. This mailing list patch submission workflow is new
to
On Sat, May 27, 2017 at 1:36 PM, Gyan wrote:
> It's weird, given those uses cases - overlays - to override the operand's
> native aspect ratio. I'd say, a design oversight, at least.
I agree. I'm not aware of any common workflow that you would have
subtitles (transparent PNGs or something) that w
On Sat, May 27, 2017 at 8:30 PM, Michael Niedermayer
wrote:
> should be merged with the patch that adds these constants
>
> thx
I'll include this with the other updated patch.
Thanks,
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@f
ssed.
On Sat, May 27, 2017 at 10:49 AM, Gyan wrote:
> On Sat, May 27, 2017 at 7:40 PM, Kevin Mark wrote:
>
> > Variables pertaining to the non-reference video are now available when
> > using the scale2ref filter. This allows scaling a video with another
> > as a referenc
Signed-off-by: Kevin Mark
---
doc/filters.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index ff41402f7e..948e43deca 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12459,7 +12459,7 @@ is 1.
@itemize
@item
-Scale a
Update the filters documentation to include the new scale2ref
constants.
Signed-off-by: Kevin Mark
---
doc/filters.texi | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index a0ab2fb0c7..ff41402f7e 100644
--- a
d is strictly a
feature patch. There are no API changes. Behavior does not change for
any previously valid inputs.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 72 ++---
1 file changed, 68 insertions(+), 4 deletions(-)
diff --git a/libavf
.
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
The following is a sample EXR that needs the patch to correctly
process in FFmpeg.
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
included line
rather than the line after the data window then the code sets the
remaining lines to 0 and thus the whole image is over written.
Fix by adjusting ptr to the correct line after decode_block returns
Signed-off-by: Kevin Wheatley
0001-libavcodec-exr-Fix-blank-output-when-data-window
On Thu, Nov 24, 2016 at 10:48:38PM -0800, Dave Yeo wrote:
>
> On 11/24/16 07:47 PM, Kevin Lo wrote:
> > Since the Linux implementation of sockaddr doesn't have sa_len as a member,
> > but the FreeBSD version does, introduce a get_sa_len() function that
> > determines
Since the Linux implementation of sockaddr doesn't have sa_len as a member,
but the FreeBSD version does, introduce a get_sa_len() function that
determines the size based on the address family.
Signed-off-by: Kevin Lo
---
v3: Check for the right feature when using a sockaddr_in6.
Some sy
Since the Linux implementation of sockaddr doesn't have sa_len as a member,
but the FreeBSD version does, introduce a get_sa_len() function that
determines the size based on the address family.
Signed-off-by: Kevin Lo
---
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index c6
Since the Linux implementation of sockaddr doesn't have sa_len as a member,
but the FreeBSD version does, introduce a get_sa_len() function that
determines the size based on the address family.
Signed-off-by: Kevin Lo
---
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index c6
On Fri, Nov 25, 2016 at 07:13:50AM +0800, Kevin Lo wrote:
>
> On Thu, Nov 24, 2016 at 04:12:41PM +0100, Nicolas George wrote:
> > Le quartidi 4 frimaire, an CCXXV, Kevin Lo a écrit :
> > > FreeBSD's socket calls require the sockaddr struct length to agree
> > >
On Thu, Nov 24, 2016 at 04:12:41PM +0100, Nicolas George wrote:
> Le quartidi 4 frimaire, an CCXXV, Kevin Lo a écrit :
> > FreeBSD's socket calls require the sockaddr struct length to agree
> > with the address family, Linux does not. This patch fixes a failing
> > get
FreeBSD's socket calls require the sockaddr struct length to agree
with the address family, Linux does not. This patch fixes a failing
getnameinfo() call on FreeBSD.
Signed-off-by: Kevin Lo
---
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index c6292c5..15fe25d 100644
--- a/libavf
I would really strongly suggest including DCI in the name at least -
though nobody else would choose to use it for anything other than the
reference calibration - most titles use a creative white different to
that of the encoding reference (one that is less green).
Kevin
or the reference projector, so
WP_DCI_P3_REFERENCE might be better, but that is a little long.
I'd go for something like WP_DCI_P3 it is not really ambiguous.
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
1 - 100 of 185 matches
Mail list logo
