Re: [FFmpeg-devel] PATCH: dshow prevent some windows 10 anniv. ed crashes
On 8/19/2016 3:28 PM, Roger Pack wrote: > No complaints, would someone please push it for me? Sorry still > haven't figured out the key thing yet. pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 2/4] FFV1 p frames
On Thu, Aug 18, 2016 at 08:50:08PM +0200, Moritz Barsnick wrote:
> On Thu, Aug 18, 2016 at 14:49:28 +0300, Станислав Долганов wrote:
>
> > +static int decode_q_branch(FFV1Context *f, int level, int x, int y){
> > +RangeCoder *const c = &f->slice_context[0]->c;
> > +OBMCContext *s = &f->obmc;
> > +const int w= s->b_width << s->block_max_depth;
>
> This whole function breaks ffmpeg style (wrt brackets and whitespace)
> throughout. How come style is so different here from the rest of the
> patch?
This code is based on libavcodec/snowdec.c:static int decode_q_branch
Fixing formating is very welcome but it should be in a seperate patch
Or could you tell me what has changed between a reformatted
decode_q_branch() and the original in libavcodec/snowdec.c
thats not reformatted ?
I cant easily, which would make review of this change much harder ...
[...]
> > +coder->c.bytestream_start = coder->c.bytestream = coder->buffer;
> > //FIXME end/start? and at the other stoo
>
> Do the FIXMEs need to get fixed before the patch is ready for
> inclusion?
I think this originate from:
origin/master:libavcodec/snowenc.c:pc.bytestream= p_buffer; //FIXME
end/start? and at the other stoo
origin/master:libavcodec/snowenc.c:ic.bytestream= i_buffer; //FIXME
end/start? and at the other stoo
vs.
master:libavcodec/snowenc.c:coder->c.bytestream_start =
coder->c.bytestream= coder->buffer; //FIXME end/start? and at the other stoo
i think the FIXME should be kept, whatever it meant when code is
factored
either way this is not a fixme stanislav added so he cant know what
it means ...
about the rest of the review, thanks alot for the help!
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add append_list flag into hlsenc
On Thu, Aug 11, 2016 at 11:04:43PM +0800, Steven Liu wrote:
> When ffmpeg exit by exception, start a new ffmpeg will cover the old
> segment list, add this flag can continue append the new segments into old
> hls segment list
[...]
> +static int parse_playlist(AVFormatContext *s, const char *url)
> +{
> +HLSContext *hls = s->priv_data;
> +AVIOContext *in;
> +int ret = 0, is_segment = 0;
> +int64_t new_start_pos;
> +int64_t duration = 0;
> +char line[1024];
> +const char *ptr;
> +
> +if ((ret = ffio_open_whitelist(&in, url, AVIO_FLAG_READ,
> + &s->interrupt_callback, NULL,
> + s->protocol_whitelist,
> s->protocol_blacklist)) < 0)
> +return ret;
> +
> +read_chomp_line(in, line, sizeof(line));
> +if (strcmp(line, "#EXTM3U")) {
> +ret = AVERROR_INVALIDDATA;
> +goto fail;
> +}
> +
> +while (!avio_feof(in)) {
> +read_chomp_line(in, line, sizeof(line));
> +if (av_strstart(line, "#EXT-X-TARGETDURATION:", &ptr)) {
> +duration = atoi(ptr);
the set duration here is never used
> +} else if (av_strstart(line, "#EXT-X-MEDIA-SEQUENCE:", &ptr)) {
> +hls->sequence = atoi(ptr);
> +} else if (av_strstart(line, "#EXT-X-ENDLIST", &ptr)) {
> +} else if (av_strstart(line, "#EXTINF:", &ptr)) {
> +is_segment = 1;
> +hls->duration = atof(ptr);
this here is used
is that intended ?
> +} else if (av_strstart(line, "#", NULL)) {
> +continue;
> +} else if (line[0]) {
> +if (is_segment) {
> +new_start_pos = avio_tell(hls->avf->pb);
> +hls->size = new_start_pos - hls->start_pos;
> +av_strlcpy(hls->avf->filename, line, sizeof(line));
> +hls_append_segment(s, hls, hls->duration, hls->start_pos,
> hls->size);
> +is_segment = 0;
> +}
> +}
> +}
> +
> +fail:
> +avio_close(in);
> +return ret;
> +}
> +
> static void hls_free_segments(HLSSegment *p)
> {
> HLSSegment *en;
> @@ -752,6 +810,10 @@ static int hls_write_header(AVFormatContext *s)
> if ((ret = hls_mux_init(s)) < 0)
> goto fail;
>
> +if (hls->flags & HLS_APPEND_LIST) {
> +parse_playlist(s, s->filename);
> +}
> +
> if ((ret = hls_start(s)) < 0)
> goto fail;
>
> @@ -927,6 +989,7 @@ static const AVOption options[] = {
> {"discont_start", "start the playlist with a discontinuity tag", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX, E, "flags"},
> {"omit_endlist", "Do not append an endlist when ending stream", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_OMIT_ENDLIST }, 0, UINT_MAX, E, "flags"},
> {"split_by_time", "split the hls segment by time which user set by
> hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
> E, "flags"},
> +{"append_list", "append the new segments into old hls segment list", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E, "flags"},
> {"use_localtime", "set filename expansion with strftime at segment
> creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
> {"use_localtime_mkdir", "create last directory component in
> strftime-generated filename", OFFSET(use_localtime_mkdir), AV_OPT_TYPE_BOOL,
> {.i64 = 0 }, 0, 1, E },
> {"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type),
> AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E,
> "pl_type" },
> --
> 2.7.4 (Apple Git-66)
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 1/4] factoring obmc out of snow
On Fri, Aug 19, 2016 at 05:07:01PM +0300, Станислав Долганов wrote: > New fixes heres another crash: http://ffmpeg.org/~michael/snow-chroma-bug-fuzzed2.avi zzuf -c -s116 -r0.001 ./ffmpeg_g -i snow-chroma-bug.avi -f null - #0 ff_emu_edge_vfix15_mmx () at libavcodec/x86/videodsp.asm:340 #1 0x00c560d1 in emulated_edge_mc (dst=0x216fe70 "", src=0x29 , dst_stride=96, src_stride=96, block_w=15, block_h=11, src_x=41, src_y=-3, w=15, h=72, vfix_tbl=0x13678a0 , v_extend_var=0xf2a5a0 , hfix_tbl=0x1367960 , h_extend_var=0xf2a650 ) at libavcodec/x86/videodsp_init.c:195 #2 0x00c562ce in emulated_edge_mc_sse2 (buf=0x216fe70 "", src=0xff09 , buf_stride=96, src_stride=96, block_w=15, block_h=11, src_x=41, src_y=-3, w=88, h=72) at libavcodec/x86/videodsp_init.c:256 #3 0x00ea6a76 in ff_obmc_pred_block (s=0x2131b60, dst=0x2171660 "\233\233\233\233\233\233\233\233", tmp=0x216fe60 "", stride=96, sx=41, sy=-3, b_w=8, b_h=4, block=0x21ae19c, plane_index=2, w=88, h=72) at libavcodec/obmemc.c:328 #4 0x00aa403d in add_yblock (s=0x2131b60, sliced=1, sb=0x2131ae8, dst=0x21563a0, dst8=0x21bf82c "", obmc=0x13c7f40 "\b\034,@Pdt\210\210tdP@,\034\b\f 8Ldx\220\244\244\220xdL8 \f\f(@\\t\220\250\304Ĩ\220t\\@(\f\020,Lh\210\244\304\340\340Ĥ\210hL,\020\020,Lh\210\244\304\340\340Ĥ\210hL,\020\f(@\\t\220\250\304Ĩ\220t\\@(\f\f 8Ldx\220\244\244\220xdL8 \f\b\034,@Pdt\210\210tdP@,\034\b\b\024$0@L\\hh\\L@0$\024\b\004\020\030$,8@LL@8,$\030\020\004\004\b\020\024\034 (,,( \034\024\020\b\004", src_x=44, src_y=0, b_w=8, b_h=4, w=88, h=72, dst_stride=88, src_stride=96, obmc_stride=16, b_x=5, b_y=-1, add=1, offset_dst=0, plane_index=2) at libavcodec/obmemc.h:290 #5 0x00aa4c72 in predict_slice_buffered (s=0x2131b60, sb=0x2131ae8, old_buffer=0x21563a0, plane_index=2, add=1, mb_y=0) at libavcodec/obmemc.h:438 #6 0x00aa7e81 in decode_frame (avctx=0x1f07a60, data=0x2164500, got_frame=0x7fffdca4, avpkt=0x7fffd980) at libavcodec/snowdec.c:492 #7 0x00af2977 in avcodec_decode_video2 (avctx=0x1f07a60, picture=0x2164500, got_picture_ptr=0x7fffdca4, avpkt=0x7fffdbe0) at libavcodec/utils.c:2223 #8 0x00431549 in decode_video (ist=0x1f07860, pkt=0x7fffdbe0, got_output=0x7fffdca4) at ffmpeg.c:2087 #9 0x004326b0 in process_input_packet (ist=0x1f07860, pkt=0x7fffddc0, no_eof=0) at ffmpeg.c:2340 #10 0x00439a9c in process_input (file_index=0) at ffmpeg.c:4016 #11 0x00439da8 in transcode_step () at ffmpeg.c:4104 #12 0x00439eef in transcode () at ffmpeg.c:4158 #13 0x0043a620 in main (argc=6, argv=0x7fffe498) at ffmpeg.c:4353 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] Motion Interpolation
On Thu, Aug 18, 2016 at 07:26:39PM +, Davinder Singh wrote: > On Thu, Aug 18, 2016 at 11:52 PM Paul B Mahol wrote: > > > [...] > > > > i tried to modify EPZS. i removed the early termination threshold which > skip some predictors :-/ > new score: > $ tiny_psnr 60_source_2.yuv 60_bbb.yuv > stddev: 1.02 PSNR: 47.94 MAXDIFF: 186 bytes:476928000/474163200 > > original epzs: > $ tiny_psnr 60_source_2.yuv 60_bbb.yuv > stddev: 1.07 PSNR: 47.51 MAXDIFF: 186 bytes:476928000/474163200 how does it perform with matrixbench instead of BBB ? as reference 100fps matrixbench generated with mcfps from https://github.com/michaelni/FFmpeg/tree/mcfps ./ffmpeg -i matrixbench_mpeg2.mpg -vf 'mcfps=3:100,setpts=4*PTS' output for easy vissual comparission: http://ffmpeg.org/~michael/matrix100.avi [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mpegtsenc: write metadata descriptor for timed ID3 packets
On date Thursday 2016-05-19 18:45:35 +0200, Stefano Sabatini encoded:
> This is required since some softwares are not able to correctly recognize
> the metadata.
> ---
> libavformat/mpegtsenc.c | 24 ++--
> 1 file changed, 14 insertions(+), 10 deletions(-)
Updated, with some more documentation and references to the MPEGTS
standard.
Note: this patch was created comparing the output of FFmpeg with those
from encoding.com and elemental. With the change the output metadata
can be read by third-party players.
If the maintainers prefer, I can enable this output mode through a
flag.
--
FFmpeg = Fiendish & Fiendish Mastering Purposeless Egregious Goblin
>From 20f22c426a9f5c59d28f66a17b59d62301503d67 Mon Sep 17 00:00:00 2001
From: Stefano Sabatini
Date: Tue, 12 Apr 2016 18:16:21 +0200
Subject: [PATCH] lavf/mpegtsenc: write metadata descriptor for timed ID3
packets
This is required since some programs are not able to correctly recognize
the metadata. See H.222, 2.6.58 Metadata pointer descriptor.
putstr8() is modified in order to allow to skip writing the string
length.
---
libavformat/mpegtsenc.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index b437100..6f40615 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -256,7 +256,7 @@ static void mpegts_write_pat(AVFormatContext *s)
}
/* NOTE: !str is accepted for an empty string */
-static void putstr8(uint8_t **q_ptr, const char *str)
+static void putstr8(uint8_t **q_ptr, const char *str, int write_len)
{
uint8_t *q;
int len;
@@ -266,7 +266,8 @@ static void putstr8(uint8_t **q_ptr, const char *str)
len = 0;
else
len = strlen(str);
-*q++ = len;
+if (write_len)
+*q++ = len;
memcpy(q, str, len);
q += len;
*q_ptr = q;
@@ -628,12 +629,15 @@ static int mpegts_write_pmt(AVFormatContext *s, MpegTSService *service)
*q++ = 'V';
*q++ = 'A';
} else if (st->codecpar->codec_id == AV_CODEC_ID_TIMED_ID3) {
-*q++ = 0x5; /* MPEG-2 registration descriptor */
-*q++ = 4;
-*q++ = 'I';
-*q++ = 'D';
-*q++ = '3';
-*q++ = ' ';
+const char *tag = "ID3 ";
+*q++ = 0x26; /* metadata descriptor */
+*q++ = 13;
+put16(&q, 0x);/* metadata application format */
+putstr8(&q, tag, 0);
+*q++ = 0xff;/* metadata format */
+putstr8(&q, tag, 0);
+*q++ = 0;/* metadata service ID */
+*q++ = 0xF; /* metadata_locator_record_flag|MPEG_carriage_flags|reserved */
}
break;
}
@@ -678,8 +682,8 @@ static void mpegts_write_sdt(AVFormatContext *s)
desc_len_ptr = q;
q++;
*q++ = ts->service_type;
-putstr8(&q, service->provider_name);
-putstr8(&q, service->name);
+putstr8(&q, service->provider_name, 1);
+putstr8(&q, service->name, 1);
desc_len_ptr[0] = q - desc_len_ptr - 1;
/* fill descriptor length */
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add append_list flag into hlsenc
2016-08-20 19:51 GMT+08:00 Michael Niedermayer :
> On Thu, Aug 11, 2016 at 11:04:43PM +0800, Steven Liu wrote:
> > When ffmpeg exit by exception, start a new ffmpeg will cover the old
> > segment list, add this flag can continue append the new segments into old
> > hls segment list
> [...]
>
> > +static int parse_playlist(AVFormatContext *s, const char *url)
> > +{
> > +HLSContext *hls = s->priv_data;
> > +AVIOContext *in;
> > +int ret = 0, is_segment = 0;
> > +int64_t new_start_pos;
> > +int64_t duration = 0;
> > +char line[1024];
> > +const char *ptr;
> > +
> > +if ((ret = ffio_open_whitelist(&in, url, AVIO_FLAG_READ,
> > + &s->interrupt_callback, NULL,
> > + s->protocol_whitelist,
> s->protocol_blacklist)) < 0)
> > +return ret;
> > +
> > +read_chomp_line(in, line, sizeof(line));
> > +if (strcmp(line, "#EXTM3U")) {
> > +ret = AVERROR_INVALIDDATA;
> > +goto fail;
> > +}
> > +
> > +while (!avio_feof(in)) {
> > +read_chomp_line(in, line, sizeof(line));
> > +if (av_strstart(line, "#EXT-X-TARGETDURATION:", &ptr)) {
>
> > +duration = atoi(ptr);
>
> the set duration here is never used
>
ok, I'll remove this duration, and ignore this TAG and EXT-X-ENDLIST
>
>
> > +} else if (av_strstart(line, "#EXT-X-MEDIA-SEQUENCE:", &ptr)) {
> > +hls->sequence = atoi(ptr);
> > +} else if (av_strstart(line, "#EXT-X-ENDLIST", &ptr)) {
> > +} else if (av_strstart(line, "#EXTINF:", &ptr)) {
> > +is_segment = 1;
>
> > +hls->duration = atof(ptr);
>
> this here is used
> is that intended ?
>
Yes, create the hls info when parsing the old list, write the info looks
like hls_write_packet.
>
>
> > +} else if (av_strstart(line, "#", NULL)) {
> > +continue;
> > +} else if (line[0]) {
> > +if (is_segment) {
> > +new_start_pos = avio_tell(hls->avf->pb);
> > +hls->size = new_start_pos - hls->start_pos;
> > +av_strlcpy(hls->avf->filename, line, sizeof(line));
> > +hls_append_segment(s, hls, hls->duration,
> hls->start_pos, hls->size);
> > +is_segment = 0;
> > +}
> > +}
> > +}
> > +
> > +fail:
> > +avio_close(in);
> > +return ret;
> > +}
> > +
> > static void hls_free_segments(HLSSegment *p)
> > {
> > HLSSegment *en;
> > @@ -752,6 +810,10 @@ static int hls_write_header(AVFormatContext *s)
> > if ((ret = hls_mux_init(s)) < 0)
> > goto fail;
> >
> > +if (hls->flags & HLS_APPEND_LIST) {
> > +parse_playlist(s, s->filename);
> > +}
> > +
> > if ((ret = hls_start(s)) < 0)
> > goto fail;
> >
> > @@ -927,6 +989,7 @@ static const AVOption options[] = {
> > {"discont_start", "start the playlist with a discontinuity tag", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX, E, "flags"},
> > {"omit_endlist", "Do not append an endlist when ending stream", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_OMIT_ENDLIST }, 0, UINT_MAX, E, "flags"},
> > {"split_by_time", "split the hls segment by time which user set by
> hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
> E, "flags"},
> > +{"append_list", "append the new segments into old hls segment
> list", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E,
> "flags"},
> > {"use_localtime", "set filename expansion with strftime at segment
> creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
> > {"use_localtime_mkdir", "create last directory component in
> strftime-generated filename", OFFSET(use_localtime_mkdir),
> AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
> > {"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type),
> AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E,
> "pl_type" },
> > --
> > 2.7.4 (Apple Git-66)
> >
>
>
>
I will resend a new patch fix the above problem.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer
On date Tuesday 2016-06-28 11:42:42 +0200, Nicolas George encoded:
> Le decadi 10 messidor, an CCXXIV, Stefano Sabatini a écrit :
> > +The fftextdata bytestream consists of a sequence of packets. Each
> > +packet starts with a timestamps expressed in a format recognized by
> > +FFmpeg (see
> > +@ref{time duration syntax,,the Time duration section in the
> > ffmpeg-utils(1) manual,ffmpeg-utils})
> > +followed by a sequence of spaces and the base64 encoded data for the
> > +packet, terminated by ";". The data representation may contain
> > +interleaved space characters (a space, a tab, or a newline) which are
> > +ignored.
> > +
> > +At the moment a single stream can be represented by an fftextdata
> > +bytestream.
>
> I like the idea very much, but I feel the format is not very sympathetic to
> future extensions.
>
> I had implemented a similar feature in the past, but I did not go to the
> end. My idea was to use the default output format of ffprobe (thus,
> hexadecimal rather than base64). The parser works, but I was stuck with the
> problem that ffprobe outputs -show_format after -show_packets. I can post
> the old patch on the list if you want.
The output of show_format is shown after since there are some
information (e.g. number of read packets) which are available only
after we process the packets. It might be possible to introduce a flag
to show format before the packets (in this case the information could
be missing or inconsistent).
Please send the patch so that I can see your approach.
--
FFmpeg = Fundamentalist and Fanciful MultiPurpose Enhancing Genius
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] New MXF maintainer wanted
Hi Long story short: I no longer work with MXF (or broadcast in general), and my free time is currently being consumed by other projects. Therefore I feel it'd be better if someone took over the role as MXF maintainer. I took a few shots at the recent MXF tickets on trac, but I've forgotten too much to effectively fix them. Hence this mail I can stay on as lxfdec maintainer, since I'm subscribed to the "lxf" tag on trac. I will likely unsubscribe from this list, posting only if there's an LXF ticket to deal with. /Tomas signature.asc Description: This is a digitally signed message part ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/window_func: use a constant instead of acosh()
On 8/20/2016 2:46 AM, Paul B Mahol wrote:
> On Saturday, August 20, 2016, James Almer wrote:
>
>> Should fix compilation with non C99 compilers like msvc 2012, where
>> acosh() is not available.
>>
>> Signed-off-by: James Almer >
>> ---
>> A fallback function like
>>
>> static av_always_inline double acosh(double x)
>> {
>> return log(x + sqrt((x * x) - 1.0));
>> }
>>
>> could be added to libm.h if acosh() is needed sometime in the
>> future for values that can't be computed at compile time.
>> The above example doesn't take into account things like x == NaN
>> and x < 1.0, though.
>>
>> libavfilter/window_func.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavfilter/window_func.c b/libavfilter/window_func.c
>> index fcdf6ea..acf1b20 100644
>> --- a/libavfilter/window_func.c
>> +++ b/libavfilter/window_func.c
>> @@ -117,7 +117,7 @@ void ff_generate_window_func(float *lut, int N, int
>> win_func, float *overlap)
>> *overlap = 0.33;
>> break;
>> case WFUNC_DOLPH: {
>> -double b = cosh(acosh(pow(10., 3)) / (N-1)), sum, t, c, norm = 0;
>> +double b = cosh(7.6009022095419887 / (N-1)), sum, t, c, norm = 0;
>> int j;
>> for (c = 1 - 1 / (b*b), n = (N-1) / 2; n >= 0; --n) {
>> for (sum = !n, b = t = j = 1; j <= n && sum != t; b *= (n-j)
>> * (1./j), ++j)
>
>
>>
>
>
>
> LGTM
Pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mpegtsenc: write metadata descriptor for timed ID3 packets
On Sat, Aug 20, 2016 at 03:48:35PM +0200, Stefano Sabatini wrote: > On date Thursday 2016-05-19 18:45:35 +0200, Stefano Sabatini encoded: > > This is required since some softwares are not able to correctly recognize > > the metadata. > > --- > > libavformat/mpegtsenc.c | 24 ++-- > > 1 file changed, 14 insertions(+), 10 deletions(-) > > Updated, with some more documentation and references to the MPEGTS > standard. > > Note: this patch was created comparing the output of FFmpeg with those > from encoding.com and elemental. With the change the output metadata > can be read by third-party players. > > If the maintainers prefer, I can enable this output mode through a > flag. > -- > FFmpeg = Fiendish & Fiendish Mastering Purposeless Egregious Goblin > mpegtsenc.c | 24 ++-- > 1 file changed, 14 insertions(+), 10 deletions(-) > 3a6655bca70653c64bfb5f2073d01feee73e64c2 > 0003-lavf-mpegtsenc-write-metadata-descriptor-for-timed-I.patch > From 20f22c426a9f5c59d28f66a17b59d62301503d67 Mon Sep 17 00:00:00 2001 > From: Stefano Sabatini > Date: Tue, 12 Apr 2016 18:16:21 +0200 > Subject: [PATCH] lavf/mpegtsenc: write metadata descriptor for timed ID3 > packets > > This is required since some programs are not able to correctly recognize > the metadata. See H.222, 2.6.58 Metadata pointer descriptor. > > putstr8() is modified in order to allow to skip writing the string > length. > --- > libavformat/mpegtsenc.c | 24 ++-- > 1 file changed, 14 insertions(+), 10 deletions(-) > > diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c > index b437100..6f40615 100644 > --- a/libavformat/mpegtsenc.c > +++ b/libavformat/mpegtsenc.c > @@ -256,7 +256,7 @@ static void mpegts_write_pat(AVFormatContext *s) > } > > /* NOTE: !str is accepted for an empty string */ > -static void putstr8(uint8_t **q_ptr, const char *str) > +static void putstr8(uint8_t **q_ptr, const char *str, int write_len) breaks build, putstr8() seems after the place where a use is added in git master, or i did somehing silly libavformat/mpegtsenc.c: In function ‘mpegts_write_pmt’: libavformat/mpegtsenc.c:618:17: error: implicit declaration of function ‘putstr8’ [-Werror=implicit-function-declaration] libavformat/mpegtsenc.c: At top level: libavformat/mpegtsenc.c:644:13: warning: conflicting types for ‘putstr8’ [enabled by default] libavformat/mpegtsenc.c:644:13: error: static declaration of ‘putstr8’ follows non-static declaration libavformat/mpegtsenc.c:618:17: note: previous implicit declaration of ‘putstr8’ was here cc1: some warnings being treated as errors make: *** [libavformat/mpegtsenc.o] Error 1 [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] V7 - Adding SCTE-35 CUI codec
On Fri, Aug 19, 2016 at 11:48 AM, Michael Niedermayer wrote: > can you document in a comment briefly what is in the AVPackets > for most codecs that is clear, SCTE-35 is maybe a bit special > also what the dts/pts values of teh AVPackets mean Really don't know what kind of comments or where to add them... dts/pts are dts/pts :-) Can you point me to a variable or function etc that is not clear? I'll be happy to add comments but I need a bit of assistance here. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_crop: make it possible to crop single pixels from subsampled pixel formats
Hi, patch attached. 0001-avfilter-vf_crop-make-it-possible-to-crop-single-pix.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] Motion Interpolation
On Fri, Aug 19, 2016 at 7:59 PM Robert Krüger wrote: > [...] Impressive results, great job! thanks :) > > I just tried minterpolate=fps=250:mc_mode=aobmc:me=epzs and did have some > artefacts in one of my slowmo samples but overall the quality is very, very > nice! If you're interested in more samples or in more testing, let me know. > search_param 32 (default) works best for me for 720p videos. for 1080p higher can be better, it reduce artifiacts in fast motion. for low end (480p) p=16 works fine. you can also try bidir me_mode. > > Is the command line I used the one best for reducing artefacts or are there > options known to be better in terms of artefact reduction? > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] Motion Interpolation
On Sat, Aug 20, 2016 at 5:45 PM Michael Niedermayer wrote: > how does it perform with matrixbench instead of BBB ? > > as reference 100fps matrixbench generated with mcfps > from https://github.com/michaelni/FFmpeg/tree/mcfps > ./ffmpeg -i matrixbench_mpeg2.mpg -vf 'mcfps=3:100,setpts=4*PTS' > output for easy vissual comparission: > http://ffmpeg.org/~michael/matrix100.avi have a look: http://www.mediafire.com/?sssw8tqj5kn3vbk ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] V7 - Adding SCTE-35 CUI codec
On Sat, Aug 20, 2016 at 10:04:15AM -0700, Carlos Fernandez Sanz wrote: > On Fri, Aug 19, 2016 at 11:48 AM, Michael Niedermayer > wrote: > > > can you document in a comment briefly what is in the AVPackets > > for most codecs that is clear, SCTE-35 is maybe a bit special > > also what the dts/pts values of teh AVPackets mean > > Really don't know what kind of comments or where to add them... > dts/pts are dts/pts :-) > Can you point me to a variable or function etc that is not clear? dts are decode timestamps, that is for video thats when a packet enters an idealized decoder, pts is the timestamp when the video frame is presented for audio pts == dts generally as theres no reordering or delay in the ideallized decoder that is assumed what do they mean for SCTE-35 ? IIUC SCTE-35 can describe various timespans, how do these relate to dts/pts ? are the dts/pts entirely meaningless and just used for transport stream interleaving or do they somehow match the start of some timestamp? Are the timespans inside relative to the dts/pts or not? I think writing a few words about this would make it easier for applications to use this instead of just passing opaque SCTE-35 packets between libavformat and libavcodec > I'll be happy to add comments but I need a bit of assistance here. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] Motion Interpolation
On Sat, Aug 20, 2016 at 06:39:17PM +, Davinder Singh wrote: > On Sat, Aug 20, 2016 at 5:45 PM Michael Niedermayer > wrote: > > > how does it perform with matrixbench instead of BBB ? > > > > as reference 100fps matrixbench generated with mcfps > > from https://github.com/michaelni/FFmpeg/tree/mcfps > > ./ffmpeg -i matrixbench_mpeg2.mpg -vf 'mcfps=3:100,setpts=4*PTS' > > output for easy vissual comparission: > > http://ffmpeg.org/~michael/matrix100.avi > > > have a look: http://www.mediafire.com/?sssw8tqj5kn3vbk thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 2/4] FFV1 p frames
More error handling based on snow decoder errors from patch 1 discussion.
2016-08-20 14:10 GMT+03:00 Michael Niedermayer :
> On Thu, Aug 18, 2016 at 08:50:08PM +0200, Moritz Barsnick wrote:
> > On Thu, Aug 18, 2016 at 14:49:28 +0300, Станислав Долганов wrote:
> >
> > > +static int decode_q_branch(FFV1Context *f, int level, int x, int y){
> > > +RangeCoder *const c = &f->slice_context[0]->c;
> > > +OBMCContext *s = &f->obmc;
> > > +const int w= s->b_width << s->block_max_depth;
> >
> > This whole function breaks ffmpeg style (wrt brackets and whitespace)
> > throughout. How come style is so different here from the rest of the
> > patch?
>
> This code is based on libavcodec/snowdec.c:static int decode_q_branch
> Fixing formating is very welcome but it should be in a seperate patch
>
> Or could you tell me what has changed between a reformatted
> decode_q_branch() and the original in libavcodec/snowdec.c
> thats not reformatted ?
> I cant easily, which would make review of this change much harder ...
>
>
> [...]
>
> > > +coder->c.bytestream_start = coder->c.bytestream = coder->buffer;
> //FIXME end/start? and at the other stoo
> >
> > Do the FIXMEs need to get fixed before the patch is ready for
> > inclusion?
>
> I think this originate from:
>
> origin/master:libavcodec/snowenc.c:pc.bytestream= p_buffer; //FIXME
> end/start? and at the other stoo
> origin/master:libavcodec/snowenc.c:ic.bytestream= i_buffer; //FIXME
> end/start? and at the other stoo
> vs.
> master:libavcodec/snowenc.c:coder->c.bytestream_start =
> coder->c.bytestream= coder->buffer; //FIXME end/start? and at the other stoo
>
> i think the FIXME should be kept, whatever it meant when code is
> factored
> either way this is not a fixme stanislav added so he cant know what
> it means ...
>
> about the rest of the review, thanks alot for the help!
>
> [...]
>
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
--
Станислав Долганов
0002-FFV1-p-frames.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 1/4] factoring obmc out of snow
On Sat, Aug 20, 2016 at 11:01:29PM +0300, Станислав Долганов wrote: > Fixed it. breaks fate (this worked with the previous patch) make: *** [fate-vsynth1-snow] Error 139 make: *** [fate-vsynth1-snow-hpel] Error 139 make: *** [fate-vsynth1-snow-ll] Error 139 make: *** [fate-filter-mcdeint-fast] Error 139 make: *** [fate-filter-mcdeint-medium] Error 139 make: *** [fate-vsynth2-snow] Error 139 make: *** [fate-vsynth2-snow-hpel] Error 139 make: *** [fate-vsynth2-snow-ll] Error 139 make: *** [fate-vsynth_lena-snow] Error 139 make: *** [fate-vsynth_lena-snow-hpel] Error 139 make: *** [fate-vsynth_lena-snow-ll] Error 139 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 2/4] FFV1 p frames
On Sat, Aug 20, 2016 at 13:10:56 +0200, Michael Niedermayer wrote:
> On Thu, Aug 18, 2016 at 08:50:08PM +0200, Moritz Barsnick wrote:
> This code is based on libavcodec/snowdec.c:static int decode_q_branch
> Fixing formating is very welcome but it should be in a seperate patch
I thought it was being factored out, I didn't realize code copy was
still taking place.
If even the formatting is copied, so is probably the majority of the
code? Can this duplication be avoided? Just wondering. Let me check...
See below.
> Or could you tell me what has changed between a reformatted
> decode_q_branch() and the original in libavcodec/snowdec.c
> thats not reformatted ?
> I cant easily, which would make review of this change much harder ...
True, though both are not identical, thanks to different choice of
variable names. But why is the code not shared? (I'm wondering, not
complaining - yet.)
As after applying patch 0001 and 0002, it looks like ffv1's
decode_q_branch() could be like this:
static int decode_q_branch(FFV1Context *f, int level, int x, int y) {
// pseudo code, you get my jist:
return snow::decode_q_branch(&f->ombc, level, x, y);
}
> I think this originate from:
> origin/master:libavcodec/snowenc.c:pc.bytestream= p_buffer; //FIXME
> end/start? and at the other stoo
> origin/master:libavcodec/snowenc.c:ic.bytestream= i_buffer; //FIXME
> end/start? and at the other stoo
I get the point.
> i think the FIXME should be kept, whatever it meant when code is
> factored either way this is not a fixme stanislav added so he cant
> know what it means ...
I agree, sorry for the noise.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 2/4] FFV1 p frames
On Sat, Aug 20, 2016 at 10:45:59PM +0200, Moritz Barsnick wrote:
> On Sat, Aug 20, 2016 at 13:10:56 +0200, Michael Niedermayer wrote:
> > On Thu, Aug 18, 2016 at 08:50:08PM +0200, Moritz Barsnick wrote:
>
> > This code is based on libavcodec/snowdec.c:static int decode_q_branch
> > Fixing formating is very welcome but it should be in a seperate patch
>
> I thought it was being factored out, I didn't realize code copy was
> still taking place.
>
> If even the formatting is copied, so is probably the majority of the
> code? Can this duplication be avoided? Just wondering. Let me check...
> See below.
>
> > Or could you tell me what has changed between a reformatted
> > decode_q_branch() and the original in libavcodec/snowdec.c
> > thats not reformatted ?
> > I cant easily, which would make review of this change much harder ...
>
> True, though both are not identical, thanks to different choice of
> variable names. But why is the code not shared? (I'm wondering, not
> complaining - yet.)
>
> As after applying patch 0001 and 0002, it looks like ffv1's
> decode_q_branch() could be like this:
> static int decode_q_branch(FFV1Context *f, int level, int x, int y) {
> // pseudo code, you get my jist:
> return snow::decode_q_branch(&f->ombc, level, x, y);
> }
its better for decode_q_branch() to be duplicated
I want to be able to develop the bitstream syntax of ffv1 and snow
idependantly.
FFV1 will likely be heavily influenced by IETF decissions, snow
wont
also theres a seperate line of thought:
Snow must use OBMC due to its use of wavelets, FFv1 may or may not
stay on the OBMC route, we will see.
iam ATM not satisfied with the non OBMC testing done.
The OBMC tests use the most advanced code we have, the non OBMC
tests used the OBMC code with the overlapp switched off AFAIK
(cuz its easy and GSoC is just too short to do everything ...)
but non overlapped MC allows other optimizations like more complete
"rate distortion" which have not been tested but which every modern
encoder use.
A key question is IMO how OBMC (without RD) vs. BMC (with RD)
perform.
Somehow BMC with RD didnt happen within the GSoC time (which is just
too short to try everything i guess), but IMHO its the most
important post GSoC work.
On the decoder side BMC should be 2-4 times faster than OBMC.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_crop: make it possible to crop single pixels from subsampled pixel formats
On Sat, Aug 20, 2016 at 07:42:09PM +0200, Paul B Mahol wrote: > Hi, > > patch attached. > vf_crop.c |2 -- > 1 file changed, 2 deletions(-) > fa7e5dd663b07c06f58f845cb3b519f8904e3bca > 0001-avfilter-vf_crop-make-it-possible-to-crop-single-pix.patch > From e9f380d9aab2f1f82183f05b91f37ec1e50bd6da Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Sat, 20 Aug 2016 19:38:48 +0200 > Subject: [PATCH] avfilter/vf_crop: make it possible to crop single pixels from > subsampled pixel formats > > --- > libavfilter/vf_crop.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c > index 01773fa..91cb3c0 100644 > --- a/libavfilter/vf_crop.c > +++ b/libavfilter/vf_crop.c > @@ -184,8 +184,6 @@ static int config_input(AVFilterLink *link) > s->w_expr, s->h_expr); > return AVERROR(EINVAL); > } > -s->w &= ~((1 << s->hsub) - 1); > -s->h &= ~((1 << s->vsub) - 1); this might be unexpected for people that use expressions like w:h*aspectwhatever as they could get odd sized videos which might have issues playing on some devices I agree that when litteral numbers are specified the change makes sense [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_crop: make it possible to crop single pixels from subsampled pixel formats
On 8/20/16, Michael Niedermayer wrote: > On Sat, Aug 20, 2016 at 07:42:09PM +0200, Paul B Mahol wrote: >> Hi, >> >> patch attached. > >> vf_crop.c |2 -- >> 1 file changed, 2 deletions(-) >> fa7e5dd663b07c06f58f845cb3b519f8904e3bca >> 0001-avfilter-vf_crop-make-it-possible-to-crop-single-pix.patch >> From e9f380d9aab2f1f82183f05b91f37ec1e50bd6da Mon Sep 17 00:00:00 2001 >> From: Paul B Mahol >> Date: Sat, 20 Aug 2016 19:38:48 +0200 >> Subject: [PATCH] avfilter/vf_crop: make it possible to crop single pixels >> from >> subsampled pixel formats >> >> --- >> libavfilter/vf_crop.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c >> index 01773fa..91cb3c0 100644 >> --- a/libavfilter/vf_crop.c >> +++ b/libavfilter/vf_crop.c >> @@ -184,8 +184,6 @@ static int config_input(AVFilterLink *link) >> s->w_expr, s->h_expr); >> return AVERROR(EINVAL); >> } >> -s->w &= ~((1 << s->hsub) - 1); >> -s->h &= ~((1 << s->vsub) - 1); > > this might be unexpected for people that use expressions > like w:h*aspectwhatever > as they could get odd sized videos which might have issues playing > on some devices > > I agree that when litteral numbers are specified the change makes > sense Then I will add option, by default turned off, to enable exact cropping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_crop: make it possible to crop single pixels from subsampled pixel formats
On 8/20/16, Paul B Mahol wrote: > On 8/20/16, Michael Niedermayer wrote: >> On Sat, Aug 20, 2016 at 07:42:09PM +0200, Paul B Mahol wrote: >>> Hi, >>> >>> patch attached. >> >>> vf_crop.c |2 -- >>> 1 file changed, 2 deletions(-) >>> fa7e5dd663b07c06f58f845cb3b519f8904e3bca >>> 0001-avfilter-vf_crop-make-it-possible-to-crop-single-pix.patch >>> From e9f380d9aab2f1f82183f05b91f37ec1e50bd6da Mon Sep 17 00:00:00 2001 >>> From: Paul B Mahol >>> Date: Sat, 20 Aug 2016 19:38:48 +0200 >>> Subject: [PATCH] avfilter/vf_crop: make it possible to crop single >>> pixels >>> from >>> subsampled pixel formats >>> >>> --- >>> libavfilter/vf_crop.c | 2 -- >>> 1 file changed, 2 deletions(-) >>> >>> diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c >>> index 01773fa..91cb3c0 100644 >>> --- a/libavfilter/vf_crop.c >>> +++ b/libavfilter/vf_crop.c >>> @@ -184,8 +184,6 @@ static int config_input(AVFilterLink *link) >>> s->w_expr, s->h_expr); >>> return AVERROR(EINVAL); >>> } >>> -s->w &= ~((1 << s->hsub) - 1); >>> -s->h &= ~((1 << s->vsub) - 1); >> >> this might be unexpected for people that use expressions >> like w:h*aspectwhatever >> as they could get odd sized videos which might have issues playing >> on some devices >> >> I agree that when litteral numbers are specified the change makes >> sense > > Then I will add option, by default turned off, to enable exact cropping. > New patch attached. 0001-avfilter-vf_crop-make-possible-to-do-exact-cropping-.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_crop: make it possible to crop single pixels from subsampled pixel formats
On Sun, Aug 21, 2016 at 12:03:45AM +0200, Paul B Mahol wrote:
> On 8/20/16, Paul B Mahol wrote:
> > On 8/20/16, Michael Niedermayer wrote:
> >> On Sat, Aug 20, 2016 at 07:42:09PM +0200, Paul B Mahol wrote:
> >>> Hi,
> >>>
> >>> patch attached.
> >>
> >>> vf_crop.c |2 --
> >>> 1 file changed, 2 deletions(-)
> >>> fa7e5dd663b07c06f58f845cb3b519f8904e3bca
> >>> 0001-avfilter-vf_crop-make-it-possible-to-crop-single-pix.patch
> >>> From e9f380d9aab2f1f82183f05b91f37ec1e50bd6da Mon Sep 17 00:00:00 2001
> >>> From: Paul B Mahol
> >>> Date: Sat, 20 Aug 2016 19:38:48 +0200
> >>> Subject: [PATCH] avfilter/vf_crop: make it possible to crop single
> >>> pixels
> >>> from
> >>> subsampled pixel formats
> >>>
> >>> ---
> >>> libavfilter/vf_crop.c | 2 --
> >>> 1 file changed, 2 deletions(-)
> >>>
> >>> diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c
> >>> index 01773fa..91cb3c0 100644
> >>> --- a/libavfilter/vf_crop.c
> >>> +++ b/libavfilter/vf_crop.c
> >>> @@ -184,8 +184,6 @@ static int config_input(AVFilterLink *link)
> >>> s->w_expr, s->h_expr);
> >>> return AVERROR(EINVAL);
> >>> }
> >>> -s->w &= ~((1 << s->hsub) - 1);
> >>> -s->h &= ~((1 << s->vsub) - 1);
> >>
> >> this might be unexpected for people that use expressions
> >> like w:h*aspectwhatever
> >> as they could get odd sized videos which might have issues playing
> >> on some devices
> >>
> >> I agree that when litteral numbers are specified the change makes
> >> sense
> >
> > Then I will add option, by default turned off, to enable exact cropping.
> >
>
> New patch attached.
> doc/filters.texi |5 +
> libavfilter/vf_crop.c | 21 +++--
> 2 files changed, 20 insertions(+), 6 deletions(-)
> 5faa13e197bdea192aa98bc14717145412ae67d3
> 0001-avfilter-vf_crop-make-possible-to-do-exact-cropping-.patch
> From 9fa1ce9969edaa9f0307616b4ca9706f618036bb Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Sun, 21 Aug 2016 00:01:57 +0200
> Subject: [PATCH] avfilter/vf_crop: make possible to do exact cropping for
> subsampled videos
>
> ---
> doc/filters.texi | 5 +
> libavfilter/vf_crop.c | 21 +++--
> 2 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index e9b8c93..591a55d 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -5633,6 +5633,11 @@ This expression is evaluated per-frame.
> If set to 1 will force the output display aspect ratio
> to be the same of the input, by changing the output sample aspect
> ratio. It defaults to 0.
> +
> +@item exact
> +Enable exact cropping. If enabled, subsampled videos will be cropped at exact
> +width/height/x/y as specified and will not be rounded to nearest smaller
> value.
> +It defaults to 0.
> @end table
>
> The @var{out_w}, @var{out_h}, @var{x}, @var{y} parameters are
> diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c
> index 01773fa..bcdbb8c 100644
> --- a/libavfilter/vf_crop.c
> +++ b/libavfilter/vf_crop.c
> @@ -82,6 +82,7 @@ typedef struct CropContext {
>
> AVRational out_sar; ///< output sample aspect ratio
> int keep_aspect;///< keep display aspect ratio when cropping
> +int exact; ///< exact cropping, for subsampled formats
>
> int max_step[4];///< max pixel step for each plane, expressed as a
> number of bytes
> int hsub, vsub; ///< chroma subsampling
> @@ -184,8 +185,11 @@ static int config_input(AVFilterLink *link)
> s->w_expr, s->h_expr);
> return AVERROR(EINVAL);
> }
> -s->w &= ~((1 << s->hsub) - 1);
> -s->h &= ~((1 << s->vsub) - 1);
> +
> +if (!s->exact) {
> +s->w &= ~((1 << s->hsub) - 1);
> +s->h &= ~((1 << s->vsub) - 1);
> +}
>
> av_expr_free(s->x_pexpr);
> av_expr_free(s->y_pexpr);
> @@ -219,8 +223,10 @@ static int config_input(AVFilterLink *link)
> /* set default, required in the case the first computed value for x/y is
> NAN */
> s->x = (link->w - s->w) / 2;
> s->y = (link->h - s->h) / 2;
> -s->x &= ~((1 << s->hsub) - 1);
> -s->y &= ~((1 << s->vsub) - 1);
> +if (!s->exact) {
> +s->x &= ~((1 << s->hsub) - 1);
> +s->y &= ~((1 << s->vsub) - 1);
> +}
> return 0;
>
> fail_expr:
> @@ -269,8 +275,10 @@ static int filter_frame(AVFilterLink *link, AVFrame
> *frame)
> s->x = link->w - s->w;
> if ((unsigned)s->y + (unsigned)s->h > link->h)
> s->y = link->h - s->h;
> -s->x &= ~((1 << s->hsub) - 1);
> -s->y &= ~((1 << s->vsub) - 1);
> +if (!s->exact) {
> +s->x &= ~((1 << s->hsub) - 1);
> +s->y &= ~((1 << s->vsub) - 1);
> +}
>
> av_log(ctx, AV_LOG_TRACE, "n:%d t:%f pos:%f x:%d y:%d x+w:%d y+h:%d\n",
> (int)s->var_values[VAR_N], s->var_values[VAR_T],
> s->var_values[VAR_POS],
> @@ -344,6 +352,7 @@ static const AVOption crop_options[] = {
> { "x", "set
Re: [FFmpeg-devel] [PATCH] libavformat/mov: Accept known codepoints in 'colr'
Hey folks,
We anticipate professional video software will start producing files with
the expanded codepoints Real Soon Now, and ProRes already supports Rec.
2020 and ST 2084 (see SMPTE RDD 36), so presumably MOV will get some of
that soon too. (QuickTime in OS X El Cap already recognizes Rec. 2020 color
in MOV, even though TN 2162 hasn't been updated yet.) Also it'd be nice to
land this for the bugfix in SD. Anything I can do to help with the review?
Thanks!
Steve
On Wed, Aug 17, 2016 at 12:25 AM, Steven Robertson wrote:
> This change relaxes the whitelist on reading color metadata in MOV/BMFF
> containers. The whitelist on writing values is still in place.
>
> As a consequence it also fixes an apparent bug in reading 'nclc' values.
> The 'nclc' spec [1] is in harmony with ISO 23001-8 for the values it
> lists, but the code getting removed was remapping 5->6 and 6->7 for
> primaries, which is incorrect, and was remapping 6->5 for color matrix
> ("colorspace" in the code), which is equivalent but an unnecessary
> inconsistency. This logic error doesn't appear in movenc.
>
> Removing the whitelist allows proper conversion when the source codec
> relies on the container for proper signaling of newer codepoints, such
> as DNxHR and VP9. If converting to a codec or container that has updated
> its spec to include the new codepoints, the metadata will be preserved.
> If going back to MOV/BMFF, the output whitelist will still kick in, so
> this won't result in out-of-spec files being created.
>
> [1] https://developer.apple.com/library/mac/technotes/tn2162/_index.html
>
> Signed-off-by: Steven Robertson
> ---
> libavformat/mov.c | 40 +---
> 1 file changed, 9 insertions(+), 31 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 7c8f784..6450d52 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1324,38 +1324,16 @@ static int mov_read_colr(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
> st->codecpar->color_range = AVCOL_RANGE_JPEG;
> else
> st->codecpar->color_range = AVCOL_RANGE_MPEG;
> -/* 14496-12 references JPEG XR specs (rather than the more
> complete
> - * 23001-8) so some adjusting is required */
> -if (color_primaries >= AVCOL_PRI_FILM)
> -color_primaries = AVCOL_PRI_UNSPECIFIED;
> -if ((color_trc >= AVCOL_TRC_LINEAR &&
> - color_trc <= AVCOL_TRC_LOG_SQRT) ||
> -color_trc >= AVCOL_TRC_BT2020_10)
> -color_trc = AVCOL_TRC_UNSPECIFIED;
> -if (color_matrix >= AVCOL_SPC_BT2020_NCL)
> -color_matrix = AVCOL_SPC_UNSPECIFIED;
> -st->codecpar->color_primaries = color_primaries;
> -st->codecpar->color_trc = color_trc;
> -st->codecpar->color_space = color_matrix;
> -} else if (!strncmp(color_parameter_type, "nclc", 4)) {
> -/* color primaries, Table 4-4 */
> -switch (color_primaries) {
> -case 1: st->codecpar->color_primaries = AVCOL_PRI_BT709; break;
> -case 5: st->codecpar->color_primaries = AVCOL_PRI_SMPTE170M;
> break;
> -case 6: st->codecpar->color_primaries = AVCOL_PRI_SMPTE240M;
> break;
> -}
> -/* color transfer, Table 4-5 */
> -switch (color_trc) {
> -case 1: st->codecpar->color_trc = AVCOL_TRC_BT709; break;
> -case 7: st->codecpar->color_trc = AVCOL_TRC_SMPTE240M; break;
> -}
> -/* color matrix, Table 4-6 */
> -switch (color_matrix) {
> -case 1: st->codecpar->color_space = AVCOL_SPC_BT709; break;
> -case 6: st->codecpar->color_space = AVCOL_SPC_BT470BG; break;
> -case 7: st->codecpar->color_space = AVCOL_SPC_SMPTE240M; break;
> -}
> }
> +if (color_primaries >= AVCOL_PRI_NB)
> +color_primaries = AVCOL_PRI_UNSPECIFIED;
> +if (color_trc >= AVCOL_TRC_NB)
> +color_trc = AVCOL_TRC_UNSPECIFIED;
> +if (color_matrix >= AVCOL_SPC_NB)
> +color_matrix = AVCOL_SPC_UNSPECIFIED;
> +st->codecpar->color_primaries = color_primaries;
> +st->codecpar->color_trc = color_trc;
> +st->codecpar->color_space = color_matrix;
> av_log(c->fc, AV_LOG_TRACE, "\n");
>
> return 0;
> --
> 2.8.0.rc2
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/mov: Accept known codepoints in 'colr'
On Sat, Aug 20, 2016 at 04:15:20PM -0700, Steven Robertson wrote: > Hey folks, > > We anticipate professional video software will start producing files with > the expanded codepoints Real Soon Now, and ProRes already supports Rec. > 2020 and ST 2084 (see SMPTE RDD 36), so presumably MOV will get some of > that soon too. (QuickTime in OS X El Cap already recognizes Rec. 2020 color > in MOV, even though TN 2162 hasn't been updated yet.) Also it'd be nice to > land this for the bugfix in SD. > Anything I can do to help with the review? yes you can review someone elses patch see, https://patchwork.ffmpeg.org/project/ffmpeg/list/ if you see one with wrong status there, you can create an account and offer to help update the patches statuses if every patch submitter reviewed one patch for each patch submitted no one else would ever need to review a patch ;) you could look at anything else on trac/wiki and help improve it example: https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12 dates missing, not linked from frontpage of the wiki, ... its publically editable just needs creating an account ATM is just a bit busy time, not saying help would ever be unwelcome, but GSoC end with lots of reviews, its august people are on vacation, Outreachy needs admins & mentors, ive a heap of issues should look at and fix, ... Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add DNxHR 12-bit example.
On Tue, Aug 16, 2016 at 10:22:54PM -0700, Steven Robertson wrote: > Signed-off-by: Steven Robertson > --- > tests/fate/dnxhd.mak | 2 ++ > tests/ref/fate/dnxhr-12bit | 6 ++ > 2 files changed, 8 insertions(+) > create mode 100644 tests/ref/fate/dnxhr-12bit applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/mov: Accept known codepoints in 'colr'
On Wed, Aug 17, 2016 at 12:25:47AM -0700, Steven Robertson wrote:
> This change relaxes the whitelist on reading color metadata in MOV/BMFF
> containers. The whitelist on writing values is still in place.
>
> As a consequence it also fixes an apparent bug in reading 'nclc' values.
> The 'nclc' spec [1] is in harmony with ISO 23001-8 for the values it
> lists, but the code getting removed was remapping 5->6 and 6->7 for
> primaries, which is incorrect, and was remapping 6->5 for color matrix
> ("colorspace" in the code), which is equivalent but an unnecessary
> inconsistency. This logic error doesn't appear in movenc.
>
> Removing the whitelist allows proper conversion when the source codec
> relies on the container for proper signaling of newer codepoints, such
> as DNxHR and VP9. If converting to a codec or container that has updated
> its spec to include the new codepoints, the metadata will be preserved.
> If going back to MOV/BMFF, the output whitelist will still kick in, so
> this won't result in out-of-spec files being created.
>
> [1] https://developer.apple.com/library/mac/technotes/tn2162/_index.html
>
> Signed-off-by: Steven Robertson
> ---
> libavformat/mov.c | 40 +---
> 1 file changed, 9 insertions(+), 31 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/hlsenc: add append_list flag into hlsenc
Fix unused *duration*
remove the #EXT-X-ENDLIST and #EXT-X-TARGETDURATION tags,
keep intened with hls->duratin, hls->start_pos, hls->size.
When ffmpeg exit by exception, start a new ffmpeg will
cover the old segment list, add this flag can continue
append the new segments into old hls segment list
Signed-off-by: LiuQi
---
doc/muxers.texi | 4
libavformat/hlsenc.c | 62
2 files changed, 66 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 5873269..2e95c6f 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -495,6 +495,10 @@ Will produce the playlist, @file{out.m3u8}, and a
single segment file,
Segment files removed from the playlist are deleted after a period of time
equal to the duration of the segment plus the duration of the playlist.
+@item hls_flags append_list
+Append new segments into the end of old segment list,
+and remove the @code{#EXT-X-ENDLIST} from the old segment list.
+
@item hls_flags round_durations
Round the duration info in the playlist file segment info to integer
values, instead of using floating point.
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 9f076ba..e65f002 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -63,6 +63,7 @@ typedef enum HLSFlags {
HLS_DISCONT_START = (1 << 3),
HLS_OMIT_ENDLIST = (1 << 4),
HLS_SPLIT_BY_TIME = (1 << 5),
+HLS_APPEND_LIST = (1 << 6),
} HLSFlags;
typedef enum {
@@ -265,6 +266,14 @@ static int hls_encryption_start(AVFormatContext *s)
return 0;
}
+static int read_chomp_line(AVIOContext *s, char *buf, int maxlen)
+{
+int len = ff_get_line(s, buf, maxlen);
+while (len > 0 && av_isspace(buf[len - 1]))
+buf[--len] = '\0';
+return len;
+}
+
static int hls_mux_init(AVFormatContext *s)
{
HLSContext *hls = s->priv_data;
@@ -389,6 +398,54 @@ static int hls_append_segment(struct AVFormatContext
*s, HLSContext *hls, double
return 0;
}
+static int parse_playlist(AVFormatContext *s, const char *url)
+{
+HLSContext *hls = s->priv_data;
+AVIOContext *in;
+int ret = 0, is_segment = 0;
+int64_t new_start_pos;
+char line[1024];
+const char *ptr;
+
+if ((ret = ffio_open_whitelist(&in, url, AVIO_FLAG_READ,
+ &s->interrupt_callback, NULL,
+ s->protocol_whitelist,
s->protocol_blacklist)) < 0)
+return ret;
+
+read_chomp_line(in, line, sizeof(line));
+if (strcmp(line, "#EXTM3U")) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
+while (!avio_feof(in)) {
+read_chomp_line(in, line, sizeof(line));
+if (av_strstart(line, "#EXT-X-MEDIA-SEQUENCE:", &ptr)) {
+hls->sequence = atoi(ptr);
+} else if (av_strstart(line, "#EXTINF:", &ptr)) {
+is_segment = 1;
+hls->duration = atof(ptr);
+} else if (av_strstart(line, "#", NULL)) {
+continue;
+} else if (line[0]) {
+if (is_segment) {
+is_segment = 0;
+new_start_pos = avio_tell(hls->avf->pb);
+hls->size = new_start_pos - hls->start_pos;
+av_strlcpy(hls->avf->filename, line, sizeof(line));
+ret = hls_append_segment(s, hls, hls->duration,
hls->start_pos, hls->size);
+if (ret < 0)
+goto fail;
+hls->start_pos = new_start_pos;
+}
+}
+}
+
+fail:
+avio_close(in);
+return ret;
+}
+
static void hls_free_segments(HLSSegment *p)
{
HLSSegment *en;
@@ -752,6 +809,10 @@ static int hls_write_header(AVFormatContext *s)
if ((ret = hls_mux_init(s)) < 0)
goto fail;
+if (hls->flags & HLS_APPEND_LIST) {
+parse_playlist(s, s->filename);
+}
+
if ((ret = hls_start(s)) < 0)
goto fail;
@@ -927,6 +988,7 @@ static const AVOption options[] = {
{"discont_start", "start the playlist with a discontinuity tag", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX, E, "flags"},
{"omit_endlist", "Do not append an endlist when ending stream", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_OMIT_ENDLIST }, 0, UINT_MAX, E, "flags"},
{"split_by_time", "split the hls segment by time which user set by
hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
E, "flags"},
+{"append_list", "append the new segments into old hls segment list",
0, AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E, "flags"},
{"use_localtime", "set filename expansion with strftime at segment
creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
{"use_localtime_mkdir", "create last directory component in
strftime-generated filename", OFFSET(use_localtime_mkdir),
AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
{"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type),
AV_OPT_TYPE_INT, {.i64 =
