Re: [FFmpeg-devel] [PATCH 2/4] avformat/mpegtsenc: add support for setting PCR interval for VBR streams
Hi Marton,
Very good work with your series of patches on the mpegtsenc!
‐‐‐ Original Message ‐‐‐
On Thursday, 15 de August de 2019 1:51, Marton Balint wrote:
> Also document the algorithm for the default PCR interval.
> [...]
> + if (ts->mux_rate > 1 || ts->pcr_period_ms >= 0) {
> + int pcr_period_ms = ts->pcr_period_ms == -1 ? PCR_RETRANS_TIME :
> ts->pcr_period_ms;
> + ts_st->pcr_period = av_rescale(pcr_period_ms, PCR_TIME_BASE, 1000);
> } else {
> /* For VBR we select the highest multiple of frame duration which is less
> than 100 ms. */
A simple aesthetic comment:
Please, change this to...
/* By default, for VBR we select the highest multiple of frame duration which
is less than 100 ms. */
Regards.
A.H.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv2 5/6] avformat/mpegtsenc: fix PCR generation intervals
Hi Marton, ‐‐‐ Original Message ‐‐‐ On Wednesday, 14 de August de 2019 23:31, Marton Balint wrote: > I pushed this series, will post the patch which enables setting pcr period > for VBR. Great! I'll prepare my updated interleaved patch. Regards. A.H. --- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] libavcodec: add timeshift bitstream filter [v3]
Hi, ‐‐‐ Original Message ‐‐‐ On Saturday, 10 de August de 2019 20:05, Andreas Håkon wrote: > Hi Gyan and Nicolas, > > ‐‐‐ Original Message ‐‐‐ > On Saturday, 10 de August de 2019 17:13, Nicolas George geo...@nsup.org wrote: > > > Gyan (12019-08-10): > > > > > Since both pts and dts are altered, avoid pts only labels. > > > > Dissenting opinion: PTS is the important thing, and there are lot of > > places where we says PTS because TS is ambiguous (Transport Stream?). > > DTS is just an annoying technical tidbit that goes with PTS. > > Regards, > > I agree with Nicolas: the change of the DTS value is a consequence of changing > the PTS value, as the second is correlated with the first. It doesn't have > sense > to change only one (at least, as far as a bitstream filter is concerned). > > So my preference is to overcome "TS" in the name of this filter. > > In any case, I prefer to listening more comments from others: "timeshift", > "pts_offest" or "editpts"? > I finally chose to use the name "editpts". I'll post the final patch soon. Regards. A.H. --- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avutil: Add Simple loop detector
On Wed, Aug 14, 2019 at 10:46:19PM +0200, Lynne wrote: > Aug 14, 2019, 19:29 by mich...@niedermayer.cc: > > > On Tue, Aug 13, 2019 at 12:11:30PM +0200, Lynne wrote: > > > >> Aug 12, 2019, 20:53 by mich...@niedermayer.cc: > >> > >> > On Sun, Aug 11, 2019 at 08:30:51PM +0200, Reimar Döffinger wrote: > >> > > >> >> On 08.08.2019, at 10:36, Michael Niedermayer > >> >> wrote: > >> >> > >> >> > This provides an alternative to retry counters. > >> >> > Useful if there is no reasonable maximum number of iterations and > >> >> > no ordering that naturally avoids loops. > >> >> > >> >> Going by the old principle of "an API is not tested until it has at > >> >> least 3 users" > >> >> might it make sense to delay this until we've found and tested it in a > >> >> few use-cases? > >> >> Depending on how much hurry there is to get the bug-fix in. > >> >> > >> >> I assume there is also an actual bug-fix patch somewhere, maybe we > >> >> should have that > >> >> in the same patch series to make it easier to review the actual usage? > >> >> > >> > > >> > sure will repost this eventually with 3+ bugfixes. > >> > But wont search for such bugs ATM as ive too many other things to do > >> > so it might take a bit of time before i do > >> > > >> > > >> >> > >> >> > diff --git a/doc/APIchanges b/doc/APIchanges > >> >> > index 6603a8229e..eee4c30ec5 100644 > >> >> > --- a/doc/APIchanges > >> >> > +++ b/doc/APIchanges > >> >> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21 > >> >> > > >> >> > API changes, most recent first: > >> >> > > >> >> > +2019-XX-XX - XX - lavu 56.XX.XXX - loop_detector.h > >> >> > + Add loop_detector.h, av_is_loop(), AVSimpleLoopDetector > >> >> > >> >> Does is mean it is a public/installed header? > >> >> > >> > > >> > that was intended, but it can of course be trivially be kept local if > >> > people > >> > prefer when i repost with 3+ dependant fixes > >> > > >> > >> You are ignoring 2 developers, and this isn't the first time you're doing > >> this, nor even the second. > >> I still do no think even with 3 bugfixes this deserves to be in lavu but > >> rather in every library as a non-installed header, at the very most. I > >> still prefer for code to be duplicated for such a small amount of fixes. > >> Iit could encourage other developers to put this in their code when it > >> isn't needed when a properly written loop would never go infinite. > >> And, regardless where this code goes, its still as its been pointed out, a > >> hack. > >> > > > > why are you agressive ? > > > > I can't find a single hint of aggression in my email. I'm being direct and > factual. > If you see this as aggression you shouldn't read any specifications or > reports, you'll find yourself very offended. What i refered to as agressive is "You are ignoring 2 developers, and this isn't the first time you're doing this, nor even the second." Lets look at this claim by claim "You are ignoring 2 developers" I do not, i noted that 2 people dislike this patch and i will eventually post a new patchset. If that is still disliked by 2 then we need to look at what the oppinion of the 2 people will be exactly about that new patchset. The 2 developers have not seen a not yet written patchset only thing really known is who the author of the patchset will be. "and this isn't the first time you're doing this, nor even the second." This is a simple ad hominem attack, we know who you speak of (me) but noone can know what issues you talk about so noone can verify this or correct or improve anything. "its still as its been pointed out, a hack." If you see some issue in the code you should explain what issue that is and not just call the code a "hack". Because noone knows what you refer to and there is nothing that can be done about issues that noone knows what they refer to. Another example of aggression from you is (IRC from a few hours ago) irc logs off? irc logs off. carl not here? carl not here. nicolas is an awful person who disagrees with everything and does no work like ever, yet hangs around the ml to be obnoxious his opinions on asserts should disqualify him from working on any library ever add reimar to that list I'll remove that assert if I push that patch, just because maybe he'll fuck off then they only work toward covering michael reimar does, nickolas is just there to misunderstand and be annoying and demanding just stop these attacks/insults against people. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavf/tls_gnutls: check for interrupt inside handshake loop
fixes #8080
Signed-off-by: Błażej Szczygieł
---
libavformat/tls_gnutls.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index f32bc2821b..f507b7d044 100644
--- a/libavformat/tls_gnutls.c
+++ b/libavformat/tls_gnutls.c
@@ -184,6 +184,10 @@ static int tls_open(URLContext *h, const char *uri, int
flags, AVDictionary **op
gnutls_priority_set_direct(p->session, "NORMAL", NULL);
do {
ret = gnutls_handshake(p->session);
+if (ff_check_interrupt(&h->interrupt_callback)) {
+ret = AVERROR_EXIT;
+goto fail;
+}
if (gnutls_error_is_fatal(ret)) {
ret = print_tls_error(h, ret);
goto fail;
--
2.22.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 11/11] avformat/internal: Remove packet for extract_extradata
On Fri, Aug 16, 2019 at 5:22 AM Andreas Rheinhardt wrote: > > The effective lifetime of the packet does not extend beyond the > extract_extradata in libavformat/utils.c, so the packet can simply be > put on the stack there. This allows to remove the allocation and the > corresponding frees. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/internal.h | 1 - > libavformat/utils.c| 10 +- > 2 files changed, 1 insertion(+), 10 deletions(-) > AVPacket is defined in avcodec, as such using it outside of avcodec on the stack feels rather iffy, as we try to get users to stop doing that and unlock the size of AVPacket from the ABI. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] irc logs mailing list ffmpeg-devel-irc
Hi all as some noticed there are missing logs on the ffmpeg-devel-irc archives. And it seemed some people on IRC think there is no logging. I just want to confirm that the IRC topic is accurate and the channels are logged. The only problem that iam aware of is a problem between the logger and the mailing list archieve (related to the used mail account and the logs being identified as spam) Once this is fixed it is possible that all the missing logs will appear in the archieves. Thanks PS: the logger bot is run by Mladen B. so if it starts working again he deserves the praise for working around the spam misdetection issue. -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [REQUEST] ffmpeg-security subscription
On Fri, Aug 16, 2019 at 3:39 AM Reimar Döffinger wrote: > > > On 15.08.2019, at 19:38, Paul B Mahol wrote: > > > On Thu, Aug 15, 2019 at 7:20 PM Reimar Döffinger < > reimar.doeffin...@gmx.de> > > wrote: > > > >> On 15.08.2019, at 13:15, Vittorio Giovara > >> wrote: > >>> I think being on the security list may have some professional > >> implications > >>> too: if you use ffmpeg in your $dayjob, being notified of security > >> problem > >>> in ffmpeg, and acting upon it before the fix lands in the tree, may be > >>> crucial. I think Paul is lamenting the fact that being selected for the > >>> security list is extremely arbitrary and there is no process described > on > >>> how to joining it. > >> > >> Sorry, but just any $dayjob I really don't see relevant at all. > >> If there is a huge user of AND major contributor to FFmpeg with vastly > >> higher risk of attack that is hard to mitigate in any other way they > might > >> have an argument. I.e. if there is a NEED because it is the only way to > >> protect a significant user/number of users. > >> But it still most likely is a misuse. The security list is about > receiving > >> reports and responding to it from our side. > >> Using it to forewarn users would either mean letting a large number of > >> people on it (I hope we agree that is obviously stupid) or > disadvantaging > > >> 99% of our users. > >> If someone has concerns in this area and I'm sure there's ways for them > to > >> contribute. > >> I still don't see it would need access to the security list though, but > it > >> might lead to being invited. > >> > >> Of course this is just my opinion and I am happy to learn: > >> are there other projects describing such a process? > >> For the Linux kernel I only know about such a thing for the list that is > >> for communicating and aligning with distributions. > >> Something comparable does not currently exist for FFmpeg. > >> > > > > So you, as developer are higher valued and more useful than other > > developers? > > I have no idea where you get that from anything I said, do you think the > bus driver is higher valued and more useful than anyone else on the bus > because they don't let just anyone who wants drive it? > Thank you for confirming that you are discriminatory against other developers. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/http: Fixes #7975. Before reusing the connection the headers are checked to see if the server is closing the connection.
On Thu, Aug 15, 2019 at 05:14:38PM -0500, Ian Klassen wrote: > Hi, > > Sorry Moritz, I somehow missed your feedback. Here's an updated patch with > the fixed formatting. I also set up a server that you can test with. Try: > > ffmpeg -i test.mp4 -hls_flags +append_list -hls_time 6 -method PUT > -http_persistent 1 http://45.33.124.115/stream.m3u8 > > The server has persistent connections turned off so you'll see the errors > appear but they should be resolved once you apply the patch. > > Thanks. > > Ian > > --- > libavformat/http.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/libavformat/http.c b/libavformat/http.c > index 579debc..dcbd33a 100644 > --- a/libavformat/http.c > +++ b/libavformat/http.c > @@ -332,15 +332,22 @@ int ff_http_do_new_request(URLContext *h, const char > *uri) this patch looks corrupted by line breaks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avutil: Add Simple loop detector
On Fri, Aug 16, 2019 at 10:35 AM Michael Niedermayer wrote: > On Wed, Aug 14, 2019 at 10:46:19PM +0200, Lynne wrote: > > Aug 14, 2019, 19:29 by mich...@niedermayer.cc: > > > > > On Tue, Aug 13, 2019 at 12:11:30PM +0200, Lynne wrote: > > > > > >> Aug 12, 2019, 20:53 by mich...@niedermayer.cc: > > >> > > >> > On Sun, Aug 11, 2019 at 08:30:51PM +0200, Reimar Döffinger wrote: > > >> > > > >> >> On 08.08.2019, at 10:36, Michael Niedermayer > wrote: > > >> >> > > >> >> > This provides an alternative to retry counters. > > >> >> > Useful if there is no reasonable maximum number of iterations and > > >> >> > no ordering that naturally avoids loops. > > >> >> > > >> >> Going by the old principle of "an API is not tested until it has > at least 3 users" > > >> >> might it make sense to delay this until we've found and tested it > in a few use-cases? > > >> >> Depending on how much hurry there is to get the bug-fix in. > > >> >> > > >> >> I assume there is also an actual bug-fix patch somewhere, maybe we > should have that > > >> >> in the same patch series to make it easier to review the actual > usage? > > >> >> > > >> > > > >> > sure will repost this eventually with 3+ bugfixes. > > >> > But wont search for such bugs ATM as ive too many other things to do > > >> > so it might take a bit of time before i do > > >> > > > >> > > > >> >> > > >> >> > diff --git a/doc/APIchanges b/doc/APIchanges > > >> >> > index 6603a8229e..eee4c30ec5 100644 > > >> >> > --- a/doc/APIchanges > > >> >> > +++ b/doc/APIchanges > > >> >> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21 > > >> >> > > > >> >> > API changes, most recent first: > > >> >> > > > >> >> > +2019-XX-XX - XX - lavu 56.XX.XXX - loop_detector.h > > >> >> > + Add loop_detector.h, av_is_loop(), AVSimpleLoopDetector > > >> >> > > >> >> Does is mean it is a public/installed header? > > >> >> > > >> > > > >> > that was intended, but it can of course be trivially be kept local > if people > > >> > prefer when i repost with 3+ dependant fixes > > >> > > > >> > > >> You are ignoring 2 developers, and this isn't the first time you're > doing this, nor even the second. > > >> I still do no think even with 3 bugfixes this deserves to be in lavu > but rather in every library as a non-installed header, at the very most. I > still prefer for code to be duplicated for such a small amount of fixes. > > >> Iit could encourage other developers to put this in their code when > it isn't needed when a properly written loop would never go infinite. > > >> And, regardless where this code goes, its still as its been pointed > out, a hack. > > >> > > > > > > why are you agressive ? > > > > > > > I can't find a single hint of aggression in my email. I'm being direct > and factual. > > If you see this as aggression you shouldn't read any specifications or > reports, you'll find yourself very offended. > > What i refered to as agressive is > "You are ignoring 2 developers, and this isn't the first time you're doing > this, nor even the second." > > Lets look at this claim by claim > > "You are ignoring 2 developers" > > I do not, i noted that 2 people dislike this patch and i will eventually > post > a new patchset. If that is still disliked by 2 then we need to look at what > the oppinion of the 2 people will be exactly about that new patchset. > The 2 developers have not seen a not yet written patchset only thing really > known is who the author of the patchset will be. > > > "and this isn't the first time you're doing this, nor even the second." > > This is a simple ad hominem attack, we know who you speak of (me) but > noone can > know what issues you talk about so noone can verify this or correct or > improve > anything. > > > "its still as its been pointed out, a hack." > > If you see some issue in the code you should explain what issue that is and > not just call the code a "hack". Because noone knows what you refer to and > there is nothing that can be done about issues that noone knows what they > refer to. > > > Another example of aggression from you is (IRC from a few hours ago) > > irc logs off? irc logs off. > carl not here? carl not here. > nicolas is an awful person who disagrees with everything and does > no work like ever, yet hangs around the ml to be obnoxious > his opinions on asserts should disqualify him from working on any > library ever > add reimar to that list > I'll remove that assert if I push that patch, just because maybe > he'll fuck off then > they only work toward covering michael > reimar does, nickolas is just there to misunderstand and be > annoying and demanding > > just stop these attacks/insults against people. > Not until all mplayer people are not longer part of organization. You called for it by this behavior. > > Thanks > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > You can kill me, but you cannot change the truth. > ___ > ffmpeg-devel mailing
[FFmpeg-devel] [PATCH] libavcodec: add editpts bitstream filter [v4]
Hi,
The latest version ready to merge of the bitstream filter "editpts".
Implements all requests.
This supersedes:
https://patchwork.ffmpeg.org/patch/14302/
https://patchwork.ffmpeg.org/patch/14195/
https://patchwork.ffmpeg.org/patch/13743/
https://patchwork.ffmpeg.org/patch/13699/
I hope it will be accepted soon.
Regards.
A.H.
---From 1cc8b06cdb7e2d38c528897d9f9f19b9cbcaf81a Mon Sep 17 00:00:00 2001
From: Andreas Hakon
Date: Fri, 16 Aug 2019 12:11:01 +0200
Subject: [PATCH] libavcodec: add editpts bitstream filter [v4]
This implements the new editpts bitstream filter.
Signed-off-by: Andreas Hakon
---
doc/bitstream_filters.texi | 11 +
libavcodec/Makefile|1 +
libavcodec/bitstream_filters.c |1 +
libavcodec/editpts_bsf.c | 87
4 files changed, 100 insertions(+)
create mode 100644 libavcodec/editpts_bsf.c
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 50a1679..dc73d20 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -644,6 +644,17 @@ codec) with metadata headers.
See also the @ref{mov2textsub} filter.
+@section editpts
+
+Change the values of the PTS/DTS timestamps.
+
+@table @option
+@item offset
+An absolute offset value to apply to the PTS/DTS timestamps with a
+90kHz resolution.
+
+@end table
+
@section trace_headers
Log trace output containing all syntax elements in the coded stream
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3cd73fb..f4cc2be 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1096,6 +1096,7 @@ OBJS-$(CONFIG_NULL_BSF) += null_bsf.o
OBJS-$(CONFIG_PRORES_METADATA_BSF)+= prores_metadata_bsf.o
OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF) += remove_extradata_bsf.o
OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
+OBJS-$(CONFIG_EDITPTS_BSF)+= editpts_bsf.o
OBJS-$(CONFIG_TRACE_HEADERS_BSF) += trace_headers_bsf.o
OBJS-$(CONFIG_TRUEHD_CORE_BSF)+= truehd_core_bsf.o mlp_parse.o
mlp.o
OBJS-$(CONFIG_VP9_METADATA_BSF) += vp9_metadata_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 4630039..59d48ef 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -51,6 +51,7 @@ extern const AVBitStreamFilter ff_null_bsf;
extern const AVBitStreamFilter ff_prores_metadata_bsf;
extern const AVBitStreamFilter ff_remove_extradata_bsf;
extern const AVBitStreamFilter ff_text2movsub_bsf;
+extern const AVBitStreamFilter ff_editpts_bsf;
extern const AVBitStreamFilter ff_trace_headers_bsf;
extern const AVBitStreamFilter ff_truehd_core_bsf;
extern const AVBitStreamFilter ff_vp9_metadata_bsf;
diff --git a/libavcodec/editpts_bsf.c b/libavcodec/editpts_bsf.c
new file mode 100644
index 000..8355dac
--- /dev/null
+++ b/libavcodec/editpts_bsf.c
@@ -0,0 +1,87 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * This bitstream filter applies changes the PTS/DTS timestamps.
+ *
+ */
+
+#include "avcodec.h"
+#include "bsf.h"
+
+#include "libavutil/opt.h"
+
+#define FILTER_MAX_PTS 0x2 // (2^33)
+
+typedef struct EditptsContext {
+const AVClass *class;
+int offset;
+int first_debug_done;
+} EditptsContext;
+
+static int editpts_filter(AVBSFContext *ctx, AVPacket *pkt)
+{
+int ret;
+EditptsContext *s = ctx->priv_data;
+int64_t opts,odts;
+
+ret = ff_bsf_get_packet_ref(ctx, pkt);
+if (ret < 0)
+return ret;
+
+opts = pkt->pts;
+if (pkt->pts != AV_NOPTS_VALUE) {
+pkt->pts += s->offset;
+pkt->pts &= FILTER_MAX_PTS;
+}
+odts = pkt->dts;
+if (pkt->dts != AV_NOPTS_VALUE) {
+pkt->dts += s->offset;
+pkt->pts &= FILTER_MAX_PTS;
+}
+
+if (!s->first_debug_done) {
+av_log(ctx, AV_LOG_DEBUG, "Updated PTS/DTS (%"PRId64"/%"PRId64" :
%"PRId64"/%"PRId64") with offset:%d\n",
+pkt->pts, pkt->dts, opts, odts, s->offset );
+s->first_debug_done = 1;
+}
+
+return 0;
+}
+
+#define OFFSET(x) offsetof(EditptsContext, x)
+#define FLAGS
(AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_SUBTITLE_PARAM|AV_OPT_FLAG_BSF_PARAM)
+
Re: [FFmpeg-devel] [PATCH 1/2] avutil: Add Simple loop detector
Michael Niedermayer (12019-08-16): > irc logs off? irc logs off. > carl not here? carl not here. > nicolas is an awful person who disagrees with everything and does no > work like ever, yet hangs around the ml to be obnoxious > his opinions on asserts should disqualify him from working on any > library ever > add reimar to that list > I'll remove that assert if I push that patch, just because maybe > he'll fuck off then > they only work toward covering michael > reimar does, nickolas is just there to misunderstand and be annoying > and demanding > > just stop these attacks/insults against people. That is not just aggressive, that is outright insulting. It is sad that some people do not realize how this kind of attitude is hurting the project and that they should rather try to see the positive that everybody brings. That is what code of conducts are for, we should start enforcing one. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avutil: Add Simple loop detector
On Fri, Aug 16, 2019 at 1:03 PM Nicolas George wrote: > Michael Niedermayer (12019-08-16): > > irc logs off? irc logs off. > > carl not here? carl not here. > > nicolas is an awful person who disagrees with everything and > does no work like ever, yet hangs around the ml to be obnoxious > > his opinions on asserts should disqualify him from working on > any library ever > > add reimar to that list > > I'll remove that assert if I push that patch, just because maybe > he'll fuck off then > > they only work toward covering michael > > reimar does, nickolas is just there to misunderstand and be > annoying and demanding > > > > just stop these attacks/insults against people. > > That is not just aggressive, that is outright insulting. It is sad that > some people do not realize how this kind of attitude is hurting the > project and that they should rather try to see the positive that > everybody brings. That is what code of conducts are for, we should start > enforcing one. > Go ahead, then none then only mplayer devs doing fuzzing will remain. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavutil: AVEncodeInfo data structures (fwd)
- Forwarded message from Nicolas George - Date: Fri, 16 Aug 2019 13:55:18 +0200 From: Nicolas George To: Juan De León Subject: Re: [FFmpeg-devel] [PATCH] libavutil: AVEncodeInfo data structures Juan De León (12019-08-15): > I don't think it's common for size_t to wrap around. size_t has a max value, like all integer types. If the mathematical result of the multiolication or the addition is greater than that, it cannot work. Regards, -- Nicolas George - End forwarded message - ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6] avfilter/avf_aphasemeter: Add out-of-phase and mono detection
> > +{ "duration", "set minimum mono or out-of-phase duration in
> seconds", OFFSET(duration), AV_OPT_TYPE_DOUBLE, {.dbl=2.}, 0, 24*60*60,
> FLAGS },
>
> ffmpeg also provides a AV_OPT_TYPE_DURATION. (This may have been
> discussed before - sorry if so.)
AV_OPT_TYPE_DURATION is used as an integer (for duration expressed in milli
or microseconds I think). But I prefer to use double and seconds. It's
easier to do the comparison with mono_duration for example, which is
calculated in seconds with floating point.
> > +static inline float get_index(AVFilterLink *inlink, AVFrame *in)
> > +{
> > +char *index_str = av_ts2timestr(in->pts, &inlink->time_base);
> > +return atof(index_str);
> > +}
>
> Just wondering: Are you sure this works? The av_ts2timestr() macro is
> specifically documented as such:
>
> [...] the return value should be used only directly in
> function arguments but never stand-alone
>
> Likely because it defines a buffer locally which goes out of scope.
>
You're right, it works but it's not correct as it should be used in
arguments. I will use : return atof(av_ts2timestr(in->pts,
&inlink->time_base));
Cheers,
Romane
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/7] avcodec/anm: Check input size for a frame with just a stop code
On Thu, Aug 15, 2019 at 11:49:13PM +0200, Michael Niedermayer wrote: > Fixes: Timeout (11sec -> 6sec) > Fixes: > 16344/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ANM_fuzzer-5673032000995328 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/anm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavcodec/anm.c b/libavcodec/anm.c > index ab6a3994e9..778f38413e 100644 > --- a/libavcodec/anm.c > +++ b/libavcodec/anm.c > @@ -119,6 +119,9 @@ static int decode_frame(AVCodecContext *avctx, > uint8_t *dst, *dst_end; > int count, ret; > > +if (buf_size < 7) > +return AVERROR_INVALIDDATA; > + > if ((ret = ff_reget_buffer(avctx, s->frame)) < 0) > return ret; > dst = s->frame->data[0]; approve. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/http: Fixes #7975. Before reusing the connection the headers are checked to see if the server is closing the connection.
Pasting it into an email may not have been a good idea... here it is as an attachment. Thanks. On Fri, Aug 16, 2019 at 4:35 AM Michael Niedermayer wrote: > On Thu, Aug 15, 2019 at 05:14:38PM -0500, Ian Klassen wrote: > > Hi, > > > > Sorry Moritz, I somehow missed your feedback. Here's an updated patch > with > > the fixed formatting. I also set up a server that you can test with. Try: > > > > ffmpeg -i test.mp4 -hls_flags +append_list -hls_time 6 -method PUT > > -http_persistent 1 http://45.33.124.115/stream.m3u8 > > > > The server has persistent connections turned off so you'll see the errors > > appear but they should be resolved once you apply the patch. > > > > Thanks. > > > > Ian > > > > --- > > libavformat/http.c | 13 ++--- > > 1 file changed, 10 insertions(+), 3 deletions(-) > > > > > > > diff --git a/libavformat/http.c b/libavformat/http.c > > index 579debc..dcbd33a 100644 > > --- a/libavformat/http.c > > +++ b/libavformat/http.c > > @@ -332,15 +332,22 @@ int ff_http_do_new_request(URLContext *h, const > char > > *uri) > > this patch looks corrupted by line breaks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. > User > questions about the command line tools should be sent to the ffmpeg-user > ML. > And questions about how to use libav* should be sent to the libav-user ML. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". 0001-avformat-http-Fixes-7975.-Before-reusing-the-connect.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/8] avcodec/cinepak: Require 1 bit per 4x4 block as minimum input
fre 2019-08-16 klockan 00:50 +0200 skrev Michael Niedermayer:
> On Thu, Aug 15, 2019 at 04:43:19PM +0200, Tomas Härdin wrote:
> > ons 2019-08-14 klockan 12:32 +0200 skrev Tomas Härdin:
> > > mån 2019-08-12 klockan 21:17 +0200 skrev Michael Niedermayer:
> > > > Fixes: Timeout (12sec -> 32ms)
> > > > Fixes: 16078/clusterfuzz-testcase-minimized-
> > > > ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5695832885559296
> > > > [...]
> > > > +if (s->size < (s->avctx->width * s->avctx->height) / (4*4*8))
> > > > +return AVERROR_INVALIDDATA;
> > >
> > > This is wrong if num_strips == 0, and if the MB area is != 0 mod 8. You
> > > could merge it with the check above into something like:
> > >
> > > if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12 +
> > > (num_strips ? ((s->avctx->width * s->avctx->height) / 16 + 7)/8 :
> > > 0)) {
> > > return AVERROR_INVALIDDATA;
> > > }
> > >
> > > The check further down could also check each strip's size, not just the
> > > first one.
> >
> > Actually, thinking a bit more about this, I suspect it might be legal
> > to have strips that don't cover the entire frame. It would certainly be
> > good to support that, for optimizing skip frames. Not sure what old
> > decoders make of that however. A skip could potentially be encoded in
> > 22 + (width/4 + 7)/8 bytes while still being compatible.
>
> i was asking myself the same questions before writing the patch, and
> in the "spec" there is
> "Each frame is segmented into 4x4 pixel blocks, and each block is coded using
> either 1 or 4 vectors."
> "Each" meaning no holes to me. If thats actually true for all real files
> that i do not know.
We should keep in mind the spec is fine with there being zero strips.
It's only if one wants to support certain decoders that there will/must
be one or more strips.
I don't have any way of testing the MacOS decoder, but the old Win3.1
decoder is easy enough to get running. Then I can also check whether
strips narrower than avctx->width are OK.
> > I'd replace s->avctx->height in the expression with the height of the
> > first strip, to not constrain things too much.
>
> ill post a patch doing that
I feel like a better fix would be to make the decoder not choke on the
kind of files that trigger this. With this style of check it's still
possible to insert a second strip that triggers the slowness, with a
trivially sized strip before it.
Would you mind sending me the sample?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 05/11] avcodec/h264_parser: Reuse the RBSP buffer
On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt < andreas.rheinha...@gmail.com> wrote: > Kieran Kunhya: > > On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt < > > andreas.rheinha...@gmail.com> wrote: > > > >> Up until now, the H.264 parser has allocated a new buffer for every > >> frame in order to store the unescaped RBSP in case the part of the RBSP > >> that will be unescaped contains 0x03 escape bytes. This is expensive > >> and this commit changes this: The buffer is now kept and reused. > >> > >> For an AVC file with an average framesize of 15304 B (without in-band > >> parameter sets etc.) and 132044 frames (131072 of which ended up in the > >> results) this reduced the average time used by the H.264 parser from > >> 87708 decicycles (excluding about 1100-1200 skips in each iteration) > >> to 16963 decicycles (excluding about 10-15 skips in each iteration). > >> The test has been iterated 10 times. > >> > > > > If I understand correctly, this patch means if you have a large frame (or > > large NAL) you are stuck with the large allocation of memory until the > > decoder is closed. > > Not sure if you have read the discussion here > > https://patchwork.ffmpeg.org/patch/5631/ > > > > Kieran > > > I am aware of said discussion; and also of your solution [1] to it. It > actually does exactly the same as I propose for the parser: It keeps a > single buffer that does not shrink. Given that this is used for the > decoders (and for cbs_h2645), I didn't deem this to be problematic. > (There is clearly no quadratic memory usage and what Derek warns about > (with huge NALs at specific positions) is a no issue for both.) > > - Andreas > > [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219100.html My solution frees the buffer when it's done. With yours it stays around as a large buffer essentially forever. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] FATE/dnn: let fate/dnn tests depend on ffmpeg static libraries
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Guo, Yejun > Sent: Wednesday, August 7, 2019 10:44 AM > To: ffmpeg-devel@ffmpeg.org > Cc: Guo, Yejun > Subject: [FFmpeg-devel] [PATCH V2] FATE/dnn: let fate/dnn tests depend on > ffmpeg static libraries > > background: > DNN (deep neural network) is a sub module of libavfilter, and FATE/dnn is > unit test for the DNN module, one unit test for one dnn layer. > The unit tests are not based on the APIs exported by libavfilter, they just > directly call into the functions within DNN submodule. > > There is an issue when run the following command: > build$ ../ffmpeg/configure --disable-static --enable-shared make make > fate-dnn-layer-pad > > And part of error message: > tests/dnn/dnn-layer-pad-test.o: In function `test_with_mode_symmetric': > /work/media/ffmpeg/build/src/tests/dnn/dnn-layer-pad-test.c:73: > undefined reference to `dnn_execute_layer_pad' > > The root cause is that function dnn_execute_layer_pad is a LOCAL symbol in > libavfilter.so, and so the linker could not find it when build > dnn-layer-pad-test. > To check it, just run: readelf -s libavfilter/libavfilter.so | grep dnn > > So, add dependency in fate/dnn Makefile with ffmpeg static libraries. > This is the same method used in fate/checkasm > > Signed-off-by: Guo, Yejun > --- > tests/dnn/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tests/dnn/Makefile b/tests/dnn/Makefile index b2e6680..0e050ea > 100644 > --- a/tests/dnn/Makefile > +++ b/tests/dnn/Makefile > @@ -4,8 +4,8 @@ DNNTESTOBJS := > $(DNNTESTOBJS:%=$(DNNTESTSDIR)%) > $(DNNTESTPROGS:%=$(DNNTESTSDIR) DNNTESTPROGS := > $(DNNTESTPROGS:%=$(DNNTESTSDIR)/%-test$(EXESUF)) > -include $(wildcard $(DNNTESTOBJS:.o=.d)) > > -$(DNNTESTPROGS): %$(EXESUF): %.o $(FF_DEP_LIBS) > - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) > $(FF_EXTRALIBS) $(ELIBS) > +$(DNNTESTPROGS): %$(EXESUF): %.o $(FF_STATIC_DEP_LIBS) > + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) > +$(FF_STATIC_DEP_LIBS) $(ELIBS) > > testclean:: > $(RM) $(addprefix $(DNNTESTSDIR)/,$(CLEANSUFFIXES) > *-test$(EXESUF)) > -- > 2.7.4 LGTM && Verified IMHO this is a high priority patch since currently FATE is broken now if build with dynamic link ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 05/11] avcodec/h264_parser: Reuse the RBSP buffer
Kieran Kunhya: > On Fri, 16 Aug 2019 at 06:08, Andreas Rheinhardt < > andreas.rheinha...@gmail.com> wrote: > >> Kieran Kunhya: >>> On Fri, 16 Aug 2019 at 04:20, Andreas Rheinhardt < >>> andreas.rheinha...@gmail.com> wrote: >>> Up until now, the H.264 parser has allocated a new buffer for every frame in order to store the unescaped RBSP in case the part of the RBSP that will be unescaped contains 0x03 escape bytes. This is expensive and this commit changes this: The buffer is now kept and reused. For an AVC file with an average framesize of 15304 B (without in-band parameter sets etc.) and 132044 frames (131072 of which ended up in the results) this reduced the average time used by the H.264 parser from 87708 decicycles (excluding about 1100-1200 skips in each iteration) to 16963 decicycles (excluding about 10-15 skips in each iteration). The test has been iterated 10 times. >>> >>> If I understand correctly, this patch means if you have a large frame (or >>> large NAL) you are stuck with the large allocation of memory until the >>> decoder is closed. >>> Not sure if you have read the discussion here >>> https://patchwork.ffmpeg.org/patch/5631/ >>> >>> Kieran >>> >> I am aware of said discussion; and also of your solution [1] to it. It >> actually does exactly the same as I propose for the parser: It keeps a >> single buffer that does not shrink. Given that this is used for the >> decoders (and for cbs_h2645), I didn't deem this to be problematic. >> (There is clearly no quadratic memory usage and what Derek warns about >> (with huge NALs at specific positions) is a no issue for both.) >> >> - Andreas >> >> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219100.html > > > My solution frees the buffer when it's done. With yours it stays around as > a large buffer essentially forever. > > Kieran > Your solution frees the buffer in the parser when it's done, but the buffers for the decoders are kept (and only grow) during decoding. So this commit merely does for the parser what is already done for the deocder. Anyway, it would be easy to add a check to the parser to free the buffer if it is considered excessively large. I don't know how easy it would be to add such precautions to the decoder, though. I am also not sure what should be considered excessively large? 5 MB? 10 MB? Setting it so high that even the highest profiles can't hit it is impossible, because for certain profiles ((Progressive) High 10, High 4:2:2, ...) no limit is imposed at all (apart from that, such a limit would surely be too high). - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [v3] avformat/flvdec: delete unused code
ping.
leozhang 于2019年8月14日周三 上午11:07写道：
>
> Reviewed-by: Carl Eugen Hoyos
> Signed-off-by: leozhang
> ---
> libavformat/flvdec.c | 17 -
> 1 file changed, 17 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index b531a39..6bfe624 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -32,7 +32,6 @@
> #include "libavutil/mathematics.h"
> #include "libavutil/time_internal.h"
> #include "libavcodec/bytestream.h"
> -#include "libavcodec/mpeg4audio.h"
> #include "avformat.h"
> #include "internal.h"
> #include "avio_internal.h"
> @@ -1265,22 +1264,6 @@ retry_duration:
> if (st->codecpar->codec_id == AV_CODEC_ID_AAC && t &&
> !strcmp(t->value, "Omnia A/XE"))
> st->codecpar->extradata_size = 2;
>
> -if (st->codecpar->codec_id == AV_CODEC_ID_AAC && 0) {
> -MPEG4AudioConfig cfg;
> -
> -if (avpriv_mpeg4audio_get_config(&cfg,
> st->codecpar->extradata,
> -
> st->codecpar->extradata_size * 8, 1) >= 0) {
> -st->codecpar->channels = cfg.channels;
> -st->codecpar->channel_layout = 0;
> -if (cfg.ext_sample_rate)
> -st->codecpar->sample_rate = cfg.ext_sample_rate;
> -else
> -st->codecpar->sample_rate = cfg.sample_rate;
> -av_log(s, AV_LOG_TRACE, "mp4a config channels %d sample rate
> %d\n",
> -st->codecpar->channels, st->codecpar->sample_rate);
> -}
> -}
> -
> ret = FFERROR_REDO;
> goto leave;
> }
> --
> 1.8.3.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avformat/utils: Fix memleaks
ff_read_packet had several potential memleaks:
1. If av_packet_make_refcounted fails, it means that the packet is not
refcounted, but it could nevertheless carry side data and therefore
needs to be unreferenced.
2. If a packet happens to have an illegal stream index (i.e. one that
does not correspond to a stream), it should nevertheless be
unreferenced.
3. If putting a packet on a packet list fails, it wasn't unreferenced.
Signed-off-by: Andreas Rheinhardt
---
libavformat/utils.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index b57e680089..a902841ad5 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -873,8 +873,10 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
}
err = av_packet_make_refcounted(pkt);
-if (err < 0)
+if (err < 0) {
+av_packet_unref(pkt);
return err;
+}
if ((s->flags & AVFMT_FLAG_DISCARD_CORRUPT) &&
(pkt->flags & AV_PKT_FLAG_CORRUPT)) {
@@ -887,6 +889,7 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
if (pkt->stream_index >= (unsigned)s->nb_streams) {
av_log(s, AV_LOG_ERROR, "Invalid stream index %d\n",
pkt->stream_index);
+av_packet_unref(pkt);
continue;
}
@@ -917,8 +920,10 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
err = ff_packet_list_put(&s->internal->raw_packet_buffer,
&s->internal->raw_packet_buffer_end,
pkt, 0);
-if (err)
+if (err < 0) {
+av_packet_unref(pkt);
return err;
+}
s->internal->raw_packet_buffer_remaining_size -= pkt->size;
if ((err = probe_codec(s, st, pkt)) < 0)
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avformat/utils: Preserve integrity of linked list
1. Instead of relying on ff_packet_list_get to get the oldest element in
an AVPacketList, ff_read_packet used its own ad-hoc code. Said code
forgot to set the end of the list to NULL if the last element of the
list has been removed, thereby leaving the list in an inconsistent state.
2. Furthermore, if the list was not empty, the oldest element of the
list would always be copied into another packet structure before it was
known whether the oldest entry of the list would be removed. This makes
the ownership confusing and potentially copies unnecessarily.
Both of these issues have been fixed. ff_packet_list_get is used now.
Signed-off-by: Andreas Rheinhardt
---
libavformat/utils.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index a902841ad5..9e87ae3f10 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -837,15 +837,14 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
AVPacketList *pktl = s->internal->raw_packet_buffer;
if (pktl) {
-*pkt = pktl->pkt;
-st = s->streams[pkt->stream_index];
+st = s->streams[pktl->pkt.stream_index];
if (s->internal->raw_packet_buffer_remaining_size <= 0)
if ((err = probe_codec(s, st, NULL)) < 0)
return err;
if (st->request_probe <= 0) {
-s->internal->raw_packet_buffer = pktl->next;
+ff_packet_list_get(&s->internal->raw_packet_buffer,
+ &s->internal->raw_packet_buffer_end, pkt);
s->internal->raw_packet_buffer_remaining_size += pkt->size;
-av_free(pktl);
return 0;
}
}
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avformat/internal: Improve documentation of ff_packet_list_get
The documentation of ff_packet_list_get currently didn't match the actual usage: 1. It said that the destination packet is supposed to be initialized. But this makes no sense given that it will be overwritten completely and flacenc, mp3enc and ttaenc ignored this. 2. ff_packet_list_get returns an int, although it can't fail in case the packet list is not empty (for which there is an assert). Again, several callers didn't check for any return value. In both cases, the documentation has been adapted to match actual usage. Signed-off-by: Andreas Rheinhardt --- libavformat/internal.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libavformat/internal.h b/libavformat/internal.h index d6a039c497..163587f416 100644 --- a/libavformat/internal.h +++ b/libavformat/internal.h @@ -773,13 +773,16 @@ int ff_packet_list_put(AVPacketList **head, AVPacketList **tail, /** * Remove the oldest AVPacket in the list and return it. + * The behaviour is undefined if the packet list is empty. * * @note The pkt will be overwritten completely. The caller owns the * packet and must unref it by itself. * * @param head List head element * @param tail List tail element - * @param pkt Pointer to an initialized AVPacket struct + * @param pkt Pointer to an AVPacket struct + * @return 0 on success. Success is guaranteed + * if the packet list is not empty. */ int ff_packet_list_get(AVPacketList **head, AVPacketList **tail, AVPacket *pkt); -- 2.21.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Need anything else Moritz? > On 14 Aug 2019, at 09:54, Ross Nicholson wrote: > > I would imagine that the way Kodi handles the stream, rtsp_hd_out is null as > per the following: > > URLContext * rtsp_hd_out > Additional output handle, used when input and output are done > separately, eg for HTTP tunneling. > > In your case it would not be. > >> On Wed, 14 Aug 2019 at 09:50, Ross Nicholson wrote: >> >> >>> On Wed, 14 Aug 2019 at 07:20, Moritz Barsnick wrote: >>> On Mon, Aug 05, 2019 at 08:18:32 +0100, Ross Nicholson wrote: >>> > Example stream that does not work: >>> > rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov >>> > >>> > Extending the condition allows the stream to be processed correctly. >>> >>> Can you give a bit more detail? Decoding this stream works for me (at >>> last the first 20 seconds or so). >>> >> >> We made some changes in Kodi regardless handling TS streams the right way. >> An unfortunate side effect was that we caused an issue with RTSP streams due >> to an issue in rtsp_send_cmd_with_content_async. The issue can be avoided >> once sending teardown is skipped if rtsp_hd_out is null. >> >>> > On Mon, 5 Aug 2019 at 08:17, Ross Nicholson wrote: >>> > > From: phunkyfish >>> >>> Do you want your real name or this pseudonym registered in the repo? It >>> can't be changed afterwards. >> >> Yes, that email is registered on github if that's what you mean. >>> >>> Moritz >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Change libaom default to crf=28.
Hi,
On Thu, Aug 15, 2019 at 1:22 PM elliottk
wrote:
>
> Current default is 256kbps, which produces inconsistent
> results (too high for low-res, too low for hi-res).
> Use CRF instead, which will adapt.
> ---
> libavcodec/libaomenc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 9b4fb3b4eb..621e897672 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -575,10 +575,11 @@ static av_cold int aom_init(AVCodecContext *avctx,
> if (enccfg.rc_end_usage == AOM_CQ) {
> enccfg.rc_target_bitrate = 100;
> } else {
> -avctx->bit_rate = enccfg.rc_target_bitrate * 1000;
> +enccfg.rc_end_usage = AOM_Q;
Unless the docs are out of date this should be AOM_CQ level since crf
is mapped to that control [1].
> +ctx->crf = 28;
> av_log(avctx, AV_LOG_WARNING,
> - "Neither bitrate nor constrained quality specified, using
> default bitrate of %dkbit/sec\n",
> - enccfg.rc_target_bitrate);
> + "Neither bitrate nor constrained quality specified, using
> default CRF of %d\n",
> + ctx->crf);
> }
> }
>
[1] https://aomedia.googlesource.com/aom/+/refs/heads/master/aom/aomcx.h#221
"For this value to be used aom_codec_enc_cfg_t::rc_end_usage must be
set to #AOM_CQ."
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavutil: AVEncodeInfo data structures
AVEncodeInfoFrame data structure to store as AVFrameSideData of type
AV_FRAME_DATA_ENCODE_INFO.
The structure stores quantization index for each plane, DC/AC deltas
for luma and chroma planes, and an array of AVEncodeInfoBlock type
denoting position, size, and delta quantizer for each block in the
frame.
Can be extended to support extraction of other block information.
Signed-off-by: Juan De León
---
libavutil/Makefile | 2 +
libavutil/encode_info.c | 68 +
libavutil/encode_info.h | 110
libavutil/frame.c | 1 +
libavutil/frame.h | 7 +++
5 files changed, 188 insertions(+)
create mode 100644 libavutil/encode_info.c
create mode 100644 libavutil/encode_info.h
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 57e6e3d7e8..37cfb099e9 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -24,6 +24,7 @@ HEADERS = adler32.h
\
dict.h\
display.h \
downmix_info.h\
+ encode_info.h \
encryption_info.h \
error.h \
eval.h\
@@ -111,6 +112,7 @@ OBJS = adler32.o
\
dict.o \
display.o\
downmix_info.o \
+ encode_info.o\
encryption_info.o\
error.o \
eval.o \
diff --git a/libavutil/encode_info.c b/libavutil/encode_info.c
new file mode 100644
index 00..ec352a403b
--- /dev/null
+++ b/libavutil/encode_info.c
@@ -0,0 +1,68 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/encode_info.h"
+#include "libavutil/mem.h"
+
+// To prevent overflow, assumes max number = 1px blocks for 8k video.
+#define AV_ENCODE_INFO_MAX_BLOCKS 33177600
+
+static int init_encode_info_data(AVEncodeInfoFrame *info, unsigned int
nb_blocks) {
+info->nb_blocks = nb_blocks;
+info->block_size = sizeof(AVEncodeInfoBlock);
+info->blocks_offset = offsetof(AVEncodeInfoFrame, blocks);
+
+for(int i = 0; i < AV_NUM_DATA_POINTERS; i++)
+info->plane_q[i] = -1;
+
+return 0;
+}
+
+AVEncodeInfoFrame *av_encode_info_alloc(unsigned int nb_blocks)
+{
+if (nb_blocks > AV_ENCODE_INFO_MAX_BLOCKS)
+return NULL;
+
+//AVEncodeInfoFrame already allocates size for one element of
AVEncodeInfoBlock
+size_t size = sizeof(AVEncodeInfoFrame) +
sizeof(AVEncodeInfoBlock)*FFMAX((int)(nb_blocks - 1), 0);
+AVEncodeInfoFrame *ptr = av_mallocz(size);
+if (!ptr)
+return NULL;
+
+init_encode_info_data(ptr, nb_blocks);
+
+return ptr;
+}
+
+AVEncodeInfoFrame *av_encode_info_create_side_data(AVFrame *frame, unsigned
int nb_blocks)
+{
+if (nb_blocks > AV_ENCODE_INFO_MAX_BLOCKS)
+return NULL;
+
+size_t size = sizeof(AVEncodeInfoFrame) +
sizeof(AVEncodeInfoBlock)*FFMAX((int)(nb_blocks - 1), 0);
+AVFrameSideData *sd = av_frame_new_side_data(frame,
+ AV_FRAME_DATA_ENCODE_INFO,
+ size);
+if (!sd)
+return NULL;
+
+memset(sd->data, 0, size);
+init_encode_info_data((AVEncodeInfoFrame*)sd->data, nb_blocks);
+
+return (AVEncodeInfoFrame*)sd->data;
+}
diff --git a/libavutil/encode_info.h b/libavutil/encode_info.h
new file mode 100644
index 00..354411b9e1
--- /dev/null
+++ b/libavutil/encode_info.h
@@ -0,0 +1,110 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free softwar
[FFmpeg-devel] [PATCH 0/3] Dolby TrueHD support in ISO BMFF
https://developer.dolby.com/globalassets/technology/dolby-truehd/dolbytruehdbitstreamswithintheisobasemediafileformat.pdf There's no software i could find that supports this, so mine is the first implementation out there. It's therefore tested with itself :p James Almer (3): avcodec/mlp_parse: move TrueHD channel layout and sample rate related code to the header avformat/mov: add demuxing support for Dolby TrueHD streams avformat/movenc: add muxing support for Dolby TrueHD streams libavcodec/mlp_parse.c | 50 -- libavcodec/mlp_parse.h | 49 + libavformat/isom.c | 1 + libavformat/mov.c | 34 +++ libavformat/movenc.c | 61 +- 5 files changed, 144 insertions(+), 51 deletions(-) -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avformat/movenc: add muxing support for Dolby TrueHD streams
Signed-off-by: James Almer
---
libavformat/movenc.c | 61 +++-
1 file changed, 60 insertions(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a96139077b..adb5cd0e5a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -771,6 +771,35 @@ static int mov_write_dops_tag(AVFormatContext *s,
AVIOContext *pb, MOVTrack *tra
return update_size(pb, pos);
}
+static int mov_write_dmlp_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack
*track)
+{
+int64_t pos = avio_tell(pb);
+int length;
+avio_wb32(pb, 0);
+ffio_wfourcc(pb, "dmlp");
+
+if (track->vos_len < 20) {
+av_log(s, AV_LOG_ERROR,
+ "Cannot write moov atom before TrueHD packets."
+ " Set the delay_moov flag to fix this.\n");
+return AVERROR(EINVAL);
+}
+
+length = (AV_RB16(track->vos_data) & 0xFFF) * 2;
+if (length < 20 || length > track->vos_len)
+return AVERROR_INVALIDDATA;
+
+// Only TrueHD is supported
+if (AV_RB32(track->vos_data + 4) != 0xF8726FBA)
+return AVERROR_INVALIDDATA;
+
+avio_wb32(pb, AV_RB32(track->vos_data + 8)); /* format_info */
+avio_wb16(pb, AV_RB16(track->vos_data + 18) << 1); /* peak_data_rate */
+avio_wb32(pb, 0); /* reserved */
+
+return update_size(pb, pos);
+}
+
static int mov_write_chan_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack
*track)
{
uint32_t layout_tag, bitmap;
@@ -1100,10 +1129,14 @@ static int mov_write_audio_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContex
avio_wb16(pb, 0); /* packet size (= 0) */
if (track->par->codec_id == AV_CODEC_ID_OPUS)
avio_wb16(pb, 48000);
+else if (track->par->codec_id == AV_CODEC_ID_TRUEHD)
+avio_wb32(pb, track->par->sample_rate);
else
avio_wb16(pb, track->par->sample_rate <= UINT16_MAX ?
track->par->sample_rate : 0);
-avio_wb16(pb, 0); /* Reserved */
+
+if (track->par->codec_id != AV_CODEC_ID_TRUEHD)
+avio_wb16(pb, 0); /* Reserved */
}
if (version == 1) { /* SoundDescription V1 extended info */
@@ -1145,6 +1178,8 @@ static int mov_write_audio_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContex
ret = mov_write_dfla_tag(pb, track);
else if (track->par->codec_id == AV_CODEC_ID_OPUS)
ret = mov_write_dops_tag(s, pb, track);
+else if (track->par->codec_id == AV_CODEC_ID_TRUEHD)
+ret = mov_write_dmlp_tag(s, pb, track);
else if (track->vos_len > 0)
ret = mov_write_glbl_tag(pb, track);
@@ -2456,6 +2491,7 @@ static int mov_write_stbl_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContext
return ret;
mov_write_stts_tag(pb, track);
if ((track->par->codec_type == AVMEDIA_TYPE_VIDEO ||
+ track->par->codec_id == AV_CODEC_ID_TRUEHD ||
track->par->codec_tag == MKTAG('r','t','p',' ')) &&
track->has_keyframes && track->has_keyframes < track->entry)
mov_write_stss_tag(pb, track, MOV_SYNC_SAMPLE);
@@ -4963,6 +4999,25 @@ static void mov_parse_vc1_frame(AVPacket *pkt, MOVTrack
*trk)
}
}
+static void mov_parse_truehd_frame(AVPacket *pkt, MOVTrack *trk)
+{
+int length;
+
+if (pkt->size < 8)
+return;
+
+length = (AV_RB16(pkt->data) & 0xFFF) * 2;
+if (length < 8 || length > pkt->size)
+return;
+
+if (AV_RB32(pkt->data + 4) == 0xF8726FBA) {
+trk->cluster[trk->entry].flags |= MOV_SYNC_SAMPLE;
+trk->has_keyframes++;
+}
+
+return;
+}
+
static int mov_flush_fragment_interleaving(AVFormatContext *s, MOVTrack *track)
{
MOVMuxContext *mov = s->priv_data;
@@ -5400,6 +5455,7 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
}
if ((par->codec_id == AV_CODEC_ID_DNXHD ||
+ par->codec_id == AV_CODEC_ID_TRUEHD ||
par->codec_id == AV_CODEC_ID_AC3) && !trk->vos_len) {
/* copy frame to create needed atoms */
trk->vos_len = size;
@@ -5509,6 +5565,8 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
if (par->codec_id == AV_CODEC_ID_VC1) {
mov_parse_vc1_frame(pkt, trk);
+} else if (par->codec_id == AV_CODEC_ID_TRUEHD) {
+mov_parse_truehd_frame(pkt, trk);
} else if (pkt->flags & AV_PKT_FLAG_KEY) {
if (mov->mode == MODE_MOV && par->codec_id == AV_CODEC_ID_MPEG2VIDEO &&
trk->entry > 0) { // force sync sample for the first key frame
@@ -6802,6 +6860,7 @@ const AVCodecTag codec_mp4_tags[] = {
{ AV_CODEC_ID_AC3 , MKTAG('a', 'c', '-', '3') },
{ AV_CODEC_ID_EAC3, MKTAG('e', 'c', '-', '3') },
{ AV_CODEC_ID_DTS , MKTAG('m', 'p', '4', 'a') },
+{ AV_CODEC_ID_TRUEHD , MKTAG('m', 'l', 'p', 'a') },
{ AV_CODEC_ID_FLAC, MKTAG('f', 'L', 'a', 'C') },
{ AV_CODEC_ID_OPUS, MKTAG('O', 'p', 'u', 's') },
{ AV_CODEC_ID_VOR
[FFmpeg-devel] [PATCH 2/3] avformat/mov: add demuxing support for Dolby TrueHD streams
Signed-off-by: James Almer
---
libavformat/isom.c | 1 +
libavformat/mov.c | 34 ++
2 files changed, 35 insertions(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index c4880878c1..fa2e318099 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -369,6 +369,7 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
{ AV_CODEC_ID_EVRC,MKTAG('s', 'e', 'v', 'c') }, /* 3GPP2 */
{ AV_CODEC_ID_SMV, MKTAG('s', 's', 'm', 'v') }, /* 3GPP2 */
{ AV_CODEC_ID_FLAC,MKTAG('f', 'L', 'a', 'C') }, /* nonstandard
*/
+{ AV_CODEC_ID_TRUEHD, MKTAG('m', 'l', 'p', 'a') }, /* mp4ra.org */
{ AV_CODEC_ID_OPUS,MKTAG('O', 'p', 'u', 's') }, /* mp4ra.org */
{ AV_CODEC_ID_NONE, 0 },
};
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 24de5429d1..8a4cdc4b43 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -49,6 +49,7 @@
#include "libavcodec/ac3tab.h"
#include "libavcodec/flac.h"
#include "libavcodec/mpegaudiodecheader.h"
+#include "libavcodec/mlp_parse.h"
#include "avformat.h"
#include "internal.h"
#include "avio_internal.h"
@@ -6683,6 +6684,38 @@ static int mov_read_dops(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return 0;
}
+static int mov_read_dmlp(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+unsigned format_info;
+int channel_assignment, channel_assignment1, channel_assignment2;
+int ratebits;
+
+if (c->fc->nb_streams < 1)
+return 0;
+st = c->fc->streams[c->fc->nb_streams-1];
+
+if (atom.size < 10)
+return AVERROR_INVALIDDATA;
+
+format_info = avio_rb32(pb);
+
+ratebits= (format_info >> 28) & 0xF;
+channel_assignment1 = (format_info >> 15) & 0x1F;
+channel_assignment2 = format_info & 0x1FFF;
+if (channel_assignment2)
+channel_assignment = channel_assignment2;
+else
+channel_assignment = channel_assignment1;
+
+st->codecpar->frame_size = 40 << (ratebits & 0x7);
+st->codecpar->sample_rate = mlp_samplerate(ratebits);
+st->codecpar->channels = truehd_channels(channel_assignment);
+st->codecpar->channel_layout = truehd_layout(channel_assignment);
+
+return 0;
+}
+
static const MOVParseTableEntry mov_default_parse_table[] = {
{ MKTAG('A','C','L','R'), mov_read_aclr },
{ MKTAG('A','P','R','G'), mov_read_avid },
@@ -6771,6 +6804,7 @@ static const MOVParseTableEntry mov_default_parse_table[]
= {
{ MKTAG('s','t','3','d'), mov_read_st3d }, /* stereoscopic 3D video box */
{ MKTAG('s','v','3','d'), mov_read_sv3d }, /* spherical video box */
{ MKTAG('d','O','p','s'), mov_read_dops },
+{ MKTAG('d','m','l','p'), mov_read_dmlp },
{ MKTAG('S','m','D','m'), mov_read_smdm },
{ MKTAG('C','o','L','L'), mov_read_coll },
{ MKTAG('v','p','c','C'), mov_read_vpcc },
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] avcodec/mlp_parse: move TrueHD channel layout and sample rate related code to the header
It will be needed by the next commit.
Signed-off-by: James Almer
---
libavcodec/mlp_parse.c | 50 --
libavcodec/mlp_parse.h | 49 +
2 files changed, 49 insertions(+), 50 deletions(-)
diff --git a/libavcodec/mlp_parse.c b/libavcodec/mlp_parse.c
index 067735303c..3a71f2c0b7 100644
--- a/libavcodec/mlp_parse.c
+++ b/libavcodec/mlp_parse.c
@@ -60,56 +60,6 @@ static const uint64_t mlp_layout[32] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
};
-static const uint8_t thd_chancount[13] = {
-// LRC LFE LRs LRvh LRc LRrs Cs Ts LRsd LRw Cvh LFE2
- 2, 1, 1, 2, 2, 2, 2, 1, 1, 2, 2, 1, 1
-};
-
-static const uint64_t thd_layout[13] = {
-AV_CH_FRONT_LEFT|AV_CH_FRONT_RIGHT, // LR
-AV_CH_FRONT_CENTER, // C
-AV_CH_LOW_FREQUENCY,// LFE
-AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT, // LRs
-AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT, // LRvh
-AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER, // LRc
-AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT, // LRrs
-AV_CH_BACK_CENTER, // Cs
-AV_CH_TOP_CENTER, // Ts
-AV_CH_SURROUND_DIRECT_LEFT|AV_CH_SURROUND_DIRECT_RIGHT, // LRsd
-AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT, // LRw
-AV_CH_TOP_FRONT_CENTER, // Cvh
-AV_CH_LOW_FREQUENCY_2, // LFE2
-};
-
-static int mlp_samplerate(int in)
-{
-if (in == 0xF)
-return 0;
-
-return (in & 8 ? 44100 : 48000) << (in & 7) ;
-}
-
-static int truehd_channels(int chanmap)
-{
-int channels = 0, i;
-
-for (i = 0; i < 13; i++)
-channels += thd_chancount[i] * ((chanmap >> i) & 1);
-
-return channels;
-}
-
-static uint64_t truehd_layout(int chanmap)
-{
-int i;
-uint64_t layout = 0;
-
-for (i = 0; i < 13; i++)
-layout |= thd_layout[i] * ((chanmap >> i) & 1);
-
-return layout;
-}
-
static int mlp_get_major_sync_size(const uint8_t * buf, int bufsize)
{
int has_extension, extensions = 0;
diff --git a/libavcodec/mlp_parse.h b/libavcodec/mlp_parse.h
index c6025d1a18..a0790ae8c7 100644
--- a/libavcodec/mlp_parse.h
+++ b/libavcodec/mlp_parse.h
@@ -56,6 +56,55 @@ typedef struct MLPHeaderInfo
int num_substreams; ///< Number of substreams within
stream
} MLPHeaderInfo;
+static const uint8_t thd_chancount[13] = {
+// LRC LFE LRs LRvh LRc LRrs Cs Ts LRsd LRw Cvh LFE2
+ 2, 1, 1, 2, 2, 2, 2, 1, 1, 2, 2, 1, 1
+};
+
+static const uint64_t thd_layout[13] = {
+AV_CH_FRONT_LEFT|AV_CH_FRONT_RIGHT, // LR
+AV_CH_FRONT_CENTER, // C
+AV_CH_LOW_FREQUENCY,// LFE
+AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT, // LRs
+AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT, // LRvh
+AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER, // LRc
+AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT, // LRrs
+AV_CH_BACK_CENTER, // Cs
+AV_CH_TOP_CENTER, // Ts
+AV_CH_SURROUND_DIRECT_LEFT|AV_CH_SURROUND_DIRECT_RIGHT, // LRsd
+AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT, // LRw
+AV_CH_TOP_FRONT_CENTER, // Cvh
+AV_CH_LOW_FREQUENCY_2, // LFE2
+};
+
+static inline int mlp_samplerate(int in)
+{
+if (in == 0xF)
+return 0;
+
+return (in & 8 ? 44100 : 48000) << (in & 7) ;
+}
+
+static inline int truehd_channels(int chanmap)
+{
+int channels = 0, i;
+
+for (i = 0; i < 13; i++)
+channels += thd_chancount[i] * ((chanmap >> i) & 1);
+
+return channels;
+}
+
+static inline uint64_t truehd_layout(int chanmap)
+{
+int i;
+uint64_t layout = 0;
+
+for (i = 0; i < 13; i++)
+layout |= thd_layout[i] * ((chanmap >> i) & 1);
+
+return layout;
+}
int ff_mlp_read_major_sync(void *log, MLPHeaderInfo *mh, GetBitContext *gb);
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/3] Dolby TrueHD support in ISO BMFF
On 8/16/2019 6:17 PM, James Almer wrote: > https://developer.dolby.com/globalassets/technology/dolby-truehd/dolbytruehdbitstreamswithintheisobasemediafileformat.pdf > > There's no software i could find that supports this, so mine is the first > implementation out there. It's therefore tested with itself :p > > James Almer (3): > avcodec/mlp_parse: move TrueHD channel layout and sample rate related > code to the header > avformat/mov: add demuxing support for Dolby TrueHD streams > avformat/movenc: add muxing support for Dolby TrueHD streams > > libavcodec/mlp_parse.c | 50 -- > libavcodec/mlp_parse.h | 49 + > libavformat/isom.c | 1 + > libavformat/mov.c | 34 +++ > libavformat/movenc.c | 61 +- > 5 files changed, 144 insertions(+), 51 deletions(-) Forgot to mention ticket #8051 in patches 2 and 3. Amended locally. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50
tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
> Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin > :
> > ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
> > > Hi Tomas,
> > >
> > > Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin <
> > tjop...@acc.umu.se
> > > > :
> > > > tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
> > > > > Hi,
> > > > >
> > > > > attached patch fixes ticket #8077.
> > > > > Please comment.
> > > >
> > > > Probably OK, bitrates lower than 5000 are fine in D-10 according to
> > > > S356m.
> > > >
> > > > > } else if ((sc->video_bit_rate >= 4840) && (sc->video_bit_rate <=
> > > > > 5000) && (mxf->time_base.den != 25)) {
> > > >
> > > > You could drop the extra parentheses, else it should be fine.
> > > >
> > >
> > > New patch attached.
> >
> > Looks OK. I'll push in a few days if no one else has any comments
> >
>
> Thanks. Would you mind porting it to branches 4.1 and 4.2?
I'm not quite sure what the process is for that. I have confirmed that
the problem exists in 4.1 and 4.2 and that your patch fixes it.
I think we also might want to put a note somewhere in the documentation
how to make NTSC IMX50 files.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/8] avcodec/cinepak: Require 1 bit per 4x4 block as minimum input
fre 2019-08-16 klockan 14:57 +0200 skrev Tomas Härdin:
> fre 2019-08-16 klockan 00:50 +0200 skrev Michael Niedermayer:
> > On Thu, Aug 15, 2019 at 04:43:19PM +0200, Tomas Härdin wrote:
> > > ons 2019-08-14 klockan 12:32 +0200 skrev Tomas Härdin:
> > > > mån 2019-08-12 klockan 21:17 +0200 skrev Michael Niedermayer:
> > > > > Fixes: Timeout (12sec -> 32ms)
> > > > > Fixes: 16078/clusterfuzz-testcase-minimized-
> > > > > ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5695832885559296
> > > > > [...]
> > > > > +if (s->size < (s->avctx->width * s->avctx->height) / (4*4*8))
> > > > > +return AVERROR_INVALIDDATA;
> > > >
> > > > This is wrong if num_strips == 0, and if the MB area is != 0 mod 8. You
> > > > could merge it with the check above into something like:
> > > >
> > > > if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12 +
> > > > (num_strips ? ((s->avctx->width * s->avctx->height) / 16 + 7)/8 :
> > > > 0)) {
> > > > return AVERROR_INVALIDDATA;
> > > > }
> > > >
> > > > The check further down could also check each strip's size, not just the
> > > > first one.
> > >
> > > Actually, thinking a bit more about this, I suspect it might be legal
> > > to have strips that don't cover the entire frame. It would certainly be
> > > good to support that, for optimizing skip frames. Not sure what old
> > > decoders make of that however. A skip could potentially be encoded in
> > > 22 + (width/4 + 7)/8 bytes while still being compatible.
> >
> > i was asking myself the same questions before writing the patch, and
> > in the "spec" there is
> > "Each frame is segmented into 4x4 pixel blocks, and each block is coded
> > using either 1 or 4 vectors."
> > "Each" meaning no holes to me. If thats actually true for all real files
> > that i do not know.
>
> We should keep in mind the spec is fine with there being zero strips.
> It's only if one wants to support certain decoders that there will/must
> be one or more strips.
I've been playing around with the Windows 3.1 cinepak decoder, and it
seems one indeed has to code every MB even if they don't change. I
suspect the reason is because that decoder uses double buffering and
they wanted to avoid doing more memcpy()s than absolutely necessary. If
one tries to play tricks like coding strips that are only 4x4 pixels to
indicate a frame without changes then parts of the video will be
replaced by garbage. So demanding number_of_bits >= number_of_mbs is
certainly in line with that decoder.
I feel I should point out that being conservative here is at odds with
the general "best effort" approach taken in this project. These toy
codecs are useful as illustrative examples of this contradiction. I'm
sure there are many more examples of files that can cause ffmpeg to do
a lot more work than expected, for almost every codec. I know afl-fuzz
is likely to find out that it can make the ZMBV decoder do a lot of
work for a small input file, because I've seen it do that with gzip.
The user base for cinepak is of course miniscule, so I doubt anyone's
going to complain that their broken CVID files don't work any more. I
certainly don't care since cinepakenc only puts out valid files. But
again, for other formats we're just going to have to tell users to put
ffmpeg inside a sandbox and stick a CPU limit on it. Even ffprobe is
vulnerable to DoS-y things.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50
On 8/16/2019 6:31 PM, Tomas Härdin wrote:
> tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
>> Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin >> :
>>> ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
Hi Tomas,
Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin <
>>> tjop...@acc.umu.se
> :
> tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
>> Hi,
>>
>> attached patch fixes ticket #8077.
>> Please comment.
>
> Probably OK, bitrates lower than 5000 are fine in D-10 according to
> S356m.
>
>> } else if ((sc->video_bit_rate >= 4840) && (sc->video_bit_rate <=
>> 5000) && (mxf->time_base.den != 25)) {
>
> You could drop the extra parentheses, else it should be fine.
>
New patch attached.
>>>
>>> Looks OK. I'll push in a few days if no one else has any comments
>>>
>>
>> Thanks. Would you mind porting it to branches 4.1 and 4.2?
>
> I'm not quite sure what the process is for that. I have confirmed that
> the problem exists in 4.1 and 4.2 and that your patch fixes it.
>
> I think we also might want to put a note somewhere in the documentation
> how to make NTSC IMX50 files.
>
> /Tomas
Use git cherry-pick -x $hash while in the 4.1 and 4.2 branches.
If there are no conflicts, it will be applied and committed without
extra work. If there are conflicts, it will ask you to solve them and
then manually commit the changes.
There shouldn't be any conflicts with 4.2 since that branch was cut a
few weeks ago, but i can't say with 4.1 since there were several changes
since 4.1 was cut.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50
fre 2019-08-16 klockan 19:26 -0300 skrev James Almer:
> On 8/16/2019 6:31 PM, Tomas Härdin wrote:
> > tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
> > > Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin
> > > > > > :
> > > > ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
> > > > > Hi Tomas,
> > > > >
> > > > > Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin <
> > > > tjop...@acc.umu.se
> > > > > > :
> > > > > > tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
> > > > > > > Hi,
> > > > > > >
> > > > > > > attached patch fixes ticket #8077.
> > > > > > > Please comment.
> > > > > >
> > > > > > Probably OK, bitrates lower than 5000 are fine in D-10
> > > > > > according to
> > > > > > S356m.
> > > > > >
> > > > > > > } else if ((sc->video_bit_rate >= 4840) &&
> > > > > > > (sc->video_bit_rate <=
> > > > > > > 5000) && (mxf->time_base.den != 25)) {
> > > > > >
> > > > > > You could drop the extra parentheses, else it should be fine.
> > > > > >
> > > > >
> > > > > New patch attached.
> > > >
> > > > Looks OK. I'll push in a few days if no one else has any comments
> > > >
> > >
> > > Thanks. Would you mind porting it to branches 4.1 and 4.2?
> >
> > I'm not quite sure what the process is for that. I have confirmed that
> > the problem exists in 4.1 and 4.2 and that your patch fixes it.
> >
> > I think we also might want to put a note somewhere in the documentation
> > how to make NTSC IMX50 files.
> >
> > /Tomas
>
> Use git cherry-pick -x $hash while in the 4.1 and 4.2 branches.
> If there are no conflicts, it will be applied and committed without
> extra work. If there are conflicts, it will ask you to solve them and
> then manually commit the changes.
>
> There shouldn't be any conflicts with 4.2 since that branch was cut a
> few weeks ago, but i can't say with 4.1 since there were several changes
> since 4.1 was cut.
It applies fine to both 4.1 and 4.2, and master of course. I'm more
thinking in terms of what goes in the changelog, documentation and so
on. Judging by "11.1 Criteria for Point Releases" fixing a regression
like this is certainly OK, and documentation about it as well.
It's getting late, I'll think about this tomorrow.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50
On 8/16/2019 7:32 PM, Tomas Härdin wrote:
> fre 2019-08-16 klockan 19:26 -0300 skrev James Almer:
>> On 8/16/2019 6:31 PM, Tomas Härdin wrote:
>>> tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin :
> ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
>> Hi Tomas,
>>
>> Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin <
> tjop...@acc.umu.se
>>> :
>>> tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
Hi,
attached patch fixes ticket #8077.
Please comment.
>>>
>>> Probably OK, bitrates lower than 5000 are fine in D-10 according to
>>> S356m.
>>>
} else if ((sc->video_bit_rate >= 4840) && (sc->video_bit_rate <=
5000) && (mxf->time_base.den != 25)) {
>>>
>>> You could drop the extra parentheses, else it should be fine.
>>>
>>
>> New patch attached.
>
> Looks OK. I'll push in a few days if no one else has any comments
>
Thanks. Would you mind porting it to branches 4.1 and 4.2?
>>>
>>> I'm not quite sure what the process is for that. I have confirmed that
>>> the problem exists in 4.1 and 4.2 and that your patch fixes it.
>>>
>>> I think we also might want to put a note somewhere in the documentation
>>> how to make NTSC IMX50 files.
>>>
>>> /Tomas
>>
>> Use git cherry-pick -x $hash while in the 4.1 and 4.2 branches.
>> If there are no conflicts, it will be applied and committed without
>> extra work. If there are conflicts, it will ask you to solve them and
>> then manually commit the changes.
>>
>> There shouldn't be any conflicts with 4.2 since that branch was cut a
>> few weeks ago, but i can't say with 4.1 since there were several changes
>> since 4.1 was cut.
>
> It applies fine to both 4.1 and 4.2, and master of course. I'm more
> thinking in terms of what goes in the changelog, documentation and so
> on. Judging by "11.1 Criteria for Point Releases" fixing a regression
> like this is certainly OK, and documentation about it as well.
>
> It's getting late, I'll think about this tomorrow.
>
> /Tomas
Michael updates Changelog to list every backported patch at the time of
a point release, but nothing stops you from pushing a second commit to
the branches adding the line yourself if you want.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/1] avformat/matroska: fully parse stsd atom in v_quicktime tracks
On Thu, Aug 15, 2019 at 07:59:28AM +0200, Stanislav Ionascu wrote:
> Hi,
>
> On Wed, Aug 14, 2019 at 11:50 PM Michael Niedermayer
> wrote:
> >
> > On Wed, Aug 14, 2019 at 08:44:11PM +0200, Stanislav Ionascu wrote:
> > > On Tue, Aug 13, 2019 at 10:22 PM Andreas Rheinhardt
> > > wrote:
> > > >
> > > > Stanislav Ionascu:
> > > > > Per matroska spec, v_quicktime contains the complete stsd atom, after
> > > > > the mandatory size + fourcc. By properly parsing the hvcc sub-atoms of
> > > > > the track, it becomes possible to demux/decode mp4/mov tracks stored
> > > > > as is
> > > > > in matroska containers.
> > > > >
> > > > > Also dvh1 in stsd in matroska is more likely hevc codec than dv.
> > > > >
> > > > > Signed-off-by: Stanislav Ionascu
> > > > > ---
> > > > > libavformat/matroskadec.c | 51
> > > > > +++
> > > > > 1 file changed, 36 insertions(+), 15 deletions(-)
> > > > >
> > > > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> > > > > index 4e20f15792..88bc89c545 100644
> > > > > --- a/libavformat/matroskadec.c
> > > > > +++ b/libavformat/matroskadec.c
> > > > > @@ -2473,25 +2473,46 @@ static int
> > > > > matroska_parse_tracks(AVFormatContext *s)
> > > > > } else if (!strcmp(track->codec_id, "V_QUICKTIME") &&
> > > > > (track->codec_priv.size >= 21) &&
> > > > > (track->codec_priv.data)) {
> > > > > +MOVStreamContext *msc;
> > > > > +MOVContext *mc = NULL;
> > > > > +AVIOContext *stsd_ctx = NULL;
> > > > > +void *priv_data;
> > > > > +int nb_streams;
> > > > > int ret = get_qt_codec(track, &fourcc, &codec_id);
> > > > > if (ret < 0)
> > > > > return ret;
> > > > > -if (codec_id == AV_CODEC_ID_NONE &&
> > > > > AV_RL32(track->codec_priv.data+4) == AV_RL32("SMI ")) {
> > > > > -fourcc = MKTAG('S','V','Q','3');
> > > > > -codec_id = ff_codec_get_id(ff_codec_movvideo_tags,
> > > > > fourcc);
> > > > > +av_log(matroska->ctx, AV_LOG_TRACE,
> > > > > + "FourCC found %s.\n", av_fourcc2str(fourcc));
> > > > > +priv_data = st->priv_data;
> > > > > +nb_streams = s->nb_streams;
> > > > > +mc = av_mallocz(sizeof(*mc));
> > > > > +if (!mc)
> > > > > +return AVERROR(ENOMEM);
> > > > > +stsd_ctx = avio_alloc_context(track->codec_priv.data,
> > > > > +track->codec_priv.size,
> > > > > +0, NULL, NULL, NULL, NULL);
> > > > > +if (!stsd_ctx)
> > > > > +return AVERROR(ENOMEM);
> > > > I haven't looked at this patch deeply yet, but it seems to me that you
> > > > should rather use ffio_init_context like it is done in the code that
> > > > you intend to delete. That saves allocating and freeing stsd_ctx. You
> > > > can even reuse the AVIOContext b that already exists on the stack.
> > >
> > > Done.
> > >
> > > > > +mc->fc = s;
> > > > > +st->priv_data = msc =
> > > > > av_mallocz(sizeof(MOVStreamContext));
> > > > > +if (!msc) {
> > > > > +av_free(mc);
> > > > > +st->priv_data = priv_data;
> > > > > +return AVERROR(ENOMEM);
> > > > > }
> > > > > -if (codec_id == AV_CODEC_ID_NONE)
> > > > > -av_log(matroska->ctx, AV_LOG_ERROR,
> > > > > - "mov FourCC not found %s.\n",
> > > > > av_fourcc2str(fourcc));
> > > > > -if (track->codec_priv.size >= 86) {
> > > > > -bit_depth = AV_RB16(track->codec_priv.data + 82);
> > > > > -ffio_init_context(&b, track->codec_priv.data,
> > > > > - track->codec_priv.size,
> > > > > - 0, NULL, NULL, NULL, NULL);
> > > > > -if (ff_get_qtpalette(codec_id, &b, track->palette)) {
> > > > > -bit_depth &= 0x1F;
> > > > > -track->has_palette = 1;
> > > > Why are you removing this code? What about tracks that ought to have a
> > > > palette?
> > >
> > > The palette parsing is done in the stsd parser, but it still has to be
> > > copied back into the track,
> > > which is done in the later patch.
> > >
> > > > > -}
> > > > > +/* ff_mov_read_stsd_entries updates stream
> > > > > s->nb_streams-1,
> > > > > + * so set it temporarily to indicate which stream to
> > > > > update. */
> > > > > +s->nb_streams = st->index + 1;
> > > > > +ff_mov_read_stsd_entries(mc, stsd_ctx, 1);
> > > > > +av_free(msc);
> > > > > +av_free(mc);
> > > > > +avio_context_free(&stsd_ctx);
> > > > > +st->priv_data = priv_data;
> > > > > +s->n
[FFmpeg-devel] [PATCH v1] avcodec/h264_mp4toannexb_bsf: force sps/pps writing before the first pict
Hi,
This patch is trying to fix #6869.
The ticket has a h264 stream NOT starting with IDR, and all frames are I
frames.
And the mp4toannexb filter insert SPS/PPS before IDR, so leads to the
result that the output has no SPS/PPS.
The fix is just simply insert SPS/PPS before first picture, no matter what
type it is. Thanks.
Best Regards
-Jun
From 052674e9d4e2e6cf29141858b6cdc707fb75ecb1 Mon Sep 17 00:00:00 2001
From: Jun Li
Date: Fri, 16 Aug 2019 15:08:23 -0700
Subject: [PATCH v1] avcodec/h264_mp4toannexb_bsf: force sps/pps writing before
the first pict
Fix #6869, write sps/pps before the first picture nal, no matter what type
of picture it is.
---
libavcodec/h264_mp4toannexb_bsf.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c b/libavcodec/h264_mp4toannexb_bsf.c
index fb3f24ea40..e616c4c210 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -36,6 +36,7 @@ typedef struct H264BSFContext {
uint8_t idr_sps_seen;
uint8_t idr_pps_seen;
int extradata_parsed;
+int first_pict;
} H264BSFContext;
static int alloc_and_copy(AVPacket *out,
@@ -160,6 +161,7 @@ static int h264_mp4toannexb_init(AVBSFContext *ctx)
s->idr_sps_seen = 0;
s->idr_pps_seen = 0;
s->extradata_parsed = 1;
+s->first_pict = 0;
} else {
av_log(ctx, AV_LOG_ERROR, "Invalid extradata size: %d\n", extra_size);
return AVERROR_INVALIDDATA;
@@ -207,6 +209,9 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *out)
buf += s->length_size;
unit_type = *buf & 0x1f;
+if (!s->first_pict && (unit_type == H264_NAL_IDR_SLICE || unit_type == H264_NAL_SLICE))
+s->first_pict = 1;
+
if (nal_size > buf_end - buf || nal_size < 0)
goto fail;
@@ -236,15 +241,15 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *out)
if (!s->new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] & 0x80))
s->new_idr = 1;
-/* prepend only to the first type 5 NAL unit of an IDR picture, if no sps/pps are already present */
-if (s->new_idr && unit_type == H264_NAL_IDR_SLICE && !s->idr_sps_seen && !s->idr_pps_seen) {
+/* prepend only to the first type 5 NAL unit of an IDR picture or the first pict NAL of the entire stream, if no sps/pps are already present */
+if ((s->new_idr && unit_type == H264_NAL_IDR_SLICE || s->first_pict == 1) && !s->idr_sps_seen && !s->idr_pps_seen) {
if ((ret=alloc_and_copy(out,
ctx->par_out->extradata, ctx->par_out->extradata_size,
buf, nal_size, 1)) < 0)
goto fail;
s->new_idr = 0;
/* if only SPS has been seen, also insert PPS */
-} else if (s->new_idr && unit_type == H264_NAL_IDR_SLICE && s->idr_sps_seen && !s->idr_pps_seen) {
+} else if ((s->new_idr && unit_type == H264_NAL_IDR_SLICE || s->first_pict == 1) && s->idr_sps_seen && !s->idr_pps_seen) {
if (s->pps_offset == -1) {
av_log(ctx, AV_LOG_WARNING, "PPS not present in the stream, nor in AVCC, stream may be unreadable\n");
if ((ret = alloc_and_copy(out, NULL, 0, buf, nal_size, 0)) < 0)
@@ -263,6 +268,10 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, AVPacket *out)
}
}
+/* first picture has been found, set the flag to -1 */
+if (s->first_pict == 1)
+s->first_pict = -1;
+
next_nal:
buf+= nal_size;
cumul_size += nal_size + s->length_size;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1] avcodec/h264_mp4toannexb_bsf: force sps/pps writing before the first pict
Fix #6869, write sps/pps before the first picture nal, no matter what type
of picture it is.
---
libavcodec/h264_mp4toannexb_bsf.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
index fb3f24ea40..e616c4c210 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -36,6 +36,7 @@ typedef struct H264BSFContext {
uint8_t idr_sps_seen;
uint8_t idr_pps_seen;
int extradata_parsed;
+int first_pict;
} H264BSFContext;
static int alloc_and_copy(AVPacket *out,
@@ -160,6 +161,7 @@ static int h264_mp4toannexb_init(AVBSFContext *ctx)
s->idr_sps_seen = 0;
s->idr_pps_seen = 0;
s->extradata_parsed = 1;
+s->first_pict = 0;
} else {
av_log(ctx, AV_LOG_ERROR, "Invalid extradata size: %d\n", extra_size);
return AVERROR_INVALIDDATA;
@@ -207,6 +209,9 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
buf += s->length_size;
unit_type = *buf & 0x1f;
+if (!s->first_pict && (unit_type == H264_NAL_IDR_SLICE || unit_type ==
H264_NAL_SLICE))
+s->first_pict = 1;
+
if (nal_size > buf_end - buf || nal_size < 0)
goto fail;
@@ -236,15 +241,15 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
if (!s->new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] & 0x80))
s->new_idr = 1;
-/* prepend only to the first type 5 NAL unit of an IDR picture, if no
sps/pps are already present */
-if (s->new_idr && unit_type == H264_NAL_IDR_SLICE && !s->idr_sps_seen
&& !s->idr_pps_seen) {
+/* prepend only to the first type 5 NAL unit of an IDR picture or the
first pict NAL of the entire stream, if no sps/pps are already present */
+if ((s->new_idr && unit_type == H264_NAL_IDR_SLICE || s->first_pict ==
1) && !s->idr_sps_seen && !s->idr_pps_seen) {
if ((ret=alloc_and_copy(out,
ctx->par_out->extradata,
ctx->par_out->extradata_size,
buf, nal_size, 1)) < 0)
goto fail;
s->new_idr = 0;
/* if only SPS has been seen, also insert PPS */
-} else if (s->new_idr && unit_type == H264_NAL_IDR_SLICE &&
s->idr_sps_seen && !s->idr_pps_seen) {
+} else if ((s->new_idr && unit_type == H264_NAL_IDR_SLICE ||
s->first_pict == 1) && s->idr_sps_seen && !s->idr_pps_seen) {
if (s->pps_offset == -1) {
av_log(ctx, AV_LOG_WARNING, "PPS not present in the stream,
nor in AVCC, stream may be unreadable\n");
if ((ret = alloc_and_copy(out, NULL, 0, buf, nal_size, 0)) < 0)
@@ -263,6 +268,10 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
}
}
+/* first picture has been found, set the flag to -1 */
+if (s->first_pict == 1)
+s->first_pict = -1;
+
next_nal:
buf+= nal_size;
cumul_size += nal_size + s->length_size;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/matroskadec: Fix seeking
matroska_reset_status (a function that is used during seeking (among
other things)) used an int for the return value of avio_seek which
returns an int64_t. Checking the return value then indicated an error
even though the seek was successfull for targets in the range of
2GB-4GB, 6GB-8GB, ... This error implied that the status hasn't been
reset and in particular, the old level was still considered to be in
force, so that ebml_parse returned errors because the newly parsed
elements were of course not contained in the previously active and still
wrongly considered active master element any more.
Addresses ticket #8084.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 4e20f15792..1ea9b807e6 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -757,7 +757,7 @@ static int matroska_reset_status(MatroskaDemuxContext
*matroska,
uint32_t id, int64_t position)
{
if (position >= 0) {
-int err = avio_seek(matroska->ctx->pb, position, SEEK_SET);
+int64_t err = avio_seek(matroska->ctx->pb, position, SEEK_SET);
if (err < 0)
return err;
}
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: Fix seeking
On 8/16/2019 9:27 PM, Andreas Rheinhardt wrote:
> matroska_reset_status (a function that is used during seeking (among
> other things)) used an int for the return value of avio_seek which
> returns an int64_t. Checking the return value then indicated an error
> even though the seek was successfull for targets in the range of
> 2GB-4GB, 6GB-8GB, ... This error implied that the status hasn't been
> reset and in particular, the old level was still considered to be in
> force, so that ebml_parse returned errors because the newly parsed
> elements were of course not contained in the previously active and still
> wrongly considered active master element any more.
>
> Addresses ticket #8084.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskadec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 4e20f15792..1ea9b807e6 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -757,7 +757,7 @@ static int matroska_reset_status(MatroskaDemuxContext
> *matroska,
> uint32_t id, int64_t position)
> {
> if (position >= 0) {
> -int err = avio_seek(matroska->ctx->pb, position, SEEK_SET);
> +int64_t err = avio_seek(matroska->ctx->pb, position, SEEK_SET);
> if (err < 0)
> return err;
> }
Applied and backported to release/4.2
Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 11/11] avformat/internal: Remove packet for extract_extradata
Hendrik Leppkes: > On Fri, Aug 16, 2019 at 5:22 AM Andreas Rheinhardt > wrote: >> >> The effective lifetime of the packet does not extend beyond the >> extract_extradata in libavformat/utils.c, so the packet can simply be >> put on the stack there. This allows to remove the allocation and the >> corresponding frees. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> libavformat/internal.h | 1 - >> libavformat/utils.c| 10 +- >> 2 files changed, 1 insertion(+), 10 deletions(-) >> > > AVPacket is defined in avcodec, as such using it outside of avcodec on > the stack feels rather iffy, as we try to get users to stop doing that > and unlock the size of AVPacket from the ABI. > > - Hendrik Ok, if it is the consensus that sizeof(AVPacket) should eventually not be public API any more, then this patch makes no sense of course. So I'll drop it. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/avformat.h: Correct some comments
1. When set_parameters was removed from AVOutputFormat in 2fb75019, it
was forgotten to remove the comment pertaining to it. Said comment now
appeared to apply to interleave_packet; it is of course nonsense and has
been replaced by an accurate description.
2. The description of av_write_uncoded_frame suggested
av_interleaved_write_frame as a replacement if the input is not
already correctly interleaved; it also referred to said function for
details. Given that said function can't write AVFrames and that the
stuff specific to writing uncoded frames is explained in the description
of av_interleaved_write_uncoded_frame, both references have been fixed.
3. Removed an outdated comment about avformat_seek_file.
Signed-off-by: Andreas Rheinhardt
---
Now without version bump.
libavformat/avformat.h | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 6eb329f13f..92c3a89f4b 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -556,7 +556,8 @@ typedef struct AVOutputFormat {
int (*write_packet)(struct AVFormatContext *, AVPacket *pkt);
int (*write_trailer)(struct AVFormatContext *);
/**
- * Currently only used to set pixel format if not YUV420P.
+ * A format-specific function for interleavement.
+ * If unset, packets will be interleaved by dts.
*/
int (*interleave_packet)(struct AVFormatContext *, AVPacket *out,
AVPacket *in, int flush);
@@ -2449,8 +2450,6 @@ int av_seek_frame(AVFormatContext *s, int stream_index,
int64_t timestamp,
* @return >=0 on success, error code otherwise
*
* @note This is part of the new seek API which is still under construction.
- * Thus do not use this yet. It may change at any time, do not expect
- * ABI compatibility yet!
*/
int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts,
int64_t ts, int64_t max_ts, int flags);
@@ -2637,9 +2636,9 @@ int av_interleaved_write_frame(AVFormatContext *s,
AVPacket *pkt);
* Write an uncoded frame to an output media file.
*
* The frame must be correctly interleaved according to the container
- * specification; if not, then av_interleaved_write_frame() must be used.
+ * specification; if not, av_interleaved_write_uncoded_frame() must be used.
*
- * See av_interleaved_write_frame() for details.
+ * See av_interleaved_write_uncoded_frame() for details.
*/
int av_write_uncoded_frame(AVFormatContext *s, int stream_index,
AVFrame *frame);
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
