Re: [FFmpeg-devel] [PATCH] avformat/mpl2dec: skip BOM when probing
On Sat, 11 Feb 2017 11:56:07 +0100
Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/mpl2dec.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavformat/mpl2dec.c b/libavformat/mpl2dec.c
> index 59589d5..0e30cb0 100644
> --- a/libavformat/mpl2dec.c
> +++ b/libavformat/mpl2dec.c
> @@ -23,6 +23,8 @@
> * MPL2 subtitles format demuxer
> */
>
> +#include "libavutil/intreadwrite.h"
> +
> #include "avformat.h"
> #include "internal.h"
> #include "subtitles.h"
> @@ -39,6 +41,9 @@ static int mpl2_probe(AVProbeData *p)
> const unsigned char *ptr = p->buf;
> const unsigned char *ptr_end = ptr + p->buf_size;
>
> +if (AV_RB24(ptr) == 0xefbbbf)
> +ptr += 3;
> +
> for (i = 0; i < 2; i++) {
> if (sscanf(ptr, "[%"SCNd64"][%"SCNd64"]%c", &start, &end, &c) != 3 &&
> sscanf(ptr, "[%"SCNd64"][]%c", &start, &c) != 2)
> @@ -94,6 +99,9 @@ static int mpl2_read_header(AVFormatContext *s)
> if (!len)
> break;
>
> +if (AV_RB24(p) == 0xefbbbf)
> +p += 3;
> +
> line[strcspn(line, "\r\n")] = 0;
>
> if (!read_ts(&p, &pts_start, &duration)) {
What happened to the equivalent patch I sent almost a year ago? My
patch skipped it only in the probe function, because the subtitle line
reader skips BOM already.
It referenced the same trac ticket.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc: consider an error during decoder draining as EOF
There is no reason that draining couldn't return an error or two. But
some decoders don't handle this very well, and might always return an
error. This can lead to API users getting into an infinite loop and
burning CPU, because no progress is made and EOF is never returned.
In fact, ffmpeg.c contains a hack against such a case. It is removed
with this patch. This particular error case seems to have been fixed
since the hack was added, though.
This might lose frames if decoding returns errors during draining.
---
ffmpeg.c | 6 --
libavcodec/utils.c | 6 +++---
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 06570c0dd0..bd54e66f08 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2529,12 +2529,6 @@ static int process_input_packet(InputStream *ist, const
AVPacket *pkt, int no_eo
ist->file_index, ist->st->index, av_err2str(ret));
if (exit_on_error)
exit_program(1);
-// Decoding might not terminate if we're draining the decoder, and
-// the decoder keeps returning an error.
-// This should probably be considered a libavcodec issue.
-// Sample: fate-vsynth1-dnxhd-720p-hr-lb
-if (!pkt)
-eof_reached = 1;
break;
}
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index f4085bf7a7..0a72dd684d 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2807,12 +2807,12 @@ static int do_decode(AVCodecContext *avctx, AVPacket
*pkt)
if (ret == AVERROR(EAGAIN))
ret = pkt->size;
-if (ret < 0)
-return ret;
-
if (avctx->internal->draining && !got_frame)
avctx->internal->draining_done = 1;
+if (ret < 0)
+return ret;
+
if (ret >= pkt->size) {
av_packet_unref(avctx->internal->buffer_pkt);
} else {
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264, videotoolbox: handle streams with multiple/changing PPS
On Wed, 15 Feb 2017 05:33:38 + Aman Gupta wrote: > On Tue, Feb 14, 2017 at 5:14 PM Aman Gupta wrote: > > > From: Aman Gupta > > > > The videotoolbox hwaccel only receives SLICE and IDR_SLICE NALUs. This > > works fine most of the time, but some streams fail to decode because > > changes in PPS are not propagated to the VT decoder. > > > Perhaps SPS can change mid-stream, and should be passed into the VT decoder > as well? I'm not familiar enough with h264 to know. Yes, it can. In theory, it should work, because a SPS/PPS change (in a slice) will trigger a configuration change and reinit the hwaccel (so ff_videotoolbox_avcc_extradata_create() will be called and update with the new SPS). But there's some partial change-detection, which prevents reconfiguration changes if the sw decoder doesn't need them, so this is imperfect. (Also assumes slices can reference only 1 SPS and 1 PPS, which is probably true.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264, videotoolbox: handle streams with multiple/changing PPS
On Tue, Feb 14, 2017 at 5:14 PM Aman Gupta wrote:
> From: Aman Gupta
>
> The videotoolbox hwaccel only receives SLICE and IDR_SLICE NALUs. This
> works fine most of the time, but some streams fail to decode because
> changes in PPS are not propagated to the VT decoder.
Perhaps SPS can change mid-stream, and should be passed into the VT decoder
as well? I'm not familiar enough with h264 to know.
>
> The failures in this case are incredibly annoying, as VTDecodeFrame()
> still returns noErr. Simiarly the decoder callback is invoked with noErr,
> and a NULL imageBuffer. Even though all the VT apis indicate success, no
> frames are actually decoded.
>
> When running ffmpeg via lldb however, some internal VT errors and
> warnings show up all of a sudden. These suggest that the bitstream is
> failing some internal consistency checks.
>
> $ ffmpeg -y -loglevel error -threads 1 -hwaccel videotoolbox \
> -i http://tmm1.s3.amazonaws.com/h264.ts -map v -f null
> /dev/null
> ...
> [h264 @ 0x7fdadc00] hardware accelerator failed to decode picture
> Error while decoding stream #0:0: Unknown error occurred
> vt decoder cb: output image buffer is null
> ...
>
> $ lldb -- ffmpeg ...
> ...
> ffmpeg[49384:2009219] GVA error: AVC_RBSP::parseSliceHeader error
> ffmpeg[49384:2009219] GVA error: pushPicture parseSliceHeader
> vt decoder cb: output image buffer is null
> ffmpeg[49384:2009219] GVA warning: OutputQueueReadyCallback status =
> 1, buffer == 0x0
> [h264 @ 0x10300a200] hardware accelerator failed to decode picture:
> Unknown error occurred
> Error while decoding stream #0:0: Unknown error occurred
> ...
>
> After this patch, there are no more errors and the sample decodes as
> expected.
> ---
> libavcodec/h264dec.c | 7 +++
> libavcodec/videotoolbox.c | 8 +---
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 41c0964..af8b256 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -755,6 +755,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
> nal->size_bits);
> if (ret < 0 && (h->avctx->err_recognition & AV_EF_EXPLODE))
> goto end;
> +if (avctx->hwaccel && avctx->hwaccel->pix_fmt ==
> AV_PIX_FMT_VIDEOTOOLBOX) {
> +ret = avctx->hwaccel->decode_slice(avctx,
> + nal->raw_data,
> + nal->raw_size);
> +if (ret < 0)
> +goto end;
> +}
> break;
> case H264_NAL_AUD:
> case H264_NAL_END_SEQUENCE:
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 1288aa5..1b5dffd 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -138,8 +138,6 @@ int ff_videotoolbox_h264_start_frame(AVCodecContext
> *avctx,
> VTContext *vtctx = avctx->internal->hwaccel_priv_data;
> H264Context *h = avctx->priv_data;
>
> -vtctx->bitstream_size = 0;
> -
> if (h->is_avc == 1) {
> return videotoolbox_buffer_copy(vtctx, buffer, size);
> }
> @@ -373,8 +371,12 @@ static int videotoolbox_h264_end_frame(AVCodecContext
> *avctx)
> {
> H264Context *h = avctx->priv_data;
> AVFrame *frame = h->cur_pic_ptr->f;
> +VTContext *vtctx = avctx->internal->hwaccel_priv_data;
> +int ret;
>
> -return videotoolbox_common_end_frame(avctx, frame);
> +ret = videotoolbox_common_end_frame(avctx, frame);
> +vtctx->bitstream_size = 0;
> +return ret;
> }
>
> static int videotoolbox_mpeg_start_frame(AVCodecContext *avctx,
> --
> 2.10.1 (Apple Git-78)
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] (for discussion): nvenc: fix wrong aspect ratio for 720x576 and 720x480 resolution
On Tue, 14 Feb 2017 12:32:07 + Yogender Gupta wrote: > Hi Miroslav , Philip, > > We will look at this issue, and provide a fix for the same. Would be > great to send me and Sumit (also copied here) the command lines that > you tried and the observations to repro at our end. Here's the sample from Miroslav - I've stuck it on dropbox. https://www.dropbox.com/s/1bjyhdzcuv1y357/dvb_mpegts_720x576_sar_nvenc.ts?dl=0 Here is the ffprobe report and the command line: > >>> INPUT: Stream #0:0[0x401]: Video: mpeg2video (Main) > >>> ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 720x576 [SAR > >>> 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc > >>> > >>> OUTPUT: Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / > >>> 0x001B), yuv420p(progressive), 720x576 [SAR 16:11 DAR 20:11], 25 > >>> fps, 25 tbr, 90k tbn, 50 tbc > >>> > >>> COMMAND: ffmpeg -deint adaptive -hwaccel cuvid -c:v mpeg2_cuvid > >>> -i "in.ts" -y -c:v h264_nvenc -c:a copy -b:v 1M -preset hq -f > >>> mpegts "out.ts" and for completeness, Miroslav's analysis: > I am sure that i know what is going on, NVENC is inserting wrong SPS > VUI aspect_ratio_idc to h264 packets when you encode at resolution > 720x576 and 720x480 > > AR 16:9 will insert aspect_ratio_idc=4 but it should be > aspect_ratio_idc=255, sar_width=64, sar_height=45 for 720x576 AR 4:3 > will insert aspect_ratio_idc=2 but it should be aspect_ratio_idc=255, > sar_width=16, sar_height=15 for 720x576 > > MP4 and MKV containers contains correct AR metadata information which > all players should accept, but TS container has nothing like that so > it relies on what is inside h264 SPS. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] spherical: Add tiled equirectangular type and projection-specific properties
On Tue, Feb 14, 2017 at 6:54 PM, James Almer wrote: > On 2/14/2017 5:52 PM, Vittorio Giovara wrote: >> On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer >> wrote: >>> On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote: Signed-off-by: Vittorio Giovara --- This should help not losing details over muxing and allows callers to get additional information in a clean manner. Please keep me in CC. Vittorio doc/APIchanges| 5 + ffprobe.c | 11 -- libavformat/dump.c| 10 + libavutil/spherical.h | 56 +++ libavutil/version.h | 2 +- 5 files changed, 81 insertions(+), 3 deletions(-) >>> >>> breaks fate >>> >>> --- ./tests/ref/fate/matroska-spherical-mono2017-02-10 >>> 23:43:51.993432371 +0100 >>> +++ tests/data/fate/matroska-spherical-mono 2017-02-11 >>> 00:24:10.297483318 +0100 >>> @@ -7,7 +7,7 @@ >>> [/SIDE_DATA] >>> [SIDE_DATA] >>> side_data_type=Spherical Mapping >>> -side_data_size=16 >>> +side_data_size=56 >>> projection=equirectangular >>> yaw=45 >>> pitch=30 >>> Test matroska-spherical-mono failed. Look at >>> tests/data/fate/matroska-spherical-mono.err for details. >>> make: *** [fate-matroska-spherical-mono] Error 1 >> >> Ah I didn't notice, it is fixed in the next commit, but I'll amend this one >> too. >> >> >> I didn't see any comment/discussion, should I assume it is ok? >> Please CC, thank you. > > These are a lot of projection specific fields. It worries me as the > spec may change in the future with new fields added or existing > fields changing purpose. Not to mention the Mesh projection, which > has like fifty specific fields of its own. Even if the spec change (which at this point would be a terrible terrible thing to do) there are now files in the wild and software that have adopted this draft, so we would have to support this anyway. > Wouldn't it be a better idea to export the binary data of the > equi/cbmp/mesh boxes into an extradata-like field in the > AVSphericalMapping struct, and let the downstream application parse > it instead? No I don't think so, lavf is an abstraction layer and one of its tasks is to provide a (simple?) unified entry layer. and letting the user parse binary data is IMO bad design and very fragile. Also it's not impossible that another standard for tagging spherical metadata emerges in the future: the current API could very easily wrap it, while exporting the binary entry would be too specification-specific and it would be tied too heavily on the google draft. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVFMT_FLAG_NOBUFFER not working on ffmpeg2.8 branch
On Wed, Feb 15, 2017 at 08:24:24AM +0800, Shi Qiu wrote: > no, it's different in ffmpeg3 which commit fixed it ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/h264, videotoolbox: handle streams with multiple/changing PPS
From: Aman Gupta
The videotoolbox hwaccel only receives SLICE and IDR_SLICE NALUs. This
works fine most of the time, but some streams fail to decode because
changes in PPS are not propagated to the VT decoder.
The failures in this case are incredibly annoying, as VTDecodeFrame()
still returns noErr. Simiarly the decoder callback is invoked with noErr,
and a NULL imageBuffer. Even though all the VT apis indicate success, no
frames are actually decoded.
When running ffmpeg via lldb however, some internal VT errors and
warnings show up all of a sudden. These suggest that the bitstream is
failing some internal consistency checks.
$ ffmpeg -y -loglevel error -threads 1 -hwaccel videotoolbox \
-i http://tmm1.s3.amazonaws.com/h264.ts -map v -f null /dev/null
...
[h264 @ 0x7fdadc00] hardware accelerator failed to decode picture
Error while decoding stream #0:0: Unknown error occurred
vt decoder cb: output image buffer is null
...
$ lldb -- ffmpeg ...
...
ffmpeg[49384:2009219] GVA error: AVC_RBSP::parseSliceHeader error
ffmpeg[49384:2009219] GVA error: pushPicture parseSliceHeader
vt decoder cb: output image buffer is null
ffmpeg[49384:2009219] GVA warning: OutputQueueReadyCallback status = 1,
buffer == 0x0
[h264 @ 0x10300a200] hardware accelerator failed to decode picture: Unknown
error occurred
Error while decoding stream #0:0: Unknown error occurred
...
After this patch, there are no more errors and the sample decodes as
expected.
---
libavcodec/h264dec.c | 7 +++
libavcodec/videotoolbox.c | 8 +---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 41c0964..af8b256 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -755,6 +755,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
nal->size_bits);
if (ret < 0 && (h->avctx->err_recognition & AV_EF_EXPLODE))
goto end;
+if (avctx->hwaccel && avctx->hwaccel->pix_fmt ==
AV_PIX_FMT_VIDEOTOOLBOX) {
+ret = avctx->hwaccel->decode_slice(avctx,
+ nal->raw_data,
+ nal->raw_size);
+if (ret < 0)
+goto end;
+}
break;
case H264_NAL_AUD:
case H264_NAL_END_SEQUENCE:
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 1288aa5..1b5dffd 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -138,8 +138,6 @@ int ff_videotoolbox_h264_start_frame(AVCodecContext *avctx,
VTContext *vtctx = avctx->internal->hwaccel_priv_data;
H264Context *h = avctx->priv_data;
-vtctx->bitstream_size = 0;
-
if (h->is_avc == 1) {
return videotoolbox_buffer_copy(vtctx, buffer, size);
}
@@ -373,8 +371,12 @@ static int videotoolbox_h264_end_frame(AVCodecContext
*avctx)
{
H264Context *h = avctx->priv_data;
AVFrame *frame = h->cur_pic_ptr->f;
+VTContext *vtctx = avctx->internal->hwaccel_priv_data;
+int ret;
-return videotoolbox_common_end_frame(avctx, frame);
+ret = videotoolbox_common_end_frame(avctx, frame);
+vtctx->bitstream_size = 0;
+return ret;
}
static int videotoolbox_mpeg_start_frame(AVCodecContext *avctx,
--
2.10.1 (Apple Git-78)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVFMT_FLAG_NOBUFFER not working on ffmpeg2.8 branch
no, it's different in ffmpeg3 On Tue, Feb 14, 2017 at 9:21 PM, Michael Niedermayer wrote: > On Tue, Feb 14, 2017 at 12:03:56PM +0800, Shi Qiu wrote: > > libavformat/utils.c,line 3308: > > Is this issue reproduceable with git master ? > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > In a rich man's house there is no place to spit but his face. > -- Diogenes of Sinope > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: Add file_open.c, needed for avpriv_open() use also to libavfilter
Needed by peakpoints filter This is identical to how it is used in the other libs --- libavfilter/Makefile| 1 + libavfilter/file_open.c | 1 + tests/ref/fate/source | 1 + 3 files changed, 3 insertions(+) create mode 100644 libavfilter/file_open.c diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 695167c9f6..f18ca199e8 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -25,6 +25,7 @@ OBJS = allfilters.o \ transform.o \ video.o \ +OBJS-$(HAVE_LIBC_MSVCRT) += file_open.o OBJS-$(HAVE_THREADS) += pthread.o # audio filters diff --git a/libavfilter/file_open.c b/libavfilter/file_open.c new file mode 100644 index 00..494a5d37a4 --- /dev/null +++ b/libavfilter/file_open.c @@ -0,0 +1 @@ +#include "libavutil/file_open.c" diff --git a/tests/ref/fate/source b/tests/ref/fate/source index 67906d1198..2eef1ce6c1 100644 --- a/tests/ref/fate/source +++ b/tests/ref/fate/source @@ -7,6 +7,7 @@ libavcodec/interplayacm.c libavcodec/log2_tab.c libavcodec/reverse.c libavdevice/file_open.c +libavfilter/file_open.c libavfilter/log2_tab.c libavformat/file_open.c libavformat/golomb_tab.c -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] spherical: Add tiled equirectangular type and projection-specific properties
On 2/14/2017 5:52 PM, Vittorio Giovara wrote: > On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer > wrote: >> On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote: >>> Signed-off-by: Vittorio Giovara >>> --- >>> This should help not losing details over muxing and allows >>> callers to get additional information in a clean manner. >>> >>> Please keep me in CC. >>> Vittorio >>> >>> doc/APIchanges| 5 + >>> ffprobe.c | 11 -- >>> libavformat/dump.c| 10 + >>> libavutil/spherical.h | 56 >>> +++ >>> libavutil/version.h | 2 +- >>> 5 files changed, 81 insertions(+), 3 deletions(-) >> >> breaks fate >> >> --- ./tests/ref/fate/matroska-spherical-mono2017-02-10 >> 23:43:51.993432371 +0100 >> +++ tests/data/fate/matroska-spherical-mono 2017-02-11 >> 00:24:10.297483318 +0100 >> @@ -7,7 +7,7 @@ >> [/SIDE_DATA] >> [SIDE_DATA] >> side_data_type=Spherical Mapping >> -side_data_size=16 >> +side_data_size=56 >> projection=equirectangular >> yaw=45 >> pitch=30 >> Test matroska-spherical-mono failed. Look at >> tests/data/fate/matroska-spherical-mono.err for details. >> make: *** [fate-matroska-spherical-mono] Error 1 > > Ah I didn't notice, it is fixed in the next commit, but I'll amend this one > too. > > > I didn't see any comment/discussion, should I assume it is ok? > Please CC, thank you. These are a lot of projection specific fields. It worries me as the spec may change in the future with new fields added or existing fields changing purpose. Not to mention the Mesh projection, which has like fifty specific fields of its own. Wouldn't it be a better idea to export the binary data of the equi/cbmp/mesh boxes into an extradata-like field in the AVSphericalMapping struct, and let the downstream application parse it instead? That way you can skip adding the extra Equirectangular enum, and also add the Mesh one. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264: Correctly initialize interlaced_frame if tff is set
On Sat, Feb 11, 2017 at 02:56:32AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 10, 2017 at 05:21:00PM -0500, Vittorio Giovara wrote:
> > In particular cases, it is possible to initialize top_field_first
> > but not interlaced_frame. Make sure to correctly tag a frame
> > as interlaced when this happens.
> >
> > Signed-off-by: Vittorio Giovara
> > ---
> > Please CC.
> > Vittorio
> >
> > libavcodec/h264_slice.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > index 91a3b25..eeb5202 100644
> > --- a/libavcodec/h264_slice.c
> > +++ b/libavcodec/h264_slice.c
> > @@ -1174,20 +1174,23 @@ static int h264_export_frame_props(H264Context *h)
> >
> > if (cur->field_poc[0] != cur->field_poc[1]) {
> > /* Derive top_field_first from field pocs. */
> > -cur->f->top_field_first = cur->field_poc[0] < cur->field_poc[1];
> > +cur->f->interlaced_frame =
> > +cur->f->top_field_first = cur->field_poc[0] < cur->field_poc[1];
>
> this looks like it would set interlaced_frame = 0 if
> cur->field_poc[0] > cur->field_poc[1];
>
> also, do you have a sample that is affected by this ?
thx for the sample, ive pushed a different fix
does that fix this completely or is some issue remaining ?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] spherical: Add tiled equirectangular type and projection-specific properties
On Tue, Feb 14, 2017 at 4:54 PM, Michael Niedermayer wrote: > On Tue, Feb 14, 2017 at 03:52:39PM -0500, Vittorio Giovara wrote: >> On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer >> wrote: >> > On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote: >> >> Signed-off-by: Vittorio Giovara >> >> --- >> >> This should help not losing details over muxing and allows >> >> callers to get additional information in a clean manner. >> >> >> >> Please keep me in CC. >> >> Vittorio >> >> >> >> doc/APIchanges| 5 + >> >> ffprobe.c | 11 -- >> >> libavformat/dump.c| 10 + >> >> libavutil/spherical.h | 56 >> >> +++ >> >> libavutil/version.h | 2 +- >> >> 5 files changed, 81 insertions(+), 3 deletions(-) >> > >> > breaks fate >> > >> > --- ./tests/ref/fate/matroska-spherical-mono2017-02-10 >> > 23:43:51.993432371 +0100 >> > +++ tests/data/fate/matroska-spherical-mono 2017-02-11 >> > 00:24:10.297483318 +0100 >> > @@ -7,7 +7,7 @@ >> > [/SIDE_DATA] >> > [SIDE_DATA] >> > side_data_type=Spherical Mapping >> > -side_data_size=16 >> > +side_data_size=56 >> > projection=equirectangular >> > yaw=45 >> > pitch=30 >> > Test matroska-spherical-mono failed. Look at >> > tests/data/fate/matroska-spherical-mono.err for details. >> > make: *** [fate-matroska-spherical-mono] Error 1 >> >> Ah I didn't notice, it is fixed in the next commit, but I'll amend this one >> too. > > maybe iam missing some patch but > it still fails here with all 3 patches of the patchset: ops sorry you're right, i forgot to update the mkv test amended locally -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] spherical: Add tiled equirectangular type and projection-specific properties
On Tue, Feb 14, 2017 at 03:52:39PM -0500, Vittorio Giovara wrote: > On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer > wrote: > > On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote: > >> Signed-off-by: Vittorio Giovara > >> --- > >> This should help not losing details over muxing and allows > >> callers to get additional information in a clean manner. > >> > >> Please keep me in CC. > >> Vittorio > >> > >> doc/APIchanges| 5 + > >> ffprobe.c | 11 -- > >> libavformat/dump.c| 10 + > >> libavutil/spherical.h | 56 > >> +++ > >> libavutil/version.h | 2 +- > >> 5 files changed, 81 insertions(+), 3 deletions(-) > > > > breaks fate > > > > --- ./tests/ref/fate/matroska-spherical-mono2017-02-10 > > 23:43:51.993432371 +0100 > > +++ tests/data/fate/matroska-spherical-mono 2017-02-11 > > 00:24:10.297483318 +0100 > > @@ -7,7 +7,7 @@ > > [/SIDE_DATA] > > [SIDE_DATA] > > side_data_type=Spherical Mapping > > -side_data_size=16 > > +side_data_size=56 > > projection=equirectangular > > yaw=45 > > pitch=30 > > Test matroska-spherical-mono failed. Look at > > tests/data/fate/matroska-spherical-mono.err for details. > > make: *** [fate-matroska-spherical-mono] Error 1 > > Ah I didn't notice, it is fixed in the next commit, but I'll amend this one > too. maybe iam missing some patch but it still fails here with all 3 patches of the patchset: --- ./tests/ref/fate/matroska-spherical-mono2017-02-14 04:07:51.870553633 +0100 +++ tests/data/fate/matroska-spherical-mono 2017-02-14 22:52:40.901410068 +0100 @@ -7,8 +7,12 @@ [/SIDE_DATA] [SIDE_DATA] side_data_type=Spherical Mapping -side_data_size=16 -projection=equirectangular +side_data_size=56 +projection=tiled equirectangular +left_bound=148 +top_bound=73 +right_bound=147 +bottom_bound=72 yaw=45 pitch=30 roll=15 Test matroska-spherical-mono failed. Look at tests/data/fate/matroska-spherical-mono.err for details. make: *** [fate-matroska-spherical-mono] Error 1 [...] -- 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] avfilter: implement halve filter
On 14/02/17 19:44, Daniel Oberhoff wrote: > filter strictly “halves” the image efficiently, which is often exactly what > is needed > likely much faster than using scale Did you benchmark this? How? $ time ./ffmpeg -f lavfi -i allyuv -vf 'scale=iw/2:ih/2' -vframes 400 -f null - ... frame= 400 fps= 26 q=-0.0 Lsize=N/A time=00:00:16.00 bitrate=N/A speed=1.05x ... real0m15.365s user0m11.092s sys 0m4.272s $ time ./ffmpeg -f lavfi -i allyuv -vf 'halve' -vframes 400 -f null - ... frame= 400 fps= 22 q=-0.0 Lsize=N/A time=00:00:16.00 bitrate=N/A speed=0.873x ... real0m18.392s user0m46.280s sys 0m3.656s So it uses four times as much CPU as swscale to be marginally slower? (Skylake 6300; I admit the SMT could well be making it look a bit worse than it actually is on the CPU time.) On a more general note, components that duplicate existing functionality are unlikely to be accepted without a compelling use-case for them to be included. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] spherical: Add tiled equirectangular type and projection-specific properties
On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer wrote: > On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote: >> Signed-off-by: Vittorio Giovara >> --- >> This should help not losing details over muxing and allows >> callers to get additional information in a clean manner. >> >> Please keep me in CC. >> Vittorio >> >> doc/APIchanges| 5 + >> ffprobe.c | 11 -- >> libavformat/dump.c| 10 + >> libavutil/spherical.h | 56 >> +++ >> libavutil/version.h | 2 +- >> 5 files changed, 81 insertions(+), 3 deletions(-) > > breaks fate > > --- ./tests/ref/fate/matroska-spherical-mono2017-02-10 23:43:51.993432371 > +0100 > +++ tests/data/fate/matroska-spherical-mono 2017-02-11 00:24:10.297483318 > +0100 > @@ -7,7 +7,7 @@ > [/SIDE_DATA] > [SIDE_DATA] > side_data_type=Spherical Mapping > -side_data_size=16 > +side_data_size=56 > projection=equirectangular > yaw=45 > pitch=30 > Test matroska-spherical-mono failed. Look at > tests/data/fate/matroska-spherical-mono.err for details. > make: *** [fate-matroska-spherical-mono] Error 1 Ah I didn't notice, it is fixed in the next commit, but I'll amend this one too. I didn't see any comment/discussion, should I assume it is ok? Please CC, thank you. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: implement halve filter
On 2/14/17, Daniel Oberhoff wrote: > filter strictly "halves" the image efficiently, which is often exactly what > is needed > likely much faster than using scale > fully slice parallelized > > Signed-off-by: Daniel Oberhoff > --- > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_halve.c | 367 > +++ > 3 files changed, 369 insertions(+) > create mode 100644 libavfilter/vf_halve.c > I see big cargo cult here. No need to use framesync for 1-1 case. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: parallelize vf_remap
On 2/14/17, Daniel Oberhoff wrote: > Signed-off-by: Daniel Oberhoff > --- > libavfilter/vf_remap.c | 149 > - > 1 file changed, 97 insertions(+), 52 deletions(-) > Have you benchmarked this with bench filter? Is it actually faster? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: implement vf_remap_frac
On 2/14/17, Daniel Oberhoff wrote: > this is a fractional version of remap that interprets > the x/y maps as 13.3bit fixed point values, i.e > the three least significant bits are used for inter-pixel > interpolation by weighed averaging the four adjacent pixels > > Signed-off-by: Daniel Oberhoff > --- > libavfilter/Makefile| 1 + > libavfilter/allfilters.c| 1 + > libavfilter/vf_remap_frac.c | 491 > > 3 files changed, 493 insertions(+) > create mode 100644 libavfilter/vf_remap_frac.c > I do not like '_' in filter name. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: parallelize vf_remap
Signed-off-by: Daniel Oberhoff
---
libavfilter/vf_remap.c | 149 -
1 file changed, 97 insertions(+), 52 deletions(-)
diff --git a/libavfilter/vf_remap.c b/libavfilter/vf_remap.c
index e70956d..84b2466 100644
--- a/libavfilter/vf_remap.c
+++ b/libavfilter/vf_remap.c
@@ -44,6 +44,7 @@
#include "framesync.h"
#include "internal.h"
#include "video.h"
+#include "pthread.h"
typedef struct RemapContext {
const AVClass *class;
@@ -52,9 +53,8 @@ typedef struct RemapContext {
int step;
FFFrameSync fs;
-void (*remap)(struct RemapContext *s, const AVFrame *in,
- const AVFrame *xin, const AVFrame *yin,
- AVFrame *out);
+void (*remap_slice)(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs);
+
} RemapContext;
#define OFFSET(x) offsetof(RemapContext, x)
@@ -66,6 +66,13 @@ static const AVOption remap_options[] = {
AVFILTER_DEFINE_CLASS(remap);
+typedef struct ThreadData {
+AVFrame *in, *xin, *yin, *out;
+int nb_planes;
+int nb_components;
+int step;
+} ThreadData;
+
static int query_formats(AVFilterContext *ctx)
{
static const enum AVPixelFormat pix_fmts[] = {
@@ -113,28 +120,36 @@ fail:
return ret;
}
+
/**
* remap_planar algorithm expects planes of same size
* pixels are copied from source to target using :
* Target_frame[y][x] = Source_frame[ ymap[y][x] ][ [xmap[y][x] ];
*/
-static void remap_planar(RemapContext *s, const AVFrame *in,
- const AVFrame *xin, const AVFrame *yin,
- AVFrame *out)
+static void remap_planar_slice(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs)
{
+const ThreadData *td = (ThreadData*)arg;
+const AVFrame *in = td->in;
+const AVFrame *xin = td->xin;
+const AVFrame *yin = td->yin;
+const AVFrame *out = td->out;
+
+const int slice_start = (out->height * jobnr ) / nb_jobs;
+const int slice_end = (out->height * (jobnr+1)) / nb_jobs;
+
const int xlinesize = xin->linesize[0] / 2;
const int ylinesize = yin->linesize[0] / 2;
int x , y, plane;
-for (plane = 0; plane < s->nb_planes ; plane++) {
-uint8_t *dst = out->data[plane];
+for (plane = 0; plane < td->nb_planes ; plane++) {
const int dlinesize = out->linesize[plane];
const uint8_t *src = in->data[plane];
+uint8_t *dst = out->data[plane] + slice_start * dlinesize;
const int slinesize = in->linesize[plane];
-const uint16_t *xmap = (const uint16_t *)xin->data[0];
-const uint16_t *ymap = (const uint16_t *)yin->data[0];
+const uint16_t *xmap = (const uint16_t *)xin->data[0] + slice_start *
xlinesize;
+const uint16_t *ymap = (const uint16_t *)yin->data[0] + slice_start *
ylinesize;
-for (y = 0; y < out->height; y++) {
+for (y = slice_start; y < slice_end; y++) {
for (x = 0; x < out->width; x++) {
if (ymap[x] < in->height && xmap[x] < in->width) {
dst[x] = src[ymap[x] * slinesize + xmap[x]];
@@ -149,23 +164,30 @@ static void remap_planar(RemapContext *s, const AVFrame
*in,
}
}
-static void remap_planar16(RemapContext *s, const AVFrame *in,
- const AVFrame *xin, const AVFrame *yin,
- AVFrame *out)
+static void remap_planar16_slice(AVFilterContext *ctx, void *arg, int jobnr,
int nb_jobs)
{
+const ThreadData *td = (ThreadData*)arg;
+const AVFrame *in = td->in;
+const AVFrame *xin = td->xin;
+const AVFrame *yin = td->yin;
+const AVFrame *out = td->out;
+
+const int slice_start = (out->height * jobnr ) / nb_jobs;
+const int slice_end = (out->height * (jobnr+1)) / nb_jobs;
+
const int xlinesize = xin->linesize[0] / 2;
const int ylinesize = yin->linesize[0] / 2;
int x , y, plane;
-for (plane = 0; plane < s->nb_planes ; plane++) {
-uint16_t *dst= (uint16_t *)out->data[plane];
+for (plane = 0; plane < td->nb_planes ; plane++) {
const int dlinesize = out->linesize[plane] / 2;
const uint16_t *src = (const uint16_t *)in->data[plane];
+ uint16_t *dst= (uint16_t *)out->data[plane] + slice_start *
dlinesize;
const int slinesize = in->linesize[plane] / 2;
-const uint16_t *xmap = (const uint16_t *)xin->data[0];
-const uint16_t *ymap = (const uint16_t *)yin->data[0];
+const uint16_t *xmap = (const uint16_t *)xin->data[0] + slice_start *
xlinesize;
+const uint16_t *ymap = (const uint16_t *)yin->data[0] + slice_start *
ylinesize;
-for (y = 0; y < out->height; y++) {
+for (y = slice_start; y < slice_end; y++) {
for (x = 0; x < out->width; x++) {
if (ymap[x] < in->height && xmap[x] < in->width) {
dst[x] = src[ymap[x] * slinesize + xmap[x]];
@@ -186,2
[FFmpeg-devel] [PATCH] avfilter: implement vf_remap_frac
this is a fractional version of remap that interprets
the x/y maps as 13.3bit fixed point values, i.e
the three least significant bits are used for inter-pixel
interpolation by weighed averaging the four adjacent pixels
Signed-off-by: Daniel Oberhoff
---
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_remap_frac.c | 491
3 files changed, 493 insertions(+)
create mode 100644 libavfilter/vf_remap_frac.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a986322..504e66a 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -250,6 +250,7 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
OBJS-$(CONFIG_READVITC_FILTER) += vf_readvitc.o
OBJS-$(CONFIG_REALTIME_FILTER) += f_realtime.o
OBJS-$(CONFIG_REMAP_FILTER) += vf_remap.o framesync.o
+OBJS-$(CONFIG_REMAP_FRAC_FILTER) += vf_remap_frac.o framesync.o
OBJS-$(CONFIG_HALVE_FILTER) += vf_halve.o framesync.o
OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o lavfutils.o
vf_removelogo.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 0b9b69c..0edd816 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -265,6 +265,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(READVITC, readvitc, vf);
REGISTER_FILTER(REALTIME, realtime, vf);
REGISTER_FILTER(REMAP, remap, vf);
+REGISTER_FILTER(REMAP_FRAC, remap_frac, vf);
REGISTER_FILTER(HALVE, halve, vf);
REGISTER_FILTER(REMOVEGRAIN,removegrain,vf);
REGISTER_FILTER(REMOVELOGO, removelogo, vf);
diff --git a/libavfilter/vf_remap_frac.c b/libavfilter/vf_remap_frac.c
new file mode 100644
index 000..f0e33d4
--- /dev/null
+++ b/libavfilter/vf_remap_frac.c
@@ -0,0 +1,491 @@
+/*
+ * Copyright (c) 2016 Floris Sluiter
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Pixel remap_frac filter
+ * This is a fractional version of the remap filter. The x and y maps
+ * are interpreted as 13.3 fixed point values, i.e. the 3 least significant
+ * bits are used for inter-pixel-interpolation by weighed averaging the four
+ * adjacaent pixels.
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "framesync.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct RemapFracContext {
+const AVClass *class;
+int nb_planes;
+int nb_components;
+int step;
+FFFrameSync fs;
+
+void (*remap_frac_slice)(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs);
+} RemapFracContext;
+
+#define OFFSET(x) offsetof(RemapFracContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption remap_frac_options[] = {
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(remap_frac);
+
+typedef struct ThreadData {
+AVFrame *in, *xin, *yin, *out;
+int nb_planes;
+int nb_components;
+int step;
+} ThreadData;
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_YUVA444P,
+AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_YUVJ444P,
+AV_PIX_FMT_RGB24, AV_PIX_FMT_BGR24,
+AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR, AV_PIX_FMT_RGBA, AV_PIX_FMT_BGRA,
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
+AV_PIX_FMT_YUV444P9, AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV444P12,
+AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_YUVA444P9, AV_PIX_FMT_YUVA444P10, AV_PIX_FMT_YUVA444P16,
+AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12,
+AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRP16,
+AV_PIX_FMT_GBRAP10, AV_PIX_FMT_GBRAP12, AV_PIX_FMT_GBRAP16,
+AV_PIX_FMT_RGB48, AV_PIX_FMT_BGR48,
+AV_PIX_FMT_RGBA64, AV_PIX_FMT_BGRA64,
+AV_PIX_FMT_NONE
+};
+static const enum AVPixelFormat map_fmts[] = {
+AV_PIX_FMT_GRAY16,
+AV_PIX_FMT_NONE
+};
+AVFilterFormats *pix_formats = NULL, *ma
[FFmpeg-devel] [PATCH] avfilter: implement halve filter
filter strictly “halves” the image efficiently, which is often exactly what is
needed
likely much faster than using scale
fully slice parallelized
Signed-off-by: Daniel Oberhoff
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_halve.c | 367 +++
3 files changed, 369 insertions(+)
create mode 100644 libavfilter/vf_halve.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 9ab65eb..a986322 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -250,6 +250,7 @@ OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
OBJS-$(CONFIG_READVITC_FILTER) += vf_readvitc.o
OBJS-$(CONFIG_REALTIME_FILTER) += f_realtime.o
OBJS-$(CONFIG_REMAP_FILTER) += vf_remap.o framesync.o
+OBJS-$(CONFIG_HALVE_FILTER) += vf_halve.o framesync.o
OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
OBJS-$(CONFIG_REMOVELOGO_FILTER) += bbox.o lswsutils.o lavfutils.o
vf_removelogo.o
OBJS-$(CONFIG_REPEATFIELDS_FILTER) += vf_repeatfields.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 2c37818..0b9b69c 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -265,6 +265,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(READVITC, readvitc, vf);
REGISTER_FILTER(REALTIME, realtime, vf);
REGISTER_FILTER(REMAP, remap, vf);
+REGISTER_FILTER(HALVE, halve, vf);
REGISTER_FILTER(REMOVEGRAIN,removegrain,vf);
REGISTER_FILTER(REMOVELOGO, removelogo, vf);
REGISTER_FILTER(REPEATFIELDS, repeatfields, vf);
diff --git a/libavfilter/vf_halve.c b/libavfilter/vf_halve.c
new file mode 100644
index 000..dd77eb8
--- /dev/null
+++ b/libavfilter/vf_halve.c
@@ -0,0 +1,367 @@
+/*
+ * Copyright (c) 2016 Floris Sluiter
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Pixel halve filter
+ * This filter makes the target image exactly halve in size in x and y
+ * dimension of the source image by summing the corresponding four source
+ * pixels.
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "framesync.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct HalveContext {
+const AVClass *class;
+int nb_planes;
+int nb_components;
+int step;
+FFFrameSync fs;
+void (*halve_slice)(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs);
+} HalveContext;
+
+#define OFFSET(x) offsetof(HalveContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption halve_options[] = {
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(halve);
+
+typedef struct ThreadData {
+AVFrame *in, *out;
+int nb_planes;
+int nb_components;
+int step;
+} ThreadData;
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_YUVA444P,
+AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_YUVJ444P,
+AV_PIX_FMT_RGB24, AV_PIX_FMT_BGR24,
+AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR, AV_PIX_FMT_RGBA, AV_PIX_FMT_BGRA,
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
+AV_PIX_FMT_YUV444P9, AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV444P12,
+AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_YUVA444P9, AV_PIX_FMT_YUVA444P10, AV_PIX_FMT_YUVA444P16,
+AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12,
+AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRP16,
+AV_PIX_FMT_GBRAP10, AV_PIX_FMT_GBRAP12, AV_PIX_FMT_GBRAP16,
+AV_PIX_FMT_RGB48, AV_PIX_FMT_BGR48,
+AV_PIX_FMT_RGBA64, AV_PIX_FMT_BGRA64,
+AV_PIX_FMT_NONE
+};
+AVFilterFormats *pix_formats = NULL;
+int ret;
+
+if (!(pix_formats = ff_make_format_list(pix_fmts))) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+if ((ret = ff_formats_ref(pix_formats, &ctx->inputs[0]->out_formats)) < 0
||
+(ret = ff_formats_ref(pix_formats, &ctx->outputs[0]->in_formats)) < 0)
+goto fail;
+return 0;
+fail:
+if (pix_formats
Re: [FFmpeg-devel] [PATCH 0/9] Merge lazy filter initialization in ffmpeg CLI
On Tue, Feb 14, 2017 at 06:11:22PM +0100, Michael Niedermayer wrote: > On Mon, Feb 13, 2017 at 12:57:30PM +0100, Michael Niedermayer wrote: > > On Mon, Feb 13, 2017 at 10:31:19AM +0100, wm4 wrote: > > > On Fri, 10 Feb 2017 15:25:13 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Fri, Feb 10, 2017 at 03:22:28PM +0100, Michael Niedermayer wrote: > > > > > On Fri, Feb 10, 2017 at 03:15:29PM +0100, Michael Niedermayer wrote: > > > > > > On Fri, Feb 10, 2017 at 01:35:32PM +0100, wm4 wrote: > > > > > > > These patches merge the previously skipped Libav commits, which > > > > > > > made > > > > > > > avconv lazily initialize libavfilter graphs. This means the > > > > > > > filters > > > > > > > are initialized with the actual output format, instead of whatever > > > > > > > libavformat reports. > > > > > > > > > > > > > > It's a prerequisite to making hardware decoding support saner, as > > > > > > > hardware decoders will output a different pixfmt than the software > > > > > > > format reported by libavformat. This can be seen on ffmpeg_qsv.c, > > > > > > > which doesn't lose any functionality, even though half of the code > > > > > > > is removed. > > > > > > > > > > > > > > There are some differences in how ffmpeg.c and avconv.c > > > > > > > filter-flow > > > > > > > works. Also, avconv.c doesn't have sub2video. Relatively intrusive > > > > > > > changes were required. > > > > > > > > > > > > > > The status of cuvid is unknown, but work in progress. > > > > > > > > > > > > > > Anton Khirnov (4): > > > > > > > ffmpeg: do packet ts rescaling in write_packet() > > > > > > > ffmpeg: init filtergraphs only after we have a frame on each > > > > > > > input > > > > > > > ffmpeg: move flushing the queued frames to > > > > > > > configure_filtergraph() > > > > > > > ffmpeg: restructure sending EOF to filters > > > > > > > > > > > > > > Timo Rothenpieler (3): > > > > > > > ffmpeg_cuvid: adapt for recent filter graph initialization > > > > > > > changes > > > > > > > avcodec/cuvid: add format mismatch debug logs > > > > > > > avcodec/cuvid: update hw_frames_ctx reference after get_format > > > > > > > call > > > > > > > > > > > > > > wm4 (2): > > > > > > > ffmpeg: make sure packets put into the muxing FIFO are > > > > > > > refcounted > > > > > > > ffmpeg: fix printing of filter input/output names > > > > > > > > > > > > This patchset breaks > > > > > > ./ffmpeg -i Voting_Machine.wmv test.avi > > > > > > > > > > > > http://data.onas.ru/fun-clips/Voting_Machine.wmv > > > > > > > > > > > > didnt bisect which patch causes it > > > > > > > > > > heres another example: > > > > > > > > > > ./ffmpeg -i ~/tickets/4329/bogus_video.mp4 -vframes 5 -vf > > > > > crop=720:404 out.mov > > > > > ./ffplay out.mov > > > > > before this patchset out.mov had an audio stream > > > > > > > > sample seems to be here: > > > > http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4329/ > > > > > > > > [...] > > > > > > > > > > > > > > Most of these should be fixed, new patches: > > > https://github.com/wm4/FFmpeg/commits/filter-merge > > > > already reported on IRC: > > this breaks: > > ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -vf scale=80x60 small.mpg && > > ./ffmpeg -i small.mpg -vframes 3 -metadata compilation="1" blah.m4a > > > > > > Also please repost the patchset or changed patches to the ML > > I think this needs more testing, its a large patchset > > a new one > > ./ffmpeg -i tickets//3080/flossless_cut.avi -f null - > (with 2c7a77304a7c4f8f7670866db319613771fcde13) > > seems to never exit on its own heres another failure: i found 3 files failing this way, sadly 1 is marked as private and one i cant figure out were i got it from so its possibly private too the 3rd is public but a fuzzed file, the other 2 are a undamaged file and one which has actual real world (unintended) damage ./ffmpeg -i tickets//4931/ffv1_fuzz1.avi out.avi this fails were previously there was some output [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/9] Merge lazy filter initialization in ffmpeg CLI
On Mon, Feb 13, 2017 at 12:57:30PM +0100, Michael Niedermayer wrote: > On Mon, Feb 13, 2017 at 10:31:19AM +0100, wm4 wrote: > > On Fri, 10 Feb 2017 15:25:13 +0100 > > Michael Niedermayer wrote: > > > > > On Fri, Feb 10, 2017 at 03:22:28PM +0100, Michael Niedermayer wrote: > > > > On Fri, Feb 10, 2017 at 03:15:29PM +0100, Michael Niedermayer wrote: > > > > > On Fri, Feb 10, 2017 at 01:35:32PM +0100, wm4 wrote: > > > > > > These patches merge the previously skipped Libav commits, which made > > > > > > avconv lazily initialize libavfilter graphs. This means the filters > > > > > > are initialized with the actual output format, instead of whatever > > > > > > libavformat reports. > > > > > > > > > > > > It's a prerequisite to making hardware decoding support saner, as > > > > > > hardware decoders will output a different pixfmt than the software > > > > > > format reported by libavformat. This can be seen on ffmpeg_qsv.c, > > > > > > which doesn't lose any functionality, even though half of the code > > > > > > is removed. > > > > > > > > > > > > There are some differences in how ffmpeg.c and avconv.c filter-flow > > > > > > works. Also, avconv.c doesn't have sub2video. Relatively intrusive > > > > > > changes were required. > > > > > > > > > > > > The status of cuvid is unknown, but work in progress. > > > > > > > > > > > > Anton Khirnov (4): > > > > > > ffmpeg: do packet ts rescaling in write_packet() > > > > > > ffmpeg: init filtergraphs only after we have a frame on each input > > > > > > ffmpeg: move flushing the queued frames to configure_filtergraph() > > > > > > ffmpeg: restructure sending EOF to filters > > > > > > > > > > > > Timo Rothenpieler (3): > > > > > > ffmpeg_cuvid: adapt for recent filter graph initialization changes > > > > > > avcodec/cuvid: add format mismatch debug logs > > > > > > avcodec/cuvid: update hw_frames_ctx reference after get_format > > > > > > call > > > > > > > > > > > > wm4 (2): > > > > > > ffmpeg: make sure packets put into the muxing FIFO are refcounted > > > > > > ffmpeg: fix printing of filter input/output names > > > > > > > > > > This patchset breaks > > > > > ./ffmpeg -i Voting_Machine.wmv test.avi > > > > > > > > > > http://data.onas.ru/fun-clips/Voting_Machine.wmv > > > > > > > > > > didnt bisect which patch causes it > > > > > > > > heres another example: > > > > > > > > ./ffmpeg -i ~/tickets/4329/bogus_video.mp4 -vframes 5 -vf crop=720:404 > > > > out.mov > > > > ./ffplay out.mov > > > > before this patchset out.mov had an audio stream > > > > > > sample seems to be here: > > > http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4329/ > > > > > > [...] > > > > > > > > > > Most of these should be fixed, new patches: > > https://github.com/wm4/FFmpeg/commits/filter-merge > > already reported on IRC: > this breaks: > ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -vf scale=80x60 small.mpg && > ./ffmpeg -i small.mpg -vframes 3 -metadata compilation="1" blah.m4a > > > Also please repost the patchset or changed patches to the ML > I think this needs more testing, its a large patchset a new one ./ffmpeg -i tickets//3080/flossless_cut.avi -f null - (with 2c7a77304a7c4f8f7670866db319613771fcde13) seems to never exit on its own [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf: fix AVStream private fields marker
On Tue, 14 Feb 2017 13:50:16 -0300
James Almer wrote:
> On 2/13/2017 7:51 AM, wm4 wrote:
> > Public fields were added after the private fields (negating the entire
> > point of this). New private fields go into AVStreamInternal anyway.
> >
> > The new marker was set by guessing which fields are supposed to be
> > private and wshich not. recommended_encoder_configuration is accessed by
> > ffserver_config.c directly, and is supposed to use the public API.
> >
> > ffmpeg.c accesses AVStream.cur_dts, even though it's a private field,
> > but that seems to be an older error.
> > ---
> > libavformat/avformat.h | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> > index 64180bca9e..4c1b18e002 100644
> > --- a/libavformat/avformat.h
> > +++ b/libavformat/avformat.h
> > @@ -1005,7 +1005,9 @@ typedef struct AVStream {
> > * All fields below this line are not part of the public API. They
> > * may not be used outside of libavformat and can be changed and
> > * removed at will.
> > - * New public fields should be added right above.
> > + * Internal note: be aware that physically removing these fields
> > + * will break ABI. Replace removed fields with dummy fields, and
> > + * add new fields to AVStreamInternal.
> > *
> > */
> >
> > @@ -1201,6 +1203,12 @@ typedef struct AVStream {
> > */
> > int inject_global_side_data;
> >
> > +/*
> > + * All fields above this line are not part of the public API.
> > + * Fields below are part of the public API and ABI again.
> > + *
> > + */
> > +
> > /**
> > * String containing paris of key and values describing recommended
> > encoder configuration.
> > * Paris are separated by ','.
> >
>
> This is incredibly confusing. Wouldn't it be a better idea to just wait
> until the next major bump and reorder the fields as needed?
>
> And for that matter, all the private fields are supposed to be moved to
> AVStreamInternal as well at the next bump.
The only way to fix this is a major bump. Until then, we shouldn't
document public fields like codecpar as private, because that's even
more confusing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf: fix AVStream private fields marker
On 2/13/2017 7:51 AM, wm4 wrote:
> Public fields were added after the private fields (negating the entire
> point of this). New private fields go into AVStreamInternal anyway.
>
> The new marker was set by guessing which fields are supposed to be
> private and wshich not. recommended_encoder_configuration is accessed by
> ffserver_config.c directly, and is supposed to use the public API.
>
> ffmpeg.c accesses AVStream.cur_dts, even though it's a private field,
> but that seems to be an older error.
> ---
> libavformat/avformat.h | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 64180bca9e..4c1b18e002 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1005,7 +1005,9 @@ typedef struct AVStream {
> * All fields below this line are not part of the public API. They
> * may not be used outside of libavformat and can be changed and
> * removed at will.
> - * New public fields should be added right above.
> + * Internal note: be aware that physically removing these fields
> + * will break ABI. Replace removed fields with dummy fields, and
> + * add new fields to AVStreamInternal.
> *
> */
>
> @@ -1201,6 +1203,12 @@ typedef struct AVStream {
> */
> int inject_global_side_data;
>
> +/*
> + * All fields above this line are not part of the public API.
> + * Fields below are part of the public API and ABI again.
> + *
> + */
> +
> /**
> * String containing paris of key and values describing recommended
> encoder configuration.
> * Paris are separated by ','.
>
This is incredibly confusing. Wouldn't it be a better idea to just wait
until the next major bump and reorder the fields as needed?
And for that matter, all the private fields are supposed to be moved to
AVStreamInternal as well at the next bump.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] HTTP: improve performance by reducing forward seeks
Great thanks! Joel > On Feb 14, 2017, at 9:59 AM, Michael Niedermayer > wrote: > > On Mon, Feb 13, 2017 at 09:57:13AM -0600, Joel Cunningham wrote: >> Friendly ping! Any issues receiving this updated patch (submitted with git >> send-email)? Anyone try it out yet? > > looks reasonable > will apply > > thanks > > [...] > -- > 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. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] x86util: import MOVHL macro
On Mon, Feb 13, 2017 at 1:44 PM, James Darnley wrote: > Originally committed to x264 in 1637239a by Henrik Gramner who has > agreed to re-license it as LGPL. Original commit message follows. > > x86: Avoid some bypass delays and false dependencies > > A bypass delay of 1-3 clock cycles may occur on some CPUs when > transitioning > between int and float domains, so try to avoid that if possible. Not sure if I see the point in copying the original commit message in this case, but the patch itself is OK. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] HTTP: improve performance by reducing forward seeks
On Mon, Feb 13, 2017 at 09:57:13AM -0600, Joel Cunningham wrote: > Friendly ping! Any issues receiving this updated patch (submitted with git > send-email)? Anyone try it out yet? looks reasonable will apply thanks [...] -- 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] new videofilters and parellelization
Ok, will try to get round to that today, otherwise it will be two weeks as I am traveling. > On 9 Feb 2017, at 17:15, Thilo Borgmann wrote: > > Am 09.02.17 um 16:01 schrieb Daniel Oberhoff: >> [...] >> we would like to contribute this back to ffmpeg as it may be useful >> for others. do you think so to? if so, should we send one big patch >> or split it up somehow? > > Yes. Try to conform to our developer documentation at > http://ffmpeg.org/developer.html and send separate patches for each logical > change you've made to ffmpeg. > > -Thilo > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Only use temporary files when outputting to file protocol
On Tue, Feb 14, 2017 at 10:18:02PM +0800, Steven Liu wrote:
> 2017-02-14 21:14 GMT+08:00 Thomas Stephens :
>
> > Has anybody had a chance to look at this patch?
> >
> > Thanks,
> > --Thomas
> >
> > On Tue, Feb 7, 2017, 2:20 PM Thomas Stephens wrote:
> >
> > > Skips using temporary files when outputting to a protocol other than
> > > "file", which enables dash to output content over network
> > > protocols. The logic has been copied from the HLS format.
> > > ---
> > > libavformat/dashenc.c | 29 +++--
> > > 1 file changed, 23 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> > > index 534fa75..fa56505 100644
> > > --- a/libavformat/dashenc.c
> > > +++ b/libavformat/dashenc.c
> > > @@ -444,9 +444,15 @@ static int write_manifest(AVFormatContext *s, int
> > > final)
> > > AVIOContext *out;
> > > char temp_filename[1024];
> > > int ret, i;
> > > +const char *proto = avio_find_protocol_name(s->filename);
> > > +int use_rename = proto && !strcmp(proto, "file");
> > > +static unsigned int warned_non_file = 0;
> > > AVDictionaryEntry *title = av_dict_get(s->metadata, "title", NULL,
> > 0);
> > >
> > > -snprintf(temp_filename, sizeof(temp_filename), "%s.tmp",
> > s->filename);
> > > +if (!use_rename && !warned_non_file++)
> > > +av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol,
> > > this may lead to races and temporary partial files\n");
> > > +
> > > +snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp"
> > > : "%s", s->filename);
> > > ret = s->io_open(s, &out, temp_filename, AVIO_FLAG_WRITE, NULL);
> > > if (ret < 0) {
> > > av_log(s, AV_LOG_ERROR, "Unable to open %s for writing\n",
> > > temp_filename);
> > > @@ -548,7 +554,11 @@ static int write_manifest(AVFormatContext *s, int
> > > final)
> > > avio_printf(out, "\n");
> > > avio_flush(out);
> > > ff_format_io_close(s, &out);
> > > -return avpriv_io_move(temp_filename, s->filename);
> > > +
> > > +if (use_rename)
> > > +return avpriv_io_move(temp_filename, s->filename);
> > > +
> > > +return 0;
> > > }
> > >
> > > static int dash_init(AVFormatContext *s)
> > > @@ -796,6 +806,10 @@ static int dash_flush(AVFormatContext *s, int final,
> > > int stream)
> > > {
> > > DASHContext *c = s->priv_data;
> > > int i, ret = 0;
> > > +
> > > +const char *proto = avio_find_protocol_name(s->filename);
> > > +int use_rename = proto && !strcmp(proto, "file");
> > > +
> > > int cur_flush_segment_index = 0;
> > > if (stream >= 0)
> > > cur_flush_segment_index = c->streams[stream].segment_index;
> > > @@ -833,7 +847,7 @@ static int dash_flush(AVFormatContext *s, int final,
> > > int stream)
> > > if (!c->single_file) {
> > > dash_fill_tmpl_params(filename, sizeof(filename),
> > > c->media_seg_name, i, os->segment_index, os->bit_rate, os->start_pts);
> > > snprintf(full_path, sizeof(full_path), "%s%s", c->dirname,
> > > filename);
> > > -snprintf(temp_path, sizeof(temp_path), "%s.tmp", full_path);
> > > +snprintf(temp_path, sizeof(temp_path), use_rename ? "%s.tmp"
> > > : "%s", full_path);
> > > ret = s->io_open(s, &os->out, temp_path, AVIO_FLAG_WRITE,
> > > NULL);
> > > if (ret < 0)
> > > break;
> > > @@ -851,9 +865,12 @@ static int dash_flush(AVFormatContext *s, int final,
> > > int stream)
> > > find_index_range(s, full_path, start_pos, &index_length);
> > > } else {
> > > ff_format_io_close(s, &os->out);
> > > -ret = avpriv_io_move(temp_path, full_path);
> > > -if (ret < 0)
> > > -break;
> > > +
> > > +if (use_rename) {
> > > +ret = avpriv_io_move(temp_path, full_path);
> > > +if (ret < 0)
> > > +break;
> > > +}
> > > }
> > > add_segment(os, filename, os->start_pts, os->max_pts -
> > > os->start_pts, start_pos, range_length, index_length);
> > > av_log(s, AV_LOG_VERBOSE, "Representation %d media segment %d
> > > written to: %s\n", i, os->segment_index, full_path);
> > > --
> > > 2.5.0
> > >
> > >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
>
> LGTM
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mail
Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
Hi Rune, On Tue, Feb 14, 2017 at 6:14 AM, wrote: > The huge difference in the amount of the data to be processed; in other > words the very essence of the vector quantization technology where frame > data is represented by a codebook, by design meant to be much smaller. We acknowledge that. We understand this. Nobody disputes this. But we still don't think breaking the modularization is the right way forward. I'm sorry. We're thinking about this in terms of maintainability as well as speed. The problem is that once we allow this, people will ask for 16bit output in h264 for all native bitdepths, or even packed formats (Kieran already asked). We know it's faster. We also know it's unreasonable from a maintenance perspective. We have to draw a line somewhere. It's an imperfect line but there's a reason for it. I'm sorry. That's life. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Only use temporary files when outputting to file protocol
2017-02-14 21:14 GMT+08:00 Thomas Stephens :
> Has anybody had a chance to look at this patch?
>
> Thanks,
> --Thomas
>
> On Tue, Feb 7, 2017, 2:20 PM Thomas Stephens wrote:
>
> > Skips using temporary files when outputting to a protocol other than
> > "file", which enables dash to output content over network
> > protocols. The logic has been copied from the HLS format.
> > ---
> > libavformat/dashenc.c | 29 +++--
> > 1 file changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> > index 534fa75..fa56505 100644
> > --- a/libavformat/dashenc.c
> > +++ b/libavformat/dashenc.c
> > @@ -444,9 +444,15 @@ static int write_manifest(AVFormatContext *s, int
> > final)
> > AVIOContext *out;
> > char temp_filename[1024];
> > int ret, i;
> > +const char *proto = avio_find_protocol_name(s->filename);
> > +int use_rename = proto && !strcmp(proto, "file");
> > +static unsigned int warned_non_file = 0;
> > AVDictionaryEntry *title = av_dict_get(s->metadata, "title", NULL,
> 0);
> >
> > -snprintf(temp_filename, sizeof(temp_filename), "%s.tmp",
> s->filename);
> > +if (!use_rename && !warned_non_file++)
> > +av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol,
> > this may lead to races and temporary partial files\n");
> > +
> > +snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp"
> > : "%s", s->filename);
> > ret = s->io_open(s, &out, temp_filename, AVIO_FLAG_WRITE, NULL);
> > if (ret < 0) {
> > av_log(s, AV_LOG_ERROR, "Unable to open %s for writing\n",
> > temp_filename);
> > @@ -548,7 +554,11 @@ static int write_manifest(AVFormatContext *s, int
> > final)
> > avio_printf(out, "\n");
> > avio_flush(out);
> > ff_format_io_close(s, &out);
> > -return avpriv_io_move(temp_filename, s->filename);
> > +
> > +if (use_rename)
> > +return avpriv_io_move(temp_filename, s->filename);
> > +
> > +return 0;
> > }
> >
> > static int dash_init(AVFormatContext *s)
> > @@ -796,6 +806,10 @@ static int dash_flush(AVFormatContext *s, int final,
> > int stream)
> > {
> > DASHContext *c = s->priv_data;
> > int i, ret = 0;
> > +
> > +const char *proto = avio_find_protocol_name(s->filename);
> > +int use_rename = proto && !strcmp(proto, "file");
> > +
> > int cur_flush_segment_index = 0;
> > if (stream >= 0)
> > cur_flush_segment_index = c->streams[stream].segment_index;
> > @@ -833,7 +847,7 @@ static int dash_flush(AVFormatContext *s, int final,
> > int stream)
> > if (!c->single_file) {
> > dash_fill_tmpl_params(filename, sizeof(filename),
> > c->media_seg_name, i, os->segment_index, os->bit_rate, os->start_pts);
> > snprintf(full_path, sizeof(full_path), "%s%s", c->dirname,
> > filename);
> > -snprintf(temp_path, sizeof(temp_path), "%s.tmp", full_path);
> > +snprintf(temp_path, sizeof(temp_path), use_rename ? "%s.tmp"
> > : "%s", full_path);
> > ret = s->io_open(s, &os->out, temp_path, AVIO_FLAG_WRITE,
> > NULL);
> > if (ret < 0)
> > break;
> > @@ -851,9 +865,12 @@ static int dash_flush(AVFormatContext *s, int final,
> > int stream)
> > find_index_range(s, full_path, start_pos, &index_length);
> > } else {
> > ff_format_io_close(s, &os->out);
> > -ret = avpriv_io_move(temp_path, full_path);
> > -if (ret < 0)
> > -break;
> > +
> > +if (use_rename) {
> > +ret = avpriv_io_move(temp_path, full_path);
> > +if (ret < 0)
> > +break;
> > +}
> > }
> > add_segment(os, filename, os->start_pts, os->max_pts -
> > os->start_pts, start_pos, range_length, index_length);
> > av_log(s, AV_LOG_VERBOSE, "Representation %d media segment %d
> > written to: %s\n", i, os->segment_index, full_path);
> > --
> > 2.5.0
> >
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
LGTM
and looks like segments, hlsenc
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVFMT_FLAG_NOBUFFER not working on ffmpeg2.8 branch
On Tue, Feb 14, 2017 at 12:03:56PM +0800, Shi Qiu wrote: > libavformat/utils.c,line 3308: Is this issue reproduceable with git master ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Only use temporary files when outputting to file protocol
Has anybody had a chance to look at this patch?
Thanks,
--Thomas
On Tue, Feb 7, 2017, 2:20 PM Thomas Stephens wrote:
> Skips using temporary files when outputting to a protocol other than
> "file", which enables dash to output content over network
> protocols. The logic has been copied from the HLS format.
> ---
> libavformat/dashenc.c | 29 +++--
> 1 file changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 534fa75..fa56505 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -444,9 +444,15 @@ static int write_manifest(AVFormatContext *s, int
> final)
> AVIOContext *out;
> char temp_filename[1024];
> int ret, i;
> +const char *proto = avio_find_protocol_name(s->filename);
> +int use_rename = proto && !strcmp(proto, "file");
> +static unsigned int warned_non_file = 0;
> AVDictionaryEntry *title = av_dict_get(s->metadata, "title", NULL, 0);
>
> -snprintf(temp_filename, sizeof(temp_filename), "%s.tmp", s->filename);
> +if (!use_rename && !warned_non_file++)
> +av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol,
> this may lead to races and temporary partial files\n");
> +
> +snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp"
> : "%s", s->filename);
> ret = s->io_open(s, &out, temp_filename, AVIO_FLAG_WRITE, NULL);
> if (ret < 0) {
> av_log(s, AV_LOG_ERROR, "Unable to open %s for writing\n",
> temp_filename);
> @@ -548,7 +554,11 @@ static int write_manifest(AVFormatContext *s, int
> final)
> avio_printf(out, "\n");
> avio_flush(out);
> ff_format_io_close(s, &out);
> -return avpriv_io_move(temp_filename, s->filename);
> +
> +if (use_rename)
> +return avpriv_io_move(temp_filename, s->filename);
> +
> +return 0;
> }
>
> static int dash_init(AVFormatContext *s)
> @@ -796,6 +806,10 @@ static int dash_flush(AVFormatContext *s, int final,
> int stream)
> {
> DASHContext *c = s->priv_data;
> int i, ret = 0;
> +
> +const char *proto = avio_find_protocol_name(s->filename);
> +int use_rename = proto && !strcmp(proto, "file");
> +
> int cur_flush_segment_index = 0;
> if (stream >= 0)
> cur_flush_segment_index = c->streams[stream].segment_index;
> @@ -833,7 +847,7 @@ static int dash_flush(AVFormatContext *s, int final,
> int stream)
> if (!c->single_file) {
> dash_fill_tmpl_params(filename, sizeof(filename),
> c->media_seg_name, i, os->segment_index, os->bit_rate, os->start_pts);
> snprintf(full_path, sizeof(full_path), "%s%s", c->dirname,
> filename);
> -snprintf(temp_path, sizeof(temp_path), "%s.tmp", full_path);
> +snprintf(temp_path, sizeof(temp_path), use_rename ? "%s.tmp"
> : "%s", full_path);
> ret = s->io_open(s, &os->out, temp_path, AVIO_FLAG_WRITE,
> NULL);
> if (ret < 0)
> break;
> @@ -851,9 +865,12 @@ static int dash_flush(AVFormatContext *s, int final,
> int stream)
> find_index_range(s, full_path, start_pos, &index_length);
> } else {
> ff_format_io_close(s, &os->out);
> -ret = avpriv_io_move(temp_path, full_path);
> -if (ret < 0)
> -break;
> +
> +if (use_rename) {
> +ret = avpriv_io_move(temp_path, full_path);
> +if (ret < 0)
> +break;
> +}
> }
> add_segment(os, filename, os->start_pts, os->max_pts -
> os->start_pts, start_pos, range_length, index_length);
> av_log(s, AV_LOG_VERBOSE, "Representation %d media segment %d
> written to: %s\n", i, os->segment_index, full_path);
> --
> 2.5.0
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/9] ffmpeg: do packet ts rescaling in write_packet()
On Mon, Feb 13, 2017 at 06:27:50AM +0100, wm4 wrote: > On Fri, 10 Feb 2017 22:43:26 +0100 > Michael Niedermayer wrote: > > > On Fri, Feb 10, 2017 at 01:35:34PM +0100, wm4 wrote: > > > From: Anton Khirnov > > > > > > This will be useful in the following commit, after which the muxer > > > timebase is not always available when encoding. > > > > > > This merges Libav commit 3e265ca. It was previously skipped. > > > > > > There is a minor change with setting the mux_timebase field only after > > > the muxer's write_header function has been called, because it can > > > readjust the timebase. > > > > > > Includes a minor merge fix by Mark Thompson. > > > > > > Signed-off-by: wm4 > > > --- > > > ffmpeg.c | 39 ++- > > > ffmpeg.h | 2 ++ > > > 2 files changed, 24 insertions(+), 17 deletions(-) > > > > Is this intended to result in no changes ? > > > > ./ffmpeg -ss 15 -i ~/tickets/1332/Starship_Troopers.vob -scodec dvbsub > > -vcodec copy -t 4 -r 24000/1001 -an aaa.ts > > differs from before and after this patch > > > > [...] > > Is it different in a good or a bad way? I did not do a analysis of the difference. My concern are the growing number of regressions (which implies more get added than fixed). And so i try to find changes and issues in patches before they are pushed. I wish to work on the many past regressions and fix at least some of them, i just realized we have some regressions that are caused by commits i did long ago. These are things i want to look into and i seem not to have as much time as i want. Analysing differences other peoples patches on the ML cause is not something i would be able to do without not doing something else that i feel iam more responsble for -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] (for discussion): nvenc: fix wrong aspect ratio for 720x576 and 720x480 resolution
Hi Miroslav , Philip, We will look at this issue, and provide a fix for the same. Would be great to send me and Sumit (also copied here) the command lines that you tried and the observations to repro at our end. Thanks, Yogender -Original Message- From: Miroslav Slugeň [mailto:thunde...@email.cz] Sent: Monday, February 13, 2017 10:04 PM To: Philip Langdale Cc: FFmpeg development discussions and patches; Sumit Agarwal; Yogender Gupta Subject: Re: [FFmpeg-devel] [PATCH] (for discussion): nvenc: fix wrong aspect ratio for 720x576 and 720x480 resolution Dne 13.2.2017 v 17:07 Philip Langdale napsal(a): > On Mon, 13 Feb 2017 07:21:51 -0800 > Philip Langdale wrote: > >> On Mon, 13 Feb 2017 08:52:34 +0100 >> Miroslav Slugeň wrote: >> >>> I am using current STABLE drivers 375.26, because BETA drivers >>> 378.09 caused some crashes while encoding on NVENC. >>> >>> I tested this on BETA drivers too and it is still same. >>> >>> Original workaround is not working anymore :( >>> >>> INPUT: Stream #0:0[0x401]: Video: mpeg2video (Main) ([2][0][0][0] / >>> 0x0002), yuv420p(tv, top first), 720x576 [SAR 64:45 DAR 16:9], 25 >>> fps, 25 tbr, 90k tbn, 50 tbc >>> >>> OUTPUT: Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / >>> 0x001B), yuv420p(progressive), 720x576 [SAR 16:11 DAR 20:11], 25 >>> fps, 25 tbr, 90k tbn, 50 tbc >>> >>> COMMAND: ffmpeg -deint adaptive -hwaccel cuvid -c:v mpeg2_cuvid -i >>> "in.ts" -y -c:v h264_nvenc -c:a copy -b:v 1M -preset hq -f mpegts >>> "out.ts" >>> >>> Also someone else is complaining about this issue: >>> http://superuser.com/questions/1174097/ffmpegnvenc-encoding-strange- >>> aspect-ratio >>> >>> M. >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> Can you point me to a sample that you see this behaviour with? I >> cannot reproduce with DVD sources here, which is where I saw the >> original problem. > You sent me a sample and I tried it out. I was able to reproduce your > problem, but it is not the original problem, and I wonder what is > really going on. > > If you take your sample and your command line and then output to a > different container (i tried mkv and mp4), it's all correct - and it > would not be correct if my original workaround was still required. > There's something specific about using mpegts that leads to this > problem. > > I'm not familiar with what parts of what metadata get respected in > different contextx For example, the out.ts, this command line > produces, is reported as having the right aspect ratio by mediainfo, > but the wrong one by ffprobe (and then plays back wrong, obviously). > > Modifying the darWidth and darHeight leads to changes that are visible > in mediainfo, and are cumulative with respect to whatever bug is > hitting you here. > > So, theory - there was a bug where nvenc was distorting the DAR and > that bug is now fixed. It seems like there is now some other bug, or > perhaps there always was a bug, which is modifying the SAR. Perhaps it > is doing it all the time but in other containers, container level > metadata is overriding it so it never becomes an issue. > > Sounds like a great time for an nvidia dev to chime in :-) > > --phil > I am sure that i know what is going on, NVENC is inserting wrong SPS VUI aspect_ratio_idc to h264 packets when you encode at resolution 720x576 and 720x480 AR 16:9 will insert aspect_ratio_idc=4 but it should be aspect_ratio_idc=255, sar_width=64, sar_height=45 for 720x576 AR 4:3 will insert aspect_ratio_idc=2 but it should be aspect_ratio_idc=255, sar_width=16, sar_height=15 for 720x576 MP4 and MKV containers contains correct AR metadata information which all players should accept, but TS container has nothing like that so it relies on what is inside h264 SPS. Miroslav Slugeň +420 724 825 885 --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: add new forced_keyframes option -hls:time
2017-02-14 19:18 GMT+08:00 Michael Niedermayer : > On Sun, Feb 12, 2017 at 07:12:31PM +0100, Miroslav Slugeň wrote: > > If we are using copyts parameter it is not possible to inserting key > > frames same way as hlsenc requests, this will lead to different hls > > segments length. > > > > -copyts is required for long period audio/video sync > > > > Small modification to hlsenc.c is also required and will arrive in > > next patch. > > > > -- > > Miroslav Slugeň > > > > > > > > > > > > > > > > > > > > > ffmpeg.c | 19 +++ > > ffmpeg.h |4 > > 2 files changed, 23 insertions(+) > > 77d7894d66a6195b7ed7c3e1f1998ec8289f66a2 0001-ffmpeg-add-new-forced_ > keyframes-option-hls-time-for-.patch > > From 90d0636ea6cd34c9b51e4b568bb9e8aa461fa615 Mon Sep 17 00:00:00 2001 > > From: Miroslav Slugen > > Date: Sun, 12 Feb 2017 19:08:27 +0100 > > Subject: [PATCH 1/1] ffmpeg: add new forced_keyframes option -hls:time > for > > inserting keyframes exactly athlsenc position compatible with copyts > > > > --- > > ffmpeg.c | 19 +++ > > ffmpeg.h | 4 > > 2 files changed, 23 insertions(+) > > Missing update to documentation > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > You can kill me, but you cannot change the truth. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > BTW, Add FATE please. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: add new forced_keyframes option -hls:time
On Sun, Feb 12, 2017 at 07:12:31PM +0100, Miroslav Slugeň wrote: > If we are using copyts parameter it is not possible to inserting key > frames same way as hlsenc requests, this will lead to different hls > segments length. > > -copyts is required for long period audio/video sync > > Small modification to hlsenc.c is also required and will arrive in > next patch. > > -- > Miroslav Slugeň > > > > > > > > > > ffmpeg.c | 19 +++ > ffmpeg.h |4 > 2 files changed, 23 insertions(+) > 77d7894d66a6195b7ed7c3e1f1998ec8289f66a2 > 0001-ffmpeg-add-new-forced_keyframes-option-hls-time-for-.patch > From 90d0636ea6cd34c9b51e4b568bb9e8aa461fa615 Mon Sep 17 00:00:00 2001 > From: Miroslav Slugen > Date: Sun, 12 Feb 2017 19:08:27 +0100 > Subject: [PATCH 1/1] ffmpeg: add new forced_keyframes option -hls:time for > inserting keyframes exactly athlsenc position compatible with copyts > > --- > ffmpeg.c | 19 +++ > ffmpeg.h | 4 > 2 files changed, 23 insertions(+) Missing update to documentation [...] -- 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] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
On Tue, Feb 14, 2017 at 10:03:41AM +0100, Paul B Mahol wrote: > Correct way in solving this is outputing in cinepak decoder actual > native format that it > uses and not do any conversions of colorspace which is currently done. > Implement correct colorspace conversions of cinepak format to others > in libswscale. Would you comment on what is the difference between now and the situation https://ffmpeg.org/pipermail/ffmpeg-devel/2013-February/138811.html when you (?) wrote on the same topic --- > i think hes asking if it should be a new colorspace in swscale, or > added into the cinepak decoder/encoder common code. > > by your answer i think it has to be a new swscale colorspace? Please leave libswscale alone. --- That position was IMHO reasonable. Commenting on your current suggestion: What would be the advantage of moving the Cinepak-specific conversions into the general purpose library? Either this would mean as many variations of the conversion code as there are in the decoder now or the conversion would be done through some intermediate format, which is a loss per se. The code still only would be used by Cinepak. Besides this, for a purely technical reason the conversions done in Cinepak are not suitable for delayed delegation to swscaler. The reason has been already pointed out in the thread: The huge difference in the amount of the data to be processed; in other words the very essence of the vector quantization technology where frame data is represented by a codebook, by design meant to be much smaller. (BTW mathematically DCT to the contrary is equivalent to referencing an extremely large codebook. This codebook does not have to be transmitted or stored, neither of which would be practical. Instead its entries are generated on-demand, for each frame data block. This is the situation where swscale is an efficient tool.) Hope this helps. Regards, Rune ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hlsenc: intialize only on ref_pkt (v2)
Dne 14.2.2017 v 09:33 Steven Liu napsal(a): 2017-02-14 16:30 GMT+08:00 Miroslav Slugeň : Dne 14.2.2017 v 04:59 Steven Liu napsal(a): 2017-02-13 21:15 GMT+08:00 Miroslav Slugeň : This patch will fix cutting hls segments into exactly same length. Because it will intialize only on first ref_packet, which is video frame, not audio frame (old behavior) Now it should be possible to create segments at exactly same length if we use new -force_key_frames hls:time_in_seconds parameter. This is required to support adaptive HLS. This patch was splitted to two parts, this is first independent part -- Miroslav Slugeň ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Patch can compile passed, but i cannot reproduce the problem before your patch, can you send a reproduce step and test file? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I can provide you with sample. But this explanation should be enough: When you use -copyts for long time audio/video sync when transcoding from MPEGTS stream, audio comes always sooner than video (it is around 1-2 s), so hlsenc is initialized with audio packet PTS instead of video packet PTS. That is not correct if you wan't to have all segments with same length -forced_keyframes to force keyframe at video position. Every other calculations of hls_time is done only on ref_packets which is video. This scenario is problematic when encoder is also inserting keyframes by its own decision (libx264 default behavior). command line please! M. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ffmpeg -i dvb_record.ts \ -map 0:v:0 -filter:v yadif -force_key_frames 'expr:gte(t,n_forced*10)' -c:v libx264 -g 250 -b:v 500k \ -map 0:a:0 -ac 2 -ar 48000 -c:a libfdk_aac -b:a 128k \ -sn \ -copyts \ -r 25 \ -hls_time 10 -hls_list_size 10 -hls_allow_cache 1 -use_localtime 1 -hls_flags omit_endlist+discont_start \ -hls_segment_filename "segment-%Y%m%d-%s.ts" -f hls -y "playlist.m3u8" But this will not work correctly until -force_key_frames is fixed for copyts, or until you use -force_key_frames hls:10 from my patch "[PATCH] ffmpeg: add new forced_keyframes option hls:time" M. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
On 2/14/17, wm4 wrote: > On Tue, 14 Feb 2017 09:51:54 +0100 > u-9...@aetey.se wrote: > >> On Tue, Feb 14, 2017 at 06:51:46AM +0100, wm4 wrote: >> > On Mon, 13 Feb 2017 18:51:39 +0100 >> > u-9...@aetey.se wrote: >> > >> > > Then abstracting a "mini-swscale" could become justifiable. >> > >> > And this is why we should probably reject this patch. >> > What you wrote paints a horrifying future. >> --^ >> > >> > Note that we would have this discussion even if it'd speed up the h264 >> > decoder. Pissing all over modularization is not a good thing to do. >> ---^^^ >> > >> > If you really want to get anything applied, you should probably try >> > looking at outputting ycgco, which appears to be the native colorspace >> > of the codec (and convert it vf_colorspace, I guess). >> >> Dear wm4, >> >> Your readiness to give feedback and your endeavor to keep the high quality >> of the code are appreciated. Nevertheless: >> >> I kindly ask you to mind your use of disparaging terms >> (emotionally charged expressions like "horrifying" or "pissing" >> which attribute a negative quality or attitude to your opponent), >> the corresponding phrases are marked above for your reference >> >> and please check your data. >> >> For additional information I would suggest >> >> https://ffmpeg.org/developer.html#Code-of-conduct >> >> https://multimedia.cx/mirror/cinepak.txt >> >> the contents of this thread > > Nevertheless your patches are rejected. Correct way in solving this is outputing in cinepak decoder actual native format that it uses and not do any conversions of colorspace which is currently done. Implement correct colorspace conversions of cinepak format to others in libswscale. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
On Tue, 14 Feb 2017 09:51:54 +0100 u-9...@aetey.se wrote: > On Tue, Feb 14, 2017 at 06:51:46AM +0100, wm4 wrote: > > On Mon, 13 Feb 2017 18:51:39 +0100 > > u-9...@aetey.se wrote: > > > > > Then abstracting a "mini-swscale" could become justifiable. > > > > And this is why we should probably reject this patch. > > What you wrote paints a horrifying future. > --^ > > > > Note that we would have this discussion even if it'd speed up the h264 > > decoder. Pissing all over modularization is not a good thing to do. > ---^^^ > > > > If you really want to get anything applied, you should probably try > > looking at outputting ycgco, which appears to be the native colorspace > > of the codec (and convert it vf_colorspace, I guess). > > Dear wm4, > > Your readiness to give feedback and your endeavor to keep the high quality > of the code are appreciated. Nevertheless: > > I kindly ask you to mind your use of disparaging terms > (emotionally charged expressions like "horrifying" or "pissing" > which attribute a negative quality or attitude to your opponent), > the corresponding phrases are marked above for your reference > > and please check your data. > > For additional information I would suggest > > https://ffmpeg.org/developer.html#Code-of-conduct > > https://multimedia.cx/mirror/cinepak.txt > > the contents of this thread Nevertheless your patches are rejected. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
On Tue, Feb 14, 2017 at 06:51:46AM +0100, wm4 wrote: > On Mon, 13 Feb 2017 18:51:39 +0100 > u-9...@aetey.se wrote: > > > Then abstracting a "mini-swscale" could become justifiable. > > And this is why we should probably reject this patch. > What you wrote paints a horrifying future. --^ > > Note that we would have this discussion even if it'd speed up the h264 > decoder. Pissing all over modularization is not a good thing to do. ---^^^ > > If you really want to get anything applied, you should probably try > looking at outputting ycgco, which appears to be the native colorspace > of the codec (and convert it vf_colorspace, I guess). Dear wm4, Your readiness to give feedback and your endeavor to keep the high quality of the code are appreciated. Nevertheless: I kindly ask you to mind your use of disparaging terms (emotionally charged expressions like "horrifying" or "pissing" which attribute a negative quality or attitude to your opponent), the corresponding phrases are marked above for your reference and please check your data. For additional information I would suggest https://ffmpeg.org/developer.html#Code-of-conduct https://multimedia.cx/mirror/cinepak.txt the contents of this thread Regards, Rune ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hlsenc: intialize only on ref_pkt (v2)
2017-02-14 16:30 GMT+08:00 Miroslav Slugeň : > Dne 14.2.2017 v 04:59 Steven Liu napsal(a): > > 2017-02-13 21:15 GMT+08:00 Miroslav Slugeň : >> >> This patch will fix cutting hls segments into exactly same length. Because >>> it will intialize only on first ref_packet, which is video frame, not >>> audio >>> frame (old behavior) >>> >>> Now it should be possible to create segments at exactly same length if we >>> use new -force_key_frames hls:time_in_seconds parameter. >>> >>> This is required to support adaptive HLS. >>> >>> This patch was splitted to two parts, this is first independent part >>> >>> -- >>> Miroslav Slugeň >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> >>> Patch can compile passed, but i cannot reproduce the problem before your >> patch, can you send a reproduce step and test file? >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > I can provide you with sample. But this explanation should be enough: > > When you use -copyts for long time audio/video sync when transcoding from > MPEGTS stream, audio comes always sooner than video (it is around 1-2 s), > so hlsenc is initialized with audio packet PTS instead of video packet PTS. > That is not correct if you wan't to have all segments with same length > -forced_keyframes to force keyframe at video position. Every other > calculations of hls_time is done only on ref_packets which is video. This > scenario is problematic when encoder is also inserting keyframes by its own > decision (libx264 default behavior). command line please! > > > M. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hlsenc: intialize only on ref_pkt (v2)
Dne 14.2.2017 v 04:59 Steven Liu napsal(a): 2017-02-13 21:15 GMT+08:00 Miroslav Slugeň : This patch will fix cutting hls segments into exactly same length. Because it will intialize only on first ref_packet, which is video frame, not audio frame (old behavior) Now it should be possible to create segments at exactly same length if we use new -force_key_frames hls:time_in_seconds parameter. This is required to support adaptive HLS. This patch was splitted to two parts, this is first independent part -- Miroslav Slugeň ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Patch can compile passed, but i cannot reproduce the problem before your patch, can you send a reproduce step and test file? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I can provide you with sample. But this explanation should be enough: When you use -copyts for long time audio/video sync when transcoding from MPEGTS stream, audio comes always sooner than video (it is around 1-2 s), so hlsenc is initialized with audio packet PTS instead of video packet PTS. That is not correct if you wan't to have all segments with same length -forced_keyframes to force keyframe at video position. Every other calculations of hls_time is done only on ref_packets which is video. This scenario is problematic when encoder is also inserting keyframes by its own decision (libx264 default behavior). M. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] (for discussion): ffmpeg_filter: initialize cuvid for filter_complex
Dne 14.2.2017 v 06:51 Hendrik Leppkes napsal(a): On Mon, Feb 13, 2017 at 11:00 PM, Timo Rothenpieler wrote: It is problem in NVENC. You create first frame before initialization of NVENC in CUVID, so this first frame is not accesible to NVENC until dl_fn->cuda_dl->cuCtxPushCurrent(ctx->cu_context) is called in NVENC. This trivial patch should fix your problem. M. Very interesting. I don't think this patch is the proper fix though. There never should be an active cuda context when returning from a function, at least that's the premise under which I wrote all cuda related functions so far. This must mean that before, cuvid or something else must somehow have leaked a bound cuda context to nvenc. So that might need fixing as well. Indeed having an implicit context active would be rather fragile, so best would be to revisit both cuvid and nvenc and make sure contexts are explicitly pushed and poped wherever needed - but I assume thats what you have planned to do now already. ;) This reminds me of this patch from Libav which landed a couple weeks ago: https://git.libav.org/?p=libav.git;a=commitdiff;h=fb59f87ce72035b940c3f5045884098b9324e1b2 Its hardly complete and only handling it in one place, but its probably fixing a similar issue. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Nice catch, this patch in libav should fix it also, i think it should be backported as soon as possible. M. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
