On 08-02-2019 03:18 AM, Carl Eugen Hoyos wrote:
2019-02-07 22:15 GMT+01:00, Gyan :
I don't see other h264 decoders, as used within ffmpeg, exporting CC
side-data, e.g. OpenH264 or QSV.
Do they provide it?
QSV offers a method to retrieve it but our wrapper doesn't.
(I do see native hevc d
On 08-02-2019 03:31 AM, Carl Eugen Hoyos wrote:
.
No strong opinion here, I hadn't realized that -crf 0 only works with
newer versions.
Can you explain why crf alone has no effect and needs -b:v 0?
Isn't this a bug both with libvpx and libaom?
With crf present but VBV params absent, VPX ope
On Wed, Feb 6, 2019 at 6:03 PM James Almer wrote:
> Can a valid ogm stream contain more than one header packet?
Looking at ogg_packet oggdec.c, we read headers until hitting the first
non-header (counted in ogg stream field nb_headers), so multiple headers
per stream is probably ok. But multipl
On Fri, Feb 8, 2019 at 2:41 AM Carl Eugen Hoyos wrote:
>
> 2019-02-08 1:38 GMT+01:00, Jan Ekström :
>
> > I really don't like to do this because I really like consensus...
>
> Again: Please don't say this, it is (still) very offensive!
>
> It is one thing that you committed a patch that I objected
On Fri, Feb 8, 2019 at 3:19 AM Carl Eugen Hoyos wrote:
>
> 2019-02-08 2:07 GMT+01:00, Jan Ekström :
> > On Fri, Feb 8, 2019 at 2:44 AM Carl Eugen Hoyos wrote:
> >>
> >> 2019-02-08 1:42 GMT+01:00, Jan Ekström :
> >> > On Fri, Feb 8, 2019 at 2:38 AM Carl Eugen Hoyos
> >> > wrote:
> >> >>
> >> >> H
2019-02-08 2:07 GMT+01:00, Jan Ekström :
> On Fri, Feb 8, 2019 at 2:44 AM Carl Eugen Hoyos wrote:
>>
>> 2019-02-08 1:42 GMT+01:00, Jan Ekström :
>> > On Fri, Feb 8, 2019 at 2:38 AM Carl Eugen Hoyos
>> > wrote:
>> >>
>> >> Hi!
>> >>
>> >> Attached patch fixes ticket #6320, tested with the sample f
On Fri, Feb 8, 2019 at 2:44 AM Carl Eugen Hoyos wrote:
>
> 2019-02-08 1:42 GMT+01:00, Jan Ekström :
> > On Fri, Feb 8, 2019 at 2:38 AM Carl Eugen Hoyos wrote:
> >>
> >> Hi!
> >>
> >> Attached patch fixes ticket #6320, tested with the sample from ticket
> >> #7069.
> >>
> >> Please comment, Carl E
2019-02-08 0:11 GMT+01:00, Marton Balint :
>
> On Thu, 7 Feb 2019, Carl Eugen Hoyos wrote:
>
>> 2019-02-07 21:40 GMT+01:00, Marton Balint :
New patch attached.
>>>
>>> Don't simply drop charset information.
>>
>>> You should convert the strings to UTF-8 based on that.
>>
>> (Yes we should)
>>
2019-02-08 1:42 GMT+01:00, Jan Ekström :
> On Fri, Feb 8, 2019 at 2:38 AM Carl Eugen Hoyos wrote:
>>
>> Hi!
>>
>> Attached patch fixes ticket #6320, tested with the sample from ticket
>> #7069.
>>
>> Please comment, Carl Eugen
>
> Nice!
>
> I will try to test this tomorrow. To tell you the truth,
On Fri, Feb 8, 2019 at 2:38 AM Carl Eugen Hoyos wrote:
>
> Hi!
>
> Attached patch fixes ticket #6320, tested with the sample from ticket #7069.
>
> Please comment, Carl Eugen
Nice!
I will try to test this tomorrow. To tell you the truth, I am quite
jealous that the text encodings you require are
2019-02-08 1:38 GMT+01:00, Jan Ekström :
> But now that I know that the disagreement that was had about
> this patch set was not a blocking one
To the best of my knowledge, we agreed on everything
concerning this patch...
Carl Eugen
___
ffmpeg-devel mai
Hi!
Attached patch fixes ticket #6320, tested with the sample from ticket #7069.
Please comment, Carl Eugen
From fdcd141a29f336925681193a9cdd3f4eaa5c368e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 8 Feb 2019 01:35:33 +0100
Subject: [PATCH] lavf/mpegts: Convert service_name and se
On Sat, Feb 2, 2019 at 3:31 PM Jan Ekström wrote:
>
> A decoder wrapper for the libaribb24 library found in various
> distributions and currently utilized by VLC.
>
> Requires GPLv3 with the current most recent release, but as the
> current library master is LGPLv3, any newer releases will require
On Fri, Feb 01, 2019 at 08:38:12AM +, Lin, Decai wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > myp...@gmail.com
> > Sent: 2019年2月1日 15:14
> > To: FFmpeg development discussions and patches
> >
> > Subject: Re: [FFmp
On Thu, Feb 07, 2019 at 01:28:35AM +0100, Hendrik Leppkes wrote:
> On Thu, Jan 31, 2019 at 1:25 AM Michael Niedermayer
> wrote:
> >
> > Changes 19sec to 10ms (12559) runtime, 17sec to 177ms (12570)
> > Fixes: Timeout
> > Fixes:
> > 12559/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AC3_fuzze
On Mon, 4 Feb 2019, Marton Balint wrote:
Signed-off-by: Marton Balint
---
fftools/ffplay.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 6a195e5542..97009f322d 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -21
On Thu, 7 Feb 2019, Carl Eugen Hoyos wrote:
2019-02-07 21:40 GMT+01:00, Marton Balint :
On Thu, 7 Feb 2019, Carl Eugen Hoyos wrote:
2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
+if (p[0] < 0x20) {
+p++;
+
Bad content may contain stsc boxes with a first_chunk index that
exceeds stco.entries (chunk_count). This ammends the existing check to
include cases where chunk_count == 0. It also patches up the case
when stsc refers to unknown chunks, but stts has no samples (so we
can simply ignore stsc).
---
Thanks! Looking at that file, I notice the stsc refers to some unknown
chunks (stsco has no chunk offsets), but this is a non-issue since stts has
no samples. Next patch will detect this condition and simply clear out stsc
structures since they're not needed and contradict stco.
On Wed, Feb 6, 201
On Fri, Feb 8, 2019 at 12:26 AM Carl Eugen Hoyos wrote:
>
> 2019-02-07 23:17 GMT+01:00, Jan Ekström :
> > On Thu, Feb 7, 2019 at 5:46 PM Carl Eugen Hoyos wrote:
> >>
> >> 2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
> >> > On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
> >> >> +
On 2/7/19 10:48 PM, Carl Eugen Hoyos wrote:
> Seems like a good reason to remove the useless information.
Done in my latest patch for what it's worth, I also don't think it's very
important
information, plus CC can also be provided by the motivated user through the
new_side_data() API anyway :)
_
2019-02-07 23:17 GMT+01:00, Jan Ekström :
> On Thu, Feb 7, 2019 at 5:46 PM Carl Eugen Hoyos wrote:
>>
>> 2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
>> > On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
>> >> +if (p[0] < 0x20) {
>> >> +p++;
>> >> +if (--len < 0
On Thu, Feb 7, 2019 at 5:46 PM Carl Eugen Hoyos wrote:
>
> 2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
> > On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
> >> +if (p[0] < 0x20) {
> >> +p++;
> >> +if (--len < 0)
> >> +return NULL;
> >> +}
> >
>
On Thursday, 07 February 2019 at 21:21, James Almer wrote:
> On 2/7/2019 5:08 PM, Carl Eugen Hoyos wrote:
> > 2019-02-07 20:57 GMT+01:00, James Almer :
> >> On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote:
> >>> Hi!
> >>>
> >>> Lossless libvpx encoding is possible with "-crf 0".
> >>
> >> Does that wor
On Thu, Feb 7, 2019, at 12:49 PM, Carl Eugen Hoyos wrote:
>
> This sounds like a strong reason not to add it to an FFmpeg
> repository: It was claimed in the past that I am the only one
> not supporting releases but the same was now repeated by
> other developers.
We can simply provide a note that
2019-02-07 21:21 GMT+01:00, James Almer :
> On 2/7/2019 5:08 PM, Carl Eugen Hoyos wrote:
>> 2019-02-07 20:57 GMT+01:00, James Almer :
>>> On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote:
Hi!
Lossless libvpx encoding is possible with "-crf 0".
>>>
>>> Does that work with all supported ver
2019-02-07 21:40 GMT+01:00, Marton Balint :
>
>
> On Thu, 7 Feb 2019, Carl Eugen Hoyos wrote:
>
>> 2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
>>> On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
+if (p[0] < 0x20) {
+p++;
+if (--len < 0)
+
2019-02-07 21:32 GMT+01:00, Werner Robitza :
> On Thu, Feb 7, 2019 at 8:50 PM Carl Eugen Hoyos wrote:
>> Please send an initial version of the formula
>
> Sure! Attached to this email.
>
>> please understand
>> that since we do not offer release support, release builds can't
>> be the default.
>
>
2019-02-07 22:15 GMT+01:00, Gyan :
> I don't see other h264 decoders, as used within ffmpeg, exporting CC
> side-data, e.g. OpenH264 or QSV.
Do they provide it?
> (I do see native hevc doing so, as well as the Decklink indev , but not
> mentioned here.)
Seems like a good reason to remove the us
On 08-02-2019 01:39 AM, Carl Eugen Hoyos wrote:
2019-02-07 21:07 GMT+01:00, Gyan :
On 08-02-2019 01:18 AM, Carl Eugen Hoyos wrote:
2019-02-07 20:16 GMT+01:00, Mathieu Duponchelle :
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libav
On Thu, Feb 7, 2019 at 9:29 PM Michael Niedermayer
wrote:
> I can setup a repo on github and or on git.ffmpeg.org (where ffmpeg-web is)
> https://github.com/FFmpeg/web currently is a mirror of git.ffmpeg.org
> assuming there is consensus that such a thing should be created
GitHub would be preferr
On Thu, 7 Feb 2019, Carl Eugen Hoyos wrote:
2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
+if (p[0] < 0x20) {
+p++;
+if (--len < 0)
+return NULL;
+}
If I understand section "A.2 Selection of
On Thu, Feb 7, 2019 at 8:50 PM Carl Eugen Hoyos wrote:
> Please send an initial version of the formula
Sure! Attached to this email.
> please understand
> that since we do not offer release support, release builds can't
> be the default.
Homebrew always points to release versions, the latest on
On Thu, Feb 07, 2019 at 05:28:10PM +, Derek Buitenhuis wrote:
> On 07/02/2019 16:43, Werner Robitza wrote:
> > Several people have already volunteered in this thread (Reto, Kyle and
> > me), as well as the author of this formula (with whom I've had offline
> > discussions), which we can use as
On 2/7/2019 5:08 PM, Carl Eugen Hoyos wrote:
> 2019-02-07 20:57 GMT+01:00, James Almer :
>> On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Lossless libvpx encoding is possible with "-crf 0".
>>
>> Does that work with all supported versions, or was it a recent change?
>
> No, it needs
2019-02-07 21:07 GMT+01:00, Gyan :
>
>
> On 08-02-2019 01:18 AM, Carl Eugen Hoyos wrote:
>> 2019-02-07 20:16 GMT+01:00, Mathieu Duponchelle :
>>> ---
>>> doc/encoders.texi | 3 +++
>>> libavcodec/mpeg12enc.c | 31 +++
>>> libavcodec/mpegvideo.h | 2 ++
>>> 3
2019-02-07 20:57 GMT+01:00, James Almer :
> On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Lossless libvpx encoding is possible with "-crf 0".
>
> Does that work with all supported versions, or was it a recent change?
No, it needs a newer version than 1.4.0
Sorry, Carl Eugen
__
On 08-02-2019 01:18 AM, Carl Eugen Hoyos wrote:
2019-02-07 20:16 GMT+01:00, Mathieu Duponchelle :
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/doc/encoders.
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..a283b9fddf 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.tex
On 07/02/2019 19:30, Chris Cunningham wrote:
> This will reject the file entirely. The testcase I have (can share once
> chromium bug is fixed) was previously hitting an av_assert0 in
> mov_read_trun, arguably also a total rejection ;). Recovery for this could
> be pretty tricky since the dropped t
---
doc/encoders.texi | 5 -
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..2d3cfa3713 100644
--- a/doc/encoders.texi
+++ b
On 2/7/19 8:48 PM, Carl Eugen Hoyos wrote:
> +Only the mpeg2 and h264 decoders provide these.
> Sorry for the late comment:
> This is not a helpful sentence imo, many features are not provided
> by all parts of FFmpeg and it is (too) difficult to keep such lists
> up-to-date.
> Which other decoder
On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> Lossless libvpx encoding is possible with "-crf 0".
Does that work with all supported versions, or was it a recent change?
>
> Please comment, Carl Eugen
>
>
> ___
> ffmpeg-devel mailing list
>
Hi!
Lossless libvpx encoding is possible with "-crf 0".
Please comment, Carl Eugen
From 76e8df1da3470a1232f6128b37a681926d4cab92 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 7 Feb 2019 20:39:12 +0100
Subject: [PATCH] lavc/libvpxenc: Deprecate lossless, there is -crf 0.
---
doc/en
2019-02-06 21:41 GMT+01:00, Werner Robitza :
> Please let me know your thoughts.
Since this may happen:
Please send an initial version of the formula, please understand
that since we do not offer release support, release builds can't
be the default.
Carl Eugen
___
2019-02-07 20:16 GMT+01:00, Mathieu Duponchelle :
> ---
> doc/encoders.texi | 3 +++
> libavcodec/mpeg12enc.c | 31 +++
> libavcodec/mpegvideo.h | 2 ++
> 3 files changed, 36 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e86ae69cc5.
2019-02-07 20:26 GMT+01:00, Jan Ekström :
> On Thu, Feb 7, 2019 at 3:03 PM Carl Eugen Hoyos wrote:
>> Carl Eugen
>> (who hopes you can use fieldmatch to watch this...)
>
> fieldmatch,decimate should be OK for the show itself, but generally I
decimate seems unneeded for this specific sample.
> a
This will reject the file entirely. The testcase I have (can share once
chromium bug is fixed) was previously hitting an av_assert0 in
mov_read_trun, arguably also a total rejection ;). Recovery for this could
be pretty tricky since the dropped trun will break decode dependencies. I
would be surpri
On Thu, Feb 7, 2019 at 3:03 PM Carl Eugen Hoyos wrote:
>
> 2019-02-07 8:18 GMT+01:00, Jan Ekström :
> > On Thu, Feb 7, 2019, 02:22 Carl Eugen Hoyos >
> >> 2019-02-07 0:57 GMT+01:00, Jan Ekström :
> >> > From: Masaki Tanaka
> >> >
> >> > Seems to fix mistaken cases of discontinuity handling in MP
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.tex
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.tex
On Thu, Feb 7, 2019, at 8:28 AM, Derek Buitenhuis wrote:
>
> I haven't seen anyone object to hosting it as a separate repo on our infra,
> but I also didn't see anyone who maintains our infra reply... maybe Michael
> has opinions.
I'm not against it. Seems like it will be helpful to users and I'm
Hi!
Attached patch fixes ticket #7675.
Please comment, Carl Eugen
From 7c1f5eeb2c266c33f57d8e2b78bacfba3b30a471 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 7 Feb 2019 20:05:10 +0100
Subject: [PATCH] lavc/tiff: Allow decoding of cmyka (five components).
Fixes ticket #7675.
---
li
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.tex
Carl Eugen Hoyos wrote:
>The question is what happens if one of the dependencies
>in FFmpeg's formula does not work or disappears.
Then the formula will be updated accordingly, as this has
been done during all the last years.
Best regards, Reto
___
ff
2019-02-07 19:24 GMT+01:00, Reto Kromer :
> Gerion Entrup wrote:
>
>>do the dependencies of the options need to be maintained
>>in the repo as well?
>
> I guess, this is out of the scope of FFmpeg.
The question is what happens if one of the dependencies
in FFmpeg's formula does not work or disappe
> On Feb 7, 2019, at 1:22 PM, Mathieu Duponchelle
> wrote:
>
>
>
> On 2/7/19 7:21 PM, Devin Heitmueller wrote:
>> Isn’t this calculation incorrect? The max cc_count possible is 31 (0x1F),
>> hence the max size should be 93.
>>
>
> True that, updating
Not to nitpick, but it might also be w
Gerion Entrup wrote:
>do the dependencies of the options need to be maintained in the
>repo as well?
I guess, this is out of the scope of FFmpeg.
Best regards, Reto
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listin
On 2/7/19 7:21 PM, Devin Heitmueller wrote:
> Isn’t this calculation incorrect? The max cc_count possible is 31 (0x1F),
> hence the max size should be 93.
>
True that, updating
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/m
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 29 +
libavcodec/mpegvideo.h | 2 ++
3 files changed, 34 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
> On Feb 7, 2019, at 1:11 PM, Mathieu Duponchelle
> wrote:
> +if (side_data->size <= 96) {
Isn’t this calculation incorrect? The max cc_count possible is 31 (0x1F),
hence the max size should be 93.
> +int i = 0;
> +
> +put_header (s, USER_START_COD
Am Mittwoch, 6. Februar 2019, 21:41:29 CET schrieb Werner Robitza:
> Dear all,
>
> Homebrew has, with its 2.0 release, removed all options for its core
> formulae [1], including ffmpeg. This means users can no longer add
> non-default dependencies that aren't included in the core formula [2].
> Th
On 2/7/19 6:28 PM, Carl Eugen Hoyos wrote:
> Should you check here if the size is not bigger than a certain maximum
> value ...
>
>> +int i = 0;
>> +
>> +put_header (s, USER_START_CODE);
>> +
>> +put_bits(&s->pb, 8, 'G'); // user_identifier
>> +
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 29 +
libavcodec/mpegvideo.h | 2 ++
3 files changed, 34 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
On 07/02/2019 16:43, Werner Robitza wrote:
> Several people have already volunteered in this thread (Reto, Kyle and
> me), as well as the author of this formula (with whom I've had offline
> discussions), which we can use as a starting point:
> https://github.com/varenc/homebrew-ffmpeg-with-options
2019-02-07 17:08 GMT+01:00, Mathieu Duponchelle :
> ---
> doc/encoders.texi | 3 +++
> libavcodec/mpeg12enc.c | 24
> libavcodec/mpegvideo.h | 2 ++
> 3 files changed, 29 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e86ae69cc5..378a2c
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Michael Niedermayer
> Sent: Wednesday, February 06, 2019 2:47 AM
> To: FFmpeg development discussions and patches
> Cc: Reimar Döffinger
> Subject: Re: [FFmpeg-devel] Server upgrades
>
> On
On Thu, Feb 7, 2019 at 5:21 PM Derek Buitenhuis
wrote:
> I guess my question is: Who amongst the devs here wants to write it?
Several people have already volunteered in this thread (Reto, Kyle and
me), as well as the author of this formula (with whom I've had offline
discussions), which we can us
On 07/02/2019 08:06, Werner Robitza wrote:
>> I don't think that's the suggestion. Separate Github repo belonging to
>> the FFmpeg Github organization.
>
> Correct. No modification in the source tree.
I guess my question is: Who amongst the devs here wants to write it?
(Not me.)
- Derek
___
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 24
libavcodec/mpegvideo.h | 2 ++
3 files changed, 29 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2
On 07/02/2019 00:12, chcunningham wrote:
> Detecting missing tfhd avoids re-using tfhd track info from the previous
> moof. For files with multiple tracks, this may make a mess of the
> avindex and fragindex, which can later trigger av_assert0 in
> mov_read_trun().
> ---
> libavformat/isom.h | 1
2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
> On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
>> +if (p[0] < 0x20) {
>> +p++;
>> +if (--len < 0)
>> +return NULL;
>> +}
>
> If I understand section "A.2 Selection of character table" of ETSI EN
> 3
On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
> +if (p[0] < 0x20) {
> +p++;
> +if (--len < 0)
> +return NULL;
> +}
If I understand section "A.2 Selection of character table" of ETSI EN
300 468 correctly, you need to drop an additional byte if t
Hi!
Attached patch fixes ticket #6320 as reported.
Please comment, Carl Eugen
From 6a26ae786194275242de8870d2de3dad6c740405 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 7 Feb 2019 14:37:48 +0100
Subject: [PATCH] lavf/mpegts: Do not print the character coding as part of
service nam
2019-02-07 8:18 GMT+01:00, Jan Ekström :
> On Thu, Feb 7, 2019, 02:22 Carl Eugen Hoyos
>> 2019-02-07 0:57 GMT+01:00, Jan Ekström :
>> > From: Masaki Tanaka
>> >
>> > Seems to fix mistaken cases of discontinuity handling in MPEG-TS
>> > when program structure changes.
>> >
>> > Additional changes
On Thu, Feb 7, 2019 at 9:18 AM Reto Kromer wrote:
> I guess the discussion is "only" on: should this happen inside
> or outside the official FFmpeg. My personal preference would be
> inside.
Yes, that was the main point – I see others have this preference as
well. And several people have already
>>On Wed, Feb 6, 2019 at 9:51 PM Carl Eugen Hoyos
>>wrote:
>>>We already provide a build script and we believe that it works very
>>>well, in addition a kind supporter offers osx binaries.
>>
>>That's all true, but not all users want to build manually (or have the
>>technical skills to understa
Werner Robitza wrote:
>On Wed, Feb 6, 2019 at 9:51 PM Carl Eugen Hoyos
> wrote:
>>We already provide a build script and we believe that it works
>>very well, in addition a kind supporter offers osx binaries.
>
>That's all true, but not all users want to build manually (or
>have the technical skill
On Wed, Feb 6, 2019 at 10:51 PM Kyle Swanson wrote:
> On Wed, Feb 6, 2019 at 1:43 PM Helmut K. C. Tessarek
> wrote:
> > Anyhow, I don't think that adding a formula to the ffmpeg src tree is
> > the right approach.
>
> I don't think that's the suggestion. Separate Github repo belonging to
> the FF
79 matches
Mail list logo
