Re: [FFmpeg-devel] [PATCH] avformat/mov: set AVFMT_SEEK_TO_PTS flag
On 03-05-2019 10:01 AM, Gyan wrote: On 03-05-2019 03:00 AM, Hendrik Leppkes wrote: On Thu, May 2, 2019 at 7:42 PM Sasi Inguva wrote: Looks good to me. We were already doing PTS based seeking in MOV demuxer (although it's not perfect). There are several problems with the MOV approach however. You cannot look at AVStream->index_entries, take a timestamp of such an index, and then ask the demuxer to seek to it. Because one is PTS and one is DTS, you would end up somewhere else. This mismatch is rather annoying if you want to use the index for anything externally. I know its a tad bit off-topic here, but this patch directly touches this area, and I ran into this just quite recently. Patch is good either way, it just documents what the demuxer does. Will apply soon. Pushed as 6223d076e3d0b887282a3ac67213a6a1563b71df Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, Apr 28, 2019 at 4:02 PM Marton Balint wrote: > Hi All, > > There has been discussion on the mailing list several times about the > inclusion of support for closed source components (codecs, formats, > filters, etc) in the main ffmpeg codebase. > > Also the removal of libNDI happened without general consensus, so a vote > is necessary to justify the removal. > > So here is a call to the voting committee [1] to decide on the following > two questions: > > 1) Should libNDI support be removed from the ffmpeg codebase? No. My thoughts (All thoughts expressed are solely mine, and does not represent the company I work for) : Open source violation by NDI is a serious issue that needs to be addressed. But removing the libndi plugin from the ffmpeg repository will not address the issue of violation. A willful violator can still distribute ffmpeg binaries with his own copy of libndi plugin(or any other non-free code). In this case NDI took prompt action and removed the said binaries from their website immediately. A similar violation was done by Amazon some time back (https://trac.ffmpeg.org/ticket/7214) and we closed that issue as Amazon took down binaries from their website and provided the source code of their plugin(In this case, NDI plugin is already open source). We didn't remove x264 plugin from ffmpeg because Amazon violated the GPL terms. Just because the violator here(Newtek) is the manufacturer of the hardware that utilizes the libndi plugin we don't have to remove it. By removing libndi we are achieving the following. - Punishing the lawful users of the libndi plugin - Nothing done to prevent the willful license violation of ffmpeg - Punishing NDI by removing their plugin from ffmpeg (An inconvenience for them, to maintain and distribute the libndi plugin sources separately) As per any rule of law, the innocents' rights will have to be protected first. In this case the rights of lawful users of libndi plugin should be protected. The violator will have to be punished without punishing the lawful users. Whatever punishment we come up with should be applicable to all violators, including those who don't have a plugin in ffmpeg repo that interacts with the violator's hardware(like Amazon's example). Regards, Karthick ___ 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/mov: set AVFMT_SEEK_TO_PTS flag
On 03-05-2019 03:00 AM, Hendrik Leppkes wrote: On Thu, May 2, 2019 at 7:42 PM Sasi Inguva wrote: Looks good to me. We were already doing PTS based seeking in MOV demuxer (although it's not perfect). There are several problems with the MOV approach however. You cannot look at AVStream->index_entries, take a timestamp of such an index, and then ask the demuxer to seek to it. Because one is PTS and one is DTS, you would end up somewhere else. This mismatch is rather annoying if you want to use the index for anything externally. I know its a tad bit off-topic here, but this patch directly touches this area, and I ran into this just quite recently. Patch is good either way, it just documents what the demuxer does. Will apply soon. Thanks, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi: add gblur_opencl filter
On Thu, May 2, 2019 at 11:27 PM Paul B Mahol wrote: > On 5/2/19, Dylan Fernando wrote: > > On Tue, 30 Apr 2019 at 11:45 pm, Paul B Mahol wrote: > > > >> On 4/30/19, Dylan Fernando wrote: > >> > > >> > Anyone have any feedback? > >> > >> If I'm not mistaken there is already one available. > >> ___ > >> 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". > > > > > > How do I run the available filter? > > Do you ask how to use gblur video filter? > ___ > 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". Sorry, I mean how do I run the opencl gblur filter, if there is one available ___ 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/mov: set AVFMT_SEEK_TO_PTS flag
On Thu, May 2, 2019 at 7:42 PM Sasi Inguva wrote: > > Looks good to me. We were already doing PTS based seeking in MOV demuxer > (although it's not perfect). > There are several problems with the MOV approach however. You cannot look at AVStream->index_entries, take a timestamp of such an index, and then ask the demuxer to seek to it. Because one is PTS and one is DTS, you would end up somewhere else. This mismatch is rather annoying if you want to use the index for anything externally. I know its a tad bit off-topic here, but this patch directly touches this area, and I ran into this just quite recently. Patch is good either way, it just documents what the demuxer does. - 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".
Re: [FFmpeg-devel] Using copyts with mpegts output fails after 26, 5 hours
OK, here it is again, attached. Στις Πέμ, 2 Μαΐ 2019 στις 9:56 μ.μ., ο/η Carl Eugen Hoyos έγραψε: > > Am Do., 2. Mai 2019 um 20:52 Uhr schrieb Panagiotis Malakoudis > : > > > > > On Thu, May 02, 2019 at 08:13:10PM +0300, Panagiotis Malakoudis wrote: > > > > > --- libavformat/mpegts.c 2019-04-30 16:11:49.0 +0300 > > > > +++ libavformat/mpegts.c 2019-04-30 18:55:12.736428766 +0300 > > > > > > doesnt apply with git am > > > Applying: Using copyts with mpegts output fails after 26, 5 hours > > > error: mpegts.c: does not exist in index > > > Patch failed at 0001 Using copyts with mpegts output fails after 26, 5 > > > hours > > > > > > > Sorry, it was a simple diff, not a git am compatible diff. Hope I made > > it correctly this time: > > You have to attach it to avoid linebreaks. > > Carl Eugen > ___ > 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". mpegts-33bit-git.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".
[FFmpeg-devel] [PATCH 2/2] avformat/webm_chunk: Check header filename length
Signed-off-by: Michael Niedermayer
---
libavformat/webm_chunk.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
index 561ec152e7..e2fbd8be1d 100644
--- a/libavformat/webm_chunk.c
+++ b/libavformat/webm_chunk.c
@@ -88,6 +88,8 @@ static int get_chunk_filename(AVFormatContext *s, int
is_header, char filename[M
{
WebMChunkContext *wc = s->priv_data;
AVFormatContext *oc = wc->avf;
+int len;
+
if (!filename) {
return AVERROR(EINVAL);
}
@@ -96,7 +98,11 @@ static int get_chunk_filename(AVFormatContext *s, int
is_header, char filename[M
av_log(oc, AV_LOG_ERROR, "No header filename provided\n");
return AVERROR(EINVAL);
}
-av_strlcpy(filename, wc->header_filename, MAX_FILENAME_SIZE);
+len = av_strlcpy(filename, wc->header_filename, MAX_FILENAME_SIZE);
+if (len >= MAX_FILENAME_SIZE) {
+av_log(oc, AV_LOG_ERROR, "header filename too long\n");
+return AVERROR(EINVAL);
+}
} else {
if (av_get_frame_filename(filename, MAX_FILENAME_SIZE,
s->url, wc->chunk_index - 1) < 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".
Re: [FFmpeg-devel] Using copyts with mpegts output fails after 26, 5 hours
> On Thu, May 02, 2019 at 08:13:10PM +0300, Panagiotis Malakoudis wrote:
> > When outputing to mpegts format, using -copyts option makes program
> > fail after the oveflow of mpegts PCR happens at around 26 hours and 30
> > minutes. When not using -copyts, only a warning is reported.
> > In order to reproduce the issue, you first have to create a 27 hour
> > mpegts video.
> > I have described the problem in thorough at ticket
> > https://trac.ffmpeg.org/ticket/7876
> >
> > The issue is resolved if you use a patch created originally by Arut
> > (Roman Arutyunyan) at
> > https://github.com/arut/ffmpeg-patches/blob/master/mpegts-33bit
> >
> > I have converted the patch in order to apply with current git and
> > confirmed working fine, fixing the above mentioned issue. Original
> > author describes the patch as: "Implements smooth 33-bit mpeg-ts
> > timestamp overflow in mpegts muxer."
> >
> > Here it is:
> > --- libavformat/mpegts.c 2019-04-30 16:11:49.0 +0300
> > +++ libavformat/mpegts.c 2019-04-30 18:55:12.736428766 +0300
>
> doesnt apply with git am
> Applying: Using copyts with mpegts output fails after 26, 5 hours
> error: mpegts.c: does not exist in index
> Patch failed at 0001 Using copyts with mpegts output fails after 26, 5 hours
>
Sorry, it was a simple diff, not a git am compatible diff. Hope I made
it correctly this time:
From 5273daaf8e568fc2a2b9a77d91cb8a834b9e14e7 Mon Sep 17 00:00:00 2001
From: Panagiotis Malakoudis
Date: Thu, 2 May 2019 21:34:44 +0300
Subject: [PATCH] Implement smooth 33bit mpegts timestamp overflow in mpegts
muxer
---
libavformat/mpegts.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 8a84e5cc19..b7f5d8ea4e 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -163,6 +163,9 @@ struct MpegTSContext {
/** structure to keep track of Program->pids mapping */
unsigned int nb_prg;
struct Program *prg;
+
+/** base timestamp for smooth rolling over 33bits */
+int64_t base_ts;
int8_t crc_validity[NB_PID_MAX];
/** filters for various streams specified by PMT + for the PAT and PMT */
@@ -982,6 +985,26 @@ static void new_data_packet(const uint8_t
*buffer, int len, AVPacket *pkt)
pkt->size = len;
}
+static int64_t unroll_timestamp(MpegTSContext *ts, int64_t t)
+{
+int64_t dt;
+
+if (t == AV_NOPTS_VALUE)
+return t;
+
+if (!ts->base_ts)
+ts->base_ts = t;
+
+dt = (t - ts->base_ts) & 0x01ll;
+if (dt & 0x01ll) {
+dt |= 0xll;
+}
+
+ts->base_ts += dt;
+
+return ts->base_ts;
+}
+
static int new_pes_packet(PESContext *pes, AVPacket *pkt)
{
uint8_t *sd;
@@ -1005,8 +1028,8 @@ static int new_pes_packet(PESContext *pes, AVPacket *pkt)
pkt->stream_index = pes->sub_st->index;
else
pkt->stream_index = pes->st->index;
-pkt->pts = pes->pts;
-pkt->dts = pes->dts;
+pkt->pts = unroll_timestamp(pes->ts, pes->pts);
+pkt->dts = unroll_timestamp(pes->ts, pes->dts);
/* store position of first TS packet of this PES packet */
pkt->pos = pes->ts_packet_pos;
pkt->flags = pes->flags;
--
2.20.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] Using copyts with mpegts output fails after 26, 5 hours
Am Do., 2. Mai 2019 um 20:52 Uhr schrieb Panagiotis Malakoudis : > > > On Thu, May 02, 2019 at 08:13:10PM +0300, Panagiotis Malakoudis wrote: > > > --- libavformat/mpegts.c 2019-04-30 16:11:49.0 +0300 > > > +++ libavformat/mpegts.c 2019-04-30 18:55:12.736428766 +0300 > > > > doesnt apply with git am > > Applying: Using copyts with mpegts output fails after 26, 5 hours > > error: mpegts.c: does not exist in index > > Patch failed at 0001 Using copyts with mpegts output fails after 26, 5 hours > > > > Sorry, it was a simple diff, not a git am compatible diff. Hope I made > it correctly this time: You have to attach it to avoid linebreaks. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/webm_chunk: Fix argument length of get_chunk_filename()
Signed-off-by: Michael Niedermayer
---
libavformat/webm_chunk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
index 2c99753b5b..561ec152e7 100644
--- a/libavformat/webm_chunk.c
+++ b/libavformat/webm_chunk.c
@@ -84,7 +84,7 @@ static int chunk_mux_init(AVFormatContext *s)
return 0;
}
-static int get_chunk_filename(AVFormatContext *s, int is_header, char
*filename)
+static int get_chunk_filename(AVFormatContext *s, int is_header, char
filename[MAX_FILENAME_SIZE])
{
WebMChunkContext *wc = s->priv_data;
AVFormatContext *oc = wc->avf;
--
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 1/3] lavf/webm_chunk: Respect buffer size
On Sat, Apr 20, 2019 at 12:03:14AM +0200, Andreas Rheinhardt wrote:
> The last argument of av_strlcpy is supposed to contain the size of the
> destination buffer, but it was filled with the size of the source
> string, effectively negating its very purpose.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> As the author information in my previous patchset has been munged, I
> resend this to make the committer's job easier.
> libavformat/webm_chunk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
> index ec1ec4bf91..2c99753b5b 100644
> --- a/libavformat/webm_chunk.c
> +++ b/libavformat/webm_chunk.c
> @@ -96,7 +96,7 @@ static int get_chunk_filename(AVFormatContext *s, int
> is_header, char *filename)
> av_log(oc, AV_LOG_ERROR, "No header filename provided\n");
> return AVERROR(EINVAL);
> }
> -av_strlcpy(filename, wc->header_filename,
> strlen(wc->header_filename) + 1);
> +av_strlcpy(filename, wc->header_filename, MAX_FILENAME_SIZE);
> } else {
> if (av_get_frame_filename(filename, MAX_FILENAME_SIZE,
>s->url, wc->chunk_index - 1) < 0) {
> --
> 2.21.0
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
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 v8] lavf/flv: Add XV (Xunlei Video) Support. fixes ticket #3720
The patch fixes ticket #3720. Add Xunlei video support.
Suggestions are appreciated.
Thank you
Shivam GoyalFrom 0f0d87b499c1e91bf2b6265a61e964c1a16da8de Mon Sep 17 00:00:00 2001
From: Shivam Goyal
Date: Thu, 2 May 2019 23:27:24 +0530
Subject: [PATCH] lavf/flv: Add XV (Xunlei Video) Support. fixes ticket #3720
---
Changelog| 1 +
doc/demuxers.texi| 7
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/flvdec.c | 74
libavformat/version.h| 4 +--
6 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/Changelog b/Changelog
index a3fa0c14a2..a9dc982d08 100644
--- a/Changelog
+++ b/Changelog
@@ -26,6 +26,7 @@ version :
- lscr decoder
- lagfun filter
- asoftclip filter
+- XV (Xunlei Video) demuxer
version 4.1:
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 57d1532212..4e27f5dfc8 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -266,6 +266,13 @@ Ignore the size of previous tag value.
Output all context of the onMetadata.
@end table
+@subsection XV (Xunlei Video file)
+
+Xunlei video files are modified flv files with some data encrypted. An XV video file @file{vid.xv} can be converted back to the original flv by using-
+@example
+ffmpeg -i vid.xv -c copy out.flv
+@end example
+
@section gif
Animated GIF demuxer.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..e090c051f1 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -561,6 +561,7 @@ OBJS-$(CONFIG_WV_MUXER) += wvenc.o wv.o apetag.o img2.o
OBJS-$(CONFIG_XA_DEMUXER)+= xa.o
OBJS-$(CONFIG_XBIN_DEMUXER) += bintext.o sauce.o
OBJS-$(CONFIG_XMV_DEMUXER) += xmv.o
+OBJS-$(CONFIG_XV_DEMUXER)+= flvdec.o
OBJS-$(CONFIG_XVAG_DEMUXER) += xvag.o
OBJS-$(CONFIG_XWMA_DEMUXER) += xwma.o
OBJS-$(CONFIG_YOP_DEMUXER) += yop.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d316a0529a..b499186071 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -456,6 +456,7 @@ extern AVOutputFormat ff_wv_muxer;
extern AVInputFormat ff_xa_demuxer;
extern AVInputFormat ff_xbin_demuxer;
extern AVInputFormat ff_xmv_demuxer;
+extern AVInputFormat ff_xv_demuxer;
extern AVInputFormat ff_xvag_demuxer;
extern AVInputFormat ff_xwma_demuxer;
extern AVInputFormat ff_yop_demuxer;
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index b531a39adc..bdb79400da 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -127,6 +127,19 @@ static int kux_probe(const AVProbeData *p)
return 0;
}
+static int xv_probe(const AVProbeData *p)
+{
+const uint8_t *d = p->buf;
+
+if (d[0] == 'X' &&
+d[1] == 'L' &&
+d[2] == 'V' &&
+d[3] == 'F') {
+return AVPROBE_SCORE_EXTENSION + 1;
+}
+return 0;
+}
+
static void add_keyframes_index(AVFormatContext *s)
{
FLVContext *flv = s->priv_data;
@@ -783,6 +796,46 @@ static int flv_read_header(AVFormatContext *s)
return 0;
}
+static int xv_read_header(AVFormatContext *s)
+{
+int flags;
+FLVContext *xv = s->priv_data;
+AVIOContext *ic = s->pb;
+int offset;
+int enc_tag_size;
+int rot;
+
+//Find the rot value for rotating the bytes
+avio_skip(ic, 0x20);
+rot = 0x46 - avio_r8(ic);
+
+avio_skip(ic, 3);
+
+flags = (avio_r8(ic) + rot) & 0xff;
+
+xv->missing_streams = flags & (FLV_HEADER_FLAG_HASVIDEO | FLV_HEADER_FLAG_HASAUDIO);
+
+s->ctx_flags |= AVFMTCTX_NOHEADER;
+
+offset = ((avio_r8(ic) + rot & 0xff) << 24 |
+ (avio_r8(ic) + rot & 0xff) << 16 |
+ (avio_r8(ic) + rot & 0xff) << 8 |
+ (avio_r8(ic) + rot & 0xff)) + 0x20;
+avio_seek(ic, offset + 5, SEEK_SET);
+
+enc_tag_size = ((avio_r8(ic) + rot & 0xff) << 16 |
+(avio_r8(ic) + rot & 0xff) << 8 |
+(avio_r8(ic) + rot & 0xff));
+//Skip encrypted data
+avio_skip(ic, enc_tag_size + 11);
+
+s->start_time = 0;
+xv->sum_flv_tag_size = 0;
+xv->last_keyframe_stream_index = -1;
+
+return 0;
+}
+
static int flv_read_close(AVFormatContext *s)
{
int i;
@@ -1424,3 +1477,24 @@ AVInputFormat ff_kux_demuxer = {
.extensions = "kux",
.priv_class = _class,
};
+
+static const AVClass xv_class = {
+.class_name = "xvdec",
+.item_name = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+AVInputFormat ff_xv_demuxer = {
+.name = "xv",
+.long_name = NULL_IF_CONFIG_SMALL("Xunlei(Thunder) Video File"),
+.priv_data_size = sizeof(FLVContext),
+.read_probe = xv_probe,
+.read_header= xv_read_header,
+.read_packet= flv_read_packet,
+.read_seek = flv_read_seek,
+.read_close = flv_read_close,
+
Re: [FFmpeg-devel] [PATCH] avformat/mov: set AVFMT_SEEK_TO_PTS flag
Looks good to me. We were already doing PTS based seeking in MOV demuxer (although it's not perfect). On Thu, May 2, 2019 at 3:23 AM Gyan wrote: > > FATE passes. Checked that transcoded output remains the same whereas in > copy mode, seek to a video KF using ffmpeg cli returns the desired KF > and not the earlier KF, as happens at present. > > Gyan > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] avcodec/cinepak: Add missing const qualifier
Michael Niedermayer: > On Thu, May 02, 2019 at 06:27:22AM +0200, Andreas Rheinhardt wrote: >> Has been forgotten in b606493717db6424d693e1a944f51171e9e72905. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> libavcodec/cinepak.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > fixed as someone on IRC pinged about it before i saw the patch > That was actually me. - Andreas/mkver ___ 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] Using copyts with mpegts output fails after 26, 5 hours
On Thu, May 02, 2019 at 08:13:10PM +0300, Panagiotis Malakoudis wrote: > When outputing to mpegts format, using -copyts option makes program > fail after the oveflow of mpegts PCR happens at around 26 hours and 30 > minutes. When not using -copyts, only a warning is reported. > In order to reproduce the issue, you first have to create a 27 hour > mpegts video. > I have described the problem in thorough at ticket > https://trac.ffmpeg.org/ticket/7876 > > The issue is resolved if you use a patch created originally by Arut > (Roman Arutyunyan) at > https://github.com/arut/ffmpeg-patches/blob/master/mpegts-33bit > > I have converted the patch in order to apply with current git and > confirmed working fine, fixing the above mentioned issue. Original > author describes the patch as: "Implements smooth 33-bit mpeg-ts > timestamp overflow in mpegts muxer." > > Here it is: > --- libavformat/mpegts.c 2019-04-30 16:11:49.0 +0300 > +++ libavformat/mpegts.c 2019-04-30 18:55:12.736428766 +0300 doesnt apply with git am Applying: Using copyts with mpegts output fails after 26, 5 hours error: mpegts.c: does not exist in index Patch failed at 0001 Using copyts with mpegts output fails after 26, 5 hours [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org 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] avcodec/cinepak: Add missing const qualifier
On Thu, May 02, 2019 at 06:27:22AM +0200, Andreas Rheinhardt wrote: > Has been forgotten in b606493717db6424d693e1a944f51171e9e72905. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/cinepak.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) fixed as someone on IRC pinged about it before i saw the patch -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu 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] Using copyts with mpegts output fails after 26, 5 hours
When outputing to mpegts format, using -copyts option makes program
fail after the oveflow of mpegts PCR happens at around 26 hours and 30
minutes. When not using -copyts, only a warning is reported.
In order to reproduce the issue, you first have to create a 27 hour
mpegts video.
I have described the problem in thorough at ticket
https://trac.ffmpeg.org/ticket/7876
The issue is resolved if you use a patch created originally by Arut
(Roman Arutyunyan) at
https://github.com/arut/ffmpeg-patches/blob/master/mpegts-33bit
I have converted the patch in order to apply with current git and
confirmed working fine, fixing the above mentioned issue. Original
author describes the patch as: "Implements smooth 33-bit mpeg-ts
timestamp overflow in mpegts muxer."
Here it is:
--- libavformat/mpegts.c 2019-04-30 16:11:49.0 +0300
+++ libavformat/mpegts.c 2019-04-30 18:55:12.736428766 +0300
@@ -163,6 +163,9 @@
/** structure to keep track of Program->pids mapping */
unsigned int nb_prg;
struct Program *prg;
+
+/** base timestamp for smooth rolling over 33bits */
+int64_t base_ts;
int8_t crc_validity[NB_PID_MAX];
/** filters for various streams specified by PMT + for the PAT and PMT */
@@ -982,6 +985,26 @@
pkt->size = len;
}
+static int64_t unroll_timestamp(MpegTSContext *ts, int64_t t)
+{
+int64_t dt;
+
+if (t == AV_NOPTS_VALUE)
+return t;
+
+if (!ts->base_ts)
+ts->base_ts = t;
+
+dt = (t - ts->base_ts) & 0x01ll;
+if (dt & 0x01ll) {
+dt |= 0xll;
+}
+
+ts->base_ts += dt;
+
+return ts->base_ts;
+}
+
static int new_pes_packet(PESContext *pes, AVPacket *pkt)
{
uint8_t *sd;
@@ -1005,8 +1028,8 @@
pkt->stream_index = pes->sub_st->index;
else
pkt->stream_index = pes->st->index;
-pkt->pts = pes->pts;
-pkt->dts = pes->dts;
+pkt->pts = unroll_timestamp(pes->ts, pes->pts);
+pkt->dts = unroll_timestamp(pes->ts, pes->dts);
/* store position of first TS packet of this PES packet */
pkt->pos = pes->ts_packet_pos;
pkt->flags = pes->flags;
___
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 3/5] doc/general.texi: remove note about regressed AviSynth+ header
On 3/30/2019 7:39 PM, Stephen Hutchinson wrote: I've uploaded the amended 1st patch and added a 6th to deal with the issues I encountered when testing the 'build FFmpeg with MSVC' route. Since git send-email (or Gmail) screwed up the threading when I sent these the first time, this is the proper order: http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241922.html <-fixed header update patch http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241502.html <-enabling the additional pix_fmts; nothing has changed on this one http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241507.html <-removing the header warning in the docs; nothing has changed on this one http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241504.html <-updating the project link to point to the AviSynth wiki page on AviSynth+; nothing has changed on this one http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241505.html <-usage note about 32-bit GCC builds of AviSynth+ and the AVSC_WIN32_GCC32 switch; nothing has changed on this one http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241923.html <-new (well, technically old) patch to fix FARPROC warnings/build errors Ping #1 for five of the six patches. ___ 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] doc/general.texi: add note about 32-bit GCC builds of AviSynth+
On 3/31/2019 8:12 PM, Stephen Hutchinson wrote:
---
The text has been updated to reflect that 32-bit builds of FFmpeg
in general don't default to AviSynth+GCC compatibility.
doc/general.texi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/doc/general.texi b/doc/general.texi
index bafa1e2ea2..6c1acb517c 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -51,6 +51,21 @@ For Windows, supported AviSynth variants are
For Linux and OS X, the supported AviSynth variant is
@url{https://github.com/avxsynth/avxsynth, AvxSynth}.
+@float NOTE
+In 2016, AviSynth+ added support for building with GCC. However, due to
+the eccentricities of Windows' calling conventions, 32-bit GCC builds
+of AviSynth+ are not compatible with typical 32-bit builds of FFmpeg.
+
+By default, FFmpeg assumes compatibility with 32-bit MSVC builds of
+AviSynth+ since that is the most widely-used and entrenched build
+configuration. Users can override this and enable support for 32-bit
+GCC builds of AviSynth+ by passing @code{-DAVSC_WIN32_GCC32} to
+@code{--extra-cflags} when configuring FFmpeg.
+
+64-bit builds of FFmpeg are not affected, and can use either MSVC or
+GCC builds of AviSynth+ without any special flags.
+@end float
+
@float NOTE
AviSynth and AvxSynth are loaded dynamically. Distributors can build FFmpeg
with @code{--enable-avisynth}, and the binaries will work regardless of the
Ping #2 for the sixth of the six patches.
___
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/3] lavf/webm_chunk: Respect buffer size
Andreas Rheinhardt:
> The last argument of av_strlcpy is supposed to contain the size of the
> destination buffer, but it was filled with the size of the source
> string, effectively negating its very purpose.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> As the author information in my previous patchset has been munged, I
> resend this to make the committer's job easier.
> libavformat/webm_chunk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
> index ec1ec4bf91..2c99753b5b 100644
> --- a/libavformat/webm_chunk.c
> +++ b/libavformat/webm_chunk.c
> @@ -96,7 +96,7 @@ static int get_chunk_filename(AVFormatContext *s, int
> is_header, char *filename)
> av_log(oc, AV_LOG_ERROR, "No header filename provided\n");
> return AVERROR(EINVAL);
> }
> -av_strlcpy(filename, wc->header_filename,
> strlen(wc->header_filename) + 1);
> +av_strlcpy(filename, wc->header_filename, MAX_FILENAME_SIZE);
> } else {
> if (av_get_frame_filename(filename, MAX_FILENAME_SIZE,
>s->url, wc->chunk_index - 1) < 0) {
>
Ping for the whole patchset.
- 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] lavfi: add gblur_opencl filter
On 5/2/19, Dylan Fernando wrote: > On Tue, 30 Apr 2019 at 11:45 pm, Paul B Mahol wrote: > >> On 4/30/19, Dylan Fernando wrote: >> > >> > Anyone have any feedback? >> >> If I'm not mistaken there is already one available. >> ___ >> 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". > > > How do I run the available filter? Do you ask how to use gblur video filter? ___ 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] lavfi: add gblur_opencl filter
On Tue, 30 Apr 2019 at 11:45 pm, Paul B Mahol wrote: > On 4/30/19, Dylan Fernando wrote: > > > > Anyone have any feedback? > > If I'm not mistaken there is already one available. > ___ > 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". How do I run the available filter? > ___ 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] [DECISION] Project policy on closed source components
Am Do., 2. Mai 2019 um 12:30 Uhr schrieb Timo Rothenpieler : > > On 28/04/2019 22:02, Marton Balint wrote: > > 1) Should libNDI support be removed from the ffmpeg codebase? > > No What do you suggest instead? Carl Eugen ___ 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 v7] lavf/flv: Add XV (Xunlei Video) Support. Fixes ticket #3720
On 02-05-2019 16:16, Moritz Barsnick wrote: > On Thu, May 02, 2019 at 10:33:41 +0530, shi...@iitk.ac.in wrote: > > A minor nitpick (which the person pushing will/should notice): > >> #define LIBAVFORMAT_VERSION_MAJOR 58 >> -#define LIBAVFORMAT_VERSION_MINOR 27 >> +#define LIBAVFORMAT_VERSION_MINOR 28 >> #define LIBAVFORMAT_VERSION_MICRO 103 > > When bumping MINOR, you need to reset MICRO to 100. Would reset it to 100. Sending another patch with the documentation too. Thank you Shivam Goyal ___ 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] avcodec: add realtime bitstream filter
On 02-05-2019 04:12 PM, Moritz Barsnick wrote:
On Wed, May 01, 2019 at 12:03:41 -0300, James Almer wrote:
+if (pkt->pts != AV_NOPTS_VALUE) {
+int64_t pts = av_rescale_q(pkt->pts, bsf->time_base_in, AV_TIME_BASE_Q) /
ctx->speed;
+int64_t now = av_gettime_relative();
+int64_t sleep = pts - now + ctx->delta;
+if (!ctx->inited) {
+ctx->inited = 1;
+sleep = 0;
+ctx->delta = now - pts;
If this is meant to be used for input, where seeking can take place,
wouldn't a flush() callback to set ctx->inited and ctx->delta back to 0
be needed?
Interesting point. I suppose you mean backward seeking. Is that a valid
use case for a bitstream filter? Would it also apply to the standard
filter, where I took this code from?
I don't know, but I can try to add that, if required. Can you tell me
how to emulate or test seeking from the command line? Would I create a
file with backward jumps in PTS (and how)?
Also, you may want to add support for -copyts which -re lacks as well.
Another complication is timestamp rollover, independent of copyts.
How does the filter behave with non-monotonic timestamps?
Gyan
P.S. you can craft files to test all of this by generating individual TS
files with custom timestamps and then 'cat'ting them together, whether
via the concat protocol or shell utility.
___
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 v7] lavf/flv: Add XV (Xunlei Video) Support. Fixes ticket #3720
On Thu, May 02, 2019 at 10:33:41 +0530, shi...@iitk.ac.in wrote: A minor nitpick (which the person pushing will/should notice): > #define LIBAVFORMAT_VERSION_MAJOR 58 > -#define LIBAVFORMAT_VERSION_MINOR 27 > +#define LIBAVFORMAT_VERSION_MINOR 28 > #define LIBAVFORMAT_VERSION_MICRO 103 When bumping MINOR, you need to reset MICRO to 100. 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".
Re: [FFmpeg-devel] [PATCH v2] avcodec: add realtime bitstream filter
On Wed, May 01, 2019 at 12:03:41 -0300, James Almer wrote:
> > +if (pkt->pts != AV_NOPTS_VALUE) {
> > +int64_t pts = av_rescale_q(pkt->pts, bsf->time_base_in,
> > AV_TIME_BASE_Q) / ctx->speed;
> > +int64_t now = av_gettime_relative();
> > +int64_t sleep = pts - now + ctx->delta;
> > +if (!ctx->inited) {
> > +ctx->inited = 1;
> > +sleep = 0;
> > +ctx->delta = now - pts;
>
> If this is meant to be used for input, where seeking can take place,
> wouldn't a flush() callback to set ctx->inited and ctx->delta back to 0
> be needed?
Interesting point. I suppose you mean backward seeking. Is that a valid
use case for a bitstream filter? Would it also apply to the standard
filter, where I took this code from?
I don't know, but I can try to add that, if required. Can you tell me
how to emulate or test seeking from the command line? Would I create a
file with backward jumps in PTS (and how)?
I also missed to bump libavcodec version, or to at least mention it,
BTW.
Thanks,
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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 28/04/2019 22:02, Marton Balint wrote: Hi All, There has been discussion on the mailing list several times about the inclusion of support for closed source components (codecs, formats, filters, etc) in the main ffmpeg codebase. Also the removal of libNDI happened without general consensus, so a vote is necessary to justify the removal. So here is a call to the voting committee [1] to decide on the following two questions: 1) Should libNDI support be removed from the ffmpeg codebase? No 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? They should have a very good reason to be included, but not generally be rejected just on that basis. On the example of NDI, its widespread use in video equipment and lack of alternatives gives it plenty of reason to be part of FFmpeg. So if this was still for vote in the current form, I'd say "No" here as well. 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/mux: skip parameter and pts checks for data muxer
On 02-05-2019 03:23 PM, Nicolas George wrote: Gyan (12019-04-28): b) ffmpeg will call avformat_write_header for the output, which will likely fail because of the aforementioned codec parameter issues. Are you sure? It looks to me like avformat_write_header() does not perform checks by itself, and null does not either. The flow is avformat_write_header -> avformat_init_output -> init_muxer And in the last function, lines 293-385 (as of 7eba26451) carry out the checks, and which my patch skips. The pipeline for dumping damaged streams is identical to dumping valid streams except for the part when timestamps are regulated and codec fields validated for the target muxer, which is what my patch disables for a single muxer that doesn't need them. I don't see much (any?) "wasted" processing with my patch, relative to streamcopying a valid stream. The problem is not about waste as a performance issue, the problem is about complexity as a maintenance issue. Exceptions are expensive in that regard. The problem is that there is no clean set of flags which isolate the parameter-agnostic muxers - not surprising as this is a library for making valid media files. A new flag could be invented, if the present patch is too idiosyncratic. On a related note, as I mentioned elsewhere in this thread, an existing flag AVFMT_NOTIMESTAMPS, which in theory I could use, is of no help here, as it has been set for muxers which do handle timestamps in some way. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mov: set AVFMT_SEEK_TO_PTS flag
FATE passes. Checked that transcoded output remains the same whereas in
copy mode, seek to a video KF using ffmpeg cli returns the desired KF
and not the earlier KF, as happens at present.
Gyan
From 029a75fe27e576cd0d04c8bdd0707d7903250bac Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Thu, 2 May 2019 15:00:02 +0530
Subject: [PATCH] avformat/mov: set AVFMT_SEEK_TO_PTS flag
Ever since 59ad504696, the demuxer expects its seek arg to be PTS
and adjusts internally to search index by DTS.
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index d0347b2970..78f692872b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -8006,5 +8006,5 @@ AVInputFormat ff_mov_demuxer = {
.read_packet= mov_read_packet,
.read_close = mov_read_close,
.read_seek = mov_read_seek,
-.flags = AVFMT_NO_BYTE_SEEK,
+.flags = AVFMT_NO_BYTE_SEEK | AVFMT_SEEK_TO_PTS,
};
--
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/mux: skip parameter and pts checks for data muxer
Gyan (12019-04-28): > b) ffmpeg will call avformat_write_header for the output, which will likely > fail because of the aforementioned codec parameter issues. Are you sure? It looks to me like avformat_write_header() does not perform checks by itself, and null does not either. > The pipeline for dumping damaged streams is identical to dumping valid > streams except for the part when timestamps are regulated and codec fields > validated for the target muxer, which is what my patch disables for a single > muxer that doesn't need them. I don't see much (any?) "wasted" processing > with my patch, relative to streamcopying a valid stream. The problem is not about waste as a performance issue, the problem is about complexity as a maintenance issue. Exceptions are expensive in that regard. Regards, -- Nicolas George 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] [DECISION] Project policy on closed source components
Marton Balint (12019-04-28): > 1) Should libNDI support be removed from the ffmpeg codebase? Yes. > 2) Should patches using closed source libraries which are not considered > "System Libraries" according to the GPL be rejected? Yes to that too, even though the vote was withdrawn pending clarification. Regards, -- Nicolas George 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] avfilter/f_realtime: add option to scale speed
Moritz Barsnick (12019-05-01): > --- > doc/filters.texi | 8 > libavfilter/f_realtime.c | 7 +-- > 2 files changed, 13 insertions(+), 2 deletions(-) LGTM. Regards, -- Nicolas George 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 V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order
> It seems awk is unconditionally required already. However I wanted to > say that it's a very nice dep to have While it's possibly nicer than other deps to have, it's still better to use it IMHO only when it adds some value, like simpler code, better performance, compliance with some things, etc. With this patchset, for part 1 I'm not sure I see the added value with awk, as it looks about the same complexity of the code compared to the shell version. Performance-wise it's negligible as print_in_columns() is only called about 5 times (but with thousands of values to process), so as long as the loop is efficient, the additional awk process per call is barely measurable. For part 2 the awk version is simpler code, but `log_file()` is called nearly 300 times, mostly with files with less than 5 lines to print. At this case it does add a performance penalty, especially on systems where a new process is expensive. ___ 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/3] avcodec/mediacodecdec: try to receive a frame after signaling EOF to the codec
On Wed, Apr 24, 2019 at 09:59:28AM +0200, Matthieu Bouron wrote:
> Avoids returning EAGAIN after signaling EOF to the codec in
> ff_mediacodec_dec_send() so we can try to receive a frame before
> returning in mediacodec_receive_frame().
>
> This helps avoiding an extra round-trip between avcodec_send_frame() and
> avcodec_receive_frame() while draining the remaining frames.
> ---
> libavcodec/mediacodecdec.c| 1 +
> libavcodec/mediacodecdec_common.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 3a4240aa95..e353e34bd5 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -461,6 +461,7 @@ static int mediacodec_receive_frame(AVCodecContext
> *avctx, AVFrame *frame)
> ret = ff_mediacodec_dec_send(avctx, s->ctx, _pkt, true);
> if (ret < 0)
> return ret;
> +return ff_mediacodec_dec_receive(avctx, s->ctx, frame, true);
> } else if (ret == AVERROR(EAGAIN) && s->ctx->current_input_buffer <
> 0) {
> return ff_mediacodec_dec_receive(avctx, s->ctx, frame, true);
> } else if (ret < 0) {
> diff --git a/libavcodec/mediacodecdec_common.c
> b/libavcodec/mediacodecdec_common.c
> index 7c2661f672..f7a06cdc6d 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -631,7 +631,7 @@ int ff_mediacodec_dec_send(AVCodecContext *avctx,
> MediaCodecDecContext *s,
> "Queued input buffer %zd size=%zd ts=%"PRIi64"\n", index,
> size, pts);
>
> s->draining = 1;
> -break;
> +return 0;
> } else {
> size = FFMIN(pkt->size - offset, size);
> memcpy(data, pkt->data + offset, size);
> --
> 2.21.0
>
Ping.
--
Matthieu B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7] lavf/flv: Add XV (Xunlei Video) Support. Fixes ticket #3720
On 2019-05-02 11:22, Gyan wrote: > On 02-05-2019 10:33 AM, shi...@iitk.ac.in wrote: > >> lavf/flv: Add XV (Xunlei Video) Support. >> The patch fixes ticket #3720. >> It would just skip the first packet, which stores the decrypted data and >> moves on the next packet. >> Also, Thank you Moritz Barsnick for commenting this on >> the ticket. It really helped me. >> >> I would also add the documentation for this once the patch is applied. > Better to submit the doc patch now so it can be reviewed. > > Gyan Ok, I am writing it. Thank You Shivam Goyal ___ 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".
