Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
On 08-02-2019 03:18 AM, Carl Eugen Hoyos wrote: 2019-02-07 22:15 GMT+01:00, Gyan : I don't see other h264 decoders, as used within ffmpeg, exporting CC side-data, e.g. OpenH264 or QSV. Do they provide it? QSV offers a method to retrieve it but our wrapper doesn't. (I do see native hevc doing so, as well as the Decklink indev , but not mentioned here.) Seems like a good reason to remove the useless information. Just means a bit more diligence needed before writing docs, not skipping it. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option
On 08-02-2019 03:31 AM, Carl Eugen Hoyos wrote:
.
No strong opinion here, I hadn't realized that -crf 0 only works with
newer versions.
Can you explain why crf alone has no effect and needs -b:v 0?
Isn't this a bug both with libvpx and libaom?
With crf present but VBV params absent, VPX operates using a constrained
Q RC mode , where the target bitrate acts as a ceiling. Since acvodec
has a non-zero default -b of 200 kbps, this produces undesirable
effects. If set to 0, VPX switches to constant quality.
I do see this block though,
if (avctx->codec_id == AV_CODEC_ID_VP9 && ctx->lossless == 1) {
enccfg.rc_min_quantizer =
enccfg.rc_max_quantizer = 0;
} else {
if (avctx->qmin >= 0)
enccfg.rc_min_quantizer = avctx->qmin;
if (avctx->qmax >= 0)
enccfg.rc_max_quantizer = avctx->qmax;
}
Looks like the quantizer range is disabled only by using the deprecated
option, or has this changed?
Also, with libvpx v1.7.0-1758, I get different results for -crf 0 -b:v
0 vs only -lossless 1, with the latter producing a slightly larger
file, and its result showing a slightly larger SSIM score. Although
neither produces a SSIM of 1, like libx264. Not truly lossless?
Gyan
___
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 Wed, Feb 6, 2019 at 6:03 PM James Almer wrote: > Can a valid ogm stream contain more than one header packet? Looking at ogg_packet oggdec.c, we read headers until hitting the first non-header (counted in ogg stream field nb_headers), so multiple headers per stream is probably ok. But multiple codecs in a given stream seems supsect to me. Someone with more ogg expertise should chime in. 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. > I'm open to hard-coding codec for gsm. One thing I notice is that the codec is just one of several codecpar fields that are potentially changing. If any of those change without need_context_update, it seems like values in the internal avctx could become stale? ___ 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 Fri, Feb 8, 2019 at 2:41 AM Carl Eugen Hoyos wrote: > > 2019-02-08 1:38 GMT+01:00, Jan Ekström : > > > I really don't like to do this because I really like consensus... > > Again: Please don't say this, it is (still) very offensive! > > It is one thing that you committed a patch that I objected (with > untrue explanations), it is not ok to claim you don't want to > do this. > > Thank you, Carl Eugen First of all, these private e-mails I don't really understand. Why do you end up sending them to me instead of the list? They have so far have clearly been a continuation of discussion on the mailing list. With regards to the case you are mentioning (the Dolby Vision mp4 identifiers), that was unprofessional and I apologized. I did feel stupid after the fact for not giving into requests like adding the ticket ID just because I felt like I was hitting a wall. Long story short, I indeed do *not* want to do this, but I *also* do not want to see my own work get wasted because of reasons I do not fully understand or do not fully agree with. While I do agree that libaribb24 has its issues (none of which I currently see as fatal), I picked it as a library that is utilized by a major application (VLC) already and is packaged in Debian etc. If you had said you were blocking this patch set, I may have just pulled the AVCodecID/description and demuxing stuff to be separate to get at least something in out of a set of work I've done - as I mentioned in my previous e-mail. And then tried to see if I could salvage the rest in some other way. Now - finally - if you are offended by me saying that I don't want to go against someone who says he doesn't like something I have done, then I cannot do much about that. I do truly feel so. But when presented with the request of specifying what you would like instead, you noted that you are not blocking this patch set. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8
On Fri, Feb 8, 2019 at 3:19 AM Carl Eugen Hoyos wrote: > > 2019-02-08 2:07 GMT+01:00, Jan Ekström : > > On Fri, Feb 8, 2019 at 2:44 AM Carl Eugen Hoyos wrote: > >> > >> 2019-02-08 1:42 GMT+01:00, Jan Ekström : > >> > On Fri, Feb 8, 2019 at 2:38 AM Carl Eugen Hoyos > >> > wrote: > >> >> > >> >> Hi! > >> >> > >> >> Attached patch fixes ticket #6320, tested with the sample from ticket > >> >> #7069. > >> >> > >> >> Please comment, Carl Eugen > >> > > >> > Nice! > >> > > >> > I will try to test this tomorrow. To tell you the truth, I am quite > >> > jealous that the text encodings you require are already in upstream > >> > libiconv. > >> > >> The sample you provided (for which it would have been > >> extra-nice to tell us where it came from, I found it meanwhile) > >> does not allow converting with iconv, or at least I couldn't > >> guess the encoding... > > > > The samples came from MBS (ARIB captions one) and Tokyo MX (the PID > > switch one), if that's what you mean. > > For our context, the sample comes from ticket #2261. > But thank you for the information about Japan, will try another encoding! > > Carl Eugen Yes, Paul was nice enough to open that ticket back then. It is a capture from back when Tokyo MX still did proper SD-to-HD PID switching. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8
2019-02-08 2:07 GMT+01:00, Jan Ekström : > On Fri, Feb 8, 2019 at 2:44 AM Carl Eugen Hoyos wrote: >> >> 2019-02-08 1:42 GMT+01:00, Jan Ekström : >> > On Fri, Feb 8, 2019 at 2:38 AM Carl Eugen Hoyos >> > wrote: >> >> >> >> Hi! >> >> >> >> Attached patch fixes ticket #6320, tested with the sample from ticket >> >> #7069. >> >> >> >> Please comment, Carl Eugen >> > >> > Nice! >> > >> > I will try to test this tomorrow. To tell you the truth, I am quite >> > jealous that the text encodings you require are already in upstream >> > libiconv. >> >> The sample you provided (for which it would have been >> extra-nice to tell us where it came from, I found it meanwhile) >> does not allow converting with iconv, or at least I couldn't >> guess the encoding... > > The samples came from MBS (ARIB captions one) and Tokyo MX (the PID > switch one), if that's what you mean. For our context, the sample comes from ticket #2261. But thank you for the information about Japan, will try another encoding! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8
On Fri, Feb 8, 2019 at 2:44 AM Carl Eugen Hoyos wrote: > > 2019-02-08 1:42 GMT+01:00, Jan Ekström : > > On Fri, Feb 8, 2019 at 2:38 AM Carl Eugen Hoyos wrote: > >> > >> Hi! > >> > >> Attached patch fixes ticket #6320, tested with the sample from ticket > >> #7069. > >> > >> Please comment, Carl Eugen > > > > Nice! > > > > I will try to test this tomorrow. To tell you the truth, I am quite > > jealous that the text encodings you require are already in upstream > > libiconv. > > The sample you provided (for which it would have been > extra-nice to tell us where it came from, I found it meanwhile) > does not allow converting with iconv, or at least I couldn't > guess the encoding... > > Carl Eugen The samples came from MBS (ARIB captions one) and Tokyo MX (the PID switch one), if that's what you mean. The channels themselves shouldn't matter too much as all broadcasts in Japan generally follow the ARIB specs/recommendations as far as how they're multiplexed. They're part of various samples I've been capturing in Japan along the years. The text coding is ARIB STD-24 and together with the EN300-468 Table00 one I linked both were nack'd at upstream due to not being encodings utilized in general computing, so the iconv modules now live in the linuxtv repository*. Which means that they most likely are not packaged anywhere. * https://git.linuxtv.org/v4l-utils.git/tree/contrib/gconv Libaribb24 is another implementation of the ARIB STD-B24 text coding (in addition to the subtitle part), and I've been so far utilizing it in my WIP branch. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Do not print the character coding as part of service name
2019-02-08 0:11 GMT+01:00, Marton Balint : > > On Thu, 7 Feb 2019, Carl Eugen Hoyos wrote: > >> 2019-02-07 21:40 GMT+01:00, Marton Balint : New patch attached. >>> >>> Don't simply drop charset information. >> >>> You should convert the strings to UTF-8 based on that. >> >> (Yes we should) >> Do you have a sample that needs this? > > There are tons of samples that needs this, two examples: > > - samples/ffmpeg-bugs/roundup/issue1871/dvbt.ts > - samples/MPEG2/res_change_ffmpeg_aspect.ts These are cool, I found the one from ticket #2261 and I realized that "ORF NÖ" also needs a conversion;-) >> If not, a patch that fixes a user-reported issue would rot >> because a better (unneeded) fix is possible. > > In this case I think an incomplete fix hurts more, because after it the > API user will have no way to determine the encoding. Removed the part of the patch that would have removed the "?" for non-iconv and unknown encodings. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8
2019-02-08 1:42 GMT+01:00, Jan Ekström : > On Fri, Feb 8, 2019 at 2:38 AM Carl Eugen Hoyos wrote: >> >> Hi! >> >> Attached patch fixes ticket #6320, tested with the sample from ticket >> #7069. >> >> Please comment, Carl Eugen > > Nice! > > I will try to test this tomorrow. To tell you the truth, I am quite > jealous that the text encodings you require are already in upstream > libiconv. The sample you provided (for which it would have been extra-nice to tell us where it came from, I found it meanwhile) does not allow converting with iconv, or at least I couldn't guess the encoding... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8
On Fri, Feb 8, 2019 at 2:38 AM Carl Eugen Hoyos wrote: > > Hi! > > Attached patch fixes ticket #6320, tested with the sample from ticket #7069. > > Please comment, Carl Eugen Nice! I will try to test this tomorrow. To tell you the truth, I am quite jealous that the text encodings you require are already in upstream libiconv. Jan ___ 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-08 1:38 GMT+01:00, Jan Ekström : > But now that I know that the disagreement that was had about > this patch set was not a blocking one To the best of my knowledge, we agreed on everything concerning this patch... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8
Hi!
Attached patch fixes ticket #6320, tested with the sample from ticket #7069.
Please comment, Carl Eugen
From fdcd141a29f336925681193a9cdd3f4eaa5c368e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 8 Feb 2019 01:35:33 +0100
Subject: [PATCH] lavf/mpegts: Convert service_name and service_provider to
utf-8.
Fixes ticket #6320.
---
libavformat/mpegts.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b04fd7b..dde610f 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -37,6 +37,9 @@
#include "avio_internal.h"
#include "mpeg.h"
#include "isom.h"
+#if CONFIG_ICONV
+#include
+#endif
/* maximum size in which we look for synchronization if
* synchronization is lost */
@@ -674,6 +677,36 @@ static char *getstr8(const uint8_t **pp, const uint8_t *p_end)
return NULL;
if (len > p_end - p)
return NULL;
+#if CONFIG_ICONV
+if (len && *p < 0x20) {
+const char *encodings[] = {
+"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7", "ISO-8859-8",
+"ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "", "ISO-8859-13",
+"ISO-8859-14", "ISO-8859-15", "", "", "", "",
+"", "ISO-10646", "KSC_5601", "GB2312", "ISO-10646", "UTF-8", "",
+"", "", "", "", "", "", "", "", ""
+};
+iconv_t cd;
+char *in, *out;
+size_t inlen = len - 1, outlen = inlen * 6;
+cd = iconv_open("UTF-8", encodings[*p]);
+if (cd == (iconv_t)-1)
+goto no_iconv;
+str =
+out = av_malloc(outlen);
+if (!str)
+return NULL;
+in = (char *)p + 1;
+if (iconv(cd, &in, &inlen, &out, &outlen) == -1) {
+iconv_close(cd);
+goto no_iconv;
+}
+*out = 0;
+*pp = in;
+return str;
+}
+no_iconv:
+#endif
str = av_malloc(len + 1);
if (!str)
return NULL;
--
1.7.10.4
___
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 Sat, Feb 2, 2019 at 3:31 PM Jan Ekström wrote: > > A decoder wrapper for the libaribb24 library found in various > distributions and currently utilized by VLC. > > Requires GPLv3 with the current most recent release, but as the > current library master is LGPLv3, any newer releases will require > only LGPLv3. > > If the library is not found in your distribution, it is available at: > https://github.com/nkoriyama/aribb24 > > A test sample can be found at: > https://kuroko.fushizen.eu/samples/arib_captions_colors_positioning_ruby_subpics.ts > > An example of how the decoded output currently looks can be found at: > https://megumin.fushizen.eu/screenshots/arib_subs/mpv-shot0004.png > > I will proceed to making a FATE test as soon as I figure out the simplest > way to limit an MPEG-TS stream to some PIDs without doing full remuxing. > (I think dvblast has something like this so I might take a look at that) > > The decoded subtitles might or might not have durations set, so with > ffmpeg.c `-fix_sub_duration` is required. > > Regarding positioning: > > I have an initial version of positioning implemented, but unfortunately > it requires multiple subtitle lines per AVSubtitle, and many applications > seem to fail at handling them, including the encoding portions of > libavformat/libavcodec (all lines end up concatenated into a single line, even > though that is 100% invalid as there is a header included). > > Thus I have decided to post the first version out now, as when the ruby > blocks are not included as a distraction, single-line output seems to be > fine and readable/enjoyable. > > Best regards, > Jan > > Jan Ekström (2): > add libaribb24 ARIB STD-B24 caption decoder > lavf/mpegts: add reading of ARIB data coding descriptor > > Changelog | 1 + > configure | 7 + > doc/decoders.texi | 25 +++ > libavcodec/Makefile | 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/avcodec.h| 4 + > libavcodec/codec_desc.c | 9 +- > libavcodec/libaribb24.c | 378 > libavcodec/profiles.c | 6 + > libavcodec/profiles.h | 1 + > libavcodec/version.h| 2 +- > libavformat/mpegts.c| 47 + > libavformat/version.h | 2 +- > 13 files changed, 481 insertions(+), 3 deletions(-) > create mode 100644 libavcodec/libaribb24.c > > -- > 2.20.1 > I really don't like to do this because I really like consensus... But now that I know that the disagreement that was had about this patch set was not a blocking one, I would like to move forward with my ARIB-related work (of which this was part 1). As I have addressed all the technical comments that I have received regarding the patches in this set, if any more doesn't come within the next 24 or so hours or so I would like to start pushing this in as a "reference" decoder for this format against which a future internal implementation can be compared against. One of the things about which I would have liked comments is the generation of the ASS header. I saw the libzvbi module just adding another style into the string returned by the default header generator, so I did end up wondering if an av_strnstr based solution would be preferable instead of duplicating the full header generation? The more detailed function that gives you control over some values didn't let me override those values that I wanted (such as PlayResX/Y in the beginning of the header), which is why I initially just used the same string template with av_asprintf and with values matching my use case. Another thing would have been the default font in the style, which I am not sure what to set to, since as far as I know there's no standard font type name which means "something that more or less matches the .jp broadcast font specs" (although I'll try to check the metadata on the .jp broadcast font that came with Windows 7 tomorrow^Wtoday after work). After this patch set, I will most likely try to see if I can fix at least the ASS encoder/muxer so that it would handle multiple AVSubtitleRects in an AVSubtitle correctly. That then enables making use of the positioning data in ARIB captions by pushing separately positioned regions as separate lines. Past that, metadata text decoding would be following (for which I already have a WIP patch in my work tree), but I will also attempt to see if the text encoding can be brought in as the beginnings of internal ARIB STD-B24 support. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref list1 for P slices.
On Fri, Feb 01, 2019 at 08:38:12AM +, Lin, Decai wrote: > > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > > myp...@gmail.com > > Sent: 2019年2月1日 15:14 > > To: FFmpeg development discussions and patches > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref > > list1 for P slices. > > > > On Fri, Feb 1, 2019 at 1:28 PM Lin, Decai wrote: > > > > > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > > > Behalf Of Michael Niedermayer > > > > Sent: 2019年2月1日 1:12 > > > > To: FFmpeg development discussions and patches > > > > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need > > > > check ref > > > > list1 for P slices. > > > > > > > > On Thu, Jan 31, 2019 at 03:36:56PM +0800, Decai Lin wrote: > > > > > This is robust for some corner case there is incorrect list1 count > > > > > in pps header, but it's a P slice and can be decoded well. > > > > > > > > please provide a sample h264 video that needs this > > > > > > > > > > Attached the test clip for this patch. > > > > > > > I think the better way is to add a new fate test case with the test clip for > > h264dec, isn't it? > > Yes, I can file another patch for the related fate test case. fate tests covering previously uncovered cases is always a good idea thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope 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/ac3: Explicitly return to discard large amounts of nonsense bytes
On Thu, Feb 07, 2019 at 01:28:35AM +0100, Hendrik Leppkes wrote: > On Thu, Jan 31, 2019 at 1:25 AM Michael Niedermayer > wrote: > > > > Changes 19sec to 10ms (12559) runtime, 17sec to 177ms (12570) > > Fixes: Timeout > > Fixes: > > 12559/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AC3_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? no, the return is limited to the (super) frame size so it re scans the garbage over and over again thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- 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 1/3] ffplay: use different decoder names for each media type
On Mon, 4 Feb 2019, Marton Balint wrote:
Signed-off-by: Marton Balint
---
fftools/ffplay.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 6a195e5542..97009f322d 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -2103,10 +2103,10 @@ static int audio_thread(void *arg)
return ret;
}
-static int decoder_start(Decoder *d, int (*fn)(void *), void *arg)
+static int decoder_start(Decoder *d, int (*fn)(void *), const char
*thread_name, void* arg)
{
packet_queue_start(d->queue);
-d->decoder_tid = SDL_CreateThread(fn, "decoder", arg);
+d->decoder_tid = SDL_CreateThread(fn, thread_name, arg);
if (!d->decoder_tid) {
av_log(NULL, AV_LOG_ERROR, "SDL_CreateThread(): %s\n", SDL_GetError());
return AVERROR(ENOMEM);
@@ -2676,7 +2676,7 @@ static int stream_component_open(VideoState *is, int
stream_index)
is->auddec.start_pts = is->audio_st->start_time;
is->auddec.start_pts_tb = is->audio_st->time_base;
}
-if ((ret = decoder_start(&is->auddec, audio_thread, is)) < 0)
+if ((ret = decoder_start(&is->auddec, audio_thread, "audio_decoder", is))
< 0)
goto out;
SDL_PauseAudioDevice(audio_dev, 0);
break;
@@ -2685,7 +2685,7 @@ static int stream_component_open(VideoState *is, int
stream_index)
is->video_st = ic->streams[stream_index];
decoder_init(&is->viddec, avctx, &is->videoq, is->continue_read_thread);
-if ((ret = decoder_start(&is->viddec, video_thread, is)) < 0)
+if ((ret = decoder_start(&is->viddec, video_thread, "video_decoder", is))
< 0)
goto out;
is->queue_attachments_req = 1;
break;
@@ -2694,7 +2694,7 @@ static int stream_component_open(VideoState *is, int
stream_index)
is->subtitle_st = ic->streams[stream_index];
decoder_init(&is->subdec, avctx, &is->subtitleq,
is->continue_read_thread);
-if ((ret = decoder_start(&is->subdec, subtitle_thread, is)) < 0)
+if ((ret = decoder_start(&is->subdec, subtitle_thread,
"subtitle_decoder", is)) < 0)
goto out;
break;
default:
--
Applied the series.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Do not print the character coding as part of service name
On Thu, 7 Feb 2019, Carl Eugen Hoyos wrote:
2019-02-07 21:40 GMT+01:00, Marton Balint :
On Thu, 7 Feb 2019, Carl Eugen Hoyos wrote:
2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
+if (p[0] < 0x20) {
+p++;
+if (--len < 0)
+return NULL;
+}
If I understand section "A.2 Selection of character table" of ETSI EN
300 468 correctly, you need to drop an additional byte if the first
byte (p[0]) is 0x1F, or an additional two bytes if the first one is
0x10.
New patch attached.
Don't simply drop charset information.
You should convert the strings to UTF-8 based on that.
(Yes we should)
Do you have a sample that needs this?
There are tons of samples that needs this, two examples:
- samples/ffmpeg-bugs/roundup/issue1871/dvbt.ts
- samples/MPEG2/res_change_ffmpeg_aspect.ts
If not, a patch that fixes a user-reported issue would rot
because a better (unneeded) fix is possible.
In this case I think an incomplete fix hurts more, because after it the
API user will have no way to determine the encoding. Using Iconv to
convert between the code pages should not be too much work.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mov: validate chunk_count vs stsc_data
Bad content may contain stsc boxes with a first_chunk index that
exceeds stco.entries (chunk_count). This ammends the existing check to
include cases where chunk_count == 0. It also patches up the case
when stsc refers to unknown chunks, but stts has no samples (so we
can simply ignore stsc).
---
libavformat/mov.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b9739f788..45a40fe922 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2694,8 +2694,11 @@ static inline int64_t
mov_get_stsc_samples(MOVStreamContext *sc, unsigned int in
if (mov_stsc_index_valid(index, sc->stsc_count))
chunk_count = sc->stsc_data[index + 1].first -
sc->stsc_data[index].first;
-else
+else {
+// Validation for stsc / stco happens earlier in mov_read_stsc +
mov_read_trak.
+av_assert0(sc->stsc_data[index].first <= sc->chunk_count);
chunk_count = sc->chunk_count - (sc->stsc_data[index].first - 1);
+}
return sc->stsc_data[index].count * (int64_t)chunk_count;
}
@@ -4167,6 +4170,13 @@ static int mov_read_trak(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
c->trak_index = -1;
+// Here stsc refers to a chunk not described in stco. This is technically
invalid,
+// but we can overlook it (clearing stsc) whenever stts_count == 0
(indicating no samples).
+if (!sc->chunk_count && !sc->stts_count && sc->stsc_count) {
+sc->stsc_count = 0;
+av_freep(&sc->stsc_data);
+}
+
/* sanity checks */
if ((sc->chunk_count && (!sc->stts_count || !sc->stsc_count ||
(!sc->sample_size && !sc->sample_count))) ||
@@ -4175,7 +4185,7 @@ static int mov_read_trak(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
st->index);
return 0;
}
-if (sc->chunk_count && sc->stsc_count && sc->stsc_data[ sc->stsc_count - 1
].first > sc->chunk_count) {
+if (sc->stsc_count && sc->stsc_data[ sc->stsc_count - 1 ].first >
sc->chunk_count) {
av_log(c->fc, AV_LOG_ERROR, "stream %d, contradictionary STSC and
STCO\n",
st->index);
return AVERROR_INVALIDDATA;
--
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] avformat/mov: validate chunk_count vs stsc_data
Thanks! Looking at that file, I notice the stsc refers to some unknown chunks (stsco has no chunk offsets), but this is a non-issue since stts has no samples. Next patch will detect this condition and simply clear out stsc structures since they're not needed and contradict stco. On Wed, Feb 6, 2019 at 7:57 AM Michael Niedermayer wrote: > 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. > ___ > 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]lavf/mpegts: Do not print the character coding as part of service name
On Fri, Feb 8, 2019 at 12:26 AM Carl Eugen Hoyos wrote:
>
> 2019-02-07 23:17 GMT+01:00, Jan Ekström :
> > On Thu, Feb 7, 2019 at 5:46 PM Carl Eugen Hoyos wrote:
> >>
> >> 2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
> >> > On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
> >> >> +if (p[0] < 0x20) {
> >> >> +p++;
> >> >> +if (--len < 0)
> >> >> +return NULL;
> >> >> +}
> >> >
> >> > If I understand section "A.2 Selection of character table" of ETSI EN
> >> > 300 468 correctly, you need to drop an additional byte if the first
> >> > byte (p[0]) is 0x1F, or an additional two bytes if the first one is
> >> > 0x10.
> >>
> >> New patch attached.
> >>
> >
> > This is weird.
> >
> > I applied this on top of my WIP ARIB branch
> > (https://github.com/jeeb/ffmpeg/commits/mpegts_arib_stuff) and now I
> > lost service name / provider altogether...
> > I mean, the stuff in the branch is "quick and dirty" at this point,
> > but it's still peculiar.
> >
> > This can be seen with both the PID switch sample I recently posted as
> > well as with the ARIB captions sample I posted in the libaribb24
> > wrapper thread.
>
> Reason is that instead of "(*p < 0x20)" it has to be "(len && *p < 0x20)".
>
> This is also the missing sample, I don't know if I'll succeed with the
> conversion.
>
It seems like the person who implemented the ARIB STD-B24 encoding and
got it merged to linuxtv also implemented ETSI EN 300 468?
https://git.linuxtv.org/v4l-utils.git/tree/contrib/gconv/en300-468-tab00.c
It is under LGPLv2.1+ so similarly usable. I did take a look at the
ARIB one yesterday and while it seems to base an awful lot on the
magic that comes from including iconv/{skeleton,loop}.c it doesn't
seem completely impenetrable...
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
On 2/7/19 10:48 PM, Carl Eugen Hoyos wrote: > Seems like a good reason to remove the useless information. Done in my latest patch for what it's worth, I also don't think it's very important information, plus CC can also be provided by the motivated user through the new_side_data() API anyway :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Do not print the character coding as part of service name
2019-02-07 23:17 GMT+01:00, Jan Ekström :
> On Thu, Feb 7, 2019 at 5:46 PM Carl Eugen Hoyos wrote:
>>
>> 2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
>> > On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
>> >> +if (p[0] < 0x20) {
>> >> +p++;
>> >> +if (--len < 0)
>> >> +return NULL;
>> >> +}
>> >
>> > If I understand section "A.2 Selection of character table" of ETSI EN
>> > 300 468 correctly, you need to drop an additional byte if the first
>> > byte (p[0]) is 0x1F, or an additional two bytes if the first one is
>> > 0x10.
>>
>> New patch attached.
>>
>
> This is weird.
>
> I applied this on top of my WIP ARIB branch
> (https://github.com/jeeb/ffmpeg/commits/mpegts_arib_stuff) and now I
> lost service name / provider altogether...
> I mean, the stuff in the branch is "quick and dirty" at this point,
> but it's still peculiar.
>
> This can be seen with both the PID switch sample I recently posted as
> well as with the ARIB captions sample I posted in the libaribb24
> wrapper thread.
Reason is that instead of "(*p < 0x20)" it has to be "(len && *p < 0x20)".
This is also the missing sample, I don't know if I'll succeed with the
conversion.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Do not print the character coding as part of service name
On Thu, Feb 7, 2019 at 5:46 PM Carl Eugen Hoyos wrote:
>
> 2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
> > On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
> >> +if (p[0] < 0x20) {
> >> +p++;
> >> +if (--len < 0)
> >> +return NULL;
> >> +}
> >
> > If I understand section "A.2 Selection of character table" of ETSI EN
> > 300 468 correctly, you need to drop an additional byte if the first
> > byte (p[0]) is 0x1F, or an additional two bytes if the first one is
> > 0x10.
>
> New patch attached.
>
This is weird.
I applied this on top of my WIP ARIB branch
(https://github.com/jeeb/ffmpeg/commits/mpegts_arib_stuff) and now I
lost service name / provider altogether...
I mean, the stuff in the branch is "quick and dirty" at this point,
but it's still peculiar.
This can be seen with both the PID switch sample I recently posted as
well as with the ARIB captions sample I posted in the libaribb24
wrapper thread.
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option
On Thursday, 07 February 2019 at 21:21, James Almer wrote: > On 2/7/2019 5:08 PM, Carl Eugen Hoyos wrote: > > 2019-02-07 20:57 GMT+01:00, James Almer : > >> On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote: > >>> Hi! > >>> > >>> Lossless libvpx encoding is possible with "-crf 0". > >> > >> Does that work with all supported versions, or was it a recent change? > > > > No, it needs a newer version than 1.4.0 > > > > Sorry, Carl Eugen > > What's the first version where this works? We could bump the minimum > required version. It would also let us remove a considerable amount of > ifdeffery. > > Debian Oldstable has a libvpx 1.6.1 package in the official backports > repository, and Ubuntu Xenial (oldest LTS) ships with 1.5.0. And if it > was added after those, an argument could also be made that if you're > compiling latest ffmpeg you can also compile its popular dependencies. > Not to mention libvpx is a library that's best to have as up to date as > possible. FWIW, RHEL6 and RHEL7 (and derivatives) have libvpx-1.3.0. Fedora has 1.7.0 and will likely upgrade to the just released 1.8.0. Regards, -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
On Thu, Feb 7, 2019, at 12:49 PM, Carl Eugen Hoyos wrote: > > This sounds like a strong reason not to add it to an FFmpeg > repository: It was claimed in the past that I am the only one > not supporting releases but the same was now repeated by > other developers. We can simply provide a note that recommends using git master by instructing the user to include the homebrew --HEAD option. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option
2019-02-07 21:21 GMT+01:00, James Almer : > On 2/7/2019 5:08 PM, Carl Eugen Hoyos wrote: >> 2019-02-07 20:57 GMT+01:00, James Almer : >>> On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote: Hi! Lossless libvpx encoding is possible with "-crf 0". >>> >>> Does that work with all supported versions, or was it a recent change? >> >> No, it needs a newer version than 1.4.0 >> >> Sorry, Carl Eugen > > What's the first version where this works? It works with 1.6.0 but not with 1.5.0. > We could bump the minimum required version. It would > also let us remove a considerable amount of ifdeffery. > > Debian Oldstable has a libvpx 1.6.1 package in the official backports > repository, and Ubuntu Xenial (oldest LTS) ships with 1.5.0. And if it > was added after those, an argument could also be made that if you're > compiling latest ffmpeg you can also compile its popular dependencies. > Not to mention libvpx is a library that's best to have as up to date as > possible. No strong opinion here, I hadn't realized that -crf 0 only works with newer versions. Can you explain why crf alone has no effect and needs -b:v 0? Isn't this a bug both with libvpx and libaom? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Do not print the character coding as part of service name
2019-02-07 21:40 GMT+01:00, Marton Balint :
>
>
> On Thu, 7 Feb 2019, Carl Eugen Hoyos wrote:
>
>> 2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
>>> On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
+if (p[0] < 0x20) {
+p++;
+if (--len < 0)
+return NULL;
+}
>>>
>>> If I understand section "A.2 Selection of character table" of ETSI EN
>>> 300 468 correctly, you need to drop an additional byte if the first
>>> byte (p[0]) is 0x1F, or an additional two bytes if the first one is
>>> 0x10.
>>
>> New patch attached.
>
> Don't simply drop charset information.
> You should convert the strings to UTF-8 based on that.
(Yes we should)
Do you have a sample that needs this?
If not, a patch that fixes a user-reported issue would rot
because a better (unneeded) fix is possible.
Carl Eugen
___
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-07 21:32 GMT+01:00, Werner Robitza : > On Thu, Feb 7, 2019 at 8:50 PM Carl Eugen Hoyos wrote: >> Please send an initial version of the formula > > Sure! Attached to this email. > >> please understand >> that since we do not offer release support, release builds can't >> be the default. > > Homebrew always points to release versions This sounds like a strong reason not to add it to an FFmpeg repository: It was claimed in the past that I am the only one not supporting releases but the same was now repeated by other developers. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
2019-02-07 22:15 GMT+01:00, Gyan : > I don't see other h264 decoders, as used within ffmpeg, exporting CC > side-data, e.g. OpenH264 or QSV. Do they provide it? > (I do see native hevc doing so, as well as the Decklink indev , but not > mentioned here.) Seems like a good reason to remove the useless information. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
On 08-02-2019 01:39 AM, Carl Eugen Hoyos wrote:
2019-02-07 21:07 GMT+01:00, Gyan :
On 08-02-2019 01:18 AM, Carl Eugen Hoyos wrote:
2019-02-07 20:16 GMT+01:00, Mathieu Duponchelle :
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the
sequence
display extension
indicating the source of the video pictures. The default is
@samp{unspecified},
can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or
@samp{mac}.
For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into
output.
+Only the mpeg2 and h264 decoders provide these.
Sorry for the late comment:
This is not a helpful sentence imo, many features are not provided
by all parts of FFmpeg and it is (too) difficult to keep such lists
up-to-date.
Which other decoder are you thinking about?
Let it remain. It is informative
How is it informative?
Which other decoders are you thinking about?
I don't see other h264 decoders, as used within ffmpeg, exporting CC
side-data, e.g. OpenH264 or QSV.
(I do see native hevc doing so, as well as the Decklink indev , but not
mentioned here.)
Full coverage is difficult, but that shouldn't be used as a reason to
suppress any coverage.
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
On Thu, Feb 7, 2019 at 9:29 PM Michael Niedermayer wrote: > I can setup a repo on github and or on git.ffmpeg.org (where ffmpeg-web is) > https://github.com/FFmpeg/web currently is a mirror of git.ffmpeg.org > assuming there is consensus that such a thing should be created GitHub would be preferred since that allows the user to simply run: brew tap-pin ffmpeg/ffmpeg brew install ffmpeg See also: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap > Its important that someone maintains this though, that is for example > someone needs to take care of reported bugs. Yes, that is absolutely clear. I think that bugs will reflect either general build errors that should be discussed here or posted on trac, or bugs in third party libraries (e.g., x265 breaking an ffmpeg build), or those which are related to Homebrew, which should be posted on their issue tracker. > It was not mentioned in this thread but i think it should be clear that > if this ends up not being maintained (well) then we should remove it again. That would be the best solution, rather than providing something that doesn't work (well). > Also we should aim toward having a good relation with everyone who > maintains a different solution. > The way i see it this is being created out of a technical need (the > removial of easy user configuration support) > Iam just saying this as ffmpeg-devel has sometimes been a bit toxic. > I think we should make double sure this does not degenerate into some > sort of hostile fork ... The idea would really be to to provide a clean formula the way it was before Homebrew removed all the options. This would also reflect what we're recommending people to do in the compilation guides (https://trac.ffmpeg.org/wiki/CompilationGuide/). The good thing about taps is that everyone can create a formula for their own needs, and it is my understanding that people may want to keep a formula that installs all dependencies by default, or have some special build flags. So I don't see a potential issue with "hostile forks". > and i probably should also say that i do not know exactly who maintains > which alternative where ... Until now, not many, since there was no real need for it. Now this need has suddenly come up, hence my initiative to provide a single good source rather than having users do a web search for whatever formula might work. Thanks for your thoughts – good points. Werner ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Do not print the character coding as part of service name
On Thu, 7 Feb 2019, Carl Eugen Hoyos wrote:
2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
+if (p[0] < 0x20) {
+p++;
+if (--len < 0)
+return NULL;
+}
If I understand section "A.2 Selection of character table" of ETSI EN
300 468 correctly, you need to drop an additional byte if the first
byte (p[0]) is 0x1F, or an additional two bytes if the first one is
0x10.
New patch attached.
Don't simply drop charset information. You should convert the strings to
UTF-8 based on that. Mpegts encoding needs updating too to be able to keep
the international characters in case of stream copy...
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
On Thu, Feb 7, 2019 at 8:50 PM Carl Eugen Hoyos wrote:
> Please send an initial version of the formula
Sure! Attached to this email.
> please understand
> that since we do not offer release support, release builds can't
> be the default.
Homebrew always points to release versions, the latest one being 4.1
for the official ffmpeg formula. There is an option --HEAD that
fetches the latest Git version though. See
https://docs.brew.sh/Manpage#install-options-formula
--
class Ffmpeg < Formula
desc "Play, record, convert, and stream audio and video"
homepage "https://ffmpeg.org/";
url "https://ffmpeg.org/releases/ffmpeg-4.1.tar.xz";
sha256 "a38ec4d026efb58506a99ad5cd23d5a9793b4bf415f2c4c2e9c1bb444acd1994"
version "4.1-custom"
head "https://github.com/FFmpeg/FFmpeg.git";
option "with-aom", "Enable AV1 video codec"
option "with-chromaprint", "Enable the Chromaprint audio
fingerprinting library"
option "with-fdk-aac", "Enable the Fraunhofer FDK AAC library"
option "with-libass", "Enable ASS/SSA subtitle format"
option "with-librsvg", "Enable SVG files as inputs via librsvg"
option "with-libsoxr", "Enable the soxr resample library"
option "with-libssh", "Enable SFTP protocol via libssh"
option "with-libvidstab", "Enable vid.stab support for video stabilization"
option "with-libvmaf", "Enable libvmaf scoring library"
option "with-opencore-amr", "Enable Opencore AMR NR/WB audio format"
option "with-openh264", "Enable OpenH264 library"
option "with-openjpeg", "Enable JPEG 2000 image format"
option "with-openssl", "Enable SSL support"
option "with-rtmpdump", "Enable RTMP protocol"
option "with-rubberband", "Enable rubberband library"
option "with-srt", "Enable SRT library"
option "with-tesseract", "Enable the tesseract OCR engine"
option "with-webp", "Enable using libwebp to encode WEBP images"
option "with-zeromq", "Enable using libzeromq to receive commands
sent through a libzeromq client"
option "with-zimg", "Enable z.lib zimg library"
depends_on "nasm" => :build
depends_on "pkg-config" => :build
depends_on "texi2html" => :build
depends_on "lame"
depends_on "libvorbis"
depends_on "libvpx"
depends_on "opus"
depends_on "sdl2"
depends_on "snappy"
depends_on "theora"
depends_on "x264"
depends_on "x265"
depends_on "xvid"
depends_on "xz"
depends_on "aom" => :optional
depends_on "chromaprint" => :optional
depends_on "fdk-aac" => :optional
depends_on "fontconfig" => :optional
depends_on "freetype" => :optional
depends_on "frei0r" => :optional
depends_on "game-music-emu" => :optional
depends_on "libass" => :optional
depends_on "libbluray" => :optional
depends_on "libbs2b" => :optional
depends_on "libcaca" => :optional
depends_on "libgsm" => :optional
depends_on "libmodplug" => :optional
depends_on "librsvg" => :optional
depends_on "libsoxr" => :optional
depends_on "libssh" => :optional
depends_on "libvidstab" => :optional
depends_on "libvmaf" => :optional
depends_on "opencore-amr" => :optional
depends_on "openh264" => :optional
depends_on "openjpeg" => :optional
depends_on "openssl" => :optional
depends_on "rtmpdump" => :optional
depends_on "rubberband" => :optional
depends_on "speex" => :optional
depends_on "srt" => :optional
depends_on "tesseract" => :optional
depends_on "two-lame" => :optional
depends_on "wavpack" => :optional
depends_on "webp" => :optional
depends_on "zeromq" => :optional
depends_on "zimg" => :optional
def install
args = %W[
--prefix=#{prefix}
--enable-shared
--enable-pthreads
--enable-version3
--enable-hardcoded-tables
--enable-avresample
--cc=#{ENV.cc}
--host-cflags=#{ENV.cflags}
--host-ldflags=#{ENV.ldflags}
--enable-ffplay
--enable-gpl
--enable-libmp3lame
--enable-libopus
--enable-libsnappy
--enable-libtheora
--enable-libvorbis
--enable-libvpx
--enable-libx264
--enable-libx265
--enable-libxvid
--enable-lzma
--disable-libjack
--disable-indev=jack
]
args << "--enable-chromaprint" if build.with? "chromaprint"
args << "--enable-frei0r" if build.with? "frei0r"
args << "--enable-libaom" if build.with? "aom"
args << "--enable-libass" if build.with? "libass"
args << "--enable-libbluray" if build.with? "libbluray"
args << "--enable-libbs2b" if build.with? "libbs2b"
args << "--enable-libcaca" if build.with? "libcaca"
args << "--enable-libfdk-aac" if build.with? "fdk-aac"
args << "--enable-libfontconfig" if build.with? "fontconfig"
args << "--enable-libfreetype" if build.with? "freetype"
args << "--enable-libgme" if build.with? "game-music-emu"
args << "--enable-libgsm" if build.with? "libgsm"
args << "--enable-libmodplug" if build.with? "libmodplug"
args << "--enable-libopencore-amrnb" <<
"--enable-libopencore-amrwb" if build.with? "opencore-amr"
args <<
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
On Thu, Feb 07, 2019 at 05:28:10PM +, Derek Buitenhuis wrote: > On 07/02/2019 16:43, Werner Robitza wrote: > > Several people have already volunteered in this thread (Reto, Kyle and > > me), as well as the author of this formula (with whom I've had offline > > discussions), which we can use as a starting point: > > https://github.com/varenc/homebrew-ffmpeg-with-options/blob/master/Formula/ffmpeg.rb > > (mentioned in my original post). > > I haven't seen anyone object to hosting it as a separate repo on our infra, > but I also didn't see anyone who maintains our infra reply... maybe Michael > has opinions. I can setup a repo on github and or on git.ffmpeg.org (where ffmpeg-web is) https://github.com/FFmpeg/web currently is a mirror of git.ffmpeg.org assuming there is consensus that such a thing should be created Its important that someone maintains this though, that is for example someone needs to take care of reported bugs. It was not mentioned in this thread but i think it should be clear that if this ends up not being maintained (well) then we should remove it again. Also we should aim toward having a good relation with everyone who maintains a different solution. The way i see it this is being created out of a technical need (the removial of easy user configuration support) Iam just saying this as ffmpeg-devel has sometimes been a bit toxic. I think we should make double sure this does not degenerate into some sort of hostile fork ... and i probably should also say that i do not know exactly who maintains which alternative where ... Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option
On 2/7/2019 5:08 PM, Carl Eugen Hoyos wrote: > 2019-02-07 20:57 GMT+01:00, James Almer : >> On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote: >>> Hi! >>> >>> Lossless libvpx encoding is possible with "-crf 0". >> >> Does that work with all supported versions, or was it a recent change? > > No, it needs a newer version than 1.4.0 > > Sorry, Carl Eugen What's the first version where this works? We could bump the minimum required version. It would also let us remove a considerable amount of ifdeffery. Debian Oldstable has a libvpx 1.6.1 package in the official backports repository, and Ubuntu Xenial (oldest LTS) ships with 1.5.0. And if it was added after those, an argument could also be made that if you're compiling latest ffmpeg you can also compile its popular dependencies. Not to mention libvpx is a library that's best to have as up to date as possible. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
2019-02-07 21:07 GMT+01:00, Gyan :
>
>
> On 08-02-2019 01:18 AM, Carl Eugen Hoyos wrote:
>> 2019-02-07 20:16 GMT+01:00, Mathieu Duponchelle :
>>> ---
>>> doc/encoders.texi | 3 +++
>>> libavcodec/mpeg12enc.c | 31 +++
>>> libavcodec/mpegvideo.h | 2 ++
>>> 3 files changed, 36 insertions(+)
>>>
>>> diff --git a/doc/encoders.texi b/doc/encoders.texi
>>> index e86ae69cc5..378a2ca8eb 100644
>>> --- a/doc/encoders.texi
>>> +++ b/doc/encoders.texi
>>> @@ -2574,6 +2574,9 @@ Specifies the video_format written into the
>>> sequence
>>> display extension
>>> indicating the source of the video pictures. The default is
>>> @samp{unspecified},
>>> can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or
>>> @samp{mac}.
>>> For maximum compatibility, use @samp{component}.
>>> +@item a53cc @var{boolean}
>>> +Import closed captions (which must be ATSC compatible format) into
>>> output.
>>> +Only the mpeg2 and h264 decoders provide these.
>> Sorry for the late comment:
>> This is not a helpful sentence imo, many features are not provided
>> by all parts of FFmpeg and it is (too) difficult to keep such lists
>> up-to-date.
>> Which other decoder are you thinking about?
>>
> Let it remain. It is informative
How is it informative?
Which other decoders are you thinking about?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option
2019-02-07 20:57 GMT+01:00, James Almer : > On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote: >> Hi! >> >> Lossless libvpx encoding is possible with "-crf 0". > > Does that work with all supported versions, or was it a recent change? No, it needs a newer version than 1.4.0 Sorry, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
On 08-02-2019 01:18 AM, Carl Eugen Hoyos wrote:
2019-02-07 20:16 GMT+01:00, Mathieu Duponchelle :
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
display extension
indicating the source of the video pictures. The default is
@samp{unspecified},
can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or
@samp{mac}.
For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these.
Sorry for the late comment:
This is not a helpful sentence imo, many features are not provided
by all parts of FFmpeg and it is (too) difficult to keep such lists up-to-date.
Which other decoder are you thinking about?
Let it remain. It is informative, and an extremely short list. Can be
updated as needed.
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4] mpeg12enc: Use Closed Captions if available
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..a283b9fddf 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
display extension
indicating the source of the video pictures. The default is @samp{unspecified},
can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Default is 1 (on).
@end table
@section png
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index d0b458e34b..15a3db9e6d 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
static uint8_t mpeg1_index_run[2][64];
static int8_t mpeg1_max_level[2][64];
+#define A53_MAX_CC_COUNT 0x1f
+
static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
{
int i;
@@ -544,6 +546,35 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int
picture_number)
}
}
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
+side_data = av_frame_get_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_A53_CC);
+if (side_data) {
+if (side_data->size <= A53_MAX_CC_COUNT) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(&s->pb, 8, 'G'); // user_identifier
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+put_bits(&s->pb, 8, 3); //
user_data_type_code
+put_bits(&s->pb, 8,
+(side_data->size / 3 & A53_MAX_CC_COUNT) | 0x40); //
flags, cc_count
+put_bits(&s->pb, 8, 0xff); // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(&s->pb, 8, side_data->data[i]);
+
+put_bits(&s->pb, 8, 0xff); // marker_bits
+} else {
+av_log(s->avctx, AV_LOG_WARNING,
+"Warning Closed Caption size can not exceed 93 bytes\n");
+}
+}
+}
+
s->mb_y = 0;
ff_mpeg1_encode_slice_header(s);
}
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index bbc6b5646a..3e52f98390 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -455,6 +455,7 @@ typedef struct MpegEncContext {
/* MPEG-2-specific - I wished not to have to support this mess. */
int progressive_sequence;
int mpeg_f_code[2][2];
+int a53_cc;
// picture structure defines are loaded from mpegutils.h
int picture_structure;
@@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
{"ps", "RTP payload size in bytes",
FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN,
INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)",
FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 },
INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT,
{.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
+{ "a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
extern const AVOption ff_mpv_generic_options[];
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov.c: require tfhd to begin parsing trun
On 07/02/2019 19:30, Chris Cunningham wrote: > This will reject the file entirely. The testcase I have (can share once > chromium bug is fixed) was previously hitting an av_assert0 in > mov_read_trun, arguably also a total rejection ;). Recovery for this could > be pretty tricky since the dropped trun will break decode dependencies. I > would be surprised to find files with missing tfhd's in the wild (outside > of fuzzer / maliciously crafted sorts). You would be surprised what kind of garbage things can produce... In any case, sounds OK to me. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3] mpeg12enc: Use Closed Captions if available
---
doc/encoders.texi | 5 -
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..2d3cfa3713 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2269,7 +2269,7 @@ ffmpeg -i foo.mpg -c:v libx264 -x264opts
keyint=123:min-keyint=20 -an out.mkv
@item a53cc @var{boolean}
Import closed captions (which must be ATSC compatible format) into output.
-Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
+Default is 1 (on).
@item x264-params (N.A.)
Override the x264 configuration using a :-separated list of key=value
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
display extension
indicating the source of the video pictures. The default is @samp{unspecified},
can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
@end table
@section png
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index d0b458e34b..15a3db9e6d 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
static uint8_t mpeg1_index_run[2][64];
static int8_t mpeg1_max_level[2][64];
+#define A53_MAX_CC_COUNT 0x1f
+
static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
{
int i;
@@ -544,6 +546,35 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int
picture_number)
}
}
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
+side_data = av_frame_get_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_A53_CC);
+if (side_data) {
+if (side_data->size <= A53_MAX_CC_COUNT) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(&s->pb, 8, 'G'); // user_identifier
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+put_bits(&s->pb, 8, 3); //
user_data_type_code
+put_bits(&s->pb, 8,
+(side_data->size / 3 & A53_MAX_CC_COUNT) | 0x40); //
flags, cc_count
+put_bits(&s->pb, 8, 0xff); // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(&s->pb, 8, side_data->data[i]);
+
+put_bits(&s->pb, 8, 0xff); // marker_bits
+} else {
+av_log(s->avctx, AV_LOG_WARNING,
+"Warning Closed Caption size can not exceed 93 bytes\n");
+}
+}
+}
+
s->mb_y = 0;
ff_mpeg1_encode_slice_header(s);
}
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index bbc6b5646a..3e52f98390 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -455,6 +455,7 @@ typedef struct MpegEncContext {
/* MPEG-2-specific - I wished not to have to support this mess. */
int progressive_sequence;
int mpeg_f_code[2][2];
+int a53_cc;
// picture structure defines are loaded from mpegutils.h
int picture_structure;
@@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
{"ps", "RTP payload size in bytes",
FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN,
INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)",
FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 },
INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT,
{.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
+{ "a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
extern const AVOption ff_mpv_generic_options[];
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
On 2/7/19 8:48 PM, Carl Eugen Hoyos wrote: > +Only the mpeg2 and h264 decoders provide these. > Sorry for the late comment: > This is not a helpful sentence imo, many features are not provided > by all parts of FFmpeg and it is (too) difficult to keep such lists > up-to-date. > Which other decoder are you thinking about? This was simply copy pasted from the "libx264, libx264rgb" section (currently l2272), I'll remove it > If you decide to send another version, please remove the > superfluous brackets. Sure ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option
On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote: > Hi! > > Lossless libvpx encoding is possible with "-crf 0". Does that work with all supported versions, or was it a recent change? > > Please comment, Carl Eugen > > > ___ > ffmpeg-devel mailing list > 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] lavc/libvpxenc: Deprecate lossless option
Hi!
Lossless libvpx encoding is possible with "-crf 0".
Please comment, Carl Eugen
From 76e8df1da3470a1232f6128b37a681926d4cab92 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 7 Feb 2019 20:39:12 +0100
Subject: [PATCH] lavc/libvpxenc: Deprecate lossless, there is -crf 0.
---
doc/encoders.texi |2 +-
libavcodec/libvpxenc.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69..9efa015 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1802,7 +1802,7 @@ Template defining the membership of frames to temporal layers.
@item VP9-specific options
@table @option
@item lossless
-Enable lossless mode.
+Deprecated, set the @option{crf} option to 0.
@item tile-columns
Set number of tile columns to use. Note this is given as
@code{log2(tile_columns)}. For example, 8 tile columns would be requested by
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index c823b8a..2ed8a70 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1219,7 +1219,7 @@ static const AVOption vp9_options[] = {
{ "auto-alt-ref","Enable use of alternate reference "
"frames (2-pass only)",OFFSET(auto_alt_ref),AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
{ "cpu-used","Quality/Speed ratio modifier",OFFSET(cpu_used),AV_OPT_TYPE_INT, {.i64 = 1}, -8, 8, VE},
-{ "lossless","Lossless mode", OFFSET(lossless),AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE},
+{ "lossless","Deprecated, use -crf 0", OFFSET(lossless),AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE},
{ "tile-columns","Number of tile columns to use, log2", OFFSET(tile_columns),AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
{ "tile-rows", "Number of tile rows to use, log2",OFFSET(tile_rows), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, VE},
{ "frame-parallel", "Enable frame parallel decodability features", OFFSET(frame_parallel), AV_OPT_TYPE_BOOL,{.i64 = -1}, -1, 1, VE},
--
1.7.10.4
___
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 : > Please let me know your thoughts. Since this may happen: Please send an initial version of the formula, please understand that since we do not offer release support, release builds can't be the default. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
2019-02-07 20:16 GMT+01:00, Mathieu Duponchelle :
> ---
> doc/encoders.texi | 3 +++
> libavcodec/mpeg12enc.c | 31 +++
> libavcodec/mpegvideo.h | 2 ++
> 3 files changed, 36 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e86ae69cc5..378a2ca8eb 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
> display extension
> indicating the source of the video pictures. The default is
> @samp{unspecified},
> can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or
> @samp{mac}.
> For maximum compatibility, use @samp{component}.
> +@item a53cc @var{boolean}
> +Import closed captions (which must be ATSC compatible format) into output.
> +Only the mpeg2 and h264 decoders provide these.
Sorry for the late comment:
This is not a helpful sentence imo, many features are not provided
by all parts of FFmpeg and it is (too) difficult to keep such lists up-to-date.
Which other decoder are you thinking about?
> Default is 1 (on).
> @end table
>
> @section png
> diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
> index d0b458e34b..0e2ab6da47 100644
> --- a/libavcodec/mpeg12enc.c
> +++ b/libavcodec/mpeg12enc.c
> @@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
> static uint8_t mpeg1_index_run[2][64];
> static int8_t mpeg1_max_level[2][64];
>
> +#define A53_MAX_CC_COUNT 0x1f
> +
> static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
> {
> int i;
> @@ -544,6 +546,35 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s,
> int picture_number)
> }
> }
>
> +if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
> +side_data = av_frame_get_side_data(s->current_picture_ptr->f,
> +AV_FRAME_DATA_A53_CC);
> +if (side_data) {
> +if (side_data->size <= A53_MAX_CC_COUNT) {
> +int i = 0;
> +
> +put_header (s, USER_START_CODE);
> +
> +put_bits(&s->pb, 8, 'G'); //
> user_identifier
> +put_bits(&s->pb, 8, 'A');
> +put_bits(&s->pb, 8, '9');
> +put_bits(&s->pb, 8, '4');
> +put_bits(&s->pb, 8, 3); //
> user_data_type_code
> +put_bits(&s->pb, 8,
> +((side_data->size / 3) & A53_MAX_CC_COUNT) | 0x40); //
> flags, cc_count
If you decide to send another version, please remove the
superfluous brackets.
Carl Eugen
___
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 20:26 GMT+01:00, Jan Ekström : > On Thu, Feb 7, 2019 at 3:03 PM Carl Eugen Hoyos wrote: >> Carl Eugen >> (who hopes you can use fieldmatch to watch this...) > > fieldmatch,decimate should be OK for the show itself, but generally I decimate seems unneeded for this specific sample. > am lazy and use yadif for non-encoding (viewing) cases. That makes > sure that all the useless advertising that often is fully interlaced > will also be correctly shown. Of course! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov.c: require tfhd to begin parsing trun
This will reject the file entirely. The testcase I have (can share once chromium bug is fixed) was previously hitting an av_assert0 in mov_read_trun, arguably also a total rejection ;). Recovery for this could be pretty tricky since the dropped trun will break decode dependencies. I would be surprised to find files with missing tfhd's in the wild (outside of fuzzer / maliciously crafted sorts). On Thu, Feb 7, 2019 at 7:58 AM Derek Buitenhuis wrote: > On 07/02/2019 00:12, chcunningham wrote: > > Detecting missing tfhd avoids re-using tfhd track info from the previous > > moof. For files with multiple tracks, this may make a mess of the > > avindex and fragindex, which can later trigger av_assert0 in > > mov_read_trun(). > > --- > > libavformat/isom.h | 1 + > > libavformat/mov.c | 10 ++ > > 2 files changed, 11 insertions(+) > > I think this seems reasonable. > > Is the intent to entirely reject these files, or only the broken parts? > (lack of patch context for how it cascades for me) > > - Derek > ___ > 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] lavf/utils: update default wrap-around reference while iterating streams
On Thu, Feb 7, 2019 at 3:03 PM Carl Eugen Hoyos wrote: > > 2019-02-07 8:18 GMT+01:00, Jan Ekström : > > On Thu, Feb 7, 2019, 02:22 Carl Eugen Hoyos > > >> 2019-02-07 0:57 GMT+01:00, Jan Ekström : > >> > From: Masaki Tanaka > >> > > >> > Seems to fix mistaken cases of discontinuity handling in 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. > > Thank you, I forgot about this switch: The original timestamp issue > is not reproducible with -merge_pmt_versions, right? > Just replicated my tests, and yes you are correct. The change seems to happen because AVPrograms get updated as the programs change, but current wrap reference will not get updated accordingly. The patch seems to help but I am not 100% sure of the logic (given that taking in both very high and low values makes it possible to pick a different reference depending on the order of the streams within the AVProgram). If someone's interested in how I checked (PID 0x121 is the one that pops up first and thus merge_pmt_versions will only export it): 1. vanilla, with AVStream merging: ffprobe pid_switch_sample.ts -select_streams "0#0x121" -show_frames -of json -merge_pmt_versions 1 > 121_track_merged.json 2. vanilla, without AVStream merging: ffprobe pid_switch_sample.ts -select_streams "0#0x121" -show_frames -of json > 121_track.json 3. see the difference with a plotting script located @ http://up-cat.net/p/0f8b428a pts_plotter.py 121_track.json 121_track_merged.json 4. patched, same command as step 2 as 121_track_patched.json or so 5. see the difference with the plotting script pts_plotter.py 121_track.json 121_track_patched.json You can also do the same with PID 111 (the HD PID) with regards to vanilla VS patched. Results are rather similar. > Carl Eugen > (who hopes you can use fieldmatch to watch this...) fieldmatch,decimate should be OK for the show itself, but generally I am lazy and use yadif for non-encoding (viewing) cases. That makes sure that all the useless advertising that often is fully interlaced will also be correctly shown. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] mpeg12enc: Use Closed Captions if available
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
display extension
indicating the source of the video pictures. The default is @samp{unspecified},
can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
@end table
@section png
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index d0b458e34b..0e2ab6da47 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
static uint8_t mpeg1_index_run[2][64];
static int8_t mpeg1_max_level[2][64];
+#define A53_MAX_CC_COUNT 0x1f
+
static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
{
int i;
@@ -544,6 +546,35 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int
picture_number)
}
}
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
+side_data = av_frame_get_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_A53_CC);
+if (side_data) {
+if (side_data->size <= A53_MAX_CC_COUNT) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(&s->pb, 8, 'G'); // user_identifier
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+put_bits(&s->pb, 8, 3); //
user_data_type_code
+put_bits(&s->pb, 8,
+((side_data->size / 3) & A53_MAX_CC_COUNT) | 0x40); //
flags, cc_count
+put_bits(&s->pb, 8, 0xff); // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(&s->pb, 8, side_data->data[i]);
+
+put_bits(&s->pb, 8, 0xff); // marker_bits
+} else {
+av_log(s->avctx, AV_LOG_WARNING,
+"Warning Closed Caption size can not exceed 93 bytes\n");
+}
+}
+}
+
s->mb_y = 0;
ff_mpeg1_encode_slice_header(s);
}
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index bbc6b5646a..3e52f98390 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -455,6 +455,7 @@ typedef struct MpegEncContext {
/* MPEG-2-specific - I wished not to have to support this mess. */
int progressive_sequence;
int mpeg_f_code[2][2];
+int a53_cc;
// picture structure defines are loaded from mpegutils.h
int picture_structure;
@@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
{"ps", "RTP payload size in bytes",
FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN,
INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)",
FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 },
INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT,
{.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
+{ "a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
extern const AVOption ff_mpv_generic_options[];
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
display extension
indicating the source of the video pictures. The default is @samp{unspecified},
can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
@end table
@section png
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index d0b458e34b..0e2ab6da47 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
static uint8_t mpeg1_index_run[2][64];
static int8_t mpeg1_max_level[2][64];
+#define A53_MAX_CC_COUNT 0x1f
+
static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
{
int i;
@@ -544,6 +546,35 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int
picture_number)
}
}
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
+side_data = av_frame_get_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_A53_CC);
+if (side_data) {
+if (side_data->size <= A53_MAX_CC_COUNT) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(&s->pb, 8, 'G'); // user_identifier
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+put_bits(&s->pb, 8, 3); //
user_data_type_code
+put_bits(&s->pb, 8,
+((side_data->size / 3) & A53_MAX_CC_COUNT) | 0x40); //
flags, cc_count
+put_bits(&s->pb, 8, 0xff); // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(&s->pb, 8, side_data->data[i]);
+
+put_bits(&s->pb, 8, 0xff); // marker_bits
+} else {
+av_log(s->avctx, AV_LOG_WARNING,
+"Warning Closed Caption size can not exceed 93 bytes\n");
+}
+}
+}
+
s->mb_y = 0;
ff_mpeg1_encode_slice_header(s);
}
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index bbc6b5646a..3e52f98390 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -455,6 +455,7 @@ typedef struct MpegEncContext {
/* MPEG-2-specific - I wished not to have to support this mess. */
int progressive_sequence;
int mpeg_f_code[2][2];
+int a53_cc;
// picture structure defines are loaded from mpegutils.h
int picture_structure;
@@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
{"ps", "RTP payload size in bytes",
FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN,
INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)",
FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 },
INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT,
{.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
+{ "a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
extern const AVOption ff_mpv_generic_options[];
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
On Thu, Feb 7, 2019, at 8:28 AM, Derek Buitenhuis wrote: > > I haven't seen anyone object to hosting it as a separate repo on our infra, > but I also didn't see anyone who maintains our infra reply... maybe Michael > has opinions. I'm not against it. Seems like it will be helpful to users and I'm certain Werner and the other volunteers will keep it actively maintained. I can setup the repo under our Github organization and give the volunteers access to just that repo. I'll wait a few days and do that if there are no objections. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/tiff: Allow decoding of cmyka (five components)
Hi!
Attached patch fixes ticket #7675.
Please comment, Carl Eugen
From 7c1f5eeb2c266c33f57d8e2b78bacfba3b30a471 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 7 Feb 2019 20:05:10 +0100
Subject: [PATCH] lavc/tiff: Allow decoding of cmyka (five components).
Fixes ticket #7675.
---
libavcodec/tiff.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 112f5b5..aad3934 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -827,6 +827,10 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
case 324:
s->avctx->pix_fmt = s->photometric == TIFF_PHOTOMETRIC_SEPARATED ? AV_PIX_FMT_RGB0 : AV_PIX_FMT_RGBA;
break;
+case 405:
+if (s->photometric == TIFF_PHOTOMETRIC_SEPARATED)
+s->avctx->pix_fmt = AV_PIX_FMT_RGBA;
+break;
case 483:
s->avctx->pix_fmt = s->le ? AV_PIX_FMT_RGB48LE : AV_PIX_FMT_RGB48BE;
break;
@@ -944,7 +948,7 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
s->height = value;
break;
case TIFF_BPP:
-if (count > 4U) {
+if (count > 5U) {
av_log(s->avctx, AV_LOG_ERROR,
"This format is not supported (bpp=%d, %d components)\n",
value, count);
@@ -975,7 +979,7 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
"Samples per pixel requires a single value, many provided\n");
return AVERROR_INVALIDDATA;
}
-if (value > 4U) {
+if (value > 5U) {
av_log(s->avctx, AV_LOG_ERROR,
"Samples per pixel %d is too large\n", value);
return AVERROR_INVALIDDATA;
@@ -1449,10 +1453,19 @@ again:
planes = s->planar ? s->bppcount : 1;
for (plane = 0; plane < planes; plane++) {
+uint8_t *five_planes = NULL;
int remaining = avpkt->size;
int decoded_height;
stride = p->linesize[plane];
dst = p->data[plane];
+if (s->photometric == TIFF_PHOTOMETRIC_SEPARATED &&
+s->avctx->pix_fmt == AV_PIX_FMT_RGBA) {
+stride = stride * 5 / 4;
+five_planes =
+dst = av_malloc(stride * s->height);
+if (!dst)
+return AVERROR(ENOMEM);
+}
for (i = 0; i < s->height; i += s->rps) {
if (i)
dst += s->rps * stride;
@@ -1485,7 +1498,7 @@ again:
av_log(s->avctx, AV_LOG_ERROR, "predictor == 2 with YUV is unsupported");
return AVERROR_PATCHWELCOME;
}
-dst = p->data[plane];
+dst = five_planes ? five_planes : p->data[plane];
soff = s->bpp >> 3;
if (s->planar)
soff = FFMAX(soff / s->bppcount, 1);
@@ -1532,21 +1545,25 @@ again:
}
if (s->photometric == TIFF_PHOTOMETRIC_SEPARATED &&
-s->avctx->pix_fmt == AV_PIX_FMT_RGB0) {
+(s->avctx->pix_fmt == AV_PIX_FMT_RGB0 || s->avctx->pix_fmt == AV_PIX_FMT_RGBA)) {
+int x = s->avctx->pix_fmt == AV_PIX_FMT_RGB0 ? 4 : 5;
+uint8_t *src = five_planes ? five_planes : p->data[plane];
dst = p->data[plane];
for (i = 0; i < s->height; i++) {
for (j = 0; j < s->width; j++) {
-int k = 255 - dst[4 * j + 3];
-int r = (255 - dst[4 * j]) * k;
-int g = (255 - dst[4 * j + 1]) * k;
-int b = (255 - dst[4 * j + 2]) * k;
+int k = 255 - src[x * j + 3];
+int r = (255 - src[x * j]) * k;
+int g = (255 - src[x * j + 1]) * k;
+int b = (255 - src[x * j + 2]) * k;
dst[4 * j] = r * 257 >> 16;
dst[4 * j + 1] = g * 257 >> 16;
dst[4 * j + 2] = b * 257 >> 16;
-dst[4 * j + 3] = 255;
+dst[4 * j + 3] = s->avctx->pix_fmt == AV_PIX_FMT_RGBA ? src[x * j + 4] : 255;
}
+src += stride;
dst += p->linesize[plane];
}
+av_freep(&five_planes);
}
}
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 31 +++
libavcodec/mpegvideo.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
display extension
indicating the source of the video pictures. The default is @samp{unspecified},
can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
@end table
@section png
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index d0b458e34b..0e2ab6da47 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -61,6 +61,8 @@ static uint32_t mpeg1_chr_dc_uni[512];
static uint8_t mpeg1_index_run[2][64];
static int8_t mpeg1_max_level[2][64];
+#define A53_MAX_CC_COUNT 0x1f
+
static av_cold void init_uni_ac_vlc(RLTable *rl, uint8_t *uni_ac_vlc_len)
{
int i;
@@ -544,6 +546,35 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int
picture_number)
}
}
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
+side_data = av_frame_get_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_A53_CC);
+if (side_data) {
+if (side_data->size <= A53_MAX_CC_COUNT) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(&s->pb, 8, 'G'); // user_identifier
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+put_bits(&s->pb, 8, 3); //
user_data_type_code
+put_bits(&s->pb, 8,
+((side_data->size / 3) & A53_MAX_CC_COUNT) | 0x40); //
flags, cc_count
+put_bits(&s->pb, 8, 0xff); // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(&s->pb, 8, side_data->data[i]);
+
+put_bits(&s->pb, 8, 0xff); // marker_bits
+} else {
+av_log(s->avctx, AV_LOG_WARNING,
+"Warning Closed Caption size can not exceed 93 bytes\n");
+}
+}
+}
+
s->mb_y = 0;
ff_mpeg1_encode_slice_header(s);
}
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index bbc6b5646a..3e52f98390 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -455,6 +455,7 @@ typedef struct MpegEncContext {
/* MPEG-2-specific - I wished not to have to support this mess. */
int progressive_sequence;
int mpeg_f_code[2][2];
+int a53_cc;
// picture structure defines are loaded from mpegutils.h
int picture_structure;
@@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
{"ps", "RTP payload size in bytes",
FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN,
INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)",
FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 },
INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT,
{.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
+{ "a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
extern const AVOption ff_mpv_generic_options[];
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
Carl Eugen Hoyos wrote: >The question is what happens if one of the dependencies >in FFmpeg's formula does not work or disappears. Then the formula will be updated accordingly, as this has been done during all the last years. Best regards, Reto ___ 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-07 19:24 GMT+01:00, Reto Kromer : > Gerion Entrup wrote: > >>do the dependencies of the options need to be maintained >>in the repo as well? > > I guess, this is out of the scope of FFmpeg. The question is what happens if one of the dependencies in FFmpeg's formula does not work or disappears. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
> On Feb 7, 2019, at 1:22 PM, Mathieu Duponchelle > wrote: > > > > On 2/7/19 7:21 PM, Devin Heitmueller wrote: >> Isn’t this calculation incorrect? The max cc_count possible is 31 (0x1F), >> hence the max size should be 93. >> > > True that, updating Not to nitpick, but it might also be worthwhile to create some #define such as MAX_CC_COUNT and have the comparison be "MAX_CC_COUNT * 3”. That makes clear where the magic value “91” came from, and the compiler will optimize out the multiply anyway since it’s a constant. Devin --- Devin Heitmueller - LTN Global Communications dheitmuel...@ltnglobal.com > ___ > 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] Proposal: Homebrew tap for FFmpeg
Gerion Entrup wrote: >do the dependencies of the options need to be maintained in the >repo as well? I guess, this is out of the scope of FFmpeg. Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
On 2/7/19 7:21 PM, Devin Heitmueller wrote: > Isn’t this calculation incorrect? The max cc_count possible is 31 (0x1F), > hence the max size should be 93. > True that, updating ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 29 +
libavcodec/mpegvideo.h | 2 ++
3 files changed, 34 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
display extension
indicating the source of the video pictures. The default is @samp{unspecified},
can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
@end table
@section png
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index d0b458e34b..6447e34563 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -544,6 +544,35 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int
picture_number)
}
}
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
+side_data = av_frame_get_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_A53_CC);
+if (side_data) {
+if (side_data->size <= 93) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(&s->pb, 8, 'G'); // user_identifier
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+put_bits(&s->pb, 8, 3); //
user_data_type_code
+put_bits(&s->pb, 8,
+((side_data->size / 3) & 0x1f) | 0x40); // flags, cc_count
+put_bits(&s->pb, 8, 0xff); // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(&s->pb, 8, side_data->data[i]);
+
+put_bits(&s->pb, 8, 0xff); // marker_bits
+} else {
+av_log(s->avctx, AV_LOG_WARNING,
+"Warning Closed Caption size can not exceed 96 bytes\n");
+}
+}
+}
+
s->mb_y = 0;
ff_mpeg1_encode_slice_header(s);
}
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index bbc6b5646a..3e52f98390 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -455,6 +455,7 @@ typedef struct MpegEncContext {
/* MPEG-2-specific - I wished not to have to support this mess. */
int progressive_sequence;
int mpeg_f_code[2][2];
+int a53_cc;
// picture structure defines are loaded from mpegutils.h
int picture_structure;
@@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
{"ps", "RTP payload size in bytes",
FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN,
INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)",
FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 },
INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT,
{.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
+{ "a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
extern const AVOption ff_mpv_generic_options[];
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
> On Feb 7, 2019, at 1:11 PM, Mathieu Duponchelle
> wrote:
> +if (side_data->size <= 96) {
Isn’t this calculation incorrect? The max cc_count possible is 31 (0x1F),
hence the max size should be 93.
> +int i = 0;
> +
> +put_header (s, USER_START_CODE);
> +
> +put_bits(&s->pb, 8, 'G'); //
> user_identifier
> +put_bits(&s->pb, 8, 'A');
> +put_bits(&s->pb, 8, '9');
> +put_bits(&s->pb, 8, '4');
> +put_bits(&s->pb, 8, 3); //
> user_data_type_code
> +put_bits(&s->pb, 8,
> +((side_data->size / 3) & 0x1f) | 0x40); // flags,
> cc_count
> +put_bits(&s->pb, 8, 0xff); // em_data
---
Devin Heitmueller - LTN Global Communications
dheitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
Am Mittwoch, 6. Februar 2019, 21:41:29 CET schrieb Werner Robitza:
> Dear all,
>
> Homebrew has, with its 2.0 release, removed all options for its core
> formulae [1], including ffmpeg. This means users can no longer add
> non-default dependencies that aren't included in the core formula [2].
> 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
Hi,
do the dependencies of the options need to be maintained in the repo as well?
(BTW, the whole option concept seems to be quite similar to use flags in Gentoo
[1].)
Regards,
Gerion
[1]
https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/ffmpeg/ffmpeg-4.1.ebuild
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
On 2/7/19 6:28 PM, Carl Eugen Hoyos wrote: > Should you check here if the size is not bigger than a certain maximum > value ... > >> +int i = 0; >> + >> +put_header (s, USER_START_CODE); >> + >> +put_bits(&s->pb, 8, 'G'); // user_identifier >> +put_bits(&s->pb, 8, 'A'); >> +put_bits(&s->pb, 8, '9'); >> +put_bits(&s->pb, 8, '4'); >> +put_bits(&s->pb, 8, 3); // >> user_data_type_code >> +put_bits(&s->pb, 8, >> +((side_data->size / 3) & 0x1f) | 0x40); // flags, cc_count > ... because of this calculation? Indeed, fixed, attached the updated patch, I'm afraid I'm not entirely familiar with git send-email and the update was posted as an answer to the original post :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 29 +
libavcodec/mpegvideo.h | 2 ++
3 files changed, 34 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
display extension
indicating the source of the video pictures. The default is @samp{unspecified},
can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
@end table
@section png
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index d0b458e34b..b01bdcc591 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -544,6 +544,35 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int
picture_number)
}
}
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
+side_data = av_frame_get_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_A53_CC);
+if (side_data) {
+if (side_data->size <= 96) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(&s->pb, 8, 'G'); // user_identifier
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+put_bits(&s->pb, 8, 3); //
user_data_type_code
+put_bits(&s->pb, 8,
+((side_data->size / 3) & 0x1f) | 0x40); // flags, cc_count
+put_bits(&s->pb, 8, 0xff); // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(&s->pb, 8, side_data->data[i]);
+
+put_bits(&s->pb, 8, 0xff); // marker_bits
+} else {
+av_log(s->avctx, AV_LOG_WARNING,
+"Warning Closed Caption size can not exceed 96 bytes\n");
+}
+}
+}
+
s->mb_y = 0;
ff_mpeg1_encode_slice_header(s);
}
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index bbc6b5646a..3e52f98390 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -455,6 +455,7 @@ typedef struct MpegEncContext {
/* MPEG-2-specific - I wished not to have to support this mess. */
int progressive_sequence;
int mpeg_f_code[2][2];
+int a53_cc;
// picture structure defines are loaded from mpegutils.h
int picture_structure;
@@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
{"ps", "RTP payload size in bytes",
FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN,
INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)",
FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 },
INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT,
{.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
+{ "a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
extern const AVOption ff_mpv_generic_options[];
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
On 07/02/2019 16:43, Werner Robitza wrote: > Several people have already volunteered in this thread (Reto, Kyle and > me), as well as the author of this formula (with whom I've had offline > discussions), which we can use as a starting point: > https://github.com/varenc/homebrew-ffmpeg-with-options/blob/master/Formula/ffmpeg.rb > (mentioned in my original post). I haven't seen anyone object to hosting it as a separate repo on our infra, but I also didn't see anyone who maintains our infra reply... maybe Michael has opinions. I think it's a good idea to have a known 'good' homebrew recipe... I've seen a lot of projects get ... interesting... bugs filed against them that only occurred because of weird ports/homebrew/etc builds. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
2019-02-07 17:08 GMT+01:00, Mathieu Duponchelle :
> ---
> doc/encoders.texi | 3 +++
> libavcodec/mpeg12enc.c | 24
> libavcodec/mpegvideo.h | 2 ++
> 3 files changed, 29 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e86ae69cc5..378a2ca8eb 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
> display extension
> indicating the source of the video pictures. The default is
> @samp{unspecified},
> can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or
> @samp{mac}.
> For maximum compatibility, use @samp{component}.
> +@item a53cc @var{boolean}
> +Import closed captions (which must be ATSC compatible format) into output.
> +Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
> @end table
>
> @section png
> diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
> index d0b458e34b..7cbb5d652f 100644
> --- a/libavcodec/mpeg12enc.c
> +++ b/libavcodec/mpeg12enc.c
> @@ -544,6 +544,30 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s,
> int picture_number)
> }
> }
>
> +if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
> +side_data = av_frame_get_side_data(s->current_picture_ptr->f,
> +AV_FRAME_DATA_A53_CC);
> +if (side_data) {
Should you check here if the size is not bigger than a certain maximum
value ...
> +int i = 0;
> +
> +put_header (s, USER_START_CODE);
> +
> +put_bits(&s->pb, 8, 'G'); // user_identifier
> +put_bits(&s->pb, 8, 'A');
> +put_bits(&s->pb, 8, '9');
> +put_bits(&s->pb, 8, '4');
> +put_bits(&s->pb, 8, 3); //
> user_data_type_code
> +put_bits(&s->pb, 8,
> +((side_data->size / 3) & 0x1f) | 0x40); // flags, cc_count
... because of this calculation?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Server upgrades
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Michael Niedermayer > Sent: Wednesday, February 06, 2019 2:47 AM > To: FFmpeg development discussions and patches > Cc: Reimar Döffinger > Subject: Re: [FFmpeg-devel] Server upgrades > > On Tue, Feb 05, 2019 at 05:03:02PM +, Eoff, Ullysses A wrote: > > > > 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 > Thanks. It is working on my end now. > [...] > -- > 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
On Thu, Feb 7, 2019 at 5:21 PM Derek Buitenhuis wrote: > I guess my question is: Who amongst the devs here wants to write it? Several people have already volunteered in this thread (Reto, Kyle and me), as well as the author of this formula (with whom I've had offline discussions), which we can use as a starting point: https://github.com/varenc/homebrew-ffmpeg-with-options/blob/master/Formula/ffmpeg.rb (mentioned in my original post). Werner ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
On 07/02/2019 08:06, Werner Robitza wrote: >> I don't think that's the suggestion. Separate Github repo belonging to >> the FFmpeg Github organization. > > Correct. No modification in the source tree. I guess my question is: Who amongst the devs here wants to write it? (Not me.) - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpeg12enc: Use Closed Captions if available
---
doc/encoders.texi | 3 +++
libavcodec/mpeg12enc.c | 24
libavcodec/mpegvideo.h | 2 ++
3 files changed, 29 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69cc5..378a2ca8eb 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2574,6 +2574,9 @@ Specifies the video_format written into the sequence
display extension
indicating the source of the video pictures. The default is @samp{unspecified},
can be @samp{component}, @samp{pal}, @samp{ntsc}, @samp{secam} or @samp{mac}.
For maximum compatibility, use @samp{component}.
+@item a53cc @var{boolean}
+Import closed captions (which must be ATSC compatible format) into output.
+Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
@end table
@section png
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index d0b458e34b..7cbb5d652f 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -544,6 +544,30 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int
picture_number)
}
}
+if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
+side_data = av_frame_get_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_A53_CC);
+if (side_data) {
+int i = 0;
+
+put_header (s, USER_START_CODE);
+
+put_bits(&s->pb, 8, 'G'); // user_identifier
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+put_bits(&s->pb, 8, 3); // user_data_type_code
+put_bits(&s->pb, 8,
+((side_data->size / 3) & 0x1f) | 0x40); // flags, cc_count
+put_bits(&s->pb, 8, 0xff); // em_data
+
+for (i = 0; i < side_data->size; i++)
+put_bits(&s->pb, 8, side_data->data[i]);
+
+put_bits(&s->pb, 8, 0xff); // marker_bits
+}
+}
+
s->mb_y = 0;
ff_mpeg1_encode_slice_header(s);
}
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index bbc6b5646a..3e52f98390 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -455,6 +455,7 @@ typedef struct MpegEncContext {
/* MPEG-2-specific - I wished not to have to support this mess. */
int progressive_sequence;
int mpeg_f_code[2][2];
+int a53_cc;
// picture structure defines are loaded from mpegutils.h
int picture_structure;
@@ -663,6 +664,7 @@ FF_MPV_OPT_CMP_FUNC, \
{"ps", "RTP payload size in bytes",
FF_MPV_OFFSET(rtp_payload_size), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN,
INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepc", "Motion estimation bitrate penalty compensation (1.0 = 256)",
FF_MPV_OFFSET(me_penalty_compensation), AV_OPT_TYPE_INT, {.i64 = 256 },
INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
{"mepre", "pre motion estimation", FF_MPV_OFFSET(me_pre), AV_OPT_TYPE_INT,
{.i64 = 0 }, INT_MIN, INT_MAX, FF_MPV_OPT_FLAGS }, \
+{ "a53cc", "Use A53 Closed Captions (if available)", FF_MPV_OFFSET(a53_cc),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FF_MPV_OPT_FLAGS }, \
extern const AVOption ff_mpv_generic_options[];
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov.c: require tfhd to begin parsing trun
On 07/02/2019 00:12, chcunningham wrote: > Detecting missing tfhd avoids re-using tfhd track info from the previous > moof. For files with multiple tracks, this may make a mess of the > avindex and fragindex, which can later trigger av_assert0 in > mov_read_trun(). > --- > libavformat/isom.h | 1 + > libavformat/mov.c | 10 ++ > 2 files changed, 11 insertions(+) I think this seems reasonable. Is the intent to entirely reject these files, or only the broken parts? (lack of patch context for how it cascades for me) - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Do not print the character coding as part of service name
2019-02-07 16:34 GMT+01:00, Moritz Barsnick :
> On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
>> +if (p[0] < 0x20) {
>> +p++;
>> +if (--len < 0)
>> +return NULL;
>> +}
>
> If I understand section "A.2 Selection of character table" of ETSI EN
> 300 468 correctly, you need to drop an additional byte if the first
> byte (p[0]) is 0x1F, or an additional two bytes if the first one is
> 0x10.
New patch attached.
Thank you, Carl Eugen
From a63c53bc224b6a1d53197e3dafd2ec9c6097d3c0 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 7 Feb 2019 16:45:19 +0100
Subject: [PATCH] lavf/mpegts: Do not print the character coding as part of
service name.
Fixes ticket #6320.
---
libavformat/mpegts.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b04fd7b..f161c0f 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -674,6 +674,18 @@ static char *getstr8(const uint8_t **pp, const uint8_t *p_end)
return NULL;
if (len > p_end - p)
return NULL;
+if (*p < 0x20) {
+if (*p == 0x10) {
+p += 2;
+len -= 2;
+} else if (*p == 0x1f) {
+p++;
+len--;
+}
+p++;
+if (--len < 0)
+return NULL;
+}
str = av_malloc(len + 1);
if (!str)
return NULL;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Do not print the character coding as part of service name
On Thu, Feb 07, 2019 at 14:40:40 +0100, Carl Eugen Hoyos wrote:
> +if (p[0] < 0x20) {
> +p++;
> +if (--len < 0)
> +return NULL;
> +}
If I understand section "A.2 Selection of character table" of ETSI EN
300 468 correctly, you need to drop an additional byte if the first
byte (p[0]) is 0x1F, or an additional two bytes if the first one is
0x10.
Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/mpegts: Do not print the character coding as part of service name
Hi!
Attached patch fixes ticket #6320 as reported.
Please comment, Carl Eugen
From 6a26ae786194275242de8870d2de3dad6c740405 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 7 Feb 2019 14:37:48 +0100
Subject: [PATCH] lavf/mpegts: Do not print the character coding as part of
service name.
Fixes ticket #6320.
---
libavformat/mpegts.c |5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b04fd7b..18130aa 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -674,6 +674,11 @@ static char *getstr8(const uint8_t **pp, const uint8_t *p_end)
return NULL;
if (len > p_end - p)
return NULL;
+if (p[0] < 0x20) {
+p++;
+if (--len < 0)
+return NULL;
+}
str = av_malloc(len + 1);
if (!str)
return NULL;
--
1.7.10.4
___
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 8:18 GMT+01:00, Jan Ekström : > On Thu, Feb 7, 2019, 02:22 Carl Eugen Hoyos >> 2019-02-07 0:57 GMT+01:00, Jan Ekström : >> > From: Masaki Tanaka >> > >> > Seems to fix mistaken cases of discontinuity handling in MPEG-TS >> > when program structure changes. >> > >> > Additional changes 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. Thank you, I forgot about this switch: The original timestamp issue is not reproducible with -merge_pmt_versions, right? Carl Eugen (who hopes you can use fieldmatch to watch this...) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
On Thu, Feb 7, 2019 at 9:18 AM Reto Kromer wrote: > I guess the discussion is "only" on: should this happen inside > or outside the official FFmpeg. My personal preference would be > inside. Yes, that was the main point – I see others have this preference as well. And several people have already volunteered to help maintain this formula. Thank you for the feedback so far! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
>>On Wed, Feb 6, 2019 at 9:51 PM Carl Eugen Hoyos >>wrote: >>>We already provide a build script and we believe that it works very >>>well, in addition a kind supporter offers osx binaries. >> >>That's all true, but not all users want to build manually (or have the >>technical skills to 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. > >In addition, I would like to add that the version 2 of Homebrew works not only >on macOS, but also on Linux and even on Windows running Linux. The >proposal >made would offer again an easy way to install a parametrable FFmpeg to the end >user. > >I guess the discussion is "only" on: should this happen inside or outside the >official FFmpeg. My personal preference would be inside. > >Hoping this is useful! Reto Just wondering, can it cross-compile ffmpeg under linux/ming64 for target win10x64 ? ___ 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] Proposal: Homebrew tap for FFmpeg
Werner Robitza wrote: >On Wed, Feb 6, 2019 at 9:51 PM Carl Eugen Hoyos > wrote: >>We already provide a build script and we believe that it works >>very well, in addition a kind supporter offers osx binaries. > >That's all true, but not all users want to build manually (or >have the technical 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. In addition, I would like to add that the version 2 of Homebrew works not only on macOS, but also on Linux and even on Windows running Linux. The proposal made would offer again an easy way to install a parametrable FFmpeg to the end user. I guess the discussion is "only" on: should this happen inside or outside the official FFmpeg. My personal preference would be inside. Hoping this is useful! Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
On Wed, Feb 6, 2019 at 10:51 PM Kyle Swanson wrote: > On Wed, Feb 6, 2019 at 1:43 PM Helmut K. C. Tessarek > wrote: > > Anyhow, I don't think that adding a formula to the ffmpeg src tree is > > the right approach. > > I don't think that's the suggestion. Separate Github repo belonging to > the FFmpeg Github organization. Correct. No modification in the source tree. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
