Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
On Wed, Feb 6, 2019 at 9:51 PM Carl Eugen Hoyos wrote: > Why don't you put your "formula" into your own github repository? I could do that, but as I've mentioned, providing an official formula (within a separate repository, not in the source tree!) would make it easier for end users to discover, and it would ensure that there's some authority over the build process. If we sent off users to third-party taps from unknown sources, that could lead to bad end user experience with Homebrew and FFmpeg, neither of which is wanted – think about outdated taps or potentially even malicious intent. > 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 understand what's going on) and take care of a dozen dependencies. The build scripts and guides are quite straightforward but it still takes more time than just running "brew install ffmpeg". Just for context, in the last 90 days, there have been over a quarter million installs of ffmpeg through Homebrew. That's a considerable amount. Also, the binaries do not contain all third-party dependencies one might want, such as non-free software or larger libraries. I've mentioned this in my post as well. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/utils: update default wrap-around reference while iterating streams
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 to patch from its original state by Jan Ekström. > > --- > > > > Had been meaning to post this for comments/discussion for a while, as > > this seems to make timestamps continuously rising in at least one of > > my samples where the program structure changes mid-stream. > > > > The original version of this patch can be found at: > > > https://github.com/jeeb/ffmpeg/commit/6117366eaadbaf48bbd88eb2a353dfc852ff3400 > > > > The sample for which this helped is available at: > > https://kuroko.fushizen.eu/samples/pid_switch_sample.ts > > > > The difference of timestamps received from libavformat can be seen with: > > > https://kuroko.fushizen.eu/screenshots/ffmpeg/blue_vanilla-orange_patched.png > > Am I correct that even with this patch, the sample cannot > be decoded / played correctly with FFmpeg / FFplay? > > No opinion about the patch, just curious, Carl Eugen > Yes, ffmpeg.c at least is static in its stream selection (and probably so is ffplay.c) so they would ignore the other video stream either before or after the switch depending on how much you probe and if you do manual stream selection. That said, this is a simple sample (no alternatives, just a clear cut switch) so -merge_pmt_versions 1 should work for it to get both the sd and hd parts decoded. This attempts to re-use a previous AVStream when a stream is removed. We do have the mechanism in mpegts.c to signal that a program's structure has changed, but unfortunately it has not been utilized in ffmpeg.c. Jan > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar
On 2/6/2019 10:13 PM, chcunningham wrote:
> Codec information may change while reading ogg packets. Update the
> stream's internal avctx to match.
> ---
> libavformat/oggparseogm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/oggparseogm.c b/libavformat/oggparseogm.c
> index a07453760b..b07a5d55ba 100644
> --- a/libavformat/oggparseogm.c
> +++ b/libavformat/oggparseogm.c
> @@ -114,6 +114,9 @@ ogm_header(AVFormatContext *s, int idx)
> bytestream2_get_buffer(&p, st->codecpar->extradata,
> st->codecpar->extradata_size);
> }
> }
> +
> +// Update internal avctx with changes to codecpar above.
> +st->internal->need_context_update = 1;
> } else if (bytestream2_peek_byte(&p) == 3) {
> bytestream2_skip(&p, 7);
> if (bytestream2_get_bytes_left(&p) > 1)
Can a valid ogm stream contain more than one header packet? Because the
issue here as far as i can see is that ogm_header() is not validating
the output of ff_codec_get_id() and is happily accepting and propagating
AV_CODEC_ID_NONE as derived from it in a late packet, long after the
parser and everything else was already initialized.
No other ogg module sets st->internal->need_context_update and all of
them may also end up calling the respective header reading function more
than once on invalid files, but unlike the ogm one, all of them hardcode
the codec_id instead of blindly accepting a potentially bogus value
derived from the bitstream.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/gsm_parser: return -1 on parse error
Thanks, this works great. Stand by for patch. On Wed, Feb 6, 2019 at 8:38 AM Hendrik Leppkes wrote: > On Thu, Jan 31, 2019 at 11:29 PM Chris Cunningham > wrote: > > > > On Wed, Jan 30, 2019 at 5:43 PM James Almer wrote: > > > > > On 1/30/2019 10:20 PM, Chris Cunningham wrote: > > > >> > > > And this definitely means there's a bug elsewhere. This parser > should > > > have not been used for codecs ids other than GSM and GSM_MS. > That's > > > precisely what this assert() is making sure of. > > > > > > >>> > > > >>> I'll take a closer look at how this parser was selected. > > > >> > > > > > > > > Ok, here are full details of how this happens: > > > > > > > >1. AV_CODEC_ID_GSM_MS is assigned to on st->codecpar->codec_id > > > >in ogm_header() (oggparseogm.c:75) > > > >2. The (deprecated) st->codec->codec_id is not assigned at that > time > > > and > > > >remains 0 (UNKNOWN) > > > >3. AV_CODEC_ID_GSM_MS from st->codecpar is passed to > av_parser_init, > > > >selecting the gsm parser (in read_frame_internal()) > > > >4. The fuzzer next (only) packet has a size of 0, so the first > call to > > > >parse_packet() (still in read_frame_internal()) does nothing > > > >5. After this call we assign several members of > st->internal->avctx to > > > >st->codecpar. This leaves codecpar->codec_id = UNKNOWN. > > > Interestingly, we > > > >do not reset the st->parser at this point (maybe we should?) > > > > > > Where does this happen? A call to avcodec_parameters_from_context() > > > should also copy codec_id. > > > > > > > Ignore #5 here - I'm not seeing that today - was likely confused. > > > > > > > > > > >6. Next iteration of the read_frame_internal() loop we get EOF > from > > > >ff_read_packet. This triggers the "flush the parsers" call to > > > >parse_packet() which finally reaches gsm_parse() to trigger the > abort > > > >(avctx->codec_id is still 0). > > > > > > > > Questions (guessing at the fix): > > > > > > > >- At what point should st->codec->codec_id be synchronized with > > > >st->codecpar->codec_id? It never is in this test. > > > > > > In avformat_find_stream_info(), i think. In any case, st->codec should > > > have no effect on parsers. What is used in parse_packet() however is > > > st->internal->avctx, so that context is the one that evidently contains > > > codec_id == UNKNOWN when it should be in sync with codecpar. > > > > > > > We do call avformat_find_stream_info, and avcodec_parameters_from_context > > is called during that process. Everything seems OK when > > avformat_find_stream_info is done. The codecpar->codec_id is in sync with > > internal->avctx->codec_id for all streams. > > > > But then we start calling av_read_frame as part of normal demuxing. > > avcodec_parameters_from_context() does not appear to be called during > this > > process. Eventually we get this stack: > > > > ogm_header > > ogg_packet > > ogg_read_packet > > ff_read_packet > > read_frame_internal > > av_read_frame > > > > Inside ogm_header, st->codecpar->codec_id is assigned AV_CODEC_ID_GSM_MS > > (previous value was codec NONE). But *st->internal->avctx->codec_id is > > never updated. It remains NONE for the rest of this test. * > > > > When this unwinds back to read_frame_internal, st->parser is assigned > using > > this new codec (GSM_MS) > > st->parser = av_parser_init(st->codecpar->codec_id); > > > > Later on, still inside read_frame_internal's loop, we get EOF and call, > > parse_packet (/* flush the parsers */) > > parse_packet() calls av_parser_parse2(), passing st->internal->avctx > > (codec_id still NONE, while codecpar still says GSM_MS). This ultimately > > gets passed to gsm_parse, which triggers the assert0. > > > > The underlined bit above seems like the root cause. Where should we be > > updating st->internal->avctx->codec_id? > > We have a flag to set that causes avformat to fix its internal state > if a demuxer changes it after the initial opening. > st->internal->need_context_update = 1 > > Try setting that at the position where the demuxer changes codecpar > (ie. in ogm_header?), and see if that resolves it. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar
This is a follow up to feedback in
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/239751.html
On Wed, Feb 6, 2019 at 5:13 PM chcunningham
wrote:
> Codec information may change while reading ogg packets. Update the
> stream's internal avctx to match.
> ---
> libavformat/oggparseogm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/oggparseogm.c b/libavformat/oggparseogm.c
> index a07453760b..b07a5d55ba 100644
> --- a/libavformat/oggparseogm.c
> +++ b/libavformat/oggparseogm.c
> @@ -114,6 +114,9 @@ ogm_header(AVFormatContext *s, int idx)
> bytestream2_get_buffer(&p, st->codecpar->extradata,
> st->codecpar->extradata_size);
> }
> }
> +
> +// Update internal avctx with changes to codecpar above.
> +st->internal->need_context_update = 1;
> } else if (bytestream2_peek_byte(&p) == 3) {
> bytestream2_skip(&p, 7);
> if (bytestream2_get_bytes_left(&p) > 1)
> --
> 2.20.1.611.gfbb209baf1-goog
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/oggparseogm: sync avctx w/ codecpar
Codec information may change while reading ogg packets. Update the
stream's internal avctx to match.
---
libavformat/oggparseogm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/oggparseogm.c b/libavformat/oggparseogm.c
index a07453760b..b07a5d55ba 100644
--- a/libavformat/oggparseogm.c
+++ b/libavformat/oggparseogm.c
@@ -114,6 +114,9 @@ ogm_header(AVFormatContext *s, int idx)
bytestream2_get_buffer(&p, st->codecpar->extradata,
st->codecpar->extradata_size);
}
}
+
+// Update internal avctx with changes to codecpar above.
+st->internal->need_context_update = 1;
} else if (bytestream2_peek_byte(&p) == 3) {
bytestream2_skip(&p, 7);
if (bytestream2_get_bytes_left(&p) > 1)
--
2.20.1.611.gfbb209baf1-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ac3: Explicitly return to discard large amounts of nonsense bytes
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_fuzzer-5666516266123264 > Fixes: > 12561/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AC3_FIXED_fuzzer-5682923041193984 > Fixes: > 12570/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EAC3_fuzzer-5194734308425728 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/ac3dec.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c > index f844a463ee..eaa327a3ee 100644 > --- a/libavcodec/ac3dec.c > +++ b/libavcodec/ac3dec.c > @@ -1490,6 +1490,8 @@ static int ac3_decode_frame(AVCodecContext * avctx, > void *data, > } > if (i >= buf_size) > return AVERROR_INVALIDDATA; > +if (i > 10) > +return i; > buf += i; > buf_size -= i; > How exactly does this speed up the decoder, anyway? Isn't the garbage immediately skipped right after this return? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/utils: update default wrap-around reference while iterating streams
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 to patch from its original state by Jan Ekström. > --- > > Had been meaning to post this for comments/discussion for a while, as > this seems to make timestamps continuously rising in at least one of > my samples where the program structure changes mid-stream. > > The original version of this patch can be found at: > https://github.com/jeeb/ffmpeg/commit/6117366eaadbaf48bbd88eb2a353dfc852ff3400 > > The sample for which this helped is available at: > https://kuroko.fushizen.eu/samples/pid_switch_sample.ts > > The difference of timestamps received from libavformat can be seen with: > https://kuroko.fushizen.eu/screenshots/ffmpeg/blue_vanilla-orange_patched.png Am I correct that even with this patch, the sample cannot be decoded / played correctly with FFmpeg / FFplay? No opinion about the patch, just curious, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov.c: require tfhd to begin parsing trun
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 +
libavformat/mov.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index e629663949..69452cae8e 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -87,6 +87,7 @@ typedef struct MOVAtom {
struct MOVParseTableEntry;
typedef struct MOVFragment {
+int found_tfhd;
unsigned track_id;
uint64_t base_data_offset;
uint64_t moof_offset;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b9739f788..6afb656dae 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1366,6 +1366,9 @@ static void fix_frag_index_entries(MOVFragmentIndex
*frag_index, int index,
static int mov_read_moof(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
+// Set by mov_read_tfhd(). mov_read_trun() will reject files missing tfhd.
+c->fragment.found_tfhd = 0;
+
if (!c->has_looked_for_mfra && c->use_mfra_for > 0) {
c->has_looked_for_mfra = 1;
if (pb->seekable & AVIO_SEEKABLE_NORMAL) {
@@ -4544,6 +4547,8 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
MOVTrackExt *trex = NULL;
int flags, track_id, i;
+c->fragment.found_tfhd = 1;
+
avio_r8(pb); /* version */
flags = avio_rb24(pb);
@@ -4679,6 +4684,11 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
AVIndexEntry *new_entries;
MOVFragmentStreamInfo * frag_stream_info;
+if (!frag->found_tfhd) {
+av_log(c->fc, AV_LOG_ERROR, "trun track id unknown, no tfhd was
found\n");
+return AVERROR_INVALIDDATA;
+}
+
for (i = 0; i < c->fc->nb_streams; i++) {
if (c->fc->streams[i]->id == frag->track_id) {
st = c->fc->streams[i];
--
2.20.1.611.gfbb209baf1-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/utils: update default wrap-around reference while iterating streams
From: Masaki Tanaka
Seems to fix mistaken cases of discontinuity handling in MPEG-TS
when program structure changes.
Additional changes to patch from its original state by Jan Ekström.
---
Had been meaning to post this for comments/discussion for a while, as
this seems to make timestamps continuously rising in at least one of
my samples where the program structure changes mid-stream.
The original version of this patch can be found at:
https://github.com/jeeb/ffmpeg/commit/6117366eaadbaf48bbd88eb2a353dfc852ff3400
The sample for which this helped is available at:
https://kuroko.fushizen.eu/samples/pid_switch_sample.ts
The difference of timestamps received from libavformat can be seen with:
https://kuroko.fushizen.eu/screenshots/ffmpeg/blue_vanilla-orange_patched.png
Jan
libavformat/utils.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 7afef545fe..0efb1aae9c 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -815,8 +815,41 @@ static int update_wrap_reference(AVFormatContext *s,
AVStream *st, int stream_in
while (program) {
if (program->pts_wrap_reference != pts_wrap_reference) {
for (i = 0; inb_stream_indexes; i++) {
-s->streams[program->stream_index[i]]->pts_wrap_reference =
pts_wrap_reference;
-s->streams[program->stream_index[i]]->pts_wrap_behavior =
pts_wrap_behavior;
+int64_t *stream_pts_wrap_reference =
&(s->streams[program->stream_index[i]]->pts_wrap_reference);
+int *stream_pts_wrap_behavior =
&(s->streams[program->stream_index[i]]->pts_wrap_behavior);
+
+if (*stream_pts_wrap_reference != AV_NOPTS_VALUE &&
+(*stream_pts_wrap_reference - pts_wrap_reference >
1ULL << (st->pts_wrap_bits - 3) ||
+ *stream_pts_wrap_reference < pts_wrap_reference)) {
+/*
+ * If we find a defined wrap reference that is
+ * considerably larger, or that is smaller than the
+ * current default wrap reference, we update
+ * the default to current stream's wrap reference.
+ */
+av_log(s, AV_LOG_DEBUG,
+ "Updating default PTS wrap reference "
+ "%"PRId64" and PTS wrap behavior %d to "
+ "stream PTS wrap reference %"PRId64" and "
+ "PTS wrap behavior %d (program: %d, stream:%d, "
+ "stream_id: %d)\n", pts_wrap_reference,
+ pts_wrap_behavior,
+ *stream_pts_wrap_reference,
+ *stream_pts_wrap_behavior,
+ program->id, program->stream_index[i],
+ s->streams[program->stream_index[i]]->id);
+
+pts_wrap_reference = *stream_pts_wrap_reference;
+pts_wrap_behavior = *stream_pts_wrap_behavior;
+} else {
+/*
+ * Otherwise, we just utilize and override the
+ * stream's wrap-around reference with the default
+ * wrap-around reference.
+ */
+*stream_pts_wrap_reference = pts_wrap_reference;
+*stream_pts_wrap_behavior = pts_wrap_behavior;
+}
}
program->pts_wrap_reference = pts_wrap_reference;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ac3: Explicitly return to discard large amounts of nonsense bytes
On Thu, Jan 31, 2019 at 01:23:51AM +0100, 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_fuzzer-5666516266123264 > Fixes: > 12561/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AC3_FIXED_fuzzer-5682923041193984 > Fixes: > 12570/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EAC3_fuzzer-5194734308425728 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/ac3dec.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo_enc: Use av_assert1() instead of assert() in merge_context_after_encode()
On Fri, Feb 01, 2019 at 10:48:54PM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/mpegvideo_enc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: Add more error checking when writing sample entries.
On Tue, Feb 05, 2019 at 10:42:32AM -0800, Baptiste Coudurier wrote: > Hi Niki, > > > > On Feb 4, 2019, at 6:03 PM, Niki Bowe wrote: > > > > Hi Baptiste. > > I agree. This patch does cause it to fail in mov_write_header in the given > > example, by propagating the errors returned from mov_write_ac3_tag. > > > > It is not always extradata related. > > Eg EAC3 parses the packets during muxing to build the dec3 atom. Perhaps > > this should be made extradata, but its not today. > > A definitely not extradata related example: mov_write_tmcd_tag can fail for > > fps reasons. > > Many atom writing functions can fail and return error codes, but today very > > little error checking exists. > > Ok, patch looks good to me. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
Hi, 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 FFmpeg Github organization. Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
Hi, On Wed, Feb 6, 2019 at 1:20 PM Reto Kromer wrote: > > Werner Robitza wrote: > > >I propose that FFmpeg maintains its own ffmpeg formula under > >its GitHub organization > > I second the idea. +1 > > (Homebrew works now on any modern x86_64 architecture running > Linux, macOS and Windows with Linux.) > > >I am happy to maintain this formula – and maybe there are other > >community members who want to support this effort. The > >maintenance effort would basically be: bumping the formula > >everytime there's an official release, and testing its build. > > I would be happy to help. Me too. > > Best regards, Reto Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2019-02-06 21:41, Werner Robitza wrote: > Please let me know your thoughts. I'd like to know why people always think that brew is the best way to get ports. Have you looked into MacPorts? No issues with ffmpeg there. If something should be missing, ping the maintainer, and/or create a PR. Done. Anyhow, I don't think that adding a formula to the ffmpeg src tree is the right approach. Cheers, K. C. - -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE191csiqpm8f5Ln9WvgmFNJ1E3QAFAlxbVN8ACgkQvgmFNJ1E 3QCBBQ//WERtTLEDSAgTOdTWC5Xcx77hmbD4BaFiabhbQklxN+CIHnLpuk5NP1vo GWEod9s7kxv8+iZyAySpsHf70iVeH8vJNGT13KZvIwk3C3QSS9z9w6RgVRr84oog Ox9l7EqUu1FWlG1HNiWmjTm2p+zzLSzp7lEk69L7g8itJ+8AXDd0xtLryXhRDMWB zFzqtrrYNVOOrt8TasJXMSTvpzwiYfZqB4lTxjyJWdfe08ip06SLOxJx4Lx3275J KeLnWHdeaUAyp7tOYjB71xBcZgVqZf1GDYMX9Hm4Ll04QNbOYWf0C/MHeEa2g2jV y8ZOams44UQRhoiJLp7dfw7XotSt3AsU4AHQ+FozpuoUxk0QW3WPbwir542cN/11 IxV/AqzI3BkekZ+vp7SZYUG3feTBQW2jlAq9GxrC2LxTNw7cnao67VSZIbm+ihWN pU2J7aZyyKEmRuIviP8Wb3Zf9JtRyUF67jrtMrX3lSGZYoSve7B5tvpnrCfyjzzK yFI462X+xTYYB2yiruHCY5UOVkGTO85Wq3+GGmj9UZcoymRnE5DC19P7vUUcenCk AONCJiaeVSbpiFHw8QGmJSewUUJ9Cwj0CeKVUlvs0vyScVdKTOG2645fw/W+mwyR FhYFGckxyv7a1N2lUqaQz6vSTm87VBUsHc5qDMsyE99iMGF6+nE= =rdZu -END PGP SIGNATURE- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
Werner Robitza wrote: >I propose that FFmpeg maintains its own ffmpeg formula under >its GitHub organization I second the idea. (Homebrew works now on any modern x86_64 architecture running Linux, macOS and Windows with Linux.) >I am happy to maintain this formula – and maybe there are other >community members who want to support this effort. The >maintenance effort would basically be: bumping the formula >everytime there's an official release, and testing its build. I would be happy to help. Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
2019-02-06 21:41 GMT+01:00, Werner Robitza : > I am happy to maintain this formula Why don't you put your "formula" into your own github repository? We already provide a build script and we believe that it works very well, in addition a kind supporter offers osx binaries. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
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].
That creates a bit of a messy situation, as users are expecting to be
able to build ffmpeg with additional libraries, including nonfree ones
such as fdk-aac. This is no longer easily doable.
The Homebrew maintainers suggest to provide an alternative third-party
tap with an ffmpeg formula, such as this one created by another user
[3].
I propose that FFmpeg maintains its own ffmpeg formula under its
GitHub organization at github.com/ffmpeg/homebrew-ffmpeg (or similar).
This will ensure that there's one formula users will discover when
they look for an alternative tap, thus improving discoverability and
avoiding fragmentation. We could use the above link as a starting
point.
Homebrew's lead maintainer also noted that this repo ("tap") could be
indexed [4] – he was reluctant to point to it in the official
formula's caveat section though, as they will not endorse third-party
taps.
I am happy to maintain this formula – and maybe there are other
community members who want to support this effort. The maintenance
effort would basically be: bumping the formula everytime there's an
official release, and testing its build.
Please let me know your thoughts.
Best regards,
Werner
[1] https://github.com/Homebrew/homebrew-core/issues/31510
[2] https://github.com/Homebrew/homebrew-core/blob/master/Formula/ffmpeg.rb
[3]
https://github.com/varenc/homebrew-ffmpeg-with-options/blob/master/Formula/ffmpeg.rb
[4] https://docs.brew.sh/Interesting-Taps-and-Forks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/sbrdsp_fixed.c: remove input value limit for sbr_sum_square_c()
2019-02-06 20:17 GMT+01:00, Michael Niedermayer : > On Wed, Feb 06, 2019 at 01:57:37PM +0100, Carl Eugen Hoyos wrote: >> 2019-02-03 18:21 GMT+01:00, Michael Niedermayer : >> > Fixes: 1377/clusterfuzz-testcase-minimized-5487049807233024 >> > Fixes: assertion failure in sbr_sum_square_c() >> >> This changes the output, no? > > in normal cases, no it should not > It may be that one can construct a case thats not yet in the range > where the old code was undefined, the new code is defined by > 1 in a Quintillion differently and then the decoder output which is > not 64bit integers still has a off by 1 difference. > That could be, or it might be not, i dont know > > You can certainly have a differenceof the old code crashing with > assertion failure though if thst is considered "different" > >> Why are the asm implementations not affected? > > Please correct me if iam wrong but > i think only the float but not the integer version > of this have been optimized. Thank you for the explanation! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/sbrdsp_fixed.c: remove input value limit for sbr_sum_square_c()
On Wed, Feb 06, 2019 at 01:57:37PM +0100, Carl Eugen Hoyos wrote: > 2019-02-03 18:21 GMT+01:00, Michael Niedermayer : > > Fixes: 1377/clusterfuzz-testcase-minimized-5487049807233024 > > Fixes: assertion failure in sbr_sum_square_c() > > This changes the output, no? in normal cases, no it should not It may be that one can construct a case thats not yet in the range where the old code was undefined, the new code is defined by 1 in a Quintillion differently and then the decoder output which is not 64bit integers still has a off by 1 difference. That could be, or it might be not, i dont know You can certainly have a differenceof the old code crashing with assertion failure though if thst is considered "different" > Why are the asm implementations not affected? Please correct me if iam wrong but i think only the float but not the integer version of this have been optimized. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/gsm_parser: return -1 on parse error
On Thu, Jan 31, 2019 at 11:29 PM Chris Cunningham wrote: > > On Wed, Jan 30, 2019 at 5:43 PM James Almer wrote: > > > On 1/30/2019 10:20 PM, Chris Cunningham wrote: > > >> > > And this definitely means there's a bug elsewhere. This parser should > > have not been used for codecs ids other than GSM and GSM_MS. That's > > precisely what this assert() is making sure of. > > > > >>> > > >>> I'll take a closer look at how this parser was selected. > > >> > > > > > > Ok, here are full details of how this happens: > > > > > >1. AV_CODEC_ID_GSM_MS is assigned to on st->codecpar->codec_id > > >in ogm_header() (oggparseogm.c:75) > > >2. The (deprecated) st->codec->codec_id is not assigned at that time > > and > > >remains 0 (UNKNOWN) > > >3. AV_CODEC_ID_GSM_MS from st->codecpar is passed to av_parser_init, > > >selecting the gsm parser (in read_frame_internal()) > > >4. The fuzzer next (only) packet has a size of 0, so the first call to > > >parse_packet() (still in read_frame_internal()) does nothing > > >5. After this call we assign several members of st->internal->avctx to > > >st->codecpar. This leaves codecpar->codec_id = UNKNOWN. > > Interestingly, we > > >do not reset the st->parser at this point (maybe we should?) > > > > Where does this happen? A call to avcodec_parameters_from_context() > > should also copy codec_id. > > > > Ignore #5 here - I'm not seeing that today - was likely confused. > > > > > > >6. Next iteration of the read_frame_internal() loop we get EOF from > > >ff_read_packet. This triggers the "flush the parsers" call to > > >parse_packet() which finally reaches gsm_parse() to trigger the abort > > >(avctx->codec_id is still 0). > > > > > > Questions (guessing at the fix): > > > > > >- At what point should st->codec->codec_id be synchronized with > > >st->codecpar->codec_id? It never is in this test. > > > > In avformat_find_stream_info(), i think. In any case, st->codec should > > have no effect on parsers. What is used in parse_packet() however is > > st->internal->avctx, so that context is the one that evidently contains > > codec_id == UNKNOWN when it should be in sync with codecpar. > > > > We do call avformat_find_stream_info, and avcodec_parameters_from_context > is called during that process. Everything seems OK when > avformat_find_stream_info is done. The codecpar->codec_id is in sync with > internal->avctx->codec_id for all streams. > > But then we start calling av_read_frame as part of normal demuxing. > avcodec_parameters_from_context() does not appear to be called during this > process. Eventually we get this stack: > > ogm_header > ogg_packet > ogg_read_packet > ff_read_packet > read_frame_internal > av_read_frame > > Inside ogm_header, st->codecpar->codec_id is assigned AV_CODEC_ID_GSM_MS > (previous value was codec NONE). But *st->internal->avctx->codec_id is > never updated. It remains NONE for the rest of this test. * > > When this unwinds back to read_frame_internal, st->parser is assigned using > this new codec (GSM_MS) > st->parser = av_parser_init(st->codecpar->codec_id); > > Later on, still inside read_frame_internal's loop, we get EOF and call, > parse_packet (/* flush the parsers */) > parse_packet() calls av_parser_parse2(), passing st->internal->avctx > (codec_id still NONE, while codecpar still says GSM_MS). This ultimately > gets passed to gsm_parse, which triggers the assert0. > > The underlined bit above seems like the root cause. Where should we be > updating st->internal->avctx->codec_id? We have a flag to set that causes avformat to fix its internal state if a demuxer changes it after the initial opening. st->internal->need_context_update = 1 Try setting that at the position where the demuxer changes codecpar (ie. in ogm_header?), and see if that resolves it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/gsm_parser: return -1 on parse error
On Mon, Feb 04, 2019 at 04:33:37PM -0800, Chris Cunningham wrote: > > > > The underlined bit above seems like the root cause. Where should we be > > updating st->internal->avctx->codec_id? > > > > Friendly ping for review I dont have a testcase so i cant test but possibly setting need_context_update would help thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: validate chunk_count vs stsc_data
On Mon, Feb 04, 2019 at 04:30:29PM -0800, chcunningham wrote: > 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. > --- > libavformat/mov.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) This seems to break GF9720Repeal20the20Eighth20with20Helen20Linehan.m4a Thats a sample from chromium issue 822666 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Server upgrades
On Wed, Feb 06, 2019 at 02:50:02PM +0100, Reimar Döffinger wrote: > On 6 February 2019 11:46:52 CET, Michael Niedermayer > wrote: > >On Tue, Feb 05, 2019 at 05:03:02PM +, Eoff, Ullysses A wrote: > > >> I'm getting an ssl error > >> with pwclient today. This is the first time I've tried using > >pwclient since this > >> upgrade, so not sure if it's related. > >> > >> ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify > >failed (_ssl.c:726) > > > >There is also a new lets encrypt certificate, these expire frequently > >The problem probably is that the server didnt sent the full chain of > >certificates > >ive manually made a certificate that works now but reimars script needs > >an update so it cats all the certs of the chain together. (ccing reimar > >for this) or maybe someone knows a cleaner way to make nginx use more > >than > >1 as apache supports. > > Where does patchwork take the certificate from? The only reference i found is /nginx/sites-available/patchwork.conf > Does it try to use the apache one? it uses what the scripts generate well, half of it. I tried a few variants with seperate chain and cert but nothing worked and timos reply sounds like seperate files are not the way to go > As I remember, apache actually wants certificate and chain separately, so we > might need to create and use 2 different ones (even if the difference is just > a cat command or so). > If nobody has any ideas I can try to have a look tonight. I assume this requires just a single cat commmand to be added to your script thanks > > Regards, > Reimar > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Server upgrades
On 06/02/2019 14:50, Reimar Döffinger wrote: As I remember, apache actually wants certificate and chain separately, so we might need to create and use 2 different ones (even if the difference is just a cat command or so). https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatechainfile It wants it as a single file, just like nginx. The old way is deprecated. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Server upgrades
On 6 February 2019 11:46:52 CET, Michael Niedermayer wrote: >On Tue, Feb 05, 2019 at 05:03:02PM +, Eoff, Ullysses A wrote: >> I'm getting an ssl error >> with pwclient today. This is the first time I've tried using >pwclient since this >> upgrade, so not sure if it's related. >> >> ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify >failed (_ssl.c:726) > >There is also a new lets encrypt certificate, these expire frequently >The problem probably is that the server didnt sent the full chain of >certificates >ive manually made a certificate that works now but reimars script needs >an update so it cats all the certs of the chain together. (ccing reimar >for this) or maybe someone knows a cleaner way to make nginx use more >than >1 as apache supports. Where does patchwork take the certificate from? Does it try to use the apache one? As I remember, apache actually wants certificate and chain separately, so we might need to create and use 2 different ones (even if the difference is just a cat command or so). If nobody has any ideas I can try to have a look tonight. Regards, Reimar ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/sbrdsp_fixed.c: remove input value limit for sbr_sum_square_c()
2019-02-03 18:21 GMT+01:00, Michael Niedermayer : > Fixes: 1377/clusterfuzz-testcase-minimized-5487049807233024 > Fixes: assertion failure in sbr_sum_square_c() This changes the output, no? Why are the asm implementations not affected? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/2] ARIB STD-B24 caption decoding using libaribb24
On Wed, Feb 6, 2019, 13:38 Carl Eugen Hoyos 2019-02-05 18:22 GMT+01:00, Jan Ekström : > > > My initial idea was to get a reference going with libaribb24 which had > > a defined interface and thus I didn't have to look too much into the > > "how the sausage is done" part of it. After that I would have started > > looking into these two things in order to see if it made sense to > > bring them in in some way, without the functionality missing > > altogether from FFmpeg for now. > > > > To be honest, what I most disliked about your reply is that you do not > > hint at all with regards to which way would you like for this to move > > on towards. I am left in the air guessing what is acceptable for you. > > I am sorry, it is exactly as you write: > I am not happy about adding this dependency, I read your mails > as if you would agree or at least you point out many reasons > not to add it and there is precedence that you cannot "bring them > in" at a later point after adding the dependency. > But at no point I wanted to "block" the dependency and I > honestly hope I never wrote that. > I do not think you have ever explicitly written that. Which can make things much less easy to try and interpret - at least for me. I wrote those things down about the alternatives to be honest. I had looked into them, and unfortunately it seemed like with my current amount of free time and being a selfish person wanting to see something work within a graspable time frame led me to try and utilize the same library as vlc (At this stage! As I could see features in the anonymous thing that are not mentioned in libaribb24 I was interested in trying to see how it looks in more detail afterwards - when there would be a reference). Also, one thing about bringing in libaribb24: it would mean that all relevant pieces of it would have to go through style-wise changes and full on code review. Personally while lgplv3 is "acceptable" as I said, I also must say that I would not be interested in going through the review process with it just to end up with something that doesn't get enabled with the default configure parameters. > > But OK, let's give this a thought if libaribb24 is not considered to > > be acceptable to link against. We want as much as possible bite-sized > > changes to go in so that it is simpler for both the author as well as > > the reviewer. Thus, even if we skip the decoder part from this patch > > set, the following parts could already be reviewed and merged: > > 1. AVCodecIDs/descriptors and profiles in lavc (I used to have these > > in a separate patch, but I was requested to merge them into the > > decoder patch for review). > > 2. MPEG-TS Demuxing in lavf (It is not like this one is going to > > change compared to when the decoder is finished). > > > > This gets us one step forward, and not all of the code has to be > > reviewed at the point where the following bigger dump of code will be > > posted. > > > > Then, for the following steps: > > 1. Text decoding. > > > > The ARIB STD-B24 gconv module is indeed LGPLv2.1+ so we can start > > taking it in. Thus the question would more become... where should it > > go? libavutil? > > (While this is a detail imo that you should decide) > Is there any problem putting it in the library where it gets used? > Or is it used in several FFmpeg libraries? > It would be used from both libavcodec and libavformat. I already have patches in my wip tree that probe for ARIB broadcast signs, and convert the channel name to utf-8 (currently via libaribb24). My plan was to post the probing and setting broadcast standard options to mpegts.c next, and then see if the text conversion stuff could be pulled in after the base arib caption demuxing and such got in. Also just by implementing positioning with this wrapper I uncovered bugs in both FFmpeg's subtitle encoding as well as client applications when a single AVSubtitle has multiple ASS lines in it. Thus having a clear finale to this patch set one way or another would be nice. > > Or should we spin up a new library called > > libbroadcasttext if we plan on taking in the DVB text format as well > > (in the future)? Or is there a common way in the different (supported > > by us) iconv systems to register new decoding and encoding functions? > > FATE tests can then be made against this, and any differences to > > libaribb24 verified and either kept or fixed on our side. The review > > of this component should be done separate compared to the subtitle > > decoding, as while one depends on the other, they are indeed separate > > things. > > > 2. Subtitle decoding. > > > > The anonymous decoder needs to be taken into its barebones and > > possibly partially rewritten. I would probably not include more > > features than this initial version of this libaribb24 wrapper in the > > initial version. And in one way, I would probably just put being able > > to extract the textual data as a prime requirement for the first stage > > of the decoder.
Re: [FFmpeg-devel] [PATCH 1/1] libavformat/dashdec: disable seeking only for live streams.
2019-02-04 21:27 GMT+01:00, Paweł Wegner :
> Signed-off-by: Paweł Wegner
> ---
> libavformat/dashdec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index f4f4e935de..89acd5807d 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -2000,8 +2000,6 @@ static int dash_read_header(AVFormatContext *s)
> if ((ret = save_avio_options(s)) < 0)
> goto fail;
>
> -av_dict_set(&c->avio_opts, "seekable", "0", 0);
> -
> if ((ret = parse_manifest(s, s->url, s->pb)) < 0)
> goto fail;
>
> @@ -2009,6 +2007,8 @@ static int dash_read_header(AVFormatContext *s)
> * stream. */
> if (!c->is_live) {
> s->duration = (int64_t) c->media_presentation_duration *
> AV_TIME_BASE;
> +} else {
> +av_dict_set(&c->avio_opts, "seekable", "0", 0);
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/1] Seeking disabled unconditionally in DASH demuxer
On Tue, Feb 5, 2019 at 12:53 AM Carl Eugen Hoyos wrote: > 2019-02-04 21:27 GMT+01:00, Paweł Wegner : > > > any reason why this commit: > > > https://github.com/FFmpeg/FFmpeg/commit/d54ae9b782c85e626a1e49a8ee204728746227d1#diff-ce2d1d31314e57cff2d1f3eb78988c88R1903 > > disables seeking in dash demuxer? Seeking works fine > > for my dash manifests when I remove the highlighted line. > > Looks like a regression since d54ae9b7 to me. > So can you merge this: https://patchwork.ffmpeg.org/patch/11967/ ? > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/2] ARIB STD-B24 caption decoding using libaribb24
2019-02-05 18:22 GMT+01:00, Jan Ekström : > My initial idea was to get a reference going with libaribb24 which had > a defined interface and thus I didn't have to look too much into the > "how the sausage is done" part of it. After that I would have started > looking into these two things in order to see if it made sense to > bring them in in some way, without the functionality missing > altogether from FFmpeg for now. > > To be honest, what I most disliked about your reply is that you do not > hint at all with regards to which way would you like for this to move > on towards. I am left in the air guessing what is acceptable for you. I am sorry, it is exactly as you write: I am not happy about adding this dependency, I read your mails as if you would agree or at least you point out many reasons not to add it and there is precedence that you cannot "bring them in" at a later point after adding the dependency. But at no point I wanted to "block" the dependency and I honestly hope I never wrote that. > But OK, let's give this a thought if libaribb24 is not considered to > be acceptable to link against. We want as much as possible bite-sized > changes to go in so that it is simpler for both the author as well as > the reviewer. Thus, even if we skip the decoder part from this patch > set, the following parts could already be reviewed and merged: > 1. AVCodecIDs/descriptors and profiles in lavc (I used to have these > in a separate patch, but I was requested to merge them into the > decoder patch for review). > 2. MPEG-TS Demuxing in lavf (It is not like this one is going to > change compared to when the decoder is finished). > > This gets us one step forward, and not all of the code has to be > reviewed at the point where the following bigger dump of code will be > posted. > > Then, for the following steps: > 1. Text decoding. > > The ARIB STD-B24 gconv module is indeed LGPLv2.1+ so we can start > taking it in. Thus the question would more become... where should it > go? libavutil? (While this is a detail imo that you should decide) Is there any problem putting it in the library where it gets used? Or is it used in several FFmpeg libraries? > Or should we spin up a new library called > libbroadcasttext if we plan on taking in the DVB text format as well > (in the future)? Or is there a common way in the different (supported > by us) iconv systems to register new decoding and encoding functions? > FATE tests can then be made against this, and any differences to > libaribb24 verified and either kept or fixed on our side. The review > of this component should be done separate compared to the subtitle > decoding, as while one depends on the other, they are indeed separate > things. > 2. Subtitle decoding. > > The anonymous decoder needs to be taken into its barebones and > possibly partially rewritten. I would probably not include more > features than this initial version of this libaribb24 wrapper in the > initial version. And in one way, I would probably just put being able > to extract the textual data as a prime requirement for the first stage > of the decoder. Which I believe is almost as good as a perfect subtitle decoder. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Server upgrades
On 06/02/2019 11:46, Michael Niedermayer wrote: There is also a new lets encrypt certificate, these expire frequently The problem probably is that the server didnt sent the full chain of certificates ive manually made a certificate that works now but reimars script needs an update so it cats all the certs of the chain together. (ccing reimar for this) or maybe someone knows a cleaner way to make nginx use more than 1 as apache supports. I'm using https://github.com/lukas2511/dehydrated on my servers. It generates a fullchain.pem, which contains the full chain and the cert, by default, which can be used for that exact purpose. Manually specifying the chain is actually deprecated even on Apache. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Server upgrades
On Tue, Feb 05, 2019 at 05:03:02PM +, Eoff, Ullysses A wrote: > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > > Michael Niedermayer > > Sent: Friday, February 01, 2019 4:53 AM > > To: FFmpeg development discussions and patches > > Subject: [FFmpeg-devel] Server upgrades > > > > Hi all > > > > The OS and related things on the host on which our servers live > > as VMs is being upgraded as it soon would reach end of support otherwise. > > The VMs may get similarly upgrades afterwards so there may be slight > > outages today. Work is being done by Raz. > > > > Thanks to Raz for doing this needed work btw > > > > Was patchwork.ffmpeg.org included in this upgrade? yes > I'm getting an ssl error > with pwclient today. This is the first time I've tried using pwclient since > this > upgrade, so not sure if it's related. > > ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed > (_ssl.c:726) There is also a new lets encrypt certificate, these expire frequently The problem probably is that the server didnt sent the full chain of certificates ive manually made a certificate that works now but reimars script needs an update so it cats all the certs of the chain together. (ccing reimar for this) or maybe someone knows a cleaner way to make nginx use more than 1 as apache supports. ive also fixed some other issue so our our https://www.ssllabs.com/ssltest score is now A (from previously B) for patchwork thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
