This way, in case of bit rate not being set, max_rate will be used
instead. This enables, for example, remuxing of MPEG-TS to ISMV+ISML
without losing general bit rate information.
---
libavformat/movenc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
Streaming servers appear to ignore all other language metadata.
---
libavformat/movenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 16b044a..11c8275 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3351,6 +3351,9 @@
As far as can be seen, this value is supposed to be the DTS of a
fragment in smooth streaming. Thus, don't take b-picture delay and
such into mention when calculating the start timestamp. The duration
calculation requires PTS values, so it is not touched.
---
libavformat/movenc.c | 3 +--
1 file
by "absolute"
timestamp.
Jan Ekström (3):
movenc: use similar logic to DASH when writing bit rate to ISML
movenc: Add support for writing language codes into ISML manifests
movenc: simplify the 'tfxd' fragment start timestamps
libavformat/movenc.c | 15 +++
1 file changed, 11
Functionality used before didn't widen the values from limited to
full range. Additionally, now the decoder uses BT.709 where it
should be used according to the video resolution.
Default for not yet set colorimetry is BT.709 due to most observed
HDMV content being HD.
BT.709 coefficients were
Functionality used before didn't widen the values from limited to
full range. Additionally, now the decoder uses BT.709 where it
should be used according to the video resolution.
Default for not yet set colorimetry is BT.709 due to most observed
HDMV content being HD.
BT.709 coefficients were
This enables having multiple tracks of the same type which would
be treated as different things by the media server (as opposed to
different bit rate versions of the same track). According to the
smooth streaming specification, just setting the systemLanguage
tag is not enough to note that a track
hin FFmpeg.
Signed-off-by: Jan Ekström <jee...@gmail.com>
---
libavformat/mxfdec.c | 60 ++--
1 file changed, 54 insertions(+), 6 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 1939761..54fc6fb 100644
--- a/li
* Updates the width/height sanity check to check all values against
INT_MAX.
* Correctly utilizes the stored width or height by default, and if
sampled or display values are available they are utilized.
Signed-off-by: Jan Ekström <jee...@gmail.com>
---
libavformat/mxfdec.
This way, in case of bit rate not being set, max_bitrate will be
used instead. This enables, for example, re-using max_bitrate
information from the input or doing transcoding with a rate
control mode that is not bit rate based.
Signed-off-by: Jan Ekström <jee...@gmail.com>
---
libav
of negative
CTS offsets, leading to the initial sample's CTS and DTS to match. If that
patch works, smooth streaming output should rather be locked to that mode.
Jan Ekström (2):
movenc: use similar logic to DASH when writing bit rate to ISML
movenc: Add support for writing language codes
Streaming servers appear to ignore all other language metadata.
Signed-off-by: Jan Ekström <jee...@gmail.com>
---
libavformat/movenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d5ed1dd..28edb18 100644
--- a/libavformat/mo
This way, in case of bit rate not being set, max_bitrate will be
used instead. This enables, for example, re-using max_bitrate
information from the input or doing transcoding with a rate
control mode that is not bit rate based.
Signed-off-by: Jan Ekström <jee...@gmail.com>
---
libav
n a group of similar features we
have a duplicate of in our code base.
Jan Ekström (2):
libx264: remove the "x264opts" AVOption
doc/encoders: remove mentions of the x264opts AVOption
doc/encoders.texi| 25 ++---
libavcodec/libx264.c | 29 ---
---
doc/encoders.texi | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 594c612..ee28b9b 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1762,9 +1762,9 @@ for detail retention (adaptive
x264-params does the same thing and this leaves us with a single
option that is name-matched with x265-params available in the
libx265 wrapper.
---
libavcodec/libx264.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
From: Martin Storsjö
Signed-off-by: Martin Storsjö
---
libavformat/tests/movenc.c | 19 +++
tests/ref/fate/movenc | 11 +++
2 files changed, 30 insertions(+)
diff --git a/libavformat/tests/movenc.c b/libavformat/tests/movenc.c
From: Martin Storsjö
This reduces the need for an edit list; streams that start with
e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid
in mov/mp4) by shifting the dts values of all packets forward.
This avoids the need for edit lists for such streams (while they
---
configure | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index b9a3a9bc1f..5aa642a9bb 100755
--- a/configure
+++ b/configure
@@ -6254,7 +6254,8 @@ EOF
fi
check_header soundcard.h
-enabled alsa && check_lib alsa alsa/asoundlib.h
From: Martin Storsjö
This reduces the need for an edit list; streams that start with
e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid
in mov/mp4) by shifting the dts values of all packets forward.
This avoids the need for edit lists for such streams (while they
From: Martin Storsjö
This reduces the need for an edit list; streams that start with
e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid
in mov/mp4) by shifting the dts values of all packets forward.
This avoids the need for edit lists for such streams (while they
@@ Pedro Arthur
Sebastien Zwickert
Vittorio Giovara
wm4
+Jan Ekström
(this list is incomplete)
--
2.13.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This FFmpeg-specific "fuzzer fix" was never perfect, but now it
stopped encoding of actual content with a big enough DTS shift.
This returns the function to its original state of results
before negative CTS offsets were added.
I remember dealing with this function before, but somehow had
On Sat, Nov 25, 2017 at 6:25 PM, Mark Thompson wrote:
> LGTM, please apply.
>
> I checked the other hwcontext implementations for the same problem, and found
> it only in OpenCL - it could also crash there, fixed in
>
Makes the uninit function re-entrable, which can be a common case
when an API user first tries to initialize its context, fails, and
then finally unrefs the AVHWDevice.
Fixes a crash reported by sm2345 on IRC.
---
libavutil/hwcontext_d3d11va.c | 21 -
1 file changed, 16
Enables the decoder to utilize the type AVCodecHWConfigInternal.
---
libavcodec/mediacodecdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 6d392adb3a..63209f52ac 100644
--- a/libavcodec/mediacodecdec.c
+++
Hi,
I have been testing FFmpeg with the Android NDK (R15)'s clang, and
recently (a few weeks ago) the build has broken at
libavcodec/arm/hevcdsp_idct_neon.
It should be enough to test this with --cc=arm-linux-androideabi-clang
(or any other ARM clang compiler) and the latest gas-preprocessor.pl
On Fri, Dec 1, 2017 at 10:44 PM, Mark Thompson wrote:
>
> LGTM.
>
> (Apologies for breaking that.)
>
Thanks for the LGTM. Pushed with the header include added in its
alphabetically ordered position as recommended on IRC.
And no problem, we all miss things :) .
Jan
On Thu, Dec 14, 2017 at 12:39 AM, Josh de Kock wrote:
> On Thu, 7 Dec 2017 11:08:47 +
> Matteo Naccari wrote:
>
>> - This patch contains the changes required to interface the Turing codec
>> [...]
>
> I still have an issue with this patch, while
On Fri, Dec 8, 2017 at 7:18 PM, Michael Niedermayer
wrote:
> please provide the uncut error message and compiler/assembler version
> affected in the commit message as reference otherwise its hard to
> understand what/where exactly the issue was
Hi,
I noticed this
On Sat, Dec 9, 2017 at 12:14 AM, James Almer wrote:
> Compilation error "out of range" fixed for armeabi-v7a. Compilation failed
> trying to build libvlc.aar for ARM7 android on ubuntu 16.04 host. Error
> messages is "Offset out of range". The reason of the error is assembler
On Sat, Dec 9, 2017 at 2:52 PM, Jan Ekström <jee...@gmail.com> wrote:
> On Sat, Dec 9, 2017 at 12:14 AM, James Almer <jamr...@gmail.com> wrote:
>> Compilation error "out of range" fixed for armeabi-v7a. Compilation failed
>> trying to build libvlc.aar for ARM
On Sat, Dec 9, 2017 at 12:14 AM, James Almer wrote:
> Compilation error "out of range" fixed for armeabi-v7a. Compilation failed
> trying to build libvlc.aar for ARM7 android on ubuntu 16.04 host. Error
> messages is "Offset out of range". The reason of the error is assembler
On Sun, May 6, 2018 at 5:32 PM, wm4 wrote:
>
> Hilarious, another of those EOf issues. Too bad we didn't just revert
> that crap. I wonder how many years it'll take until we got all of them.
>
> LGTM.
Thanks, pushed. This should be back-ported to release/4.0 I guess?
Jan
Yet another case of forgotten 0 =! EOF translation. The libbluray
documentation specifically mentions that a read of 0 is EOF.
Reported by Fyr on IRC.
---
libavformat/bluray.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/bluray.c b/libavformat/bluray.c
index
On Sun, May 6, 2018 at 7:41 PM, James Almer wrote:
>
> LGTM.
Thanks, pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
WHAT!?
This LGTM was for the bit mask *only*
ALL OTHER POINTS STAND
Jan
On Fri, May 4, 2018, 06:04 Steven Liu <l...@chinaffmpeg.org> wrote:
>
>
> > On 4 May 2018, at 02:00, Jan Ekström <jee...@gmail.com> wrote:
> >
> > On Thu, May 3, 2018 at 8:58 PM,
On Mon, May 14, 2018 at 10:42 PM, Carl Eugen Hoyos wrote:
> 2018-05-14 21:39 GMT+02:00, Nicolas George :
>> Carl Eugen Hoyos (2018-05-14):
>>> Attached patch allows to easily enable the dash demuxer on systems
>>> without pkg-config.
>>
>> I am rather for
On Wed, May 9, 2018 at 3:38 PM, Yu Xiaolei wrote:
> Hello,
> I noticed that commit 7e8eba2d87 deprecated avcodec_register and there was
> some disagreement on this issue. Will there be some sort of replacement for
> it?
>
> We want to build ffmpeg in a way that only the
On Sun, May 6, 2018 at 11:16 PM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Sun, May 06, 2018 at 06:55:01PM +0300, Jan Ekström wrote:
>> Thanks, pushed. This should be back-ported to release/4.0 I guess?
>
> probably yes
>
> thanks
>
Finally got the tim
On Thu, May 10, 2018 at 6:53 PM, Paul B Mahol wrote:
>
> Against.
Hi,
Thank you for your review.
I would recommend you put a bit more effort into explaining which
parts you are opposed to. Think of yourself being on the receiving end
of such comments, how you would like to
On Fri, May 11, 2018 at 1:39 AM, Alex Converse <alex.conve...@gmail.com> wrote:
> On Thu, May 3, 2018 at 10:58 AM, Jan Ekström <jee...@gmail.com> wrote:
>>
>> Hi,
>>
>> While the timestamp field is 8+24=32 bits, the DTS value is int64_ts.
>> Thus, wh
On Fri, May 11, 2018 at 1:48 AM, Alex Converse wrote:
>
> Sorry about the lateness on my part. Were there any later comments. I
> haven't seen any. (And yes I can push this myself when all the
> concerns are resolved).
It's OK, it has been a rather busy time for me as
On Fri, May 4, 2018 at 9:32 AM, Karthick J wrote:
> From: Karthick Jeyapal
>
> Right now segment file format is chosen to be either mp4 or webm based on the
> codec format.
> This patch makes that choice configurable by the user, instead of being
>
On Fri, May 11, 2018 at 4:40 AM, Alex Converse wrote:
> From: Alex Converse
>
> ---
> libavformat/flvenc.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index
On Sun, May 13, 2018 at 12:25 PM, Jan Ekström <jee...@gmail.com> wrote:
> On Fri, May 11, 2018 at 4:40 AM, Alex Converse <alex.conve...@gmail.com>
> wrote:
>> From: Alex Converse <alexc...@twitch.tv>
>>
>> ---
>> libavformat/flvenc.c | 9 -
On Sun, May 13, 2018 at 6:07 PM, Niklas Haas wrote:
> From: Niklas Haas
>
> This should be included as ``, same as is done in af_lv2.c.
> Forcing the extra lilv-0 breaks platforms where the include dir is
> `/usr/include/lilv/lilv.h` rather than
>
On Sun, May 13, 2018 at 7:12 PM, Paul B Mahol wrote:
> On 5/13/18, Jan Ekstroem wrote:
>> On Sun, May 13, 2018 at 6:52 PM, Paul B Mahol wrote:
>>> On 5/13/18, Niklas Haas wrote:
From: Niklas Haas
On Sun, May 13, 2018 at 7:11 PM, Paul B Mahol wrote:
> On 5/13/18, Reino Wijnsma wrote:
>> *ping*
>
> Could you wait for new libmysofa release?
Hi,
I think this depends on whether this breaks build where it used to
work before. As you may notice, it still
On Sun, May 13, 2018 at 7:12 PM, Paul B Mahol wrote:
> On 5/13/18, Jan Ekstroem wrote:
>> On Sun, May 13, 2018 at 6:52 PM, Paul B Mahol wrote:
>>> On 5/13/18, Niklas Haas wrote:
From: Niklas Haas
On Sun, May 13, 2018 at 6:52 PM, Paul B Mahol wrote:
> On 5/13/18, Niklas Haas wrote:
>> From: Niklas Haas
>>
>> This should be included as ``, same as is done in af_lv2.c.
>> Forcing the extra lilv-0 breaks platforms where the include dir is
It exists, so why not use it? Helps one get rid of additional
search path related flags in addition to PKG_CONFIG_{PATH,LIBDIR}
when utilizing a cross-prefix separate from the sysroot.
---
configure | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index
On Sun, May 20, 2018 at 1:54 PM, Carl Eugen Hoyos wrote:
>
> Reading the original submission above, isn't the whole point of the
> patch to add public symbols to help downstream with real-world
> issues?
>
> Carl Eugen
Yes, currently the API user has no visibility over how
On Sun, May 20, 2018 at 2:06 PM, Jan Ekström <jee...@gmail.com> wrote:
> On Sun, May 20, 2018 at 1:54 PM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
>>
>> Reading the original submission above, isn't the whole point of the
>> patch to add public symbols t
On Mon, May 14, 2018 at 7:50 PM, Derek Buitenhuis
wrote:
>
> So, I present to you two possible options:
>
> 1. Implement a formal CoC enforcement system. This has been mostly
> copypasted
>from VideoLAN's, and is meant as more of a blueprint. This will no
On Tue, May 15, 2018, 15:12 Michael Niedermayer
wrote:
> On Mon, May 14, 2018 at 03:54:01PM -0700, Aman Gupta wrote:
> > From: Aman Gupta
> >
> > This new optional flag makes it easier to deal with mpegts
> > samples where the PMT is updated and elementary
On Sat, Jun 9, 2018 at 11:00 PM, Carl Eugen Hoyos wrote:
> 2018-05-29 6:53 GMT+02:00, Gyan Doshi :
>>
>> On 29-05-2018 03:34 AM, Carl Eugen Hoyos wrote:
>>
>>> Just remove "and is not known...",
>
>>> please don't state that you guarantee
>>> they are compatible.
>
> Where should we sent people
On Sun, Jun 10, 2018 at 10:39 PM, Morten With wrote:
> As Gyan clarified, this only affects one input file. Help text has been
> modified as per Gyan's instructions (not yet submitted).
>
> This feature was specifically requested here (and I had the same issue as
> the one who opened the ticket):
On Wed, Jun 13, 2018 at 1:27 PM, Gj X wrote:
> fix:
> diff --git a/libavformat/ftp.c b/libavformat/ftp.c
> index 9aa7a45629..3474a0adbc 100644
> --- a/libavformat/ftp.c
> +++ b/libavformat/ftp.c
> @@ -777,7 +777,11 @@ static int ftp_read(URLContext *h, unsigned char *buf,
> int size)
> {
>
On Wed, Jun 13, 2018 at 12:47 PM, Carl Eugen Hoyos wrote:
> 2018-05-06 23:05 GMT+02:00, Marton Balint :
>
>> +List of teletext page numbers to decode. Pages that do not match the
>> specified
>> +list are dropped. You may use the special @code{*} string to match all
>> pages,
>> +or
On Mon, May 28, 2018 at 2:16 PM, Nicolas George wrote:
> Jan Ekström (2018-05-28):
>> Yet another case of forgotten 0 =! EOF translation.
>>
>> While the documentation for this specific synchronous read
>> function does not mention it, the documentation for
>
On Wed, May 30, 2018 at 4:19 AM, hwren wrote:
> Signed-off-by: hwren
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 +++
> libavcodec/version.h| 4 ++--
> 4 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git
On Mon, May 28, 2018, 03:21 Jan Ekström <jee...@gmail.com> wrote:
> Yet another case of forgotten 0 =! EOF translation.
>
> While the documentation for this specific synchronous read
> function does not mention it, the documentation for
> `sftp_async_read` documents i
These files depend on libavformat, and the vf_srcnn filter
currently is the only thing utilizing these dnn_* files and
already happens to have a dependency on libavformat.
This fixes compilation in cases where libavformat is not a
dependency for libavfilter.
Reported by Kam_ on IRC.
---
On Sat, Jun 2, 2018 at 7:07 PM, Jan Ekström wrote:
> These files depend on libavformat, and the vf_srcnn filter
> currently is the only thing utilizing these dnn_* files and
> already happens to have a dependency on libavformat.
>
> This fixes compilation in cases wh
Yet another case of forgotten 0 =! EOF translation.
While the documentation for this specific synchronous read
function does not mention it, the documentation for
`sftp_async_read` documents it, as well as looking at the
implementation of this function leads one to find
`if (handle->eof) { return
On Thu, Apr 26, 2018 at 12:00 PM, Jeyapal, Karthick wrote:
>
>
> On 4/23/18 11:40 AM, Karthick J wrote:
>> From: Karthick Jeyapal
>>
>> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in
>> DASH.
>> Hence in this muxer we will
It has not ever been working and has not been validated,
Additionally, mention that the segment file names should be changed
to end with webm instead of m4s, which is utilized for ISOBMFF
fragments.
---
libavformat/dashenc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
FF_COMPLIANCE_EXPERIMENTAL strictness. That way nobody should be
accidentally utilizing it.
Jan Ekström (2):
lavf/dashenc: require experimental mode to be enabled for WebM
lavf/dashenc: pass standards compliance value to the internal context
Rodger Combs (1):
lavf/dashenc: don't call
Enables one to test possibly nonstandard formats such as Opus or
FLAC in ISOBMFF, among other things.
This becomes much more useful if output segment format becomes an
option, or if the WebM segment feature gets removed.
---
libavformat/dashenc.c | 9 +
1 file changed, 5 insertions(+), 4
From: Rodger Combs
Fixes crash when muxing MKV-in-DASH
---
libavformat/dashenc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 211ef23cb0..4f8f61b704 100644
---
On Fri, Apr 27, 2018 at 3:51 AM, Jan Ekström <jee...@gmail.com> wrote:
> Personally I would be for removal of the WebM muxing feature in dashenc
> altogether, since the dashenc feature has never seemingly worked, and
> since there is a whole separate WebM-specific DASH meta muxer i
On Thu, May 3, 2018 at 8:58 PM, Jan Ekström <jee...@gmail.com> wrote:
> On Thu, May 3, 2018 at 7:50 PM, Alex Converse <alex.conve...@gmail.com> wrote:
>> From: Alex Converse <alexc...@twitch.tv>
>>
>> ---
>> libavformat/flvenc.c | 10 +-
>
On Thu, May 3, 2018 at 7:50 PM, Alex Converse wrote:
> From: Alex Converse
>
> ---
> libavformat/flvenc.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index
On Fri, Apr 27, 2018 at 3:51 AM, Jan Ekström <jee...@gmail.com> wrote:
> Personally I would be for removal of the WebM muxing feature in dashenc
> altogether, since the dashenc feature has never seemingly worked, and
> since there is a whole separate WebM-specific DASH meta muxer i
On Fri, Jan 26, 2018 at 1:56 AM, Carl Eugen Hoyos wrote:
> 2018-01-26 0:52 GMT+01:00 wm4 :
>> (and I already wrote that on IRC too, where he lurks as
>> michaelni)
>
> Could one of the native speakers please try to convince
> me that this is not a
From: Masaki Tanaka
Utilizes the temporal_reference field from the picture header.
---
libavcodec/mpegvideo_parser.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
index 3406346a8b..4f554b684e 100644
---
From: Masaki Tanaka
Lets one receive the proper field order from pictures coded in
field picture mode, until now forcibly set to BFF.
---
libavcodec/mpegvideo_parser.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git
From: Masaki Tanaka
---
libavcodec/mpegvideo_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpegvideo_parser.c b/libavcodec/mpegvideo_parser.c
index 4f554b684e..ecf7c28e72 100644
--- a/libavcodec/mpegvideo_parser.c
+++
These were brought to my knowledge by Yusuke, and they seemed correct
according to the specification, as well as the picture structure
parsing patch apparently fixes the detected field order with field
coded picture MPEG-2 video streams.
Masaki Tanaka (3):
mpegvideo_parser: implement parsing of
On Sun, Feb 11, 2018 at 7:52 PM, Michael Niedermayer
wrote:
>
> should be ok unless its intended to also restore the MSB
>
The value seemed to be 10bit and if the pointer is at the position
right after the picture_start_code, then `buf[0] << 2` would move the
8 bits left
On Mon, Feb 12, 2018 at 12:23 AM, Michael Niedermayer
wrote:
>
> I think a better API is needed to export the picture_structure correctly.
>
I might be misunderstanding the problem at hand, but I'm not sure if a
better API is required right now in the sense that if we
On Tue, Feb 13, 2018 at 2:13 PM, Michael Niedermayer
wrote:
> ...
> If there are 2 fields in a packet that can be as 2 field pictures or
> as a interlaced frame coded in a way thats inseperable. Then you have
> 2 timestamps really and might have information associated with
Fixes breakage with --disable-muxers as it was originally limited
to the muxer, and not the demuxer.
---
libavformat/aptxdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/aptxdec.c b/libavformat/aptxdec.c
index 467bc3fd5a..a262cd9ebe 100644
---
On Sat, Feb 10, 2018 at 6:18 PM, Paul B Mahol wrote:
>
> lgtm
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Cheers, pushed.
Jan
On Sat, Feb 10, 2018 at 6:27 PM, James Almer wrote:
>
> I know it's a simple fix so in this case it's fine, but keep in mind
> Aurelien Jacobs is the maintainer of aptx for future patches.
Yes, if this was less straightforward I would have waited for the maintainer.
Jan
On Mon, Jan 1, 2018 at 11:32 AM, wrote:
> ...
> +avctx->sample_rate= ctx->sample_rate;
> +avctx->block_align= ctx->frame_size;
> +avctx->bit_rate = ctx->sample_rate * ctx->frame_size * 8 /
> 2048;
> +avctx->channels =
On Mon, Feb 26, 2018 at 9:40 AM, Tobias Rapp wrote:
> Signed-off-by: Tobias Rapp
> ---
> fftools/ffmpeg.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index
On Thu, Jul 26, 2018 at 1:20 PM, Timo Rothenpieler
wrote:
> ---
> libavformat/librtmp.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/librtmp.c b/libavformat/librtmp.c
> index f3cfa9a8e2..43013e46e0 100644
> --- a/libavformat/librtmp.c
> +++
On Fri, Jul 27, 2018 at 1:30 AM, Michael Niedermayer
wrote:
> breaks fate
>
fate-lavf-ismv seems to be all about the version identifier (0 is for
uintXX CTS offsets, and 1 is for intXX CTS offsets). F.ex. with the
first file:
diff --git a/old_1st.log b/new_1st.log
index f188075577..5100ff6710
On Fri, Jul 27, 2018 at 11:14 AM, Clément Bœsch wrote:
> On Fri, Jul 27, 2018 at 12:03:46AM +0300, Jan Ekström wrote:
>> Clang is more strict about some things.
>> ---
>> libavfilter/aarch64/vf_nlmeans_neon.S | 4 ++--
>> 1 file changed, 2 insertions(+), 2 de
ISMV lacks any sort of edit list support, as well as tfxd is
effectively the PTS of the fragment for most intents and purposes.
Thus, if b-frames are requested without negative CTS offsets you
end up with N frames' worth of delay (tfxd PTS plus the CTS offset
of the first sample). Negative CTS
Clang is more strict about some things.
---
libavfilter/aarch64/vf_nlmeans_neon.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/aarch64/vf_nlmeans_neon.S
b/libavfilter/aarch64/vf_nlmeans_neon.S
index 6308a428db..ac16157bbd 100644
---
ISMV lacks any sort of edit list support, as well as tfxd is
effectively the PTS of the fragment for most intents and purposes.
Thus, if b-frames are requested without negative CTS offsets you
end up with N frames' worth of delay (tfxd PTS plus the CTS offset
of the first sample). Negative CTS
On 7/29/18, Jan Ekström wrote:
> ISMV lacks any sort of edit list support, as well as tfxd is
> effectively the PTS of the fragment for most intents and purposes.
>
> Thus, if b-frames are requested without negative CTS offsets you
> end up with N frames' worth of delay (tfxd P
On Sun, Aug 5, 2018 at 6:31 AM Jan Ekström wrote:
> Hi,
>
> Since this fixes b-frames in ISMV by not adding a double-delay (tfxd
> PTS + positive CTS offset), unless someone has any comments I will
> push this tonight (JST).
>
> Best r
The initial fix for sub2video flushing during filter chain restarts
seemed to add additional buffering into the filter chain, which in case
of files did work, but when handling live streams would cause premature
failure.
This fix reverts the timestamp filtering, and separates flushing from
normal
This commit tries to keep the sub2video canvas
size in case a filter chain re-initialization occurs. This issue
could also be improved by having this size be checked as new frames are
pushed into the overlay, or the overlay filter itself having an option
to scale overlayed images to the primary
On Sat, Mar 3, 2018 at 10:30 PM, Jan Ekström <jee...@gmail.com> wrote:
> On Wed, Feb 21, 2018 at 7:57 PM, Stefan _ <sf...@live.de> wrote:
>> Hadn't seen that one, it does indeed describe this exact problem.
>> I've included it in the commit message, new patch attached.
On Tue, Mar 6, 2018 at 10:39 AM, Paul B Mahol wrote:
> LGTM
Cheers, pushed.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
1 - 100 of 1155 matches
Mail list logo