Re: [FFmpeg-devel] [PATCH] avfilter/vf_unsharp: enable slice threading
Am Fr., 10. Mai 2019 um 08:50 Uhr schrieb Song, Ruiling : > > > -Original Message- > > From: Song, Ruiling > > Sent: Thursday, May 9, 2019 3:43 PM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Song, Ruiling > > Subject: [PATCH] avfilter/vf_unsharp: enable slice threading > > > > Signed-off-by: Ruiling Song > > --- > > libavfilter/unsharp.h| 4 +- > > libavfilter/vf_unsharp.c | 98 ++-- > > 2 files changed, 78 insertions(+), 24 deletions(-) > > Add some performance number in case somebody have interest to know. > Running "ffmpeg -i 1080p.mp4 -vf unsharp=la=3:ca=3 -an -f null /dev/null" on > my local machine (i7-6770HQ): the fps increase from 50 to 120. Something like this should be part of the commit message imo. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42
Am Fr., 10. Mai 2019 um 07:59 Uhr schrieb Philip Langdale : > > I don't think this is terribly useful, as the only thing out there that > can even handle NV24 content is VDPAU and the only time you have to > deal with it is when doing VDPAU OpenGL interop where swscale is > irrelevant. In the other cases you can use YV24 (YUV444P). I believe this information was missing from the other commit message (or I missed it which is absolutely possible). Could it be worthwhile to test where within the vdpau / opengl pipeline an issue is making this patch useful? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
From: Daniel Kucera
Signed-off-by: Daniel Kucera
---
doc/ffplay.texi | 2 ++
fftools/ffplay.c | 4
2 files changed, 6 insertions(+)
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index c305465078..a37c02dc0d 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -66,6 +66,8 @@ Set custom interval, in seconds, for seeking using left/right
keys. Default is 1
Disable graphical display.
@item -noborder
Borderless window.
+@item -alwaysontop
+Window always on top.
@item -volume
Set the startup volume. 0 means silence, 100 means no volume reduction or
amplification. Negative values are treated as 0, values above 100 are treated
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 8f050e16e6..931dc08e2d 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -324,6 +324,7 @@ static int seek_by_bytes = -1;
static float seek_interval = 10;
static int display_disable;
static int borderless;
+static int alwaysontop;
static int startup_volume = 100;
static int show_status = 1;
static int av_sync_type = AV_SYNC_AUDIO_MASTER;
@@ -3581,6 +3582,7 @@ static const OptionDef options[] = {
{ "seek_interval", OPT_FLOAT | HAS_ARG, { &seek_interval }, "set seek
interval for left/right keys, in seconds", "seconds" },
{ "nodisp", OPT_BOOL, { &display_disable }, "disable graphical display" },
{ "noborder", OPT_BOOL, { &borderless }, "borderless window" },
+{ "alwaysontop", OPT_BOOL, { &alwaysontop }, "window always on top" },
{ "volume", OPT_INT | HAS_ARG, { &startup_volume}, "set startup volume
0=min 100=max", "volume" },
{ "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt" },
{ "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg =
opt_frame_pix_fmt }, "set pixel format", "format" },
@@ -3722,6 +3724,8 @@ int main(int argc, char **argv)
if (!display_disable) {
int flags = SDL_WINDOW_HIDDEN;
+if (alwaysontop)
+flags |= SDL_WINDOW_ALWAYS_ON_TOP;
if (borderless)
flags |= SDL_WINDOW_BORDERLESS;
else
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v9] lavf/flv: Add XV (Xunlei Video) Support. fixes ticket #3720
The patch is for ticket #3720. XV Xunlei video support. XV video is a
flv video. The flv data starts from 0x20th byte and the next 0x400
bytes are rotated, to find the value by which the next 0x400 bytes are
rotated. I subtracted the 0x20th byte from 0x46 ( 'F' ) ( As every
flv video starts from 'FLV' signature, So, i already know the original
0x20th byte), So, i got the value by which the next 0x400 bytes are
rotated. In the below patch i have skipped the first packet, so that i
don't have to decrypt the encrypted 0x400 bytes.
But i also tried to decrypt the 0x400 bytes from that rot value. but
every time i try i reached at two situations: Either this becomes too
low level ( needs modifications of the avio stuff, which a demuxer
should not do). Or it affects the flv demuxer, like adding too many 'if
else' statements to the flv_read_packet() would slow demuxing of flv
format too, which i don't want. The ways i tried -
-> Checking if the format is xv or flv every time it reads from input
file (decrypt it if needed).
-> decrypt the input buffer at the time of reading header
-> Making two avio contexts and one calling the other ( I am not sure if
i implemented it in the right way, but still i reached low level ).
In the patch i have skipped the first packet due to this it can't tell
the rate and duration of video but it plays and can be converted with no
errors.
Please review if it is right,or there can be another approach ( i know
this is an easy task but just due to those 0x400 bytes it is tricky ).
Thank you,
Shivam GoyalFrom b9dde21af273c8137df370399ade79c0c59a4046 Mon Sep 17 00:00:00 2001
From: Shivam Goyal
Date: Fri, 10 May 2019 17:53:26 +0530
Subject: [PATCH] lavf/flv: Add XV(Xunlei video file) support, fixes ticket
#3720
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/flvdec.c | 74
libavformat/version.h| 4 +--
5 files changed, 79 insertions(+), 2 deletions(-)
diff --git a/Changelog b/Changelog
index a3fa0c14a2..a9dc982d08 100644
--- a/Changelog
+++ b/Changelog
@@ -26,6 +26,7 @@ version :
- lscr decoder
- lagfun filter
- asoftclip filter
+- XV (Xunlei Video) demuxer
version 4.1:
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..e090c051f1 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -561,6 +561,7 @@ OBJS-$(CONFIG_WV_MUXER) += wvenc.o wv.o apetag.o img2.o
OBJS-$(CONFIG_XA_DEMUXER)+= xa.o
OBJS-$(CONFIG_XBIN_DEMUXER) += bintext.o sauce.o
OBJS-$(CONFIG_XMV_DEMUXER) += xmv.o
+OBJS-$(CONFIG_XV_DEMUXER)+= flvdec.o
OBJS-$(CONFIG_XVAG_DEMUXER) += xvag.o
OBJS-$(CONFIG_XWMA_DEMUXER) += xwma.o
OBJS-$(CONFIG_YOP_DEMUXER) += yop.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d316a0529a..b499186071 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -456,6 +456,7 @@ extern AVOutputFormat ff_wv_muxer;
extern AVInputFormat ff_xa_demuxer;
extern AVInputFormat ff_xbin_demuxer;
extern AVInputFormat ff_xmv_demuxer;
+extern AVInputFormat ff_xv_demuxer;
extern AVInputFormat ff_xvag_demuxer;
extern AVInputFormat ff_xwma_demuxer;
extern AVInputFormat ff_yop_demuxer;
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index b531a39adc..87bfb68ee5 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -127,6 +127,19 @@ static int kux_probe(const AVProbeData *p)
return 0;
}
+static int xv_probe(const AVProbeData *p)
+{
+const uint8_t *d = p->buf;
+
+if (d[0] == 'X' &&
+d[1] == 'L' &&
+d[2] == 'V' &&
+d[3] == 'F') {
+return AVPROBE_SCORE_EXTENSION + 1;
+}
+return 0;
+}
+
static void add_keyframes_index(AVFormatContext *s)
{
FLVContext *flv = s->priv_data;
@@ -783,6 +796,46 @@ static int flv_read_header(AVFormatContext *s)
return 0;
}
+static int xv_read_header(AVFormatContext *s)
+{
+int flags;
+FLVContext *xv = s->priv_data;
+AVIOContext *ic = s->pb;
+int offset;
+int enc_tag_size;
+int rot;
+
+// Find rot for rotating the bytes
+avio_skip(ic, 0x20);
+rot = 0x46 - avio_r8(ic);
+
+avio_skip(ic, 3);
+
+flags = (avio_r8(ic) + rot) & 0xff;
+
+xv->missing_streams = flags & (FLV_HEADER_FLAG_HASVIDEO | FLV_HEADER_FLAG_HASAUDIO);
+
+s->ctx_flags |= AVFMTCTX_NOHEADER;
+
+offset = ((avio_r8(ic) + rot & 0xff) << 24 |
+ (avio_r8(ic) + rot & 0xff) << 16 |
+ (avio_r8(ic) + rot & 0xff) << 8 |
+ (avio_r8(ic) + rot & 0xff)) + 0x20;
+avio_seek(ic, offset + 5, SEEK_SET);
+
+enc_tag_size = ((avio_r8(ic) + rot & 0xff) << 16 |
+(avio_r8(ic) + rot & 0xff) << 8 |
+(avio_r8(ic) + rot & 0xff));
+// Skip encoded data
+avio_skip(ic, en
Re: [FFmpeg-devel] [PATCH] libavformat: forced PCR pid in mpegts muxer
Ping. Waiting to review. A.H. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/drawtext: make command processing error-resilient
At present, if the command args passed to drawtext contain any invalid
values, ffmpeg may crash or, at best, stop drawing any text.
Attached patch gets the filter to continue with existing parameters, if
not all of the changes can be parsed or applied. This allows users in
live processing to correct and resubmit.
Gyan
From 57cb3a085363602877790945b619c92b0fedddcd Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Fri, 10 May 2019 19:13:33 +0530
Subject: [PATCH] avfilter/drawtext: make command processing error-resilient
Prevents crash or blank-out if new option string contains invalid
values.
---
libavfilter/vf_drawtext.c | 47 +++
1 file changed, 38 insertions(+), 9 deletions(-)
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index cca2cbcb88..b166574d71 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -862,20 +862,49 @@ static int config_input(AVFilterLink *inlink)
static int command(AVFilterContext *ctx, const char *cmd, const char *arg,
char *res, int res_len, int flags)
{
-DrawTextContext *s = ctx->priv;
+DrawTextContext *old = ctx->priv;
+DrawTextContext *new = NULL;
+int ret;
if (!strcmp(cmd, "reinit")) {
-int ret;
+new = av_mallocz(sizeof(DrawTextContext));
+if (!new)
+return AVERROR(ENOMEM);
+
+new->class = &drawtext_class;
+ret = av_opt_copy(new, old);
+if (ret < 0)
+goto fail;
+
+ctx->priv = new;
+ret = av_set_options_string(ctx, arg, "=", ":");
+if (ret < 0) {
+ctx->priv = old;
+goto fail;
+}
+
+ret = init(ctx);
+if (ret < 0) {
+uninit(ctx);
+ctx->priv = old;
+goto fail;
+}
+
+new->reinit = 1;
+
+ctx->priv = old;
uninit(ctx);
-s->reinit = 1;
-if ((ret = av_set_options_string(ctx, arg, "=", ":")) < 0)
-return ret;
-if ((ret = init(ctx)) < 0)
-return ret;
+av_freep(old);
+
+ctx->priv = new;
return config_input(ctx->inputs[0]);
-}
+} else
+return AVERROR(ENOSYS);
-return AVERROR(ENOSYS);
+fail:
+av_log(ctx, AV_LOG_ERROR, "Failed to process command. Continuing with
existing parameters.\n");
+av_freep(new);
+return ret;
}
static int func_pict_type(AVFilterContext *ctx, AVBPrint *bp,
--
2.21.0___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42
On Fri, 10 May 2019 11:03:46 +0200 Carl Eugen Hoyos wrote: > Am Fr., 10. Mai 2019 um 07:59 Uhr schrieb Philip Langdale > : > > > > I don't think this is terribly useful, as the only thing out there > > that can even handle NV24 content is VDPAU and the only time you > > have to deal with it is when doing VDPAU OpenGL interop where > > swscale is irrelevant. In the other cases you can use YV24 > > (YUV444P). > > I believe this information was missing from the other commit message > (or I missed it which is absolutely possible). > > Could it be worthwhile to test where within the vdpau / opengl > pipeline an issue is making this patch useful? I mentioned this in the thread around the previous patch. There's no issue - the interop extension always returns semi planar formats by design, previously just nv12 for 420 content but now nv24 for 444 content. As I also mentioned, I've got an mpv patch that uses the new pixel format to correctly handle this case in the interop. Thanks, --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation
Patch updated again. Made some more cleanups to the transforms, the tables and the main context. API changed again, now the init function populates the function pointer for transform. I decided that having a separate function would encourage bad usage (e.g. calling the function every time before doing a transform rather than storing the pointer) when we're trying to avoid the overhead of function calls. Also adjusted file names to match the API. >From 1bc43f2aa7d4dd08468e656c5796055ea064a3d7 Mon Sep 17 00:00:00 2001 From: Lynne Date: Thu, 2 May 2019 15:07:12 +0100 Subject: [PATCH v2] libavutil: add an FFT & MDCT implementation This commit adds a new API to libavutil to allow for arbitrary transformations on various types of data. This is a partly new implementation, with the power of two transforms taken from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while the 3-point FFT was written from scratch. The (i)mdct folding code is taken from mdct15 as well, as the mdct_template code was somewhat old, messy and not easy to separate. A notable feature of this implementation is that it allows for 3xM and 5xM based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc. AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will allow for decoding of such streams. A non-exaustive list of supported sizes: 4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240, 256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560... The API was designed such that it allows for not only 1D transforms but also 2D transforms of certain block sizes. This was partly on accident as the stride argument is required for Opus MDCTs, but can be used in the context of a 2D transform as well. Also, various data types would be implemented eventually as well, such as "double" and "int32_t". Some performance comparisons with libfftw3f (SIMD disabled for both): 120: 22353 decicycles in fftwf_execute, 1024 runs, 0 skips 21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips 128: 22003 decicycles in fftwf_execute, 1024 runs, 0 skips 23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips 384: 75939 decicycles in fftwf_execute,1024 runs, 0 skips 73973 decicycles in compound_fft_3x128,1024 runs, 0 skips 640: 104354 decicycles in fftwf_execute, 1024 runs, 0 skips 149518 decicycles in compound_fft_5x128,1024 runs, 0 skips 768: 109323 decicycles in fftwf_execute,1024 runs, 0 skips 164096 decicycles in compound_fft_3x256,1024 runs, 0 skips 960: 186210 decicycles in fftwf_execute,1024 runs, 0 skips 215256 decicycles in compound_fft_15x64,1024 runs, 0 skips 1024: 163464 decicycles in fftwf_execute, 1024 runs, 0 skips 199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD is around 2x faster than theirs, even if our ptwo SIMD is slightly slower. The goal is to remove the libavcodec/mdct15 code and deprecate the libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported. It is unlikely that libavcodec/fft will be removed soon as there's much SIMD written for exotic or old platforms there, but nevertheless new code should use this new API throughout the project. The implementation passes fate when used in Opus and AAC, and the output is identical in ATRAC9 as well. --- libavutil/Makefile | 2 + libavutil/tx.c | 781 + libavutil/tx.h | 86 + 3 files changed, 869 insertions(+) create mode 100644 libavutil/tx.c create mode 100644 libavutil/tx.h diff --git a/libavutil/Makefile b/libavutil/Makefile index 53208fc587..8a7a44e4b5 100644 --- a/libavutil/Makefile +++ b/libavutil/Makefile @@ -79,6 +79,7 @@ HEADERS = adler32.h \ version.h \ xtea.h\ tea.h \ + tx.h \ HEADERS-$(CONFIG_LZO) += lzo.h @@ -159,6 +160,7 @@ OBJS = adler32.o\ xga_font_data.o \ xtea.o \ tea.o\ + tx.o \ OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o OBJS-$(CONFIG_D3D11VA) += hwcontext_d3d11va.o diff --git a/libavutil/tx.c b/libavutil/tx.c new file mode 100644 index 00..ee6e0b7ac
Re: [FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42
On Fri, 10 May 2019 08:07:45 -0700 Philip Langdale wrote: > On Fri, 10 May 2019 09:35:40 +0300 > Lauri Kasanen wrote: > > > > > I'm having trouble making out what formats exactly isSemiPlanarYUV() > > matches. Are you sure it's an equivalent check? > > > > Well, the check's been in there for quite a while; that's not new. > > (isPlanarYUV(pix_fmt) && desc->comp[1].plane == desc->comp[2].plane); > > So, any planar yuv format where component 1 and component 2 are on the > same plane. Except for semi planar formats, you expect either all > components on the same plane (packed, so not planar) or every component > on a separate plain (normal planar). Yes, I understand that. I mean: can you list all formats that function matches? - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42
On Fri, 10 May 2019 09:35:40 +0300 Lauri Kasanen wrote: > > I'm having trouble making out what formats exactly isSemiPlanarYUV() > matches. Are you sure it's an equivalent check? > Well, the check's been in there for quite a while; that's not new. (isPlanarYUV(pix_fmt) && desc->comp[1].plane == desc->comp[2].plane); So, any planar yuv format where component 1 and component 2 are on the same plane. Except for semi planar formats, you expect either all components on the same plane (packed, so not planar) or every component on a separate plain (normal planar). --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop
---
libavformat/Makefile | 2 +-
libavformat/avc.c| 188 ++
libavformat/avc.h| 15 +++
libavformat/hevc.c | 36 +---
libavformat/mxf.h| 1 +
libavformat/mxfenc.c | 213 ++-
6 files changed, 374 insertions(+), 81 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..df87c54a58 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER) += musx.o
OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
OBJS-$(CONFIG_MVI_DEMUXER) += mvi.o
OBJS-$(CONFIG_MXF_DEMUXER) += mxfdec.o mxf.o
-OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
+OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
avc.o
OBJS-$(CONFIG_MXG_DEMUXER) += mxg.o
OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
diff --git a/libavformat/avc.c b/libavformat/avc.c
index ec50033a04..8f53228bf3 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -21,6 +21,7 @@
#include "libavutil/intreadwrite.h"
#include "libavcodec/h264.h"
+#include "libavcodec/get_bits.h"
#include "avformat.h"
#include "avio.h"
#include "avc.h"
@@ -241,3 +242,190 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t
*start,
return start + res;
}
+
+uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
+ uint32_t *dst_len, int header_len)
+{
+uint8_t *dst;
+uint32_t i, len;
+
+dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!dst)
+return NULL;
+
+/* NAL unit header */
+i = len = 0;
+while (i < header_len && i < src_len)
+dst[len++] = src[i++];
+
+while (i + 2 < src_len)
+if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
+dst[len++] = src[i++];
+dst[len++] = src[i++];
+i++; // remove emulation_prevention_three_byte
+} else
+dst[len++] = src[i++];
+
+while (i < src_len)
+dst[len++] = src[i++];
+
+memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
+*dst_len = len;
+return dst;
+}
+
+static const AVRational avc_sample_aspect_ratio[17] = {
+{ 0, 1 },
+{ 1, 1 },
+{ 12, 11 },
+{ 10, 11 },
+{ 16, 11 },
+{ 40, 33 },
+{ 24, 11 },
+{ 20, 11 },
+{ 32, 11 },
+{ 80, 33 },
+{ 18, 11 },
+{ 15, 11 },
+{ 64, 33 },
+{ 160, 99 },
+{ 4, 3 },
+{ 3, 2 },
+{ 2, 1 },
+};
+
+static inline int get_ue_golomb(GetBitContext *gb) {
+int i, v;
+for (i = 0; i < 32 && !get_bits1(gb); i++)
+;
+for (v = 1; i--;)
+v = (v << 1) | get_bits1(gb);
+return v - 1;
+}
+
+static inline int get_se_golomb(GetBitContext *gb) {
+int v = get_ue_golomb(gb) + 1;
+int sign = -(v & 1);
+return ((v >> 1) ^ sign) - sign;
+}
+
+H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int buf_size)
+{
+int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
+int num_ref_frames_in_pic_order_cnt_cycle;
+int delta_scale, lastScale = 8, nextScale = 8;
+int sizeOfScalingList;
+H264SequenceParameterSet *sps = NULL;
+GetBitContext gb;
+uint8_t *rbsp_buf;
+
+rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, &rbsp_size, 0);
+if (!rbsp_buf)
+return NULL;
+
+ret = init_get_bits8(&gb, rbsp_buf, rbsp_size);
+if (ret < 0)
+goto end;
+
+sps = av_mallocz(sizeof(*sps));
+if (!sps)
+goto end;
+
+sps->profile_idc = get_bits(&gb, 8);
+sps->constraint_set_flags |= get_bits1(&gb) << 0; // constraint_set0_flag
+sps->constraint_set_flags |= get_bits1(&gb) << 1; // constraint_set1_flag
+sps->constraint_set_flags |= get_bits1(&gb) << 2; // constraint_set2_flag
+sps->constraint_set_flags |= get_bits1(&gb) << 3; // constraint_set3_flag
+sps->constraint_set_flags |= get_bits1(&gb) << 4; // constraint_set4_flag
+sps->constraint_set_flags |= get_bits1(&gb) << 5; // constraint_set5_flag
+skip_bits(&gb, 2); // reserved_zero_2bits
+sps->level_idc = get_bits(&gb, 8);
+sps->id = get_ue_golomb(&gb);
+
+if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
+sps->profile_idc == 122 || sps->profile_idc == 244 || sps->profile_idc
== 44 ||
+sps->profile_idc == 83 || sps->profile_idc == 86 || sps->profile_idc
== 118 ||
+sps->profile_idc == 128 || sps->profile_idc == 138 || sps->profile_idc
== 139 ||
+sps->profile_idc == 134) {
+sps->chroma_format_idc = get_ue_golomb(&gb); // chroma_format_idc
+if (sps->chroma_format_idc == 3) {
+skip_bits1(&gb); // separate_colour_plane_flag
+}
+sps->bit_depth_luma = get_ue_golomb(&gb) + 8;
+get_ue_golomb(&g
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop
> On Apr 10, 2019, at 3:16 PM, James Almer wrote: > > On 4/10/2019 6:23 PM, Baptiste Coudurier wrote: >> --- >> libavformat/Makefile | 2 +- >> libavformat/avc.c| 173 +++ >> libavformat/avc.h| 15 +++ >> libavformat/hevc.c | 36 +--- >> libavformat/mxf.h| 1 + >> libavformat/mxfenc.c | 213 ++- >> 6 files changed, 359 insertions(+), 81 deletions(-) >> >> diff --git a/libavformat/Makefile b/libavformat/Makefile >> index 99be60d184..df87c54a58 100644 >> --- a/libavformat/Makefile >> +++ b/libavformat/Makefile >> @@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER) += musx.o >> OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o >> OBJS-$(CONFIG_MVI_DEMUXER) += mvi.o >> OBJS-$(CONFIG_MXF_DEMUXER) += mxfdec.o mxf.o >> -OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o >> +OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o >> audiointerleave.o avc.o >> OBJS-$(CONFIG_MXG_DEMUXER) += mxg.o >> OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o >> OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o >> diff --git a/libavformat/avc.c b/libavformat/avc.c >> index ec50033a04..06a1e495a8 100644 >> --- a/libavformat/avc.c >> +++ b/libavformat/avc.c >> @@ -21,6 +21,7 @@ >> >> #include "libavutil/intreadwrite.h" >> #include "libavcodec/h264.h" >> +#include "libavcodec/golomb.h" > > Right, so golomb has a bunch of lookup tables in golomb.c, obviously not > accessible from libavformat. So this will probably fail to build in > shared builds. > > One option is to include golomb.c here. Another is donig with it the > same we're doing with libavutil's log2_tab.c, and the other is to write > simple get_se() and get_ue() functions here that don't use lookup tables. Patch updated, reimplemented get_se and get_ue as suggested. — Baptiste ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/6] lavc/libvpxenc: remove redundant condition check
From: Jun Zhao
Redundant condition: '!A || B' is equivalent to '!A || (A && B)' but
more clearly.
Signed-off-by: Jun Zhao
---
libavcodec/libvpxenc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index c823b8a..feb52ea 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -978,7 +978,7 @@ static int queue_frames(AVCodecContext *avctx, AVPacket
*pkt_out)
are only good through the next vpx_codec call */
while ((pkt = vpx_codec_get_cx_data(&ctx->encoder, &iter)) &&
(!ctx->is_alpha ||
-(ctx->is_alpha && (pkt_alpha =
vpx_codec_get_cx_data(&ctx->encoder_alpha, &iter_alpha) {
+(pkt_alpha = vpx_codec_get_cx_data(&ctx->encoder_alpha,
&iter_alpha {
switch (pkt->kind) {
case VPX_CODEC_CX_FRAME_PKT:
if (!size) {
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/6] lavc/mlpenc: remove the redundant condition check
From: Jun Zhao
remove the redundant condition check for 'frame'
Signed-off-by: Jun Zhao
---
libavcodec/mlpenc.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
index 7536d3b..deb1716 100644
--- a/libavcodec/mlpenc.c
+++ b/libavcodec/mlpenc.c
@@ -2232,10 +2232,8 @@ static int mlp_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
return 1;
/* add current frame to queue */
-if (frame) {
-if ((ret = ff_af_queue_add(&ctx->afq, frame)) < 0)
-return ret;
-}
+if ((ret = ff_af_queue_add(&ctx->afq, frame)) < 0)
+return ret;
data = frame->data[0];
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/6] lavc/aacenc_ltp: remove unnecessary condition check.
From: Jun Zhao
Condition 'sum==2' is always true, so remove the check logic to
make the code clean.
Signed-off-by: Jun Zhao
---
libavcodec/aacenc_ltp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/aacenc_ltp.c b/libavcodec/aacenc_ltp.c
index 674a2a0..f77f0b6 100644
--- a/libavcodec/aacenc_ltp.c
+++ b/libavcodec/aacenc_ltp.c
@@ -144,7 +144,7 @@ void ff_aac_adjust_common_ltp(AACEncContext *s,
ChannelElement *cpe)
int sum = sce0->ics.ltp.used[sfb] + sce1->ics.ltp.used[sfb];
if (sum != 2) {
sce0->ics.ltp.used[sfb] = 0;
-} else if (sum == 2) {
+} else {
count++;
}
}
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/6] lavc/pngenc: check malloc fail before using the pointer
From: Jun Zhao
Need to check malloc fail before using the pointer
Signed-off-by: Jun Zhao
---
libavcodec/pngenc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 69b4495..d4d8dc8 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -748,11 +748,11 @@ static int apng_encode_frame(AVCodecContext *avctx, const
AVFrame *pict,
original_bytestream_end = s->bytestream_end;
temp_bytestream = av_malloc(original_bytestream_end - original_bytestream);
-temp_bytestream_end = temp_bytestream + (original_bytestream_end -
original_bytestream);
if (!temp_bytestream) {
ret = AVERROR(ENOMEM);
goto fail;
}
+temp_bytestream_end = temp_bytestream + (original_bytestream_end -
original_bytestream);
for (last_fctl_chunk.dispose_op = 0; last_fctl_chunk.dispose_op < 3;
++last_fctl_chunk.dispose_op) {
// 0: APNG_DISPOSE_OP_NONE
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/6] lavc/bink: Remove the dead code block
From: Jun Zhao Remove the dead code block Signed-off-by: Jun Zhao --- libavcodec/bink.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/libavcodec/bink.c b/libavcodec/bink.c index 6673afa..d0f1b39 100644 --- a/libavcodec/bink.c +++ b/libavcodec/bink.c @@ -1046,8 +1046,6 @@ static int bink_decode_plane(BinkContext *c, AVFrame *frame, GetBitContext *gb, if ((ret = read_runs(c->avctx, gb, &c->bundle[BINK_SRC_RUN])) < 0) return ret; -if (by == bh) -break; dst = frame->data[plane_idx] + 8*by*stride; prev = (c->last->data[plane_idx] ? c->last->data[plane_idx] : frame->data[plane_idx]) + 8*by*stride; -- 1.7.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/6] lavc/avpacket: check NULL before using the pointer
From: Jun Zhao
Need to check NULL before using the pointer
Signed-off-by: Jun Zhao
---
libavcodec/avpacket.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 8f0603d..2b20067 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -522,11 +522,12 @@ fail:
int av_packet_unpack_dictionary(const uint8_t *data, int size, AVDictionary
**dict)
{
-const uint8_t *end = data + size;
+const uint8_t *end;
int ret = 0;
if (!dict || !data || !size)
return ret;
+end = data + size;
if (size && end[-1])
return AVERROR_INVALIDDATA;
while (data < end) {
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42
On 2019-05-10 08:12, Lauri Kasanen wrote: On Fri, 10 May 2019 08:07:45 -0700 Philip Langdale wrote: On Fri, 10 May 2019 09:35:40 +0300 Lauri Kasanen wrote: > > I'm having trouble making out what formats exactly isSemiPlanarYUV() > matches. Are you sure it's an equivalent check? > Well, the check's been in there for quite a while; that's not new. (isPlanarYUV(pix_fmt) && desc->comp[1].plane == desc->comp[2].plane); So, any planar yuv format where component 1 and component 2 are on the same plane. Except for semi planar formats, you expect either all components on the same plane (packed, so not planar) or every component on a separate plain (normal planar). Yes, I understand that. I mean: can you list all formats that function matches? For formats that swscale understands: NV12, NV21 P010(BE|LE) P016(BE|LE) and now NV24, NV42. There are also NV16 and NV20(BE|LE) formats which are not supported by swscale. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Possible memory leaks in dshow capture
Thanks for cleaning that up! On Thu, Jan 3, 2019 at 9:32 AM James Almer wrote: > > On 1/3/2019 1:12 PM, Oliver Collyer wrote: > > Version created using git format-patch. > > Applied, thanks. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation
May 10, 2019, 4:14 PM by d...@lynne.ee: > Patch updated again. > Made some more cleanups to the transforms, the tables and the main context. > API changed again, now the init function populates the function pointer for > transform. > I decided that having a separate function would encourage bad usage (e.g. > calling > the function every time before doing a transform rather than storing the > pointer) when > we're trying to avoid the overhead of function calls. > Also adjusted file names to match the API. > Forgot to change an include, new patch attached. >From c20808a88d3e2acde12a5de293262ca95b92f5a5 Mon Sep 17 00:00:00 2001 From: Lynne Date: Thu, 2 May 2019 15:07:12 +0100 Subject: [PATCH v3] libavutil: add an FFT & MDCT implementation This commit adds a new API to libavutil to allow for arbitrary transformations on various types of data. This is a partly new implementation, with the power of two transforms taken from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while the 3-point FFT was written from scratch. The (i)mdct folding code is taken from mdct15 as well, as the mdct_template code was somewhat old, messy and not easy to separate. A notable feature of this implementation is that it allows for 3xM and 5xM based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc. AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will allow for decoding of such streams. A non-exaustive list of supported sizes: 4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240, 256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560... The API was designed such that it allows for not only 1D transforms but also 2D transforms of certain block sizes. This was partly on accident as the stride argument is required for Opus MDCTs, but can be used in the context of a 2D transform as well. Also, various data types would be implemented eventually as well, such as "double" and "int32_t". Some performance comparisons with libfftw3f (SIMD disabled for both): 120: 22353 decicycles in fftwf_execute, 1024 runs, 0 skips 21836 decicycles in compound_fft_15x8, 1024 runs, 0 skips 128: 22003 decicycles in fftwf_execute, 1024 runs, 0 skips 23132 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips 384: 75939 decicycles in fftwf_execute,1024 runs, 0 skips 73973 decicycles in compound_fft_3x128,1024 runs, 0 skips 640: 104354 decicycles in fftwf_execute, 1024 runs, 0 skips 149518 decicycles in compound_fft_5x128,1024 runs, 0 skips 768: 109323 decicycles in fftwf_execute,1024 runs, 0 skips 164096 decicycles in compound_fft_3x256,1024 runs, 0 skips 960: 186210 decicycles in fftwf_execute,1024 runs, 0 skips 215256 decicycles in compound_fft_15x64,1024 runs, 0 skips 1024: 163464 decicycles in fftwf_execute, 1024 runs, 0 skips 199686 decicycles in monolithic_fft_ptwo, 1024 runs, 0 skips With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD is around 2x faster than theirs, even if our ptwo SIMD is slightly slower. The goal is to remove the libavcodec/mdct15 code and deprecate the libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported. It is unlikely that libavcodec/fft will be removed soon as there's much SIMD written for exotic or old platforms there, but nevertheless new code should use this new API throughout the project. The implementation passes fate when used in Opus and AAC, and the output is identical in ATRAC9 as well. --- libavutil/Makefile | 2 + libavutil/tx.c | 781 + libavutil/tx.h | 85 + 3 files changed, 868 insertions(+) create mode 100644 libavutil/tx.c create mode 100644 libavutil/tx.h diff --git a/libavutil/Makefile b/libavutil/Makefile index 53208fc587..8a7a44e4b5 100644 --- a/libavutil/Makefile +++ b/libavutil/Makefile @@ -79,6 +79,7 @@ HEADERS = adler32.h \ version.h \ xtea.h\ tea.h \ + tx.h \ HEADERS-$(CONFIG_LZO) += lzo.h @@ -159,6 +160,7 @@ OBJS = adler32.o\ xga_font_data.o \ xtea.o \ tea.o\ + tx.o \ OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o OBJS-$(CONFIG_D3D11VA) += h
Re: [FFmpeg-devel] [SOLVED] movie Filter reload Option
I am marking this as [SOLVED] as I found a command line combination that
does what I need. I think it is proper enough. I am testing it as follows,
and will respond with results.
Using 3 separate console windows:
1) A script like this is running:
while :; do date +%s > live.txt; cp 1px-Alpha.png overlay.png ; sleep 1; cp
Image.png overlay.png ; date +%s > live.txt; sleep 1; done
This creates a blinking image, and a 1-second clock.
2) From a directory with a bunch of FLV files of various lengths:
while :; do vid=`ls videos/*.flv | sort -R | head -n1`; /usr/local/bin/ffmpeg
-re -y -r 30 -i $vid -c:v libx264 -x264-params "nal-hrd=vbr" -qmin 1 -qmax 15
-c:a aac -b:a 128k -b:v 8M -maxrate 40M -bufsize 20M -g 15 -preset ultrafast
-s 640x360 -t 7 -f flv "rtmp://localhost:1935/video_overlay/key"; done
I have nginx running on localhost, and video_overlay is an application that is
just a relay:
application video_overlay
{
live on;
record off;
}
3) The Big Boy:
/usr/local/bin/ffmpeg -y -re -r 30 -i Input.flv -re -r 30 -i
"rtmp://localhost:1935/video_overlay/key?listen&listen_timeout=15000" -f
image2 -loop 1 -r 30 -i /home/nginx/overlay.png -c:v libx264 -x264-params
"nal-hrd=vbr" -filter_complex
'overlay=100:main_h-overlay_h-50:repeatlast=0:eof_action=pass,
overlay=100:main_h-overlay_h-600,
drawtext=fontfile=/home/nginx/fonts/Live.ttf:textfile=/home/nginx/live.txt:reload=1:x=main_w/33:y=main_h/24:fontsize=h/20:fontcolor=white:borderw=3'
-qmin 1 -qmax 15 -c:a aac -b:a 128k -b:v 8M -maxrate 40M -bufsize 20M -g 15
-preset ultrafast -s 1920x1080 -f mp4 out.mp4
Notes:
a) The first Input "Input.flv" is a file, but can be another nginx application,
same as the one above, that can be used
to receive inbound RTMP from an app or a camera. This will be tested.
b) The second Input receives the stream from the script in 2).
c) To stream to YouTube, replace the "-f mp4 out.mp4" at the end of the command
line with: "-f flv rtmp://a.rtmp.youtube.com/live2/".
likewise for some other RTMP Endpoint.
d) The "repeatlast=0:eof_action=pass" does not seem to work, but the workaround
is to use a alpha-clear overlay intermittently in script 2) above.
e) The "loop" filter is not used with regard to the video overlay. Instead,
that input comes via RTMP.
f) The main command line, 3) waits until it receives input from script in 2).
If you keep pressing "q" in the terminal window running script 2), the
resulting video will capture
the switch from video to video, very well.
If you do a "Ctrl-c" in the terminal running script 2, the main command line,
3) goes back to waiting.
If you do a "Ctrl-z" in the terminal running script 2, the main command waits
where it is, until you
foreground the job again. If you type "q" in the window running 3), it will
quit after 2) is foregrounded
again. Otherwise it goes back to receiving input via RTMP if it is there, or
waiting for it to come in.
(The "Ctrl-z" test is to try to simulate network dropping).
g) There may be some sync issues. Checking. The audio dissync appears to be
consistent.
For the above reasons, I am marking this as [SOLVED] because a reload option to
the movie filter
appears to be the wrong place to look for what I wanted to accomplish.
This will be tested live on YouTube, and this thread will be updated when it is.
My FFMPEG Is as follows:
git branch
master
* release/4.1
git log | head -n 1
commit 7211e1ca9367f7f1a4a04983a66c7b1e2c9a3c92
ffmpeg 2>&1 | grep configuration
configuration: --extra-libs=-lpthread --extra-libs=-lm --enable-gpl
--enable-libfdk_aac --enable-libfreetype --enable-libmp3lame --enable-libx264
--enable-nonfree --enable-fontconfig --enable-libfribidi --disable-stripping
--enable-debug=3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
On 10-05-2019 03:42 PM, Daniel Kucera wrote:
From: Daniel Kucera
Signed-off-by: Daniel Kucera
---
doc/ffplay.texi | 2 ++
fftools/ffplay.c | 4
2 files changed, 6 insertions(+)
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index c305465078..a37c02dc0d 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -66,6 +66,8 @@ Set custom interval, in seconds, for seeking using left/right
keys. Default is 1
Disable graphical display.
@item -noborder
Borderless window.
+@item -alwaysontop
+Window always on top.
@item -volume
Set the startup volume. 0 means silence, 100 means no volume reduction or
amplification. Negative values are treated as 0, values above 100 are treated
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 8f050e16e6..931dc08e2d 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -324,6 +324,7 @@ static int seek_by_bytes = -1;
static float seek_interval = 10;
static int display_disable;
static int borderless;
+static int alwaysontop;
static int startup_volume = 100;
static int show_status = 1;
static int av_sync_type = AV_SYNC_AUDIO_MASTER;
@@ -3581,6 +3582,7 @@ static const OptionDef options[] = {
{ "seek_interval", OPT_FLOAT | HAS_ARG, { &seek_interval }, "set seek interval for
left/right keys, in seconds", "seconds" },
{ "nodisp", OPT_BOOL, { &display_disable }, "disable graphical display" },
{ "noborder", OPT_BOOL, { &borderless }, "borderless window" },
+{ "alwaysontop", OPT_BOOL, { &alwaysontop }, "window always on top" },
{ "volume", OPT_INT | HAS_ARG, { &startup_volume}, "set startup volume 0=min
100=max", "volume" },
{ "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt" },
{ "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg = opt_frame_pix_fmt }, "set
pixel format", "format" },
@@ -3722,6 +3724,8 @@ int main(int argc, char **argv)
if (!display_disable) {
int flags = SDL_WINDOW_HIDDEN;
+if (alwaysontop)
+flags |= SDL_WINDOW_ALWAYS_ON_TOP;
if (borderless)
flags |= SDL_WINDOW_BORDERLESS;
else
Can you also add a keypress event to make it switchable during play?
Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/6] lavc/libvpxenc: remove redundant condition check
From: Jun Zhao
Date: Fri, May 10, 2019 at 9:06 AM
To:
Cc: Jun Zhao
> From: Jun Zhao
>
> Redundant condition: '!A || B' is equivalent to '!A || (A && B)' but
> more clearly.
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/libvpxenc.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index c823b8a..feb52ea 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -978,7 +978,7 @@ static int queue_frames(AVCodecContext *avctx, AVPacket
> *pkt_out)
> are only good through the next vpx_codec call */
> while ((pkt = vpx_codec_get_cx_data(&ctx->encoder, &iter)) &&
> (!ctx->is_alpha ||
> -(ctx->is_alpha && (pkt_alpha =
> vpx_codec_get_cx_data(&ctx->encoder_alpha, &iter_alpha) {
> +(pkt_alpha = vpx_codec_get_cx_data(&ctx->encoder_alpha,
> &iter_alpha {
> switch (pkt->kind) {
> case VPX_CODEC_CX_FRAME_PKT:
> if (!size) {
> --
> 1.7.1
>
lgtm.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Vignesh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window
> Can you also add a keypress event to make it switchable during play? > > Thanks, > Gyan I haven't found a function which would allow to modify window flags after creation: https://wiki.libsdl.org/SDL_GetWindowFlags -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation
Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne : > > May 10, 2019, 4:14 PM by d...@lynne.ee: > > > Patch updated again. > > Made some more cleanups to the transforms, the tables and the main context. > > API changed again, now the init function populates the function pointer for > > transform. > > I decided that having a separate function would encourage bad usage (e.g. > > calling > > the function every time before doing a transform rather than storing the > > pointer) when > > we're trying to avoid the overhead of function calls. > > Also adjusted file names to match the API. > > > > Forgot to change an include, new patch attached. If I understand the commit message correctly, some of the code in the new file you are adding comes from other parts of FFmpeg. I am surprised that there is no copyright claim on the top of this new file. Is there none on top of the files you took the code from? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/6] lavc/avpacket: check NULL before using the pointer
Am Fr., 10. Mai 2019 um 18:13 Uhr schrieb Jun Zhao :
>
> From: Jun Zhao
>
> Need to check NULL before using the pointer
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/avpacket.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 8f0603d..2b20067 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -522,11 +522,12 @@ fail:
>
> int av_packet_unpack_dictionary(const uint8_t *data, int size, AVDictionary
> **dict)
> {
> -const uint8_t *end = data + size;
> +const uint8_t *end;
> int ret = 0;
>
> if (!dict || !data || !size)
> return ret;
> +end = data + size;
Could somebody explain to me why this is necessary?
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v9] lavf/flv: Add XV (Xunlei Video) Support. fixes ticket #3720
On 10.05.2019, at 15:10, Shivam Goyal wrote: > > -> Making two avio contexts and one calling the other ( I am not sure if > i implemented it in the right way, but still i reached low level ). Can't you at least figure out the header size, decrypt the header and pass that to the normal header parsing code? Even if not, I'd at least suggest changing the code from reading bytewise and applying rot to reading all 8 bytes in a buffer, use a loop to apply rot and then the standard AV_RL functions to read the 32 and 24 bit values. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] lavf/h264: add support for h264 video from Arecont camera, fixes ticket #5154
On Thu, May 09, 2019 at 11:45:59PM +0530, Shivam Goyal wrote:
> @@ -117,4 +120,128 @@ static int h264_probe(const AVProbeData *p)
> return 0;
> }
>
> +static const uint8_t arecont_sign[] = {0x2D, 0x2D, 0x66, 0x62, 0x64, 0x72,
> 0x0D, 0x0A};
I admit I was more thinking of either
static const uint8_t arecont_sign[] = "--fbdr\r\n";
which ends up 1 byte too long, or
static const uint8_t arecont_sign[8] = "--fbdr\r\n";
Though there is also the option to go for
static const uint64_t arecont_sign = AV_RL64("--fbdr\r\n");
or similar.
> +static int arecont_find_sign(unsigned char *data, int size)
You should be consistent with the types even if they are essentially
the same.
i.e. uint8_t instead of unsigned char *
Also const, since this function does/should not modify "data".
> +int sign_size = sizeof(arecont_sign) / sizeof(arecont_sign[0]);
First, this is the expression of number of elements, so the
division part is semantically wrong.
Also it's pointless because it will be 1 always.
> +j = memchr(data, arecont_sign[0], size);
> +while (j != NULL && size - sign_size >= (j - data)) {
> +if (!memcmp(arecont_sign, j, sign_size))
> +return (j - data);
> +if (size - sign_size == (j - data))
> +return -1;
> +j = memchr(data + (j - data) + 1, arecont_sign[0], size - (j -
> data));
> +}
I know I brought this memchr up, but did you do any benchmarks?
Unless you have actual evidence of a speed problem AND can
show that your solution actually makes it faster, I'd
suggest to go with the simplest possible solution.
> +data = av_malloc(size);
> +ret = avio_read_partial(s->pb, data, size);
> +if (ret < 0) {
> +av_free(data);
> +av_packet_unref(pkt);
> +return ret;
> +}
> +if (pos <= ARECONT_H264_MIME_SIZE) {
> +avio_seek(s->pb, 0, SEEK_SET);
> +start = pos;
> +} else {
> +avio_seek(s->pb, pos - ARECONT_H264_MIME_SIZE, SEEK_SET);
> +start = ARECONT_H264_MIME_SIZE;
> +}
> +ret = avio_read_partial(s->pb, data, size);
> +if (ret < 0 || start >= ret) {
> +av_free(data);
> +av_packet_unref(pkt);
> +return ret;
> +}
Unfortunately I still have no idea what that code is meant to do.
First there is no point in allocating "data" when you have
pkt->data already (yes, it would mean using memmove instead
of memcpy later on, but that seems to be about it).
Then the code reads TWICE into the same buffer for some reason,
the first read seems completely pointless?
Also the only point of the _partial variant of the read function
is reducing latency, however the avio_seek is likely to be
quite a bad hit for latency that this really seems like
premature optimization.
Also the avio_seek means this demuxer might not work at all
if the stream is not seekable (might since I don't know
if we maybe do enough buffering nowadays - but if the code
relies on that there should be a check).
> +if ((j = arecont_find_sign(data + i, ret - i)) >= 0) {
Very personal dislike but:
please just don't put assignments into the if.
> +k = 0;
> +for (w = j + sign_size; w + 1 < ret; w++) {
So what exactly happens when you actually end up hitting
that loop end condition?
It seems to me you then just leave the whole thing in,
even though you should have removed it?
> +} else
> +break;
Inverting the condition and putting the 1-line case in the
"if" instead of the "else" is much better for readability.
In this case it also saves you 1 indentation level.
On the general approach:
you are scanning a whole, potentially many, many GB large video
file for a 8-character string.
A false positive has a REALLY high likelihood.
I think this needs to be changed into a more clever approach,
that actually knows where these strings can appear and removes
them in a more targeted way...
Best regards,
Reimar Döffinger
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/6] lavc/avpacket: check NULL before using the pointer
On Fri, May 10, 2019 at 10:00:54PM +0200, Carl Eugen Hoyos wrote:
> Am Fr., 10. Mai 2019 um 18:13 Uhr schrieb Jun Zhao :
> >
> > From: Jun Zhao
> >
> > Need to check NULL before using the pointer
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/avpacket.c |3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> > index 8f0603d..2b20067 100644
> > --- a/libavcodec/avpacket.c
> > +++ b/libavcodec/avpacket.c
> > @@ -522,11 +522,12 @@ fail:
> >
> > int av_packet_unpack_dictionary(const uint8_t *data, int size,
> > AVDictionary **dict)
> > {
> > -const uint8_t *end = data + size;
> > +const uint8_t *end;
> > int ret = 0;
> >
> > if (!dict || !data || !size)
> > return ret;
> > +end = data + size;
>
> Could somebody explain to me why this is necessary?
if data is NULL adding a non zero value to it would be undefined behavior
i think
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
There will always be a question for which you do not know the correct answer.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] lavf/mov: Fix timestamp rescale on sidx atom
On Thu, May 9, 2019 at 2:08 AM Jun Li wrote: > Fix #5090 > Fix the timestamp rescale issue, from sidx timebase to > stream's timebase. > --- > libavformat/mov.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/mov.c b/libavformat/mov.c > index 78f692872b..d058855e6c 100644 > --- a/libavformat/mov.c > +++ b/libavformat/mov.c > @@ -5017,7 +5017,7 @@ static int mov_read_sidx(MOVContext *c, AVIOContext > *pb, MOVAtom atom) > return AVERROR_PATCHWELCOME; > } > avio_rb32(pb); // sap_flags > -timestamp = av_rescale_q(pts, st->time_base, timescale); > +timestamp = av_rescale_q(pts, timescale, st->time_base); > > index = update_frag_index(c, offset); > frag_stream_info = get_frag_stream_info(&c->frag_index, index, > track_id); > -- > 2.17.1 > Ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/6] lavc/bink: Remove the dead code block
On Sat, May 11, 2019 at 12:05:51AM +0800, Jun Zhao wrote: > From: Jun Zhao > > Remove the dead code block > > Signed-off-by: Jun Zhao > --- > libavcodec/bink.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/bink.c b/libavcodec/bink.c > index 6673afa..d0f1b39 100644 > --- a/libavcodec/bink.c > +++ b/libavcodec/bink.c > @@ -1046,8 +1046,6 @@ static int bink_decode_plane(BinkContext *c, AVFrame > *frame, GetBitContext *gb, > if ((ret = read_runs(c->avctx, gb, &c->bundle[BINK_SRC_RUN])) < 0) > return ret; > > -if (by == bh) > -break; > dst = frame->data[plane_idx] + 8*by*stride; > prev = (c->last->data[plane_idx] ? c->last->data[plane_idx] > : frame->data[plane_idx]) + > 8*by*stride; > -- > 1.7.1 looks good. please apply. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] Add multiple padding method in dnn native
---
libavfilter/dnn_backend_native.c | 52
libavfilter/dnn_backend_native.h | 3 ++
2 files changed, 43 insertions(+), 12 deletions(-)
diff --git a/libavfilter/dnn_backend_native.c b/libavfilter/dnn_backend_native.c
index 06fbdf368b..171a756385 100644
--- a/libavfilter/dnn_backend_native.c
+++ b/libavfilter/dnn_backend_native.c
@@ -61,6 +61,12 @@ static DNNReturnType set_input_output_native(void *model,
DNNInputData *input, c
return DNN_ERROR;
}
cur_channels = conv_params->output_num;
+
+if(conv_params->padding_method == VALID){
+int pad_size = conv_params->kernel_size - 1;
+cur_height -= pad_size;
+cur_width -= pad_size;
+}
break;
case DEPTH_TO_SPACE:
depth_to_space_params = (DepthToSpaceParams
*)network->layers[layer].params;
@@ -77,6 +83,10 @@ static DNNReturnType set_input_output_native(void *model,
DNNInputData *input, c
if (network->layers[layer].output){
av_freep(&network->layers[layer].output);
}
+
+if(cur_height <= 0 || cur_width <= 0)
+return DNN_ERROR;
+
network->layers[layer].output = av_malloc(cur_height * cur_width *
cur_channels * sizeof(float));
if (!network->layers[layer].output){
return DNN_ERROR;
@@ -154,13 +164,14 @@ DNNModel *ff_dnn_load_model_native(const char
*model_filename)
ff_dnn_free_model_native(&model);
return NULL;
}
+conv_params->padding_method =
(int32_t)avio_rl32(model_file_context);
conv_params->activation = (int32_t)avio_rl32(model_file_context);
conv_params->input_num = (int32_t)avio_rl32(model_file_context);
conv_params->output_num = (int32_t)avio_rl32(model_file_context);
conv_params->kernel_size = (int32_t)avio_rl32(model_file_context);
kernel_size = conv_params->input_num * conv_params->output_num *
conv_params->kernel_size * conv_params->kernel_size;
-dnn_size += 16 + (kernel_size + conv_params->output_num << 2);
+dnn_size += 20 + (kernel_size + conv_params->output_num << 2);
if (dnn_size > file_size || conv_params->input_num <= 0 ||
conv_params->output_num <= 0 || conv_params->kernel_size <= 0){
avio_closep(&model_file_context);
@@ -218,23 +229,35 @@ DNNModel *ff_dnn_load_model_native(const char
*model_filename)
static void convolve(const float *input, float *output, const
ConvolutionalParams *conv_params, int width, int height)
{
-int y, x, n_filter, ch, kernel_y, kernel_x;
int radius = conv_params->kernel_size >> 1;
int src_linesize = width * conv_params->input_num;
int filter_linesize = conv_params->kernel_size * conv_params->input_num;
int filter_size = conv_params->kernel_size * filter_linesize;
+int pad_size = (conv_params->padding_method == VALID) ?
(conv_params->kernel_size - 1) / 2 : 0;
-for (y = 0; y < height; ++y){
-for (x = 0; x < width; ++x){
-for (n_filter = 0; n_filter < conv_params->output_num; ++n_filter){
+for (int y = pad_size; y < height - pad_size; ++y){
+for (int x = pad_size; x < width - pad_size; ++x){
+for (int n_filter = 0; n_filter < conv_params->output_num;
++n_filter){
output[n_filter] = conv_params->biases[n_filter];
-for (ch = 0; ch < conv_params->input_num; ++ch){
-for (kernel_y = 0; kernel_y < conv_params->kernel_size;
++kernel_y){
-for (kernel_x = 0; kernel_x <
conv_params->kernel_size; ++kernel_x){
-output[n_filter] += input[CLAMP_TO_EDGE(y +
kernel_y - radius, height) * src_linesize +
- CLAMP_TO_EDGE(x +
kernel_x - radius, width) * conv_params->input_num + ch] *
-conv_params->kernel[n_filter *
filter_size + kernel_y * filter_linesize +
-kernel_x *
conv_params->input_num + ch];
+
+for (int ch = 0; ch < conv_params->input_num; ++ch){
+for (int kernel_y = 0; kernel_y <
conv_params->kernel_size; ++kernel_y){
+for (int kernel_x = 0; kernel_x <
conv_params->kernel_size; ++kernel_x){
+float input_pel;
+if(conv_params->padding_method ==
SAME_CLAMP_TO_EDGE){
+int y_pos = CLAMP_TO_EDGE(y + kernel_y -
radius, height);
+int x_pos = CLAMP_TO_EDGE(x + kernel_x -
radius, width);
+input_pel = input[y_pos * src_linesize + x_pos
* conv_params->input_num + ch];
+
Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffmpeg: Add stream metadata from first frame's metadata
On Thu, May 9, 2019 at 1:52 AM Nicolas George wrote: > Jun Li (12019-05-06): > > I agree with it that the patch can't solve the case that "not all frames > > have the same orientation". > > The only way I can think of (correct me if I am wrong) is a filter that > > dynamic do tranformation per frame. > > > > From a technical perspective, this kind of media is absolutely possible. > > For example motion jpeg consists of jpg with different orientations. > > But I assume it is rare with my limited knowledge. What do you think? > > I think they can be quite common: imagine somebody trying to make a > slideshow from vacation photos. > > A filter that applies the transform on each frame based on the metadata > would be my first idea too. We already have the filter: the one that > does the transform right now. It needs to be adapter to change the > transform on a per-frame basis. That should be easy. > > But it is a bit harder than that: lavfi does not support real > reconfiguration of the stream properties. Therefore, this filter must be > added to the small list of "temporary" exceptions in the framework. And > the user will need to insert scale/pad/crop to normalize the output. > That needs to be documented. > Hi Nicolas, I think now I understand what you mean"lavfi does not support real reconfiguration of the stream properties. " Even we have a perfect filter for this case, we still have to dynamic turn on/off the filter per frame's metadata. Then I just wonder maybe we just need a function to rotate/flip the frame data, rather than using filter ? Do you mind sharing some advice ? Thanks -Jun Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v9] lavf/flv: Add XV (Xunlei Video) Support. fixes ticket #3720
On 11-05-2019 03:21, Reimar Döffinger wrote: > On 10.05.2019, at 15:10, Shivam Goyal wrote: > >> -> Making two avio contexts and one calling the other ( I am not sure if >> i implemented it in the right way, but still i reached low level ). > > Can't you at least figure out the header size, decrypt the header and pass > that to the normal header parsing code? I can get the header size. but the problem is with the first flv packet. which should be parsed by the flv_read_packet and which is taking AVFormatContaxt as argument and reads from the file with avio* functions. > Even if not, I'd at least suggest changing the code from reading bytewise and > applying rot > to reading all 8 bytes in a buffer, use a loop to apply rot and then the > standard AV_RL functions to read the 32 and 24 bit values. If i understood correctly, i think this is exactly the same approach which i already took in decrypting the filled buffer. but the code become low level because it modifies the buffer, which a demuxer should not do. Thanks for the review Shivam Goyal ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42
On Fri, 10 May 2019 10:08:57 -0700 Philip Langdale wrote: > On 2019-05-10 08:12, Lauri Kasanen wrote: > > On Fri, 10 May 2019 08:07:45 -0700 > > Philip Langdale wrote: > > > >> On Fri, 10 May 2019 09:35:40 +0300 > >> Lauri Kasanen wrote: > >> > >> > > >> > I'm having trouble making out what formats exactly isSemiPlanarYUV() > >> > matches. Are you sure it's an equivalent check? > >> > > >> > >> Well, the check's been in there for quite a while; that's not new. > >> > >> (isPlanarYUV(pix_fmt) && desc->comp[1].plane == desc->comp[2].plane); > >> > >> So, any planar yuv format where component 1 and component 2 are on the > >> same plane. Except for semi planar formats, you expect either all > >> components on the same plane (packed, so not planar) or every > >> component > >> on a separate plain (normal planar). > > > > Yes, I understand that. I mean: can you list all formats that function > > matches? > > For formats that swscale understands: > > NV12, NV21 > P010(BE|LE) > P016(BE|LE) > > and now NV24, NV42. > > There are also NV16 and NV20(BE|LE) formats which are not supported by > swscale. Thanks. Then the ppc part looks ok to me. Please include that list in the commit message too. - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
