[FFmpeg-devel] [PATCH V2] doc/ffmpeg: Document dts_error_threshold option
From: Jun Zhao
Document dts_error_threshold option.
Signed-off-by: Jun Zhao
---
doc/ffmpeg.texi |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index cd35eb4..1da18d9 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1515,6 +1515,10 @@ Enable bitexact mode for (de)muxer and (de/en)coder
Finish encoding when the shortest input stream ends.
@item -dts_delta_threshold
Timestamp discontinuity delta threshold.
+@item -dts_error_threshold @var{seconds}
+Timestamp error delta threshold. This threshold use to discard crazy/damaged
+timestamps and the default is 30 hours which is arbitrarily picked and quite
+conservative.
@item -muxdelay @var{seconds} (@emph{output})
Set the maximum demux-decode delay.
@item -muxpreload @var{seconds} (@emph{output})
--
1.7.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] lavf/showinfo: support mastering display sidedata
From: Jun Zhao
support mastering display sidedata.
Signed-off-by: Jun Zhao
---
libavfilter/vf_showinfo.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index f6f8f49..8889c01 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -34,6 +34,7 @@
#include "libavutil/stereo3d.h"
#include "libavutil/timestamp.h"
#include "libavutil/timecode.h"
+#include "libavutil/mastering_display_metadata.h"
#include "avfilter.h"
#include "internal.h"
@@ -133,6 +134,32 @@ static void dump_roi(AVFilterContext *ctx, AVFrameSideData
*sd)
}
}
+static void dump_mastering_display(AVFilterContext *ctx, AVFrameSideData *sd)
+{
+AVMasteringDisplayMetadata *mastering_display;
+
+av_log(ctx, AV_LOG_INFO, "mastering display: ");
+if (sd->size < sizeof(*mastering_display)) {
+av_log(ctx, AV_LOG_INFO, "invalid data");
+return;
+}
+
+mastering_display = (AVMasteringDisplayMetadata *)sd->data;
+
+av_log(ctx, AV_LOG_INFO, "has_primaries:%d has_luminance:%d "
+ "r(%5.4f,%5.4f) g(%5.4f,%5.4f) b(%5.4f %5.4f) wp(%5.4f, %5.4f) "
+ "min_luminance=%f, max_luminance=%f",
+ mastering_display->has_primaries, mastering_display->has_luminance,
+ av_q2d(mastering_display->display_primaries[0][0]),
+ av_q2d(mastering_display->display_primaries[0][1]),
+ av_q2d(mastering_display->display_primaries[1][0]),
+ av_q2d(mastering_display->display_primaries[1][1]),
+ av_q2d(mastering_display->display_primaries[2][0]),
+ av_q2d(mastering_display->display_primaries[2][1]),
+ av_q2d(mastering_display->white_point[0]),
av_q2d(mastering_display->white_point[1]),
+ av_q2d(mastering_display->min_luminance),
av_q2d(mastering_display->max_luminance));
+}
+
static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
{
const char *color_range_str = av_color_range_name(frame->color_range);
@@ -271,6 +298,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
case AV_FRAME_DATA_REGIONS_OF_INTEREST:
dump_roi(ctx, sd);
break;
+case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA:
+dump_mastering_display(ctx, sd);
+break;
default:
av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d bytes)",
sd->type, sd->size);
--
1.7.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] avformat/assenc: Don't truncate lines to 4095 characters
On Sat, 3 Aug 2019, Tellow Krinkle wrote: Fixes #6390 Sample file for new test: https://gist.githubusercontent.com/tellowkrinkle/d6a6e328f892dbbacc000ad9c3890644/raw/4f68e56b1f0fab594aae040723722af4f5161a02/longline.ass Signed-off-by: Tellow Krinkle --- libavformat/assenc.c | 4 +++- tests/fate/subtitles.mak | 4 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/libavformat/assenc.c b/libavformat/assenc.c index d50f18feb1..9b44b16597 100644 --- a/libavformat/assenc.c +++ b/libavformat/assenc.c @@ -95,7 +95,9 @@ static void purge_dialogues(AVFormatContext *s, int force) ass->expected_readorder, dialogue->readorder); ass->expected_readorder = dialogue->readorder; } -avio_printf(s->pb, "Dialogue: %s\r\n", dialogue->line); +avio_write(s->pb, "Dialogue: ", 10); +avio_write(s->pb, dialogue->line, strlen(dialogue->line)); +avio_write(s->pb, "\r\n", 2); IMHO avio_printf should be fixed instead to use an AVBPrint buffer, this should remove the 4k limit from it. Regards, Marton ___ 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 V1] lavf/showinfo: support mastering display sidedata
> 在 2019年8月4日，18:30，Jun Zhao 写道：
>
> From: Jun Zhao
>
> support mastering display sidedata.
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/vf_showinfo.c | 30 ++
> 1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> index f6f8f49..8889c01 100644
> --- a/libavfilter/vf_showinfo.c
> +++ b/libavfilter/vf_showinfo.c
> @@ -34,6 +34,7 @@
> #include "libavutil/stereo3d.h"
> #include "libavutil/timestamp.h"
> #include "libavutil/timecode.h"
> +#include "libavutil/mastering_display_metadata.h"
>
> #include "avfilter.h"
> #include "internal.h"
> @@ -133,6 +134,32 @@ static void dump_roi(AVFilterContext *ctx,
> AVFrameSideData *sd)
>}
> }
>
> +static void dump_mastering_display(AVFilterContext *ctx, AVFrameSideData *sd)
> +{
> +AVMasteringDisplayMetadata *mastering_display;
> +
> +av_log(ctx, AV_LOG_INFO, "mastering display: ");
> +if (sd->size < sizeof(*mastering_display)) {
> +av_log(ctx, AV_LOG_INFO, "invalid data”);
Why don’t use ERROR level if it is invalid data?
> +return;
> +}
> +
> +mastering_display = (AVMasteringDisplayMetadata *)sd->data;
> +
> +av_log(ctx, AV_LOG_INFO, "has_primaries:%d has_luminance:%d "
> + "r(%5.4f,%5.4f) g(%5.4f,%5.4f) b(%5.4f %5.4f) wp(%5.4f, %5.4f) "
> + "min_luminance=%f, max_luminance=%f",
> + mastering_display->has_primaries,
> mastering_display->has_luminance,
> + av_q2d(mastering_display->display_primaries[0][0]),
> + av_q2d(mastering_display->display_primaries[0][1]),
> + av_q2d(mastering_display->display_primaries[1][0]),
> + av_q2d(mastering_display->display_primaries[1][1]),
> + av_q2d(mastering_display->display_primaries[2][0]),
> + av_q2d(mastering_display->display_primaries[2][1]),
> + av_q2d(mastering_display->white_point[0]),
> av_q2d(mastering_display->white_point[1]),
> + av_q2d(mastering_display->min_luminance),
> av_q2d(mastering_display->max_luminance));
> +}
> +
> static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> {
>const char *color_range_str = av_color_range_name(frame->color_range);
> @@ -271,6 +298,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *frame)
>case AV_FRAME_DATA_REGIONS_OF_INTEREST:
>dump_roi(ctx, sd);
>break;
> +case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA:
> +dump_mastering_display(ctx, sd);
> +break;
>default:
>av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d bytes)",
> sd->type, sd->size);
> --
> 1.7.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".
Thanks
刘歧|CDN|研发总监
吉林省高升科技有限公司北京分公司
地址：北京市海淀区西三环北路87号国际财经中心B座9层
手机：18611075131
邮箱: li...@gosun.com
电话：010-82602628
Thanks
Steven
___
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] FFmpeg 4.2
On 04.08.2019 07:56, Michael Niedermayer wrote: On Sun, Jul 21, 2019 at 07:11:40PM +0200, Michael Niedermayer wrote: On Mon, May 20, 2019 at 08:39:45PM +0200, Michael Niedermayer wrote: Hi Its quite some time since 4.1 so its probably getting time to branch 4.2. If there are any bugs you want fixed in 4.2 its probably a good idea to fix them soon. Are there any suggestions for a name ? If not ill pick something from unused past suggestions. If there are no objections i will likely make that release in the next weeks 4.2 branch made i intend to make the 4.2 release from HEAD of release/4.2 in the next 1-2 weeks please backport any relevant bugfixes to it. Status update: There are a few remaining crashes / security issues which i think we should fix and include before the release. Iam working on that currently. When thats done depends on 1. any delays (bikesheds, distractions, headaches, good weather that makes me ignore this and go for a walk or maybe going for a walk occasionally actually helps my efficiency who knows, ...) 2. influx of more security reports (fuzzer and any human reports), there where several new reports in the last 2 weeks which fall in the "I think that should be fixed before the release" category 3. murphies law and anything else unexpected Thanks I would kinda like to have the h263 hwaccel fix in for 4.2. It's a one line patch that unbreaks it for all hwaccel backends. smime.p7s Description: S/MIME Cryptographic 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] avformat/assenc: Don't truncate lines to 4095 characters
On Sun, Aug 4, 2019 at 12:54 PM Marton Balint wrote: > > > On Sat, 3 Aug 2019, Tellow Krinkle wrote: > > > Fixes #6390 > > > > Sample file for new test: > https://gist.githubusercontent.com/tellowkrinkle/d6a6e328f892dbbacc000ad9c3890644/raw/4f68e56b1f0fab594aae040723722af4f5161a02/longline.ass > > > > Signed-off-by: Tellow Krinkle > > --- > > libavformat/assenc.c | 4 +++- > > tests/fate/subtitles.mak | 4 > > 2 files changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/libavformat/assenc.c b/libavformat/assenc.c > > index d50f18feb1..9b44b16597 100644 > > --- a/libavformat/assenc.c > > +++ b/libavformat/assenc.c > > @@ -95,7 +95,9 @@ static void purge_dialogues(AVFormatContext *s, int > force) > >ass->expected_readorder, dialogue->readorder); > > ass->expected_readorder = dialogue->readorder; > > } > > -avio_printf(s->pb, "Dialogue: %s\r\n", dialogue->line); > > +avio_write(s->pb, "Dialogue: ", 10); > > +avio_write(s->pb, dialogue->line, strlen(dialogue->line)); > > +avio_write(s->pb, "\r\n", 2); > > IMHO avio_printf should be fixed instead to use an AVBPrint buffer, this > should remove the 4k limit from it. > That is unrelated issue. Using avio_printf in this specific case is overkill. > > Regards, > Marton > ___ > 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] avformat/assenc: Don't truncate lines to 4095 characters
On Sun, 4 Aug 2019, Paul B Mahol wrote: On Sun, Aug 4, 2019 at 12:54 PM Marton Balint wrote: On Sat, 3 Aug 2019, Tellow Krinkle wrote: > Fixes #6390 > > Sample file for new test: https://gist.githubusercontent.com/tellowkrinkle/d6a6e328f892dbbacc000ad9c3890644/raw/4f68e56b1f0fab594aae040723722af4f5161a02/longline.ass > > Signed-off-by: Tellow Krinkle > --- > libavformat/assenc.c | 4 +++- > tests/fate/subtitles.mak | 4 > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/libavformat/assenc.c b/libavformat/assenc.c > index d50f18feb1..9b44b16597 100644 > --- a/libavformat/assenc.c > +++ b/libavformat/assenc.c > @@ -95,7 +95,9 @@ static void purge_dialogues(AVFormatContext *s, int force) >ass->expected_readorder, dialogue->readorder); > ass->expected_readorder = dialogue->readorder; > } > -avio_printf(s->pb, "Dialogue: %s\r\n", dialogue->line); > +avio_write(s->pb, "Dialogue: ", 10); > +avio_write(s->pb, dialogue->line, strlen(dialogue->line)); > +avio_write(s->pb, "\r\n", 2); IMHO avio_printf should be fixed instead to use an AVBPrint buffer, this should remove the 4k limit from it. That is unrelated issue. Using avio_printf in this specific case is overkill. Using 3 avio_writes instead is a useless micro optimalization which also reduces readblity, but feel free to apply if you feel stong about it. Regards, Marton ___ 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/assenc: Don't truncate lines to 4095 characters
On Sun, Aug 4, 2019 at 2:58 PM Marton Balint wrote: > > > On Sun, 4 Aug 2019, Paul B Mahol wrote: > > > On Sun, Aug 4, 2019 at 12:54 PM Marton Balint wrote: > > > >> > >> > >> On Sat, 3 Aug 2019, Tellow Krinkle wrote: > >> > >> > Fixes #6390 > >> > > >> > Sample file for new test: > >> > https://gist.githubusercontent.com/tellowkrinkle/d6a6e328f892dbbacc000ad9c3890644/raw/4f68e56b1f0fab594aae040723722af4f5161a02/longline.ass > >> > > >> > Signed-off-by: Tellow Krinkle > >> > --- > >> > libavformat/assenc.c | 4 +++- > >> > tests/fate/subtitles.mak | 4 > >> > 2 files changed, 7 insertions(+), 1 deletion(-) > >> > > >> > diff --git a/libavformat/assenc.c b/libavformat/assenc.c > >> > index d50f18feb1..9b44b16597 100644 > >> > --- a/libavformat/assenc.c > >> > +++ b/libavformat/assenc.c > >> > @@ -95,7 +95,9 @@ static void purge_dialogues(AVFormatContext *s, int > >> force) > >> >ass->expected_readorder, dialogue->readorder); > >> > ass->expected_readorder = dialogue->readorder; > >> > } > >> > -avio_printf(s->pb, "Dialogue: %s\r\n", dialogue->line); > >> > +avio_write(s->pb, "Dialogue: ", 10); > >> > +avio_write(s->pb, dialogue->line, strlen(dialogue->line)); > >> > +avio_write(s->pb, "\r\n", 2); > >> > >> IMHO avio_printf should be fixed instead to use an AVBPrint buffer, this > >> should remove the 4k limit from it. > >> > > > > That is unrelated issue. Using avio_printf in this specific case is > > overkill. > > Using 3 avio_writes instead is a useless micro optimalization which also > reduces readblity, but feel free to apply if you feel stong about it. > I doubt so, make actual benchmark to prove your claims. Allocation + memcpy is slower than direct writing. > > Regards, > Marton > ___ > 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] FFmpeg 4.2
On 8/4/2019 8:08 AM, Timo Rothenpieler wrote: > On 04.08.2019 07:56, Michael Niedermayer wrote: >> On Sun, Jul 21, 2019 at 07:11:40PM +0200, Michael Niedermayer wrote: >>> On Mon, May 20, 2019 at 08:39:45PM +0200, Michael Niedermayer wrote: Hi Its quite some time since 4.1 so its probably getting time to branch 4.2. If there are any bugs you want fixed in 4.2 its probably a good idea to fix them soon. Are there any suggestions for a name ? If not ill pick something from unused past suggestions. If there are no objections i will likely make that release in the next weeks >>> >>> 4.2 branch made >>> i intend to make the 4.2 release from HEAD of release/4.2 in the next >>> 1-2 weeks >>> please backport any relevant bugfixes to it. >> >> Status update: There are a few remaining crashes / security issues >> which i think >> we should fix and include before the release. Iam working on that >> currently. >> >> When thats done depends on >> 1. any delays (bikesheds, distractions, headaches, good weather that >> makes me ignore >> this and go for a walk or maybe going for a walk occasionally >> actually helps >> my efficiency who knows, ...) >> 2. influx of more security reports (fuzzer and any human reports), >> there where >> several new reports in the last 2 weeks which fall in the "I think >> that should >> be fixed before the release" category >> 3. murphies law and anything else unexpected >> >> Thanks > > I would kinda like to have the h263 hwaccel fix in for 4.2. > It's a one line patch that unbreaks it for all hwaccel backends. Just backport it. As long as it's not something that changes the API with a version bump (Since that's already frozen in the release/4.2 branch), it should be fine. ___ 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] Fixing HW accelerated decoders hanging or throwing error in h263dec
On 02.08.2019 11:18, Stefan Schoenefeld wrote: Hi all, Recently we encountered an issue when decoding a h.263 file: FFmpeg will freeze when decoding h.263 video with NVDEC. Turns out this is not directly related to NVDEC but is a problem that shows with several other HW decoders like VDPAU, though the exact kind of error is different (either error messages or freezing[1]). The root cause is that ff_thread_finish_setup() is called twice per frame from ff_h263_decode_frame(). This is not supported by ff_thread_finish_setup() and specifically checked for and warned against in the functions code. The issue is also specific to hw accelerated decoding only as the second call to ff_thread_finish_setup() is only issued when hw acceleration is on. The fix is simple: add a check that the first call is only send when hw acceleration is off, and the second call only when hw acceleration is on (see attached patch). This works fine as far as I was able to test with vdpau and nvdec/nvcuvid hw decoding. The patch also adds NVDEC to the hw config list if available. I also noticed a secondary issue when browsing through the code which is that, according to documentation, ff_thread_finish_setup() should only be called if the codec implements update_thread_context(), which h263dec does not. The patch does not address this and I'm not sure any action needs to be taken here at all. Thanks, Stefan [1] This is depending on whether or not the hw decoder sets the HWACCEL_CAPS_ASYNC_SAFE flag Split in two, applied and backported to relevant branches. smime.p7s Description: S/MIME Cryptographic 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] [PATCHv2 1/4] avformat/mpegtsenc: fix incorrect PCR selection with multiple programs
Hi Marton,
‐‐‐ Original Message ‐‐‐
> v2: a video is stream is preferred if there are no programs, just like before
> the patch.
Thank you for your effort!
However, something is wrong with this patch regarding PCR intervals.
First, try this example (using the file shared by Michael
https://trac.ffmpeg.org/raw-attachment/ticket/3714/FFmpeg%20Sample_cut.ts ):
% ffmpeg -loglevel info -y -i Sample_cut.ts \
-map '0:v:0' -c:v:0 copy \
-map '0:v:0' -c:v:1 copy \
-map '0:a:0' -c:a:0 copy \
-pat_period 1 \
-program st=0,1,2 \
-program st=0,2 \
-program st=1,2 \
-program st=3 \
-sdt_period 1 \
this_was_less_than_256-marton.ts
Then you get:
[mpegts @ 0x3046880] service 1 using PCR in pid=256
[mpegts @ 0x3046880] service 2 using PCR in pid=256
[mpegts @ 0x3046880] service 3 using PCR in pid=257
[mpegts @ 0x3046880] service 4 using PCR in pid=258
Until here all seems correct.
However, if you analyze the PCR intervals:
- 256: PCR_count: 0x3 (3) => repetition rate: 0,299 seconds
- 257: PCR_count: 0x3 (3) => repetition rate: 0,305 seconds
- 258: PCR_count: 0x4 (4) => repetition rate: 0,139 seconds
(You can check it with the DVB Inspector tool or any other)
And regular repetition rate are 0,450 seconds (with ffmpeg).
So...
> @@ -57,8 +57,6 @@ typedef struct MpegTSService {
> uint8_t name[256];
> uint8_t provider_name[256];
> int pcr_pid;
>
> - int pcr_packet_count;
> - int pcr_packet_period;
> AVProgram *program;
> } MpegTSService;
Why you remove the "pcr_packet_period" from services?
I know that the value can be the same for all services inside the
same TS, but the PCR interval is per service, and not per TS.
> @@ -1015,8 +1032,7 @@ static int mpegts_init(AVFormatContext *s)
> else
> av_log(s, AV_LOG_VERBOSE, "muxrate %d, ", ts->mux_rate);
> av_log(s, AV_LOG_VERBOSE,
> - "pcr every %d pkts, sdt every %d, pat/pmt every %d pkts\\n",
> - service->pcr_packet_period,
> + "sdt every %d, pat/pmt every %d pkts\\n",
> ts->sdt_packet_period, ts->pat_packet_period);
The information about the PCR interval is a must have. Please, don't remove it!
> @@ -1198,12 +1214,12 @@ static void mpegts_write_pes(AVFormatContext *s,
> AVStream *st,
> force_pat = 0;
> write_pcr = 0;
> - if (ts_st->pid == ts_st->service->pcr_pid) {
> + if (ts_st->pcr_packet_period) {
>if (ts->mux_rate > 1 || is_start) // VBR pcr period is based
> on frames
> - ts_st->service->pcr_packet_count++;
> - if (ts_st->service->pcr_packet_count >=
> - ts_st->service->pcr_packet_period) {
> - ts_st->service->pcr_packet_count = 0;
> + ts_st->pcr_packet_count++;
> + if (ts_st->pcr_packet_count >=
> + ts_st->pcr_packet_period) {
> + ts_st->pcr_packet_count = 0;
>}
>}
In this way, with multiple services (the reason for this patch) you're
generating a
Transport Stream with PCR streams sharing the interval period. That's a new
serious BUG!
For each service it's one PCR. And the interval of each PCR for one stream is
computed from the last PCR of the same stream. It can't be calculated from the
last
PCR of any other stream.
Please, fix this bug before merging this patch.
> @@ -1236,7 +1252,7 @@ static void mpegts_write_pes(AVFormatContext *s,
> AVStream *st,
> }
> if (key && is_start && pts != AV_NOPTS_VALUE) {
> // set Random Access for key frames
>
> - if (ts_st->pid == ts_st->service->pcr_pid)
> + if (ts_st->pcr_packet_period)
>write_pcr = 1;
>set_af_flag(buf, 0x40);
>q = get_ts_payload_start(buf);
Just the same problem.
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] avformat/assenc: Don't truncate lines to 4095 characters
On Sun, 4 Aug 2019, Paul B Mahol wrote:
On Sun, Aug 4, 2019 at 2:58 PM Marton Balint wrote:
On Sun, 4 Aug 2019, Paul B Mahol wrote:
> On Sun, Aug 4, 2019 at 12:54 PM Marton Balint wrote:
>
>>
>>
>> On Sat, 3 Aug 2019, Tellow Krinkle wrote:
>>
>> > Fixes #6390
>> >
>> > Sample file for new test:
>>
https://gist.githubusercontent.com/tellowkrinkle/d6a6e328f892dbbacc000ad9c3890644/raw/4f68e56b1f0fab594aae040723722af4f5161a02/longline.ass
>> >
>> > Signed-off-by: Tellow Krinkle
>> > ---
>> > libavformat/assenc.c | 4 +++-
>> > tests/fate/subtitles.mak | 4
>> > 2 files changed, 7 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/libavformat/assenc.c b/libavformat/assenc.c
>> > index d50f18feb1..9b44b16597 100644
>> > --- a/libavformat/assenc.c
>> > +++ b/libavformat/assenc.c
>> > @@ -95,7 +95,9 @@ static void purge_dialogues(AVFormatContext *s, int
>> force)
>> >ass->expected_readorder, dialogue->readorder);
>> > ass->expected_readorder = dialogue->readorder;
>> > }
>> > -avio_printf(s->pb, "Dialogue: %s\r\n", dialogue->line);
>> > +avio_write(s->pb, "Dialogue: ", 10);
>> > +avio_write(s->pb, dialogue->line, strlen(dialogue->line));
>> > +avio_write(s->pb, "\r\n", 2);
>>
>> IMHO avio_printf should be fixed instead to use an AVBPrint buffer, this
>> should remove the 4k limit from it.
>>
>
> That is unrelated issue. Using avio_printf in this specific case is
> overkill.
Using 3 avio_writes instead is a useless micro optimalization which also
reduces readblity, but feel free to apply if you feel stong about it.
I doubt so, make actual benchmark to prove your claims.
Allocation + memcpy is slower than direct writing.
And considering the size of ASS files (a few hundred KB) it will not be
measureable overall, only if you benchmark the actual function.
If you are really concerened, we could add a function like this:
int avio_print_n_strings(AVIOContext *s, int nb_strings, ...)
{
va_list ap;
int ret = 0;
va_start(ap, nb_strings);
for (int i = 0; i < nb_strings; i++) {
const char *str = va_arg(ap, const char *);
int len = strlen(str);
avio_write(s, (const unsigned char *)str, len);
ret += len;
}
va_end(ap);
return ret;
}
/**
* Write nb_strings number of strings (const char *) to the context.
*/
#define avio_print(s, ...) avio_print_n_strings(s, sizeof((const
char*[]){__VA_ARGS__}) / sizeof(const char*), __VA_ARGS__);
So from ASSenc you could use:
avio_print(s->pb, "Dialogue: ", dialogue->line, "\r\n");
Regards,
Marton
___
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] [RFC] samples.ffmpeg.org
On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer wrote: > Hi all > > It seems we do not have a list of people volunteering to do uploads to > samples. And no place to send such requests to except here, where they > sometimes get ignored. > Just give everyone with push access right to upload. 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".
[FFmpeg-devel] [PATCH 01/13] avcodec/apedec: Do not partially clear data array
Fixes: Assertion failure and memleak
Fixes:
15709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5182435093905408
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/apedec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index e9ffdfdcdf..8872185b84 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1451,7 +1451,8 @@ static int ape_decode_frame(AVCodecContext *avctx, void
*data,
if (s->fileversion >= 3900) {
if (offset > 3) {
av_log(avctx, AV_LOG_ERROR, "Incorrect offset passed\n");
-s->data = NULL;
+av_freep(&s->data);
+s->data_size = 0;
return AVERROR_INVALIDDATA;
}
if (s->data_end - s->ptr < offset) {
--
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 03/13] avcodec/mss3: Check for the rac stream being invalid in rac_normalize()
Fixes: out of array read
Fixes:
15982/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSA1_fuzzer-5630676251967488
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mss3.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/mss3.c b/libavcodec/mss3.c
index 21226f9085..02bd360996 100644
--- a/libavcodec/mss3.c
+++ b/libavcodec/mss3.c
@@ -298,6 +298,10 @@ static void rac_normalise(RangeCoder *c)
c->got_error = 1;
c->low = 1;
}
+if (c->low > c->range) {
+c->got_error = 1;
+c->low = 1;
+}
if (c->range >= RAC_BOTTOM)
return;
}
--
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 07/13] avcodec/cfhd: Check destination space for bayer before writing
Fixes: out of array write
Fixes:
16105/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5690817309573120
Fixes:
16119/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5099050675732480
Fixes:
16135/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5705501601431552
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cfhd.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index a162fc7da3..27eed415d1 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -963,6 +963,15 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
int *got_frame,
}
low = s->plane[plane].l_h[6];
high = s->plane[plane].l_h[7];
+
+if (avctx->pix_fmt == AV_PIX_FMT_BAYER_RGGB16 &&
+(lowpass_height * 2 > avctx->coded_height / 2 ||
+ lowpass_width * 2 > avctx->coded_width / 2)
+) {
+ret = AVERROR_INVALIDDATA;
+goto end;
+}
+
for (i = 0; i < lowpass_height * 2; i++) {
if (avctx->pix_fmt == AV_PIX_FMT_BAYER_RGGB16)
horiz_filter_clip_bayer(dst, low, high, lowpass_width,
s->bpc);
--
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 04/13] avcodec/apedec: Fix 2 signed overflows
Fixes: left shift of 1073741824 by 1 places cannot be represented in type 'int'
Fixes: signed integer overflow: 2049431315 + 262759074 cannot be represented in
type 'int'
Fixes:
16012/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5719016003338240
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/apedec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 8872185b84..70939abeb4 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -589,7 +589,7 @@ static void decode_array_(APEContext *ctx,
GetBitContext *gb,
int32_t *out, APERice *rice, int blockstodecode)
{
int i;
-int ksummax, ksummin;
+unsigned ksummax, ksummin;
rice->ksum = 0;
for (i = 0; i < FFMIN(blockstodecode, 5); i++) {
@@ -836,7 +836,7 @@ static av_always_inline int filter_fast_3320(APEPredictor
*p,
else
p->coeffsA[filter][0]--;
-p->filterA[filter] += p->lastA[filter];
+p->filterA[filter] += (unsigned)p->lastA[filter];
return p->filterA[filter];
}
--
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 12/13] avcodec/ralf: Fix integer overflow in apply_lpc()
Fixes: signed integer overflow: 1603085316 + 1238786562 cannot be represented
in type 'int'
Fixes:
16203/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RALF_fuzzer-5086088934195200
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/ralf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ralf.c b/libavcodec/ralf.c
index 3f7953c6db..0d6b57d652 100644
--- a/libavcodec/ralf.c
+++ b/libavcodec/ralf.c
@@ -323,7 +323,7 @@ static void apply_lpc(RALFContext *ctx, int ch, int length,
int bits)
acc = 0;
for (j = 0; j < flen; j++)
-acc += ctx->filter[j] * audio[i - j - 1];
+acc += (unsigned)ctx->filter[j] * audio[i - j - 1];
if (acc < 0) {
acc = (acc + bias - 1) >> ctx->filter_bits;
acc = FFMAX(acc, min_clip);
--
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 09/13] avformat/realtextdec: Check for duplicate extradata in realtext_read_header()
Fixes: memleak
Fixes:
16140/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5684008052064256
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/realtextdec.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/realtextdec.c b/libavformat/realtextdec.c
index e12871e6ad..204e557aa2 100644
--- a/libavformat/realtextdec.c
+++ b/libavformat/realtextdec.c
@@ -87,6 +87,10 @@ static int realtext_read_header(AVFormatContext *s)
/* save header to extradata */
const char *p = ff_smil_get_attr_ptr(buf.str, "duration");
+if (st->codecpar->extradata) {
+res = AVERROR_INVALIDDATA;
+goto end;
+}
if (p)
duration = read_ts(p);
st->codecpar->extradata = av_strdup(buf.str);
--
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 05/13] avcodec/cbs_av1_syntax_template: Check ref_frame_idx before use
Fixes: index -1 out of bounds for type 'AV1ReferenceFrameState [8]'
Fixes:
16079/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5758807440883712
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cbs_av1_syntax_template.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cbs_av1_syntax_template.c
b/libavcodec/cbs_av1_syntax_template.c
index b04cd51d55..806b302de6 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -419,16 +419,17 @@ static int
FUNC(frame_size_with_refs)(CodedBitstreamContext *ctx, RWContext *rw,
for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
flags(found_ref[i], 1, i);
if (current->found_ref[i]) {
-AV1ReferenceFrameState *ref =
-&priv->ref[current->ref_frame_idx[i]];
+AV1ReferenceFrameState *ref;
-if (!ref->valid) {
+if (current->ref_frame_idx[i] < 0 ||
+!priv->ref[current->ref_frame_idx[i]].valid) {
av_log(ctx->log_ctx, AV_LOG_ERROR,
"Missing reference frame needed for frame size "
"(ref = %d, ref_frame_idx = %d).\n",
i, current->ref_frame_idx[i]);
return AVERROR_INVALIDDATA;
}
+ref = &priv->ref[current->ref_frame_idx[i]];
priv->upscaled_width = ref->upscaled_width;
priv->frame_width= ref->frame_width;
--
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 02/13] avcodec/vc1_block: Check get_vlc2() return before use
Fixes: index -1 out of bounds for type 'const uint8_t [185][2]'
Fixes:
15720/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSS2_fuzzer-5666071933091840
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vc1_block.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index eda0b28964..97c873f138 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -526,6 +526,8 @@ static int vc1_decode_ac_coeff(VC1Context *v, int *last,
int *skip,
int escape = decode210(gb);
if (escape != 2) {
index = get_vlc2(gb, ff_vc1_ac_coeff_table[codingset].table,
AC_VLC_BITS, 3);
+if (index < 0)
+return AVERROR_INVALIDDATA;
run = vc1_index_decode_table[codingset][index][0];
level = vc1_index_decode_table[codingset][index][1];
lst = index >= vc1_last_decode_table[codingset];
--
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 10/13] avcodec/vorbisdec: Check parameters in vorbis_floor0_decode() before divide
Fixes: division by zero Fixes: 16183/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VORBIS_fuzzer-5688966782648320 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/vorbisdec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c index a86d4c4c36..793f079737 100644 --- a/libavcodec/vorbisdec.c +++ b/libavcodec/vorbisdec.c @@ -1182,6 +1182,9 @@ static int vorbis_floor0_decode(vorbis_context *vc, q *= q; } +if (p + q == 0.0) +return AVERROR_INVALIDDATA; + /* calculate linear floor value */ q = expamplitude*vf->amplitude_offset) / (((1ULL << vf->amplitude_bits) - 1) * sqrt(p + q))) -- 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 08/13] avformat/vividas: Fix memleak of AVIOContext in track_header()
Fixes: memleak
Fixes:
16127/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5649290914955264
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/vividas.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/vividas.c b/libavformat/vividas.c
index c3d3cf548c..e70c9164a1 100644
--- a/libavformat/vividas.c
+++ b/libavformat/vividas.c
@@ -375,15 +375,19 @@ static int track_header(VividasDemuxContext *viv,
AVFormatContext *s, uint8_t *
num_data = avio_r8(pb);
for (j = 0; j < num_data; j++) {
uint64_t len = ffio_read_varlen(pb);
-if (len > INT_MAX/2 - xd_size)
+if (len > INT_MAX/2 - xd_size) {
+av_free(pb);
return AVERROR_INVALIDDATA;
+}
data_len[j] = len;
xd_size += len;
}
st->codecpar->extradata_size = 64 + xd_size + xd_size / 255;
-if (ff_alloc_extradata(st->codecpar, st->codecpar->extradata_size))
+if (ff_alloc_extradata(st->codecpar,
st->codecpar->extradata_size)) {
+av_free(pb);
return AVERROR(ENOMEM);
+}
p = st->codecpar->extradata;
p[0] = 2;
--
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 06/13] avcodec/cfhd: Fix linesize type
Signed-off-by: Michael Niedermayer
---
libavcodec/cfhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index c770ef3288..a162fc7da3 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -808,7 +808,7 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
int *got_frame,
int lowpass_width = s->plane[plane].band[0][0].width;
int highpass_stride = s->plane[plane].band[0][1].stride;
int act_plane = plane == 1 ? 2 : plane == 2 ? 1 : plane;
-int dst_linesize;
+ptrdiff_t dst_linesize;
int16_t *low, *high, *output, *dst;
if (avctx->pix_fmt == AV_PIX_FMT_BAYER_RGGB16) {
--
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 11/13] avcodec/vorbisdec: Implement vr->classifications = 1
It appears no valid file uses this, so this is not testable with
a valid file.
Fixes: assertion failure
Fixes:
16187/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VORBIS_fuzzer-5638880618872832
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vorbisdec.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
index 793f079737..1045d574b1 100644
--- a/libavcodec/vorbisdec.c
+++ b/libavcodec/vorbisdec.c
@@ -1361,8 +1361,12 @@ static av_always_inline int
setup_classifs(vorbis_context *vc,
return AVERROR_INVALIDDATA;
}
-av_assert0(vr->classifications > 1); //needed for inverse[]
-
+if (vr->classifications == 1) {
+for (i = partition_count + c_p_c - 1; i >= partition_count;
i--) {
+if (i < ptns_to_read)
+vr->classifs[p + i] = 0;
+}
+} else {
for (i = partition_count + c_p_c - 1; i >= partition_count; i--) {
temp2 = (((uint64_t)temp) * inverse_class) >> 32;
@@ -1370,6 +1374,7 @@ static av_always_inline int setup_classifs(vorbis_context
*vc,
vr->classifs[p + i] = temp - temp2 * vr->classifications;
temp = temp2;
}
+}
}
p += ptns_to_read;
}
--
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 13/13] avcodec/ralf: Fix undefined pointer in decode_channel()
Fixes:
16203/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RALF_fuzzer-5086088934195200
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/ralf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ralf.c b/libavcodec/ralf.c
index 0d6b57d652..619fd7126a 100644
--- a/libavcodec/ralf.c
+++ b/libavcodec/ralf.c
@@ -286,7 +286,7 @@ static int decode_channel(RALFContext *ctx, GetBitContext
*gb, int ch,
add_bits--;
range= 10;
range2 = 21;
-code_vlc = set->long_codes + code_params - 15;
+code_vlc = set->long_codes + (code_params - 15);
} else {
add_bits = 0;
range= 6;
--
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 1/2] build: add support for building CUDA files with clang
On 30.07.2019 09:51, Rodger Combs wrote: This avoids using the CUDA SDK at all; instead, we provide a minimal reimplementation of the basic functionality that lavfi actually uses. It generates very similar code to what NVCC produces. The header contains no implementation code derived from the SDK. The function and type declarations are derived from the SDK only to the extent required to build a compatible implementation. This is generally accepted to qualify as fair use. Because this option does not require the proprietary SDK, it does not require the "--enable-nonfree" flag in configure. Changed configure logic to autodetect cuda-llvm and applied. smime.p7s Description: S/MIME Cryptographic 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 v2] libavformat: Add ZeroMQ as a protocol option
Changes in v2:
1. Replaced zmq_poll with zmq_msg_recv.
2. Remove user timeout option as zmq_msg_recv(.., .., ZMQ_DONTWAIT) is a
non-blocking call.
3. Updated docs.
Andriy
>From 53e6e00d30c9fbf5127eea9d377686d37e981c0c Mon Sep 17 00:00:00 2001
From: Andriy Gelman
Date: Tue, 30 Jul 2019 14:39:32 -0400
Subject: [PATCH] libavformat: Add ZeroMQ as a protocol option
Currently multiple clients are only supported by using a
multicast destination address. An alternative is to stream to a server
which re-distributes the content.
This commit adds ZeroMQ as a protocol option, which allows
multiple clients to connect to a single ffmpeg instance.
---
configure | 2 +
doc/general.texi| 1 +
doc/protocols.texi | 32
libavformat/Makefile| 1 +
libavformat/libzmq.c| 159
libavformat/protocols.c | 1 +
6 files changed, 196 insertions(+)
create mode 100644 libavformat/libzmq.c
diff --git a/configure b/configure
index 5a4f507246..4515341b06 100755
--- a/configure
+++ b/configure
@@ -3400,6 +3400,8 @@ libsrt_protocol_deps="libsrt"
libsrt_protocol_select="network"
libssh_protocol_deps="libssh"
libtls_conflict="openssl gnutls mbedtls"
+libzmq_protocol_deps="libzmq"
+libzmq_protocol_select="network"
# filters
afftdn_filter_deps="avcodec"
diff --git a/doc/general.texi b/doc/general.texi
index 3c0c803449..b8e063268c 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1329,6 +1329,7 @@ performance on systems without hardware floating point
support).
@item TCP @tab X
@item TLS @tab X
@item UDP @tab X
+@item ZMQ @tab E
@end multitable
@code{X} means that the protocol is supported.
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 3e4e7af3d4..174eaacd0f 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1728,4 +1728,36 @@ Timeout in ms.
Create the Unix socket in listening mode.
@end table
+@section libzmq
+
+ZeroMQ asynchronous messaging library.
+
+This library supports unicast streaming to multiple clients without relying on
+an external server.
+
+The required syntax for streaming or connecting to a stream is:
+@example
+zmq:tcp://ip-address:port
+@end example
+
+Example:
+Create a localhost stream on port :
+@example
+ffmpeg -re -i input -f mpegts zmq:tcp://127.0.0.1:
+@end example
+
+Multiple clients may connect to the stream using:
+@example
+ffplay zmq:tcp://127.0.0.1:
+@end example
+
+Streaming to multiple clients is implemented using a ZMQ Pub-Sub pattern.
+The server binds to a port and publishes data. Clients connect to the
+server (IP address/port) and subscribe to the stream. The order in which
+the server and client start generally does not matter.
+
+ffmpeg must be compiled with the --enable-libzmq option to support
+this protocol option. See the compilation guide
@url{https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu}
+for an example on how this option may be set.
+
@c man end PROTOCOLS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index a434b005a4..4a535429b7 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -631,6 +631,7 @@ OBJS-$(CONFIG_LIBRTMPTE_PROTOCOL)+= librtmp.o
OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o
OBJS-$(CONFIG_LIBSRT_PROTOCOL) += libsrt.o
OBJS-$(CONFIG_LIBSSH_PROTOCOL) += libssh.o
+OBJS-$(CONFIG_LIBZMQ_PROTOCOL) +=
libzmq.o
# libavdevice dependencies
OBJS-$(CONFIG_IEC61883_INDEV)+= dv.o
diff --git a/libavformat/libzmq.c b/libavformat/libzmq.c
new file mode 100644
index 00..24eebb1fee
--- /dev/null
+++ b/libavformat/libzmq.c
@@ -0,0 +1,159 @@
+/*
+ * ZMQ URLProtocol
+ *
+ * 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
+#include "url.h"
+#include "network.h"
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+
+typedef struct ZMQContext {
+const AVClass *class;
+void *context;
+void *socket;
+unsigned int timeout; /*blocking timeout during zmq poll in milliseconds */
+} ZMQContext;
+
+static const AVOption options[] = {
+{ NULL }
+};
+
+static int ff_zmq_open(URLContext *h, const char *uri, int flags)
+{
+
Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote: > On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer > wrote: > > > Hi all > > > > It seems we do not have a list of people volunteering to do uploads to > > samples. And no place to send such requests to except here, where they > > sometimes get ignored. > > > > Just give everyone with push access right to upload. Upload currently requires an account on the server, giving everyone an account is a security risk. It also doesnt really make sense to give someone access who doesnt need access. If someone wants to take care of uploads (s)he can have access. Of course if theres a majority wanting everyone with push access to have an account on the server, sure we will do that but i dont think its a good idea. IMHO its always better (aka more secure) if access is kept at a minimum. besides, it would be a bit of work to keep the list of who has push access and who has sampeles access synchronized. Its different servers and different types of "accounts" and the whole point from my point of view is that id like to spend my time on other areas on FFmpeg While keeping accounts synchronized would be probably more work than doing the uploads myself Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire 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] [PATCHv2 1/4] avformat/mpegtsenc: fix incorrect PCR selection with multiple programs
On Sun, 4 Aug 2019, Andreas Håkon wrote:
Hi Marton,
‐‐‐ Original Message ‐‐‐
v2: a video is stream is preferred if there are no programs, just like before
the patch.
Thank you for your effort!
However, something is wrong with this patch regarding PCR intervals.
First, try this example (using the file shared by Michael
https://trac.ffmpeg.org/raw-attachment/ticket/3714/FFmpeg%20Sample_cut.ts ):
% ffmpeg -loglevel info -y -i Sample_cut.ts \
-map '0:v:0' -c:v:0 copy \
-map '0:v:0' -c:v:1 copy \
-map '0:a:0' -c:a:0 copy \
-pat_period 1 \
-program st=0,1,2 \
-program st=0,2 \
-program st=1,2 \
-program st=3 \
-sdt_period 1 \
this_was_less_than_256-marton.ts
This command line does not seem correct, there is no stream 3, also in
order to specify multiple streams per program you have to use this syntax:
-program st=0:st=2.
Then you get:
[mpegts @ 0x3046880] service 1 using PCR in pid=256
[mpegts @ 0x3046880] service 2 using PCR in pid=256
[mpegts @ 0x3046880] service 3 using PCR in pid=257
[mpegts @ 0x3046880] service 4 using PCR in pid=258
Until here all seems correct.
However, if you analyze the PCR intervals:
- 256: PCR_count: 0x3 (3) => repetition rate: 0,299 seconds
- 257: PCR_count: 0x3 (3) => repetition rate: 0,305 seconds
- 258: PCR_count: 0x4 (4) => repetition rate: 0,139 seconds
(You can check it with the DVB Inspector tool or any other)
And regular repetition rate are 0,450 seconds (with ffmpeg).
450m PCR seems wrong. ISO/IEC13818-1 specifies
an interval of 100 ms, while DVB recommends 40 ms PCR-s.
What was the PCR interval before the patch? 450 ms seems like the
keyframe interval of your video, because for keyframes you always get
a PCR with the current code.
Keep in mind that according to this
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192040.html
PCR in VBR streams never worked correctly.
CBR with multiple programs was also problematic, because instead of
counting all packets the counter only counted the packets of a service.
The way I see it PCR generation needs a serious rework, I will post a
patch for that, you will have to apply it on top of this series.
So...
@@ -57,8 +57,6 @@ typedef struct MpegTSService {
uint8_t name[256];
uint8_t provider_name[256];
int pcr_pid;
- int pcr_packet_count;
- int pcr_packet_period;
AVProgram *program;
} MpegTSService;
Why you remove the "pcr_packet_period" from services?
I know that the value can be the same for all services inside the
same TS, but the PCR interval is per service, and not per TS.
It is per PID now instead of per service.
@@ -1015,8 +1032,7 @@ static int mpegts_init(AVFormatContext *s)
else
av_log(s, AV_LOG_VERBOSE, "muxrate %d, ", ts->mux_rate);
av_log(s, AV_LOG_VERBOSE,
- "pcr every %d pkts, sdt every %d, pat/pmt every %d pkts\\n",
- service->pcr_packet_period,
+ "sdt every %d, pat/pmt every %d pkts\\n",
ts->sdt_packet_period, ts->pat_packet_period);
The information about the PCR interval is a must have. Please, don't remove it!
It is written out in select_pcr_streams.
@@ -1198,12 +1214,12 @@ static void mpegts_write_pes(AVFormatContext *s,
AVStream *st,
force_pat = 0;
write_pcr = 0;
- if (ts_st->pid == ts_st->service->pcr_pid) {
+ if (ts_st->pcr_packet_period) {
if (ts->mux_rate > 1 || is_start) // VBR pcr period is based on
frames
- ts_st->service->pcr_packet_count++;
- if (ts_st->service->pcr_packet_count >=
- ts_st->service->pcr_packet_period) {
- ts_st->service->pcr_packet_count = 0;
+ ts_st->pcr_packet_count++;
+ if (ts_st->pcr_packet_count >=
+ ts_st->pcr_packet_period) {
+ ts_st->pcr_packet_count = 0;
}
}
In this way, with multiple services (the reason for this patch) you're
generating a
Transport Stream with PCR streams sharing the interval period. That's a new
serious BUG!
No, ts_st is different for each stream (each PID).
For each service it's one PCR. And the interval of each PCR for one stream is
computed from the last PCR of the same stream. It can't be calculated from the
last
PCR of any other stream.
ts_st is different for each stream, it is not common.
Please, fix this bug before merging this patch.
@@ -1236,7 +1252,7 @@ static void mpegts_write_pes(AVFormatContext *s, AVStream
*st,
}
if (key && is_start && pts != AV_NOPTS_VALUE) {
// set Random Access for key frames
- if (ts_st->pid == ts_st->service->pcr_pid)
+ if (ts_st->pcr_packet_period)
write_pcr = 1;
set_af_flag(buf, 0x40);
q = get_ts_payload_start(buf);
Just the same problem.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mpegtsenc: fix PCR generation intervals
PCR generation was based on counting packets for both CBR and VBR streams.
Couting packets might have worked for CBR streams (when muxrate was specified)
but it only took into account the packets of a service (or the packets of the
PCR stream lately), so even that was problematic for multi program streams.
The new code works on actual PCR for CBR and packet DTS values for VBR streams,
so the default 20ms PCR retransmission time is now respected for both CBR and
VBR.
Signed-off-by: Marton Balint
---
libavformat/mpegtsenc.c | 60 +++--
tests/ref/lavf/ts | 2 +-
2 files changed, 19 insertions(+), 43 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 02651308f8..a501807711 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -237,10 +237,9 @@ typedef struct MpegTSWriteStream {
int payload_flags;
uint8_t *payload;
AVFormatContext *amux;
-AVRational user_tb;
-int pcr_packet_count;
-int pcr_packet_period;
+int pcr_period;
+int64_t last_pcr;
/* For Opus */
int opus_queued_samples;
@@ -792,32 +791,9 @@ static void
enable_pcr_generation_for_stream(AVFormatContext *s, AVStream *pcr_s
MpegTSWrite *ts = s->priv_data;
MpegTSWriteStream *ts_st = pcr_st->priv_data;
-if (ts->mux_rate > 1) {
-ts_st->pcr_packet_period = (int64_t)ts->mux_rate * ts->pcr_period /
- (TS_PACKET_SIZE * 8 * 1000);
-} else {
-if (pcr_st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
-int frame_size = av_get_audio_frame_duration2(pcr_st->codecpar, 0);
-if (!frame_size) {
-av_log(s, AV_LOG_WARNING, "frame size not set\n");
-ts_st->pcr_packet_period =
-pcr_st->codecpar->sample_rate / (10 * 512);
-} else {
-ts_st->pcr_packet_period =
-pcr_st->codecpar->sample_rate / (10 * frame_size);
-}
-} else {
-// max delta PCR 0.1s
-// TODO: should be avg_frame_rate
-ts_st->pcr_packet_period =
-ts_st->user_tb.den / (10 * ts_st->user_tb.num);
-}
-if (!ts_st->pcr_packet_period)
-ts_st->pcr_packet_period = 1;
-}
-
+ts_st->pcr_period = av_rescale(ts->pcr_period, PCR_TIME_BASE, 1000);
// output a PCR as soon as possible
-ts_st->pcr_packet_count = ts_st->pcr_packet_period;
+ts_st->last_pcr = av_rescale(s->max_delay, PCR_TIME_BASE, AV_TIME_BASE)
- ts_st->pcr_period;
}
static void select_pcr_streams(AVFormatContext *s)
@@ -907,7 +883,6 @@ static int mpegts_init(AVFormatContext *s)
}
st->priv_data = ts_st;
-ts_st->user_tb = st->time_base;
avpriv_set_pts_info(st, 33, 1, 9);
ts_st->payload = av_mallocz(ts->pes_payload_size);
@@ -1183,7 +1158,6 @@ static void mpegts_write_pes(AVFormatContext *s, AVStream
*st,
uint8_t *q;
int val, is_start, len, header_len, write_pcr, is_dvb_subtitle,
is_dvb_teletext, flags;
int afc_len, stuffing_len;
-int64_t pcr = -1; /* avoid warning */
int64_t delay = av_rescale(s->max_delay, 9, AV_TIME_BASE);
int force_pat = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO && key &&
!ts_st->prev_payload_key;
@@ -1194,18 +1168,24 @@ static void mpegts_write_pes(AVFormatContext *s,
AVStream *st,
is_start = 1;
while (payload_size > 0) {
+int64_t pcr = -1; /* avoid warning */
+
retransmit_si_info(s, force_pat, dts);
force_pat = 0;
write_pcr = 0;
-if (ts_st->pcr_packet_period) {
-if (ts->mux_rate > 1 || is_start) // VBR pcr period is based on
frames
-ts_st->pcr_packet_count++;
-if (ts_st->pcr_packet_count >=
-ts_st->pcr_packet_period) {
-ts_st->pcr_packet_count = 0;
-write_pcr = 1;
+if (ts_st->pcr_period) {
+if (ts->mux_rate > 1) {
+pcr = get_pcr(ts, s->pb);
+if (pcr - ts_st->last_pcr >= ts_st->pcr_period)
+write_pcr = 1;
+} else if (dts != AV_NOPTS_VALUE) {
+pcr = (dts - delay) * 300;
+if (pcr - ts_st->last_pcr >= ts_st->pcr_period && is_start)
+write_pcr = 1;
}
+if (write_pcr)
+ts_st->last_pcr = FFMAX(pcr - ts_st->pcr_period,
ts_st->last_pcr + ts_st->pcr_period);
}
if (ts->mux_rate > 1 && dts != AV_NOPTS_VALUE &&
@@ -1236,7 +1216,7 @@ static void mpegts_write_pes(AVFormatContext *s, AVStream
*st,
}
if (key && is_start && pts != AV_NOPTS_VALUE) {
// set Random Access for key frames
-if (ts_st->pcr_packet_period)
+if (ts_st->pcr_period)
write_pcr = 1;
set_af_flag(buf, 0x40);
[FFmpeg-devel] [PATCH] avformat/rtspdec: Don't send teardown if rtsp_hd_out is null
Example: rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov Extending the condition allows the stream to be processed correctly. 0001-Don-t-send-teardown-if-rtsp_hd_out-is-null.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] Don't send teardown if rtsp_hd_out is null
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.
On Sun, 4 Aug 2019 at 22:39, Ross Nicholson wrote:
> From: phunkyfish
>
> ---
> libavformat/rtspdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
> index 32dff2319c..3a79d1b175 100644
> --- a/libavformat/rtspdec.c
> +++ b/libavformat/rtspdec.c
> @@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
> {
> RTSPState *rt = s->priv_data;
>
> -if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
> +if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
> ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
>
> ff_rtsp_close_streams(s);
> --
> 2.20.1 (Apple Git-117)
>
>
___
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] Don't send teardown if rtsp_hd_out is null
From: phunkyfish
---
libavformat/rtspdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 32dff2319c..3a79d1b175 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -57,7 +57,7 @@ static int rtsp_read_close(AVFormatContext *s)
{
RTSPState *rt = s->priv_data;
-if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN))
+if (!(rt->rtsp_flags & RTSP_FLAG_LISTEN) && rt->rtsp_hd_out)
ff_rtsp_send_cmd_async(s, "TEARDOWN", rt->control_uri, NULL);
ff_rtsp_close_streams(s);
--
2.20.1 (Apple Git-117)
___
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 1/4] avformat/mpegtsenc: fix incorrect PCR selection with multiple programs
On Sun, 4 Aug 2019, Marton Balint wrote: @@ -1015,8 +1032,7 @@ static int mpegts_init(AVFormatContext *s) else av_log(s, AV_LOG_VERBOSE, "muxrate %d, ", ts->mux_rate); av_log(s, AV_LOG_VERBOSE, - "pcr every %d pkts, sdt every %d, pat/pmt every %d pkts\\n", - service->pcr_packet_period, + "sdt every %d, pat/pmt every %d pkts\\n", ts->sdt_packet_period, ts->pat_packet_period); The information about the PCR interval is a must have. Please, don't remove it! It is written out in select_pcr_streams. Sorry, I had some version locally which did this, but not the current version. The PCR rework replaces this anyway with a fixed time based approach, so it does not really matter. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fate: Add cuda_runtime.h to FATE source test ref file
It uses a nonstandard inclusion guard. Signed-off-by: Andreas Rheinhardt --- tests/ref/fate/source | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/ref/fate/source b/tests/ref/fate/source index 8e12582ce8..3695238e71 100644 --- a/tests/ref/fate/source +++ b/tests/ref/fate/source @@ -25,6 +25,7 @@ compat/avisynth/avs/types.h compat/avisynth/avxsynth_c.h compat/avisynth/windowsPorts/basicDataTypeConversions.h compat/avisynth/windowsPorts/windows2linux.h +compat/cuda/cuda_runtime.h compat/cuda/dynlink_loader.h compat/djgpp/math.h compat/float/float.h -- 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] fate: Add cuda_runtime.h to FATE source test ref file
On 04.08.2019 23:52, Andreas Rheinhardt wrote: It uses a nonstandard inclusion guard. Is there any problem with just fixing the inclusion guard instead? I forgot that this exists, but the inclusion guard in it looked fairly standard to me. Feel free to just fix it. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate: Add cuda_runtime.h to FATE source test ref file
Timo Rothenpieler: > On 04.08.2019 23:52, Andreas Rheinhardt wrote: >> It uses a nonstandard inclusion guard. > > Is there any problem with just fixing the inclusion guard instead? > I forgot that this exists, but the inclusion guard in it looked fairly > standard to me. > Feel free to just fix it. > The standard inclusion guard for this file should be COMPAT_CUDA_CUDA_RUNTIME_H without AV_, as this file isn't in any of the libav*/ paths (at least that is what the source test expects). Given that this header is designed to fulfill FFmpeg's needs and given that dynlink_loader.h also uses an AV_ prefix (and is therefore marked as an exception in the source test ref file), I thought that it is intended to use the AV_ prefix so that it needs to be marked as an exception. But if this is not so, then said prefix can of course be removed. I don't know which of the two ways should be choosen. - 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] [PATCH] fate: Add cuda_runtime.h to FATE source test ref file
On 8/4/2019 9:34 PM, Andreas Rheinhardt wrote: > Timo Rothenpieler: >> On 04.08.2019 23:52, Andreas Rheinhardt wrote: >>> It uses a nonstandard inclusion guard. >> >> Is there any problem with just fixing the inclusion guard instead? >> I forgot that this exists, but the inclusion guard in it looked fairly >> standard to me. >> Feel free to just fix it. >> > The standard inclusion guard for this file should be > COMPAT_CUDA_CUDA_RUNTIME_H without AV_, as this file isn't in any of > the libav*/ paths (at least that is what the source test expects). > Given that this header is designed to fulfill FFmpeg's needs and given > that dynlink_loader.h also uses an AV_ prefix (and is therefore marked > as an exception in the source test ref file), I thought that it is > intended to use the AV_ prefix so that it needs to be marked as an > exception. But if this is not so, then said prefix can of course be > removed. I don't know which of the two ways should be choosen. > > - Andreas Remove the AV_ prefix. It's unnecessary and was probably added by mistake. And while at it, you can do the same with dynlink_loader.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".
[FFmpeg-devel] [PATCH] compat/cuda: Change inclusion guards
cuda_runtime.h as well as dynlink_loader.h used nonstandard inclusion guards with an AV_ prefix, although these files are not in an libav*/ path. So change the inclusion guards and adapt the ref file of the source fate test accordingly. Signed-off-by: Andreas Rheinhardt --- compat/cuda/cuda_runtime.h | 6 +++--- compat/cuda/dynlink_loader.h | 6 +++--- tests/ref/fate/source| 1 - 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/compat/cuda/cuda_runtime.h b/compat/cuda/cuda_runtime.h index dbe50f8711..92c55ad859 100644 --- a/compat/cuda/cuda_runtime.h +++ b/compat/cuda/cuda_runtime.h @@ -20,8 +20,8 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ -#ifndef AV_COMPAT_CUDA_CUDA_RUNTIME_H -#define AV_COMPAT_CUDA_CUDA_RUNTIME_H +#ifndef COMPAT_CUDA_CUDA_RUNTIME_H +#define COMPAT_CUDA_CUDA_RUNTIME_H // Common macros #define __global__ __attribute__((global)) @@ -128,4 +128,4 @@ static inline __device__ T tex2D(cudaTextureObject_t texObject, float x, float y return ret; } -#endif +#endif /* COMPAT_CUDA_CUDA_RUNTIME_H */ diff --git a/compat/cuda/dynlink_loader.h b/compat/cuda/dynlink_loader.h index 9f93465088..ca79e604c7 100644 --- a/compat/cuda/dynlink_loader.h +++ b/compat/cuda/dynlink_loader.h @@ -16,8 +16,8 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ -#ifndef AV_COMPAT_CUDA_DYNLINK_LOADER_H -#define AV_COMPAT_CUDA_DYNLINK_LOADER_H +#ifndef COMPAT_CUDA_DYNLINK_LOADER_H +#define COMPAT_CUDA_DYNLINK_LOADER_H #include "libavutil/log.h" #include "compat/w32dlfcn.h" @@ -30,4 +30,4 @@ #include -#endif +#endif /* COMPAT_CUDA_DYNLINK_LOADER_H */ diff --git a/tests/ref/fate/source b/tests/ref/fate/source index 8e12582ce8..ad1e5b95d6 100644 --- a/tests/ref/fate/source +++ b/tests/ref/fate/source @@ -25,7 +25,6 @@ compat/avisynth/avs/types.h compat/avisynth/avxsynth_c.h compat/avisynth/windowsPorts/basicDataTypeConversions.h compat/avisynth/windowsPorts/windows2linux.h -compat/cuda/dynlink_loader.h compat/djgpp/math.h compat/float/float.h compat/float/limits.h -- 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 v3] iavformat/hlsenc: merge mpegts and fmp4 workflow to one workflow
write mpegts or fmp4 context into buffer, and flush the buffer into
output file when split fragment. merge two format split workflow into
one workflow
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 251 +--
1 file changed, 124 insertions(+), 127 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 51310fb528..f6f9c8161d 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -815,7 +815,7 @@ static int hls_mux_init(AVFormatContext *s, VariantStream
*vs)
vs->start_pos = 0;
vs->new_start = 1;
-if (hls->segment_type == SEGMENT_TYPE_FMP4) {
+if (hls->segment_type == SEGMENT_TYPE_FMP4 && hls->max_seg_size > 0) {
if (hls->http_persistent > 0) {
//TODO: Support fragment fmp4 for http persistent in HLS muxer.
av_log(s, AV_LOG_WARNING, "http persistent mode is currently
unsupported for fragment mp4 in the HLS muxer.\n");
@@ -824,34 +824,38 @@ static int hls_mux_init(AVFormatContext *s, VariantStream
*vs)
av_log(s, AV_LOG_WARNING, "Multi-file byterange mode is currently
unsupported in the HLS muxer.\n");
return AVERROR_PATCHWELCOME;
}
+}
-vs->packets_written = 0;
-vs->init_range_length = 0;
-set_http_options(s, &options, hls);
-if ((ret = avio_open_dyn_buf(&oc->pb)) < 0)
-return ret;
+vs->packets_written = 0;
+vs->init_range_length = 0;
+set_http_options(s, &options, hls);
+if ((ret = avio_open_dyn_buf(&oc->pb)) < 0)
+return ret;
+if (hls->segment_type == SEGMENT_TYPE_FMP4) {
if (byterange_mode) {
ret = hlsenc_io_open(s, &vs->out, vs->basename, &options);
} else {
ret = hlsenc_io_open(s, &vs->out, vs->base_output_dirname,
&options);
}
-av_dict_free(&options);
+}
+av_dict_free(&options);
+if (ret < 0) {
+av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n",
vs->fmp4_init_filename);
+return ret;
+}
+
+if (hls->format_options_str) {
+ret = av_dict_parse_string(&hls->format_options,
hls->format_options_str, "=", ":", 0);
if (ret < 0) {
-av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n",
vs->fmp4_init_filename);
+av_log(s, AV_LOG_ERROR, "Could not parse format options list
'%s'\n",
+ hls->format_options_str);
return ret;
}
+}
-if (hls->format_options_str) {
-ret = av_dict_parse_string(&hls->format_options,
hls->format_options_str, "=", ":", 0);
-if (ret < 0) {
-av_log(s, AV_LOG_ERROR, "Could not parse format options list
'%s'\n",
- hls->format_options_str);
-return ret;
-}
-}
-
-av_dict_copy(&options, hls->format_options, 0);
+av_dict_copy(&options, hls->format_options, 0);
+if (hls->segment_type == SEGMENT_TYPE_FMP4) {
av_dict_set(&options, "fflags", "-autobsf", 0);
av_dict_set(&options, "movflags", "+frag_custom+dash+delay_moov",
AV_DICT_APPEND);
ret = avformat_init_output(oc, &options);
@@ -862,9 +866,9 @@ static int hls_mux_init(AVFormatContext *s, VariantStream
*vs)
av_dict_free(&options);
return AVERROR(EINVAL);
}
-avio_flush(oc->pb);
-av_dict_free(&options);
}
+avio_flush(oc->pb);
+av_dict_free(&options);
return 0;
}
@@ -1435,7 +1439,6 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
{
HLSContext *hls = s->priv_data;
HLSSegment *en;
-AVFormatContext *oc = vs->avf;
int target_duration = 0;
int ret = 0;
char temp_filename[MAX_URL_SIZE];
@@ -1471,7 +1474,7 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
set_http_options(s, &options, hls);
snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp" :
"%s", vs->m3u8_name);
-if ((ret = hlsenc_io_open(s, (byterange_mode || hls->segment_type ==
SEGMENT_TYPE_FMP4) ? &hls->m3u8_out : &oc->pb, temp_filename, &options)) < 0) {
+if ((ret = hlsenc_io_open(s, (byterange_mode || hls->segment_type ==
SEGMENT_TYPE_FMP4) ? &hls->m3u8_out : &vs->out, temp_filename, &options)) < 0) {
if (hls->ignore_io_errors)
ret = 0;
goto fail;
@@ -1483,33 +1486,33 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
}
vs->discontinuity_set = 0;
-ff_hls_write_playlist_header((byterange_mode || hls->segment_type ==
SEGMENT_TYPE_FMP4) ? hls->m3u8_out : oc->pb, hls->version, hls->allowcache,
+ff_hls_write_playlist_header((byterange_mode || hls->segment_type ==
SEGMENT_TYPE_FMP4) ? hls->m3u8_out : vs->out, hls->version, hls->allowcache,
target_duration, sequence, hls->pl_type,
hls->flags & HLS_I_FRAMES_ONLY);
[FFmpeg-devel] [PATCH v4] avformat/hlsenc: merge mpegts and fmp4 workflow to one workflow
just remove the 'i' of the v3 mail subject.
write mpegts or fmp4 context into buffer, and flush the buffer into
output file when split fragment. merge two format split workflow into
one workflow
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 251 +--
1 file changed, 124 insertions(+), 127 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 51310fb528..f6f9c8161d 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -815,7 +815,7 @@ static int hls_mux_init(AVFormatContext *s, VariantStream
*vs)
vs->start_pos = 0;
vs->new_start = 1;
-if (hls->segment_type == SEGMENT_TYPE_FMP4) {
+if (hls->segment_type == SEGMENT_TYPE_FMP4 && hls->max_seg_size > 0) {
if (hls->http_persistent > 0) {
//TODO: Support fragment fmp4 for http persistent in HLS muxer.
av_log(s, AV_LOG_WARNING, "http persistent mode is currently
unsupported for fragment mp4 in the HLS muxer.\n");
@@ -824,34 +824,38 @@ static int hls_mux_init(AVFormatContext *s, VariantStream
*vs)
av_log(s, AV_LOG_WARNING, "Multi-file byterange mode is currently
unsupported in the HLS muxer.\n");
return AVERROR_PATCHWELCOME;
}
+}
-vs->packets_written = 0;
-vs->init_range_length = 0;
-set_http_options(s, &options, hls);
-if ((ret = avio_open_dyn_buf(&oc->pb)) < 0)
-return ret;
+vs->packets_written = 0;
+vs->init_range_length = 0;
+set_http_options(s, &options, hls);
+if ((ret = avio_open_dyn_buf(&oc->pb)) < 0)
+return ret;
+if (hls->segment_type == SEGMENT_TYPE_FMP4) {
if (byterange_mode) {
ret = hlsenc_io_open(s, &vs->out, vs->basename, &options);
} else {
ret = hlsenc_io_open(s, &vs->out, vs->base_output_dirname,
&options);
}
-av_dict_free(&options);
+}
+av_dict_free(&options);
+if (ret < 0) {
+av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n",
vs->fmp4_init_filename);
+return ret;
+}
+
+if (hls->format_options_str) {
+ret = av_dict_parse_string(&hls->format_options,
hls->format_options_str, "=", ":", 0);
if (ret < 0) {
-av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n",
vs->fmp4_init_filename);
+av_log(s, AV_LOG_ERROR, "Could not parse format options list
'%s'\n",
+ hls->format_options_str);
return ret;
}
+}
-if (hls->format_options_str) {
-ret = av_dict_parse_string(&hls->format_options,
hls->format_options_str, "=", ":", 0);
-if (ret < 0) {
-av_log(s, AV_LOG_ERROR, "Could not parse format options list
'%s'\n",
- hls->format_options_str);
-return ret;
-}
-}
-
-av_dict_copy(&options, hls->format_options, 0);
+av_dict_copy(&options, hls->format_options, 0);
+if (hls->segment_type == SEGMENT_TYPE_FMP4) {
av_dict_set(&options, "fflags", "-autobsf", 0);
av_dict_set(&options, "movflags", "+frag_custom+dash+delay_moov",
AV_DICT_APPEND);
ret = avformat_init_output(oc, &options);
@@ -862,9 +866,9 @@ static int hls_mux_init(AVFormatContext *s, VariantStream
*vs)
av_dict_free(&options);
return AVERROR(EINVAL);
}
-avio_flush(oc->pb);
-av_dict_free(&options);
}
+avio_flush(oc->pb);
+av_dict_free(&options);
return 0;
}
@@ -1435,7 +1439,6 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
{
HLSContext *hls = s->priv_data;
HLSSegment *en;
-AVFormatContext *oc = vs->avf;
int target_duration = 0;
int ret = 0;
char temp_filename[MAX_URL_SIZE];
@@ -1471,7 +1474,7 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
set_http_options(s, &options, hls);
snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp" :
"%s", vs->m3u8_name);
-if ((ret = hlsenc_io_open(s, (byterange_mode || hls->segment_type ==
SEGMENT_TYPE_FMP4) ? &hls->m3u8_out : &oc->pb, temp_filename, &options)) < 0) {
+if ((ret = hlsenc_io_open(s, (byterange_mode || hls->segment_type ==
SEGMENT_TYPE_FMP4) ? &hls->m3u8_out : &vs->out, temp_filename, &options)) < 0) {
if (hls->ignore_io_errors)
ret = 0;
goto fail;
@@ -1483,33 +1486,33 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
}
vs->discontinuity_set = 0;
-ff_hls_write_playlist_header((byterange_mode || hls->segment_type ==
SEGMENT_TYPE_FMP4) ? hls->m3u8_out : oc->pb, hls->version, hls->allowcache,
+ff_hls_write_playlist_header((byterange_mode || hls->segment_type ==
SEGMENT_TYPE_FMP4) ? hls->m3u8_out : vs->out, hls->version, hls->allowcache,
target_duration, sequence, hls->pl_t
Re: [FFmpeg-devel] [PATCH v3] iavformat/hlsenc: merge mpegts and fmp4 workflow to one workflow
ignore this version patch please, the subject incorrect.
> 在 2019年8月5日，上午10:26，Steven Liu 写道：
>
> write mpegts or fmp4 context into buffer, and flush the buffer into
> output file when split fragment. merge two format split workflow into
> one workflow
>
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 251 +--
> 1 file changed, 124 insertions(+), 127 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 51310fb528..f6f9c8161d 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -815,7 +815,7 @@ static int hls_mux_init(AVFormatContext *s, VariantStream
> *vs)
> vs->start_pos = 0;
> vs->new_start = 1;
>
> -if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> +if (hls->segment_type == SEGMENT_TYPE_FMP4 && hls->max_seg_size > 0) {
> if (hls->http_persistent > 0) {
> //TODO: Support fragment fmp4 for http persistent in HLS muxer.
> av_log(s, AV_LOG_WARNING, "http persistent mode is currently
> unsupported for fragment mp4 in the HLS muxer.\n");
> @@ -824,34 +824,38 @@ static int hls_mux_init(AVFormatContext *s,
> VariantStream *vs)
> av_log(s, AV_LOG_WARNING, "Multi-file byterange mode is currently
> unsupported in the HLS muxer.\n");
> return AVERROR_PATCHWELCOME;
> }
> +}
>
> -vs->packets_written = 0;
> -vs->init_range_length = 0;
> -set_http_options(s, &options, hls);
> -if ((ret = avio_open_dyn_buf(&oc->pb)) < 0)
> -return ret;
> +vs->packets_written = 0;
> +vs->init_range_length = 0;
> +set_http_options(s, &options, hls);
> +if ((ret = avio_open_dyn_buf(&oc->pb)) < 0)
> +return ret;
>
> +if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> if (byterange_mode) {
> ret = hlsenc_io_open(s, &vs->out, vs->basename, &options);
> } else {
> ret = hlsenc_io_open(s, &vs->out, vs->base_output_dirname,
> &options);
> }
> -av_dict_free(&options);
> +}
> +av_dict_free(&options);
> +if (ret < 0) {
> +av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n",
> vs->fmp4_init_filename);
> +return ret;
> +}
> +
> +if (hls->format_options_str) {
> +ret = av_dict_parse_string(&hls->format_options,
> hls->format_options_str, "=", ":", 0);
> if (ret < 0) {
> -av_log(s, AV_LOG_ERROR, "Failed to open segment '%s'\n",
> vs->fmp4_init_filename);
> +av_log(s, AV_LOG_ERROR, "Could not parse format options list
> '%s'\n",
> + hls->format_options_str);
> return ret;
> }
> +}
>
> -if (hls->format_options_str) {
> -ret = av_dict_parse_string(&hls->format_options,
> hls->format_options_str, "=", ":", 0);
> -if (ret < 0) {
> -av_log(s, AV_LOG_ERROR, "Could not parse format options list
> '%s'\n",
> - hls->format_options_str);
> -return ret;
> -}
> -}
> -
> -av_dict_copy(&options, hls->format_options, 0);
> +av_dict_copy(&options, hls->format_options, 0);
> +if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> av_dict_set(&options, "fflags", "-autobsf", 0);
> av_dict_set(&options, "movflags", "+frag_custom+dash+delay_moov",
> AV_DICT_APPEND);
> ret = avformat_init_output(oc, &options);
> @@ -862,9 +866,9 @@ static int hls_mux_init(AVFormatContext *s, VariantStream
> *vs)
> av_dict_free(&options);
> return AVERROR(EINVAL);
> }
> -avio_flush(oc->pb);
> -av_dict_free(&options);
> }
> +avio_flush(oc->pb);
> +av_dict_free(&options);
> return 0;
> }
>
> @@ -1435,7 +1439,6 @@ static int hls_window(AVFormatContext *s, int last,
> VariantStream *vs)
> {
> HLSContext *hls = s->priv_data;
> HLSSegment *en;
> -AVFormatContext *oc = vs->avf;
> int target_duration = 0;
> int ret = 0;
> char temp_filename[MAX_URL_SIZE];
> @@ -1471,7 +1474,7 @@ static int hls_window(AVFormatContext *s, int last,
> VariantStream *vs)
>
> set_http_options(s, &options, hls);
> snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp" :
> "%s", vs->m3u8_name);
> -if ((ret = hlsenc_io_open(s, (byterange_mode || hls->segment_type ==
> SEGMENT_TYPE_FMP4) ? &hls->m3u8_out : &oc->pb, temp_filename, &options)) < 0)
> {
> +if ((ret = hlsenc_io_open(s, (byterange_mode || hls->segment_type ==
> SEGMENT_TYPE_FMP4) ? &hls->m3u8_out : &vs->out, temp_filename, &options)) <
> 0) {
> if (hls->ignore_io_errors)
> ret = 0;
> goto fail;
> @@ -1483,33 +1486,33 @@ static int hls_window(AVFormatContext *s, int last,
> VariantStream *vs)
> }
>
> vs->discontinuity_set = 0;
> -ff_hls_write_playlist_header((byterange_mode || hls->segment_type ==
> SEGMENT_TYPE_FMP4) ?
Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Michael Niedermayer > Sent: Monday, August 5, 2019 3:45 AM > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [RFC] samples.ffmpeg.org > > On Sun, Aug 04, 2019 at 05:42:14PM +0100, Kieran Kunhya wrote: > > On Sat, 3 Aug 2019 at 18:35, Michael Niedermayer > > > > wrote: > > > > > Hi all > > > > > > It seems we do not have a list of people volunteering to do uploads > > > to samples. And no place to send such requests to except here, where > > > they sometimes get ignored. > > > > > > > Just give everyone with push access right to upload. > > Upload currently requires an account on the server, giving everyone an > account is a security risk. > It also doesnt really make sense to give someone access who doesnt need > access. > If someone wants to take care of uploads (s)he can have access. > > Of course if theres a majority wanting everyone with push access to have an > account on the server, sure we will do that but i dont think its a good idea. > IMHO its always better (aka more secure) if access is kept at a minimum. > > besides, it would be a bit of work to keep the list of who has push access and > who has sampeles access synchronized. Its different servers and different > types of "accounts" > and the whole point from my point of view is that id like to spend my time on > other areas on FFmpeg While keeping accounts synchronized would be > probably more work than doing the uploads myself > > Thanks My suggestions would be: 1. If there is any volunteer to be fate-samples MAINTAINERS, tell him how to apply and update the FATE MAINTAINERS list. 2. If there is anyone with push access has a requirement to upload a fate sample, reply him to please apply fate access and update the FATE MAINTAINERS list. Then there will be several or a dozen of people with fate access in the future, they can help to take the requirements from someone who have no both push access and FATE account, this will be not a big burden for everyone. ___ 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 V1] lavf/showinfo: support mastering display sidedata
On Sun, Aug 4, 2019 at 7:00 PM Steven Liu wrote:
>
>
>
> > 在 2019年8月4日，18:30，Jun Zhao 写道：
> >
> > From: Jun Zhao
> >
> > support mastering display sidedata.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavfilter/vf_showinfo.c | 30 ++
> > 1 files changed, 30 insertions(+), 0 deletions(-)
> >
> > diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> > index f6f8f49..8889c01 100644
> > --- a/libavfilter/vf_showinfo.c
> > +++ b/libavfilter/vf_showinfo.c
> > @@ -34,6 +34,7 @@
> > #include "libavutil/stereo3d.h"
> > #include "libavutil/timestamp.h"
> > #include "libavutil/timecode.h"
> > +#include "libavutil/mastering_display_metadata.h"
> >
> > #include "avfilter.h"
> > #include "internal.h"
> > @@ -133,6 +134,32 @@ static void dump_roi(AVFilterContext *ctx,
> > AVFrameSideData *sd)
> >}
> > }
> >
> > +static void dump_mastering_display(AVFilterContext *ctx, AVFrameSideData
> > *sd)
> > +{
> > +AVMasteringDisplayMetadata *mastering_display;
> > +
> > +av_log(ctx, AV_LOG_INFO, "mastering display: ");
> > +if (sd->size < sizeof(*mastering_display)) {
> > +av_log(ctx, AV_LOG_INFO, "invalid data”);
> Why don’t use ERROR level if it is invalid data?
Will change to ERROR and update the other part in this file like this
case, Thanks.
> > +return;
> > +}
> > +
> > +mastering_display = (AVMasteringDisplayMetadata *)sd->data;
> > +
> > +av_log(ctx, AV_LOG_INFO, "has_primaries:%d has_luminance:%d "
> > + "r(%5.4f,%5.4f) g(%5.4f,%5.4f) b(%5.4f %5.4f) wp(%5.4f, %5.4f) "
> > + "min_luminance=%f, max_luminance=%f",
> > + mastering_display->has_primaries,
> > mastering_display->has_luminance,
> > + av_q2d(mastering_display->display_primaries[0][0]),
> > + av_q2d(mastering_display->display_primaries[0][1]),
> > + av_q2d(mastering_display->display_primaries[1][0]),
> > + av_q2d(mastering_display->display_primaries[1][1]),
> > + av_q2d(mastering_display->display_primaries[2][0]),
> > + av_q2d(mastering_display->display_primaries[2][1]),
> > + av_q2d(mastering_display->white_point[0]),
> > av_q2d(mastering_display->white_point[1]),
> > + av_q2d(mastering_display->min_luminance),
> > av_q2d(mastering_display->max_luminance));
> > +}
> > +
> > static void dump_color_property(AVFilterContext *ctx, AVFrame *frame)
> > {
> >const char *color_range_str =
> > av_color_range_name(frame->color_range);
> > @@ -271,6 +298,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> > *frame)
> >case AV_FRAME_DATA_REGIONS_OF_INTEREST:
> >dump_roi(ctx, sd);
> >break;
> > +case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA:
> > +dump_mastering_display(ctx, sd);
> > +break;
> >default:
> >av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d
> > bytes)",
> > sd->type, sd->size);
> > --
> > 1.7.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".
