Re: [FFmpeg-devel] [PATCH] ffprobe: show stream id in packets and frames
On 20-02-2020 10:05 am, Gyan Doshi wrote: On 20-02-2020 04:52 am, Jan Ekström wrote: Hi, On Wed, Feb 19, 2020 at 8:31 AM Gyan Doshi wrote: Required for reliably identifying streams in MPEGTS-like live inputs. --- Can you please explain to me how would this be any different from adding `-show_programs -show_streams` and checking out the listing of those first? It saves some steps in shell scripts, avoiding having to correlate stream index with id. Any more comments? Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] doc: add adpcm_ima_{ssi,apm}
Signed-off-by: Zane van Iperen --- doc/general.texi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/general.texi b/doc/general.texi index 01d2748f28..dbdc348598 100644 --- a/doc/general.texi +++ b/doc/general.texi @@ -1101,6 +1101,8 @@ following image formats are supported: @item ADPCM IMA Electronic Arts SEAD @tab @tab X @item ADPCM IMA Funcom @tab @tab X @item ADPCM IMA QuickTime@tab X @tab X +@item ADPCM IMA Simon & Schuster Interactive @tab @tab X +@item ADPCM IMA Ubisoft APM @tab @tab X @item ADPCM IMA Loki SDL MJPEG @tab @tab X @item ADPCM IMA WAV @tab X @tab X @item ADPCM IMA Westwood @tab @tab X -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] changelog: add adpcm_ima_ssi decoder and kvag demuxer
Signed-off-by: Zane van Iperen --- Changelog | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Changelog b/Changelog index ac873fd39e..e8ba02cb02 100644 --- a/Changelog +++ b/Changelog @@ -36,6 +36,8 @@ version : - xfade_opencl filter - afirsrc audio filter source - pad_opencl filter +- Simon & Schuster Interactive ADPCM decoder +- Real War KVAG demuxer - CDToons video decoder - siren audio decoder - Rayman 2 ADPCM decoder -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] GSoC 2020
Em sáb., 22 de fev. de 2020 às 06:43, Thilo Borgmann escreveu: > > Hi, > > >>> please help fill the 2020 GSoC Ideas page > >>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020 > >> > >> It seems the 2020 results page [1] contains results from 2019. > >> > >> [1] - https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020/Results > > > > you mean the sample project ? > > feel free to edit it to look nicer otherwise ill wait for thilo, who added > > this to reply > > yes, it is just one of the results from 2019 kept as a template for this year. > Can't see a nice option to look more obviously not to be a real finished > project (except for making it invisible). Feel free to make it more clear if > you wish for it. > I've updated it and include a link to last year result page, thanks! > -Thilo > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Add .mailmap
This allows for easy shortlog/log parsing, useful in determining eligible members of the general assembly for the new FFmpeg voting system. Signed-off-by: Josh de Kock --- This list was automatically generated based off of commits from people with the same names. If you want this adjusted/your mapping added in this commit then please comment. .mailmap | 16 1 file changed, 16 insertions(+) create mode 100644 .mailmap diff --git a/.mailmap b/.mailmap new file mode 100644 index 00..347d3f1a9d --- /dev/null +++ b/.mailmap @@ -0,0 +1,16 @@ + + + + + + + + + + + + + + + + -- 2.21.1 (Apple Git-122.3) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Don't trigger errors for multiple id3 tags.
On Fri, Feb 21, 2020 at 12:55:57PM -0800, Dale Curtis wrote: > On Fri, Feb 21, 2020 at 12:54 PM Dale Curtis > wrote: > > > On Fri, Feb 21, 2020 at 11:26 AM Andreas Rheinhardt < > > andreas.rheinha...@gmail.com> wrote: > > > >> I doubt that this patch still applies as-is because of > >> e2307f4ff197646a7feee0edbcdd2d3262932676. > >> > >> > > Ah, good point. Rebased and attached. > > > > Whoops, attached the wrong file. > > - dale > utils.c |9 + > 1 file changed, 1 insertion(+), 8 deletions(-) > 422825273de6afebc105fcfa6f4f8020c285fa5a no_errors_on_id3_v3.patch > From f9f2b953a1e71e439a88581894715568987cba5c Mon Sep 17 00:00:00 2001 > From: Dale Curtis > Date: Fri, 21 Feb 2020 12:53:30 -0800 > Subject: [PATCH] Don't trigger errors for multiple id3 tags. > > Such errors may make sense for specific formats, but general parsing > logic shouldn't be treating these as errors regardless of the error > recognition mode. > > Fixes loading of the following wave when using -err_detect explode: > https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership. - Colin Powell signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/7] avformat/segafilmenc: Remove redundant checks
On Fri, Feb 21, 2020 at 02:10:00PM +0100, Paul B Mahol wrote: > lgtm will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate/adpcm: add adpcm_ima_apm tests
On Sat, Feb 22, 2020 at 01:21:02PM +, Zane van Iperen wrote: > Signed-off-by: Zane van Iperen > --- > tests/fate/adpcm.mak| 6 ++ > tests/ref/fate/adpcm-ima-apm-mono | 1 + > tests/ref/fate/adpcm-ima-apm-stereo | 1 + > 3 files changed, 8 insertions(+) > create mode 100644 tests/ref/fate/adpcm-ima-apm-mono > create mode 100644 tests/ref/fate/adpcm-ima-apm-stereo tested on mingw32/64, linux x86-32/64 mips arm will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avdevice/decklink: add support for SDK version 11.5
Signed-off-by: Marton Balint
---
libavdevice/decklink_common.cpp | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 04c0f99edc..53b57ffe4e 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -269,7 +269,22 @@ int ff_decklink_set_format(AVFormatContext *avctx,
if (ctx->bmd_mode == bmdModeUnknown)
return -1;
-#if BLACKMAGIC_DECKLINK_API_VERSION >= 0x0b00
+#if BLACKMAGIC_DECKLINK_API_VERSION >= 0x0b05
+if (direction == DIRECTION_IN) {
+BMDDisplayMode actualMode = ctx->bmd_mode;
+if (ctx->dli->DoesSupportVideoMode(ctx->video_input, ctx->bmd_mode,
(BMDPixelFormat) cctx->raw_format,
+ bmdNoVideoInputConversion,
bmdSupportedVideoModeDefault,
+ , ) != S_OK ||
!support || ctx->bmd_mode != actualMode)
+return -1;
+} else {
+BMDDisplayMode actualMode = ctx->bmd_mode;
+if (ctx->dlo->DoesSupportVideoMode(bmdVideoConnectionUnspecified,
ctx->bmd_mode, ctx->raw_format,
+ bmdNoVideoOutputConversion,
bmdSupportedVideoModeDefault,
+ , ) != S_OK ||
!support || ctx->bmd_mode != actualMode)
+return -1;
+}
+return 0;
+#elif BLACKMAGIC_DECKLINK_API_VERSION >= 0x0b00
if (direction == DIRECTION_IN) {
if (ctx->dli->DoesSupportVideoMode(ctx->video_input, ctx->bmd_mode,
(BMDPixelFormat) cctx->raw_format,
bmdSupportedVideoModeDefault,
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avdevice/decklink_dec: fix stopping streams in read_close
The capture_started variable was never set, it is simpler to call the stop
functions unconditionally if the interface is available.
Signed-off-by: Marton Balint
---
libavdevice/decklink_common.h | 1 -
libavdevice/decklink_dec.cpp | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 8b3dbce2fb..27ce6a8a40 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -115,7 +115,6 @@ struct decklink_ctx {
/* Status */
int playback_started;
-int capture_started;
int64_t last_pts;
unsigned long frameCount;
unsigned int dropped;
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 1fd5adf515..c8d931517e 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -983,7 +983,7 @@ av_cold int ff_decklink_read_close(AVFormatContext *avctx)
struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
-if (ctx->capture_started) {
+if (ctx->dli) {
ctx->dli->StopStreams();
ctx->dli->DisableVideoInput();
ctx->dli->DisableAudioInput();
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/9] avformat/libsrt: fix timeout unit confusion between milisec and microsec
On Mon, 17 Feb 2020, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavformat/libsrt.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Ping for the series, will apply soon.
Regards,
Marton
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index d7faa603f5..1d748f0e81 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -210,7 +210,7 @@ static int libsrt_network_wait_fd_timeout(URLContext *h,
int eid, int fd, int wr
}
}
-static int libsrt_listen(int eid, int fd, const struct sockaddr *addr,
socklen_t addrlen, URLContext *h, int timeout)
+static int libsrt_listen(int eid, int fd, const struct sockaddr *addr,
socklen_t addrlen, URLContext *h, int64_t timeout)
{
int ret;
int reuse = 1;
@@ -243,7 +243,7 @@ static int libsrt_listen(int eid, int fd, const struct
sockaddr *addr, socklen_t
return ret;
}
-static int libsrt_listen_connect(int eid, int fd, const struct sockaddr *addr,
socklen_t addrlen, int timeout, URLContext *h, int will_try_next)
+static int libsrt_listen_connect(int eid, int fd, const struct sockaddr *addr,
socklen_t addrlen, int64_t timeout, URLContext *h, int will_try_next)
{
int ret;
@@ -447,7 +447,7 @@ static int libsrt_setup(URLContext *h, const char *uri, int
flags)
}
if (s->mode == SRT_MODE_LISTENER) {
// multi-client
-if ((ret = libsrt_listen(s->eid, fd, cur_ai->ai_addr, cur_ai->ai_addrlen,
h, open_timeout / 1000)) < 0)
+if ((ret = libsrt_listen(s->eid, fd, cur_ai->ai_addr, cur_ai->ai_addrlen,
h, open_timeout)) < 0)
goto fail1;
fd = ret;
} else {
@@ -458,7 +458,7 @@ static int libsrt_setup(URLContext *h, const char *uri, int
flags)
}
if ((ret = libsrt_listen_connect(s->eid, fd, cur_ai->ai_addr,
cur_ai->ai_addrlen,
- open_timeout / 1000, h,
!!cur_ai->ai_next)) < 0) {
+ open_timeout, h, !!cur_ai->ai_next))
< 0) {
if (ret == AVERROR_EXIT)
goto fail1;
else
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Update HDR10+ metadata structure.
On Fri, Feb 21, 2020, 6:44 PM Vittorio Giovara wrote: > On Fri, Feb 21, 2020 at 5:17 PM Mohammad Izadi > wrote: > > > Why does the struct belong to lavu? This struct is super similar to > structs > > in libavcodec/hevc_sei.h. We just move it to a new file to share it > between > > hevc and vp9 encoder/decoder. > > > > -- > > > > 1. Please kindly stop top posting: http://www.idallen.com/topposting.html > 2. It belongs to lavu because it's where the frame code generically code > is. I'm not familiar with this API too much, but from what i gather users > may need to have a way of accessing this data without pulling in all the > dependencies of lavc or lavf. > This struct is related to parsing and SEI, not frame. If so, why other structs are not in lavu? Please check similar structs in hevc_sei? > > Vittorio > > On Fri, Feb 21, 2020 at 2:03 PM Hendrik Leppkes > wrote: > > > > > On Fri, Feb 21, 2020 at 7:08 PM Mohammad Izadi > > > wrote: > > > > > > > > If you believe lavc is at the top of the hierarchy, I can simply move > > the > > > > file to lavc. Then both lavc and lavf can use it and hierarchy is > > > > respected. Can I do that? Doesn't break API? Any objection (with > > > solution)? > > > > Let's make right decisions to speed up the process please :). > > > > -- > > > > > > > > > The struct itself belongs in lavu with everything else of AVFrame. The > > > parsing of the mpeg-specific SEI data belongs in avcodec. You can't > > > just blindly move everything. > > > > > > - Hendrik > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > To unsubscribe, visit link above, or email > > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > > -- > Vittorio > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Interested in GSOC 2020
On Sat, Feb 22, 2020 at 11:52:52AM +0530, Sourabh Sharma wrote: > Hi, I am a 3rd Year Computer Science Student Currently Studying at > Medi-Caps University, Indore. > I want to make a contribution to FFmpeg Project in GSOC 2020. > For Gsoc 2020 I interested in Fuzzing FATE tests in libavformat, libavutil > and libswscale. > > I have one minor documentation bug fixed. > And I also worked with git in the past. > > Can I ask my query here or I can only ask in IRC. yes, ffmpeg-devel is a very good choice to ask questions about ffmpeg gsoc Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Followup: FOSDEM meeting
On 2020-02-22 13:25, Paul B Mahol wrote: > On 2/22/20, James Darnley wrote: >> On 2020-02-22 11:11, Thilo Borgmann wrote: >>> Please someone put an IRC log from the meeting there, too. James Darnley? >>> Also the audio was streamed, somebody might remember where too exactly. >>> Michael? >> >> I can post my log from the day, probably email attachment. Should I >> remove any of the lines from it, particularly after the meting >> concluded? There was a little chat afterwards and into the early evening. >> > > Consor my entries. > [Sat 22 18:00] <@durandal_1707> J_Darnley: no censoring allowed That is more clear Attached is the log for the entire day. I don't think anything needs removing so it is complete. [14:10:59] hello [14:11:01] https://hangouts.google.com/call/jYaO0pADYZELBBfsntHgAEEI [14:11:13] hullo [14:11:40] I can't invite, need op [14:13:07] ugh google wants me phone# [14:13:12] my [14:14:23] just use talky.io [14:14:47] I hope I'm showing up as muted since this UI isn't making me sure if I am or not (I should be) [14:15:03] Do you people hear us? [14:15:20] no audio so far [14:15:34] no [14:15:35] No [14:15:51] I'm just following irc, not the hangout unfortunately [14:16:10] ok, james's video feed picked up [14:16:24] JEEB: with sound ? [14:16:42] neat [14:16:56] no sound still but I can just attempt to re-join [14:17:19] nope [14:17:27] ok, audio [14:17:28] yes [14:17:31] yeah [14:17:32] have audio [14:20:13] I'm in. idling with mic off [14:26:55] usually what you do is have a nomination committee that asks people in advance and then present the nominees [14:27:53] Can everybody hear? [14:28:14] I can hear [14:28:20] voting 1: 3d, vote 2: a week, so seems like the conn is working here :) [14:28:21] I can too [14:28:23] Atm we donât copy into irc what is said [14:29:08] (v1 was IIRC people nominated who might not otherwise show up on voting list, v2 was committees, right?) [14:29:15] git log --since="last 36 months" --author="name" --oneline | wc -l [14:29:16] yes [14:29:18] Jeeb: Please write short summaries about what you hear [14:29:24] the hangout in the topic is empty btw [14:29:31] (mobile phone here) [14:29:36] BBB: https://hangouts.google.com/call/jYaO0pADYZELBBfsntHgAEEI [14:30:16] cehoyos: will attempt. [14:30:22] git log --no-merges --since=2020-01-25T00:00:00Z --until 2020-02-01T00:00:00Z --pretty=fuller | grep '^Author:' | sed 's/<.*//' |sort | uniq -c | sort -nr [14:31:03] Ty [14:31:06] j-b noting - CoC more like a values list as opposed to specific rules. there will be a suggestion which would then be voted on [14:33:08] Lynne noting - various audio decoders do checks already done avcodec common utils [14:33:17] (if I acught that right) [14:33:41] i have some difficulty understanding lynne with my headphones [14:35:24] michaelni: the sample rate and other checks in audio decoders that are now checked internally by the API so they should be removed [14:35:39] you added them, I pinged you on IRC and you didn't remove them [14:36:07] Lynne, i dont remember abouzt the ping but yes if there are redundant checks i should remove them [14:36:15] ping me again until i react! [14:36:42] for new joiners: since the topic is out of date if you want to join muted the URL is https://hangouts.google.com/call/jYaO0pADYZELBBfsntHgAEEI [14:36:59] patches would not be "lost" if we move to gitlab, for example [14:37:32] gitlab move: I guess main part being discussed atm being merge requests [14:37:44] if patches are handled by say gitlab, is it possible to subscribe via rss/atom? [14:38:01] I think yes, you can cehck with videolan's gitlab instance [14:38:45] couldn't find RSS/atom right away, but they have JSON https://code.videolan.org/videolan/x264/merge_requests.json [14:38:50] ugh [14:38:56] (just giving x264 as an example) [14:39:02] I keep track of mxf issues over rss [14:39:11] which is really handy [14:39:21] thardin: there are atom feeds for project activity, not sure if there's one *specific* to MRs [14:39:27] ah [14:39:33] haasn: that might be enough [14:39:46] rss readers typically haev filters [14:39:57] i dont see the problem with the existing infrastructure, so i dont see why we should move to gitlab [14:40:05] e.g. https://code.videolan.org/videolan/dav1d.atom [14:40:47] I run a gitlab instance at uni, and one thing I've found with gitlab is that it's.. a big thing. like it sometimes breaks for seemingly random reasons [14:42:16] yes, it's a very large ruby on rails thing, which is why I would hopefully share the system with another project, like videolan [14:42:31] that sounds like a good idea [14:43:01] I upgraded our instance when the last ubuntu lts came out, which was a bit of a chore but now I don't have to care about it for a long time [14:43:01] (one consideration that shouldn't be ignored IMHO is that MRs also have a lower barrier for entry for outside contributions, since adopting a ML workflow
Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB coded side data
On Fri, Feb 21, 2020 at 01:20:47PM +, Gaullier Nicolas wrote:
> > De : ffmpeg-devel De la part de Michael
> > Niedermayer
> > Envoyé : vendredi 21 février 2020 12:54
> > À : FFmpeg development discussions and patches
> > Objet : Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB coded
> > side data
> >
> > On Thu, Feb 20, 2020 at 11:22:33AM +, Gaullier Nicolas wrote:
> > > > De : ffmpeg-devel De la part de
> > > > Michael Niedermayer
> > > > Envoyé : vendredi 7 février 2020 23:39
> > > > À : FFmpeg development discussions and patches
> > > > Objet : Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB
> > > > coded side data
> > > >
> > > > On Wed, Jan 15, 2020 at 12:42:13AM +0100, Nicolas Gaullier wrote:
> > > > > This fixes mpeg2video stream copies to mpeg muxer like this:
> > > > > ffmpeg -i xdcamhd.mxf -c:v copy output.mpg
> > > > > ---
> > > > > libavcodec/mpeg12dec.c | 7 +++
> > > > > tests/ref/fate/mxf-probe-d10 | 3 +++
> > > > > tests/ref/fate/ts-demux | 2 +-
> > > > > 3 files changed, 11 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c index
> > > > > 17f9495a1d..48ac14fafa 100644
> > > > > --- a/libavcodec/mpeg12dec.c
> > > > > +++ b/libavcodec/mpeg12dec.c
> > > > > @@ -1398,6 +1398,7 @@ static void
> > > > > mpeg_decode_sequence_extension(Mpeg1Context *s1)
> > > > > MpegEncContext *s = >mpeg_enc_ctx;
> > > > > int horiz_size_ext, vert_size_ext;
> > > > > int bit_rate_ext;
> > > > > +AVCPBProperties *cpb_props;
> > > > >
> > > > > skip_bits(>gb, 1); /* profile and level esc*/
> > > > > s->avctx->profile = get_bits(>gb, 3);
> > > > > @@ -1429,6 +1430,12 @@ static void
> > > > > mpeg_decode_sequence_extension(Mpeg1Context *s1)
> > > > > ff_dlog(s->avctx, "sequence extension\n");
> > > > > s->codec_id = s->avctx->codec_id = AV_CODEC_ID_MPEG2VIDEO;
> > > > >
> > > > > +if (cpb_props = ff_add_cpb_side_data(s->avctx)) {
> > > > > +cpb_props->buffer_size = FFMAX(cpb_props->buffer_size,
> > > > > s->avctx->rc_buffer_size);
> > > > > +if (s->bit_rate != 0x3*400)
> > > > > +cpb_props->max_bitrate = FFMAX(cpb_props->max_bitrate,
> > > > > s->bit_rate);
> > > > > +}
> > > >
> > > > why does this not export exactly the numbers as read from the header?
> > > >
> > > > thx
> > > The header values are expressed in units of 400bit/s, and the native
> > > value 0x3 is reserved, in case of MPEG-1 (but the code is
> > shared), for vbr signalling.
> > > This is not very nice to read, but this is how it is implemented in
> > > current code.
> >
> > you misunderstand, why do you take the maximum of several things instead of
> > exporting the value from the header ?
> >
> > Thanks
> Sorry for my misunderstanding. I thought the cpb properties had to reflect
> the entire stream at the end and thus cumulate the size/max values.
well, i see your point but that would not work in practice because in a
scenario where a stream is remuxed the output properties would be written in
regular intervalls before the input is read to the end so that would not
work.
Outputing the values as is would at least preserve the values as they are
> I agree it is best to have an exact match with native header values.
> Thank you for your feedback.
> I will send a new version with the 2x FFMAX removed.
> Nicolas
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead
Andreas Rheinhardt: > Andreas Rheinhardt: >> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the >> beginning referencing the main level 1 elements (i.e. not the Clusters) >> and one at the end, referencing the Clusters. This second SeekHead was >> useless and has therefore been removed. Yet the SeekHead-related >> functions and structures are still geared towards this usecase: They >> are built around an allocated array of variable size that gets >> reallocated every time an element is added to it although the maximum >> number of Seek entries is a small compile-time constant, so that one should >> rather include the array in the SeekHead structure itself; and said >> structure should be contained in the MatroskaMuxContext instead of being >> allocated separately. >> >> The earlier code reserved space for a SeekHead with 10 entries, although >> we currently write at most 6. Reducing said number implied that every >> Matroska/Webm file will be 84 bytes smaller and required to adapt >> several FATE tests; furthermore, the reserved amount overestimated the >> amount needed for for the SeekHead's length field and how many bytes >> need to be reserved to write a EBML Void element, bringing the total >> reduction to 89 bytes. >> >> Signed-off-by: Andreas Rheinhardt >> --- > > Ping. > > - Andreas > Ping (the actual patch (which has been omitted for brevity) is here: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-February/256997.html). - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/magicyuv: Check that there are enough lines for interlacing to be possible
Fixes: out of array access
Fixes:
20763/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-5759562508664832
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/magicyuv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavcodec/magicyuv.c b/libavcodec/magicyuv.c
index 21a32785bc..aacd0d4d7d 100644
--- a/libavcodec/magicyuv.c
+++ b/libavcodec/magicyuv.c
@@ -659,6 +659,17 @@ static int magy_decode_frame(AVCodecContext *avctx, void
*data,
return AVERROR_INVALIDDATA;
}
+if (s->interlaced) {
+if ((s->slice_height >> s->vshift[1]) < 2) {
+av_log(avctx, AV_LOG_ERROR, "impossible slice height\n");
+return AVERROR_INVALIDDATA;
+}
+if ((avctx->coded_height % s->slice_height) && ((avctx->coded_height %
s->slice_height) >> s->vshift[1]) < 2) {
+av_log(avctx, AV_LOG_ERROR, "impossible height\n");
+return AVERROR_INVALIDDATA;
+}
+}
+
for (i = 0; i < s->planes; i++) {
av_fast_malloc(>slices[i], >slices_size[i], s->nb_slices *
sizeof(Slice));
if (!s->slices[i])
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fate/adpcm: add adpcm_ima_apm tests
Signed-off-by: Zane van Iperen --- tests/fate/adpcm.mak| 6 ++ tests/ref/fate/adpcm-ima-apm-mono | 1 + tests/ref/fate/adpcm-ima-apm-stereo | 1 + 3 files changed, 8 insertions(+) create mode 100644 tests/ref/fate/adpcm-ima-apm-mono create mode 100644 tests/ref/fate/adpcm-ima-apm-stereo diff --git a/tests/fate/adpcm.mak b/tests/fate/adpcm.mak index a8493e8c58..ba8aa64fc5 100644 --- a/tests/fate/adpcm.mak +++ b/tests/fate/adpcm.mak @@ -100,5 +100,11 @@ fate-adpcm-ima-ssi-mono: CMD = md5 -i $(TARGET_SAMPLES)/kvag/mull1_cut.vag -f s1 FATE_ADPCM-$(call DEMDEC, KVAG, ADPCM_IMA_SSI) += fate-adpcm-ima-ssi-stereo fate-adpcm-ima-ssi-stereo: CMD = md5 -i $(TARGET_SAMPLES)/kvag/credits_cut.vag -f s16le +FATE_ADPCM-$(call DEMDEC, APM, ADPCM_IMA_APM) += fate-adpcm-ima-apm-mono +fate-adpcm-ima-apm-mono: CMD = md5 -i $(TARGET_SAMPLES)/apm/outro1.apm -f s16le + +FATE_ADPCM-$(call DEMDEC, APM, ADPCM_IMA_APM) += fate-adpcm-ima-apm-stereo +fate-adpcm-ima-apm-stereo: CMD = md5 -i $(TARGET_SAMPLES)/apm/AS01.apm -f s16le + FATE_SAMPLES_AVCONV += $(FATE_ADPCM-yes) fate-adpcm: $(FATE_ADPCM-yes) diff --git a/tests/ref/fate/adpcm-ima-apm-mono b/tests/ref/fate/adpcm-ima-apm-mono new file mode 100644 index 00..c97e09f759 --- /dev/null +++ b/tests/ref/fate/adpcm-ima-apm-mono @@ -0,0 +1 @@ +a5cb56a035ab4b79adceba6fe4a428d2 diff --git a/tests/ref/fate/adpcm-ima-apm-stereo b/tests/ref/fate/adpcm-ima-apm-stereo new file mode 100644 index 00..28bd689758 --- /dev/null +++ b/tests/ref/fate/adpcm-ima-apm-stereo @@ -0,0 +1 @@ +e7ceb7f846f831b0bb3728d8ec18fdd4 -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Status and Plans for Subtitle Filters
On Sat, Feb 22, 2020 at 12:51:13PM +, Soft Works wrote: [...] > > > Would there be any filters at all that would operate on subtitles? > > > (other than rendering to a video surface) > > > > Sure. A few ideas that come to my mind: > > > > - rasterization (text subtitles to bitmap subtitles) > > - ocr (bitmap subtitles to text) > > - all kind of text processing (eventually piped to some external tools) > > - censoring bad words > > - inserting "watermark" text > > - timing processing: trimming, shift, scaling of time > > - lorem ipsum or similar "source" filter (equivalent to our video mires) > > for testing purposes > > - audio to text for auto captioning > > - text to audio for audio synthesis > > - concat multiple subtitle files (think of a multiple episode merged into > > one, and you want to do the same for subtitles) > > - merge/overlap multiple subtitle tracks (think of multi-language > > subtitles) > > I knew there would be reasonable ones. Maybe except the text-to-speech > Idea. I suppose you need to be a masochist to watch a full movie hearing > synthesized speech ;-) As a creator, you may not want to use your voice (because of your pronunciation, because you're mute, because you care for you anonymity, etc), and thus you would write subtitles (for accessibility) and use a synth for the audio track. We already have something similar btw, see the flite filter. > > > [...] > > > But when the primary purpose of having subtitles in filtergraphs would > > > be to have them eventually converted to bitmaps, and given that it's > > > really so extremely difficult and controversial to implement this, > > > plus that there seems to be only moderate support for this from other > > > developers- could it possibly be an easier and more pragmatic solution > > > to convert the subtitles to images simply before they are entering the > > filtergraph? > > > > That means it's likely to be only available within the command line tool and > > not the API. Unless you design a separated "libavsubtitle" (discussed in the > > past several times), but you'll need at some point many interfaces with the > > usual demuxing-decoding-encoding-muxing pipeline. > > You're right, I was focused on the CLI, and first of all at the huge > discrepancy > in the required amount of work. > > While the predominant model of ffmpeg development (patch-trial-and-error > until it gets accepted) seems to have proven to be quite successful, I'm > wondering whether in this case it wouldn't be a better strategy to come to > agree about a plan before anybody will spend more time on this..? Yes, that was my point earlier. -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Status and Plans for Subtitle Filters
> -Original Message- > From: ffmpeg-devel On Behalf Of > > On Sat, Feb 22, 2020 at 10:59:46AM +, Soft Works wrote: > [...] > > Reading through the discussion around your patch was discouraging, > > even destructive in some parts. I understand why you felt alone with > > that and I wonder why nobody else chimed in. I mean, sometimes there > > are extensive discussions about some of the least important video > > formats in the world, while subtitles are a pretty fundamental thing... > > I think the main reason is that subtitles are a different beast in the > multimedia world, and most people intuitively understand this is not fun > work at all. It's much more comfortable to work with audio and video since > the framework design revolves around them. > > > On the other hand - playing devil's advocate: Why even handle a > > subtitle media type in filtergraphs? > > > > It's not only about lavfi: the whole framework works with AVFrame. If you > use something else, you'll have to duplicate most of the APIs to handle > subtitles as well. In the past, audio was actually separated, and unification > with video was a relief. Going another path for subtitles is going to be > extremely invasive, verbose, and annoying to maintain on API change. > > > Would there be any filters at all that would operate on subtitles? > > (other than rendering to a video surface) > > Sure. A few ideas that come to my mind: > > - rasterization (text subtitles to bitmap subtitles) > - ocr (bitmap subtitles to text) > - all kind of text processing (eventually piped to some external tools) > - censoring bad words > - inserting "watermark" text > - timing processing: trimming, shift, scaling of time > - lorem ipsum or similar "source" filter (equivalent to our video mires) > for testing purposes > - audio to text for auto captioning > - text to audio for audio synthesis > - concat multiple subtitle files (think of a multiple episode merged into > one, and you want to do the same for subtitles) > - merge/overlap multiple subtitle tracks (think of multi-language > subtitles) I knew there would be reasonable ones. Maybe except the text-to-speech Idea. I suppose you need to be a masochist to watch a full movie hearing synthesized speech ;-) > [...] > > But when the primary purpose of having subtitles in filtergraphs would > > be to have them eventually converted to bitmaps, and given that it's > > really so extremely difficult and controversial to implement this, > > plus that there seems to be only moderate support for this from other > > developers- could it possibly be an easier and more pragmatic solution > > to convert the subtitles to images simply before they are entering the > filtergraph? > > That means it's likely to be only available within the command line tool and > not the API. Unless you design a separated "libavsubtitle" (discussed in the > past several times), but you'll need at some point many interfaces with the > usual demuxing-decoding-encoding-muxing pipeline. You're right, I was focused on the CLI, and first of all at the huge discrepancy in the required amount of work. While the predominant model of ffmpeg development (patch-trial-and-error until it gets accepted) seems to have proven to be quite successful, I'm wondering whether in this case it wouldn't be a better strategy to come to agree about a plan before anybody will spend more time on this..? softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Followup: FOSDEM meeting
On 2/22/20, James Darnley wrote: > On 2020-02-22 11:11, Thilo Borgmann wrote: >> Please someone put an IRC log from the meeting there, too. James Darnley? >> Also the audio was streamed, somebody might remember where too exactly. >> Michael? > > I can post my log from the day, probably email attachment. Should I > remove any of the lines from it, particularly after the meting > concluded? There was a little chat afterwards and into the early evening. > Consor my entries. > I didn't record the audio but it was broadcast on Google hangouts. I > don't know whether it records. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Followup: FOSDEM meeting
On 2020-02-22 11:11, Thilo Borgmann wrote: > Please someone put an IRC log from the meeting there, too. James Darnley? > Also the audio was streamed, somebody might remember where too exactly. > Michael? I can post my log from the day, probably email attachment. Should I remove any of the lines from it, particularly after the meting concluded? There was a little chat afterwards and into the early evening. I didn't record the audio but it was broadcast on Google hangouts. I don't know whether it records. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Status and Plans for Subtitle Filters
On Sat, Feb 22, 2020 at 10:59:46AM +, Soft Works wrote: [...] > Reading through the discussion around your patch was discouraging, > even destructive in some parts. I understand why you felt alone with that > and I wonder why nobody else chimed in. I mean, sometimes there are > extensive discussions about some of the least important video formats in > the world, while subtitles are a pretty fundamental thing... I think the main reason is that subtitles are a different beast in the multimedia world, and most people intuitively understand this is not fun work at all. It's much more comfortable to work with audio and video since the framework design revolves around them. > On the other hand - playing devil's advocate: Why even handle a subtitle > media type in filtergraphs? > It's not only about lavfi: the whole framework works with AVFrame. If you use something else, you'll have to duplicate most of the APIs to handle subtitles as well. In the past, audio was actually separated, and unification with video was a relief. Going another path for subtitles is going to be extremely invasive, verbose, and annoying to maintain on API change. > Would there be any filters at all that would operate on subtitles? > (other than rendering to a video surface) Sure. A few ideas that come to my mind: - rasterization (text subtitles to bitmap subtitles) - ocr (bitmap subtitles to text) - all kind of text processing (eventually piped to some external tools) - censoring bad words - inserting "watermark" text - timing processing: trimming, shift, scaling of time - lorem ipsum or similar "source" filter (equivalent to our video mires) for testing purposes - audio to text for auto captioning - text to audio for audio synthesis - concat multiple subtitle files (think of a multiple episode merged into one, and you want to do the same for subtitles) - merge/overlap multiple subtitle tracks (think of multi-language subtitles) [...] > But when the primary purpose of having subtitles in filtergraphs would be > to have them eventually converted to bitmaps, and given that it's really so > extremely difficult and controversial to implement this, plus that there > seems to be only moderate support for this from other developers- > could it possibly be an easier and more pragmatic solution to convert > the subtitles to images simply before they are entering the filtergraph? That means it's likely to be only available within the command line tool and not the API. Unless you design a separated "libavsubtitle" (discussed in the past several times), but you'll need at some point many interfaces with the usual demuxing-decoding-encoding-muxing pipeline. Regards, -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Status and Plans for Subtitle Filters
> -Original Message- > From: Clément Bœsch > Sent: Saturday, February 22, 2020 9:47 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Cc: Soft Works > Subject: Re: [FFmpeg-devel] Status and Plans for Subtitle Filters > > On Fri, Feb 14, 2020 at 03:26:30AM +, Soft Works wrote: > > Hi, > > > > Hi, > > > I am looking for some guidance regarding future plans about processing > subtitle streams in filter graphs. > > > > Please correct me where I'm wrong - this is the situation as I've understood > it so far: > [...] > > Your analysis was pretty much on point. I've been away from FFmpeg > development from around the time of that patchset. While I can't > recommend a course of action, I can elaborate on what was blocking and > missing. Beware that this is reconstructed from my unreliable memory and I > may forget important points. > > Last state can be found at > https://github.com/ubitux/FFmpeg/tree/subtitles-new-api > > The last WIP commit includes a TODO.txt which I'm sharing here for the > record: > > > TODO: > > - heartbeat mechanism > > - drop sub2video (needs heartbeat) > > - properly deal with -ss and -t (need strim filter?) > > - sub_start_display/sub_end_display needs to be honored > > - find a test case for dvbsub as it's likely broken (ffmpeg.c hack is > > removed and should be replaced by a EAGAIN logic in lavc/utils.c) > > - make it pass FATE: > > * fix cc/subcc > > * broke various other stuff > > - Changelog/APIchanges > > - proper API doxy > > - update lavfi/subtitles? > > - merge [avs]null filters > > - filters doc > > - avcodec_default_get_buffer2? > > - how to transfer subtitle header down to libavfilter? > > The biggest TODO entry right now is the heartbeat mechanism which is > required for being able to drop the sub2video hack. You've seen that > discussed in the thread. > > Thing is, that branch is already a relatively invasive and may include > controversial API change. Typically, the way I decided to handle subtitle > text/rectangle allocation within AVSubtitle is "different" but I couldn't come > up with a better solution. Basically, we have to fit them in AVFrame for a > clean integration within FFmpeg ecosystem, but subtitles are not simple > buffers like audio and video can be: they have to be backed by more > complex dynamic structures. > > Also unfortunately, addressing the problem through an iterative process is > extremely difficult in the current situation due to historical technical debt. > You may have noticed that the decode and encode subtitles API are a few > generations behind the audio and video ones. The reason it wasn't > modernized earlier was because it was already a pita in the past. > > The subtitles refactor requires to see the big picture and all the problems at > once. Since the core change (subtitles in AVFrame) requires the introduction > of a new subtitles structure and API, it also involve addressing the > shortcomings of the original API (or maybe we could tolerate a new API that > actually looks like the old?). So even if we ignore the subtitle-in-avframe > thing, we don't have a clear answer for a sane API that handles everything. > Here is a non-exhaustive list of stuff that we have to take into account while > thinking about that: > > - text subtitles with and without markup > - sparsity, overlapping > - different semantics for duration (duration available, no known duration, > event-based clearing, ...) > - closed captions / teletext > - bitmap subtitles and their potential colorspaces (each rectangle as an > AVFrame is way overkill but technically that's exactly what it is) > > This should give you a hint on why the task has been quite overwhelming. > Subtitles were the reason I initially came into the multimedia world, and they > might have played a role in why I distanced myself from it. > > That said, I'd say the main reason it was put in stand by was because I was > kind of alone in that struggle. While I got a lot of support from people, I > think > the main help I needed would have been formalizing the API we wanted. > Like, code and API gymnastic is not that much of a problem, but deciding on > what to do, and what path we take to reach that point is/was the core issue. > > And to be honest, I never really made up my mind on abandoning the work. > So I'm calling it again: if someone is interested in addressing the problem > once and for all, I can spend some time rebasing the current state and > clarifying what has been said in this mail in the details so we can work > together on an API contract we want between FFmpeg and our users. When > we have this, I think progress can be made again. Thanks a lot for taking the time to respond! I'm and on-/off reader of ffmpeg-devel for a few years, making some small contributions, most of which are regularly being ignored what in turn made me refrain from submitting patches of larger scale. Reading through the discussion around your patch
Re: [FFmpeg-devel] Followup: FOSDEM meeting
Am 22.02.20 um 11:11 schrieb Thilo Borgmann: > Hi, > >> Firstly, I want to thank j-b for his organisation of the meeting at >> FOSDEM, I think the meeting itself was productive and the outcome was >> good. >> >> Unfortunately, there is one issue: So far no one has shared a copy of >> the notes or a picture of the blackboard after the meeting. I was silly >> to assuming that someone else had recorded it and not taking a photo was >> my mistake. >> >> Did anyone keep a note of the results of the meeting at FOSDEM (or can >> at least recall them, my memory is not so good)? If not, this makes it >> difficult to begin the process of enacting the various votes which were >> discussed. > > I created a new page on the wiki about this meeting. I already uploaded my > pictures of the blackboard - sorry for being late, this was raised on IRC > already, too. > > Please someone put an IRC log from the meeting there, too. James Darnley? > Also the audio was streamed, somebody might remember where too exactly. > Michael? > > >> I will make sure to take notes in any future meetings. I think that this >> is the best way to ensure that it properly gets done by holding myself, >> rather than others, accountable. > > Thanks a lot! It would be a big help for everyone - especially if these > things could be declared before the meeting and not ad-hoc. Nobody will thank > you for that and it's typically a job nobody wants to do either. So let me do > that at least once here :) https://trac.ffmpeg.org/wiki/FFmeeting/2020-02 -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Followup: FOSDEM meeting
Hi, > Firstly, I want to thank j-b for his organisation of the meeting at > FOSDEM, I think the meeting itself was productive and the outcome was > good. > > Unfortunately, there is one issue: So far no one has shared a copy of > the notes or a picture of the blackboard after the meeting. I was silly > to assuming that someone else had recorded it and not taking a photo was > my mistake. > > Did anyone keep a note of the results of the meeting at FOSDEM (or can > at least recall them, my memory is not so good)? If not, this makes it > difficult to begin the process of enacting the various votes which were > discussed. I created a new page on the wiki about this meeting. I already uploaded my pictures of the blackboard - sorry for being late, this was raised on IRC already, too. Please someone put an IRC log from the meeting there, too. James Darnley? Also the audio was streamed, somebody might remember where too exactly. Michael? > I will make sure to take notes in any future meetings. I think that this > is the best way to ensure that it properly gets done by holding myself, > rather than others, accountable. Thanks a lot! It would be a big help for everyone - especially if these things could be declared before the meeting and not ad-hoc. Nobody will thank you for that and it's typically a job nobody wants to do either. So let me do that at least once here :) -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] GSoC 2020
Hi, > please help fill the 2020 GSoC Ideas page > https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020 > > (This page is key to being acccepted to GSoC) I guess everybody already noticed that FFmpeg had been accepted as a mentoring Org in GSoC 2020! :D Thanks to all potential mentors! -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] GSoC 2020
Hi, >>> please help fill the 2020 GSoC Ideas page >>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020 >> >> It seems the 2020 results page [1] contains results from 2019. >> >> [1] - https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020/Results > > you mean the sample project ? > feel free to edit it to look nicer otherwise ill wait for thilo, who added > this to reply yes, it is just one of the results from 2019 kept as a template for this year. Can't see a nice option to look more obviously not to be a real finished project (except for making it invisible). Feel free to make it more clear if you wish for it. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Status and Plans for Subtitle Filters
On Fri, Feb 14, 2020 at 03:26:30AM +, Soft Works wrote: > Hi, > Hi, > I am looking for some guidance regarding future plans about processing > subtitle streams in filter graphs. > > Please correct me where I'm wrong - this is the situation as I've understood > it so far: [...] Your analysis was pretty much on point. I've been away from FFmpeg development from around the time of that patchset. While I can't recommend a course of action, I can elaborate on what was blocking and missing. Beware that this is reconstructed from my unreliable memory and I may forget important points. Last state can be found at https://github.com/ubitux/FFmpeg/tree/subtitles-new-api The last WIP commit includes a TODO.txt which I'm sharing here for the record: > TODO: > - heartbeat mechanism > - drop sub2video (needs heartbeat) > - properly deal with -ss and -t (need strim filter?) > - sub_start_display/sub_end_display needs to be honored > - find a test case for dvbsub as it's likely broken (ffmpeg.c hack is > removed and should be replaced by a EAGAIN logic in lavc/utils.c) > - make it pass FATE: > * fix cc/subcc > * broke various other stuff > - Changelog/APIchanges > - proper API doxy > - update lavfi/subtitles? > - merge [avs]null filters > - filters doc > - avcodec_default_get_buffer2? > - how to transfer subtitle header down to libavfilter? The biggest TODO entry right now is the heartbeat mechanism which is required for being able to drop the sub2video hack. You've seen that discussed in the thread. Thing is, that branch is already a relatively invasive and may include controversial API change. Typically, the way I decided to handle subtitle text/rectangle allocation within AVSubtitle is "different" but I couldn't come up with a better solution. Basically, we have to fit them in AVFrame for a clean integration within FFmpeg ecosystem, but subtitles are not simple buffers like audio and video can be: they have to be backed by more complex dynamic structures. Also unfortunately, addressing the problem through an iterative process is extremely difficult in the current situation due to historical technical debt. You may have noticed that the decode and encode subtitles API are a few generations behind the audio and video ones. The reason it wasn't modernized earlier was because it was already a pita in the past. The subtitles refactor requires to see the big picture and all the problems at once. Since the core change (subtitles in AVFrame) requires the introduction of a new subtitles structure and API, it also involve addressing the shortcomings of the original API (or maybe we could tolerate a new API that actually looks like the old?). So even if we ignore the subtitle-in-avframe thing, we don't have a clear answer for a sane API that handles everything. Here is a non-exhaustive list of stuff that we have to take into account while thinking about that: - text subtitles with and without markup - sparsity, overlapping - different semantics for duration (duration available, no known duration, event-based clearing, ...) - closed captions / teletext - bitmap subtitles and their potential colorspaces (each rectangle as an AVFrame is way overkill but technically that's exactly what it is) This should give you a hint on why the task has been quite overwhelming. Subtitles were the reason I initially came into the multimedia world, and they might have played a role in why I distanced myself from it. That said, I'd say the main reason it was put in stand by was because I was kind of alone in that struggle. While I got a lot of support from people, I think the main help I needed would have been formalizing the API we wanted. Like, code and API gymnastic is not that much of a problem, but deciding on what to do, and what path we take to reach that point is/was the core issue. And to be honest, I never really made up my mind on abandoning the work. So I'm calling it again: if someone is interested in addressing the problem once and for all, I can spend some time rebasing the current state and clarifying what has been said in this mail in the details so we can work together on an API contract we want between FFmpeg and our users. When we have this, I think progress can be made again. Regards, -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
