Re: [FFmpeg-devel] Motion interpolation in libavfilter
On 3/8/16, Subhashish Pradhan wrote: > Hello, > > I am Subhashish Pradhan, a CS undergrad from India. I want to take up the > project "Motion interpolation in libavfilter" for GSoC 2016 and I'd like to > understand the goals for this project. Goals are already written on wiki, if you have more specific questions ask them. > > This would help me dive into the code with an idea of what I'm supposed to > do for the qualification task. You do basic motion estimation filter, again, if you have more specific questions ask them. > > Hoping for the best, > Subhashish Pradhan > ___ > 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]lavc/mjpegdec: Set sar for multiscope videos
Hi!
Attached patch fixes the samples in
samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4535 for me.
Please comment, Carl Eugen
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 1e83e88..e24db44 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1878,8 +1878,10 @@ static int mjpeg_decode_com(MJpegDecodeContext *s)
else if ((!strncmp(cbuf, "Intel(R) JPEG Library, version 1", 32)
&& s->avctx->codec_tag) ||
(!strncmp(cbuf, "Metasoft MJPEG Codec", 20)))
s->flipped = 1;
-else if (!strcmp(cbuf, "MULTISCOPE II"))
+else if (!strcmp(cbuf, "MULTISCOPE II")) {
+s->avctx->sample_aspect_ratio = (AVRational) { 1, 2 };
s->multiscope = 2;
+}
av_free(cbuf);
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
Forget the old one. Refactored some variables to more appropriate
locations as well.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 766dc9c46ed9d528d41505f8b67e18ef261f8f0e Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Tue, 8 Mar 2016 11:26:32 +0100
Subject: [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
---
libavformat/avienc.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 357dd34..ad50379 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -656,13 +656,8 @@ static int write_skip_frames(AVFormatContext *s, int stream_index, int64_t dts)
static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
{
-unsigned char tag[5];
const int stream_index = pkt->stream_index;
-AVIOContext *pb = s->pb;
AVCodecContext *enc = s->streams[stream_index]->codec;
-AVIStream *avist= s->streams[stream_index]->priv_data;
-AVPacket *opkt = pkt;
-enum AVPixelFormat pix_fmt = enc->pix_fmt;
int ret;
if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) {
@@ -678,6 +673,9 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
return avi_write_packet_internal(s, pkt); /* Passthrough */
if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+AVIStream *avist = s->streams[stream_index]->priv_data;
+AVIOContext *pb = s->pb;
+AVPacket *opkt = pkt;
if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
@@ -686,11 +684,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
return ret;
} else
ret = 0;
-if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
-pix_fmt = AV_PIX_FMT_MONOWHITE;
-if (pix_fmt == AV_PIX_FMT_PAL8 ||
-pix_fmt == AV_PIX_FMT_MONOWHITE ||
-pix_fmt == AV_PIX_FMT_MONOBLACK) {
+if (enc->pix_fmt == AV_PIX_FMT_PAL8) {
int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
if (ret2 < 0)
return ret2;
@@ -712,6 +706,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
avist->pal_offset = 0;
}
if (memcmp(avist->palette, avist->old_palette, pal_size * 4)) {
+unsigned char tag[5];
avi_stream2fourcc(tag, stream_index, enc->codec_type);
tag[2] = 'p'; tag[3] = 'c';
pc_tag = ff_start_tag(pb, tag);
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
On 03/08/2016 11:42 AM, Mats Peterson wrote: Forget the old one. Refactored some variables to more appropriate locations as well. And forget the old 2-part patch set with the avi_write_xxpc() function. It would only be used once, so it was superfluous. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] lavf/avienc: New AVOption write_keyframe_palette
Here's a somewhat experimental patch with a new AVOption
write_keyframe_palette that allows you to write the palette to every
keyframe. It is disabled by default, but it is needed for any file that
contains palette changes in order to switch palette properly in FFplay
(and, in the future, probably MPlayer, unless it manages to solve it in
a different way).
It's interesting to note that Windows Media Player doesn't need xxpc
chunks at keyframes in order to seek properly in the original file
TOON.AVI below from Sierra's King's Quest VI. I have of course no idea
how they solve that.
This file doesn't work properly in FFplay for some reason. It generates
"stream_ptr out of bounds" messages at the locations of the xxpc chunks.
It seems it has something to do with the index, since if I copy it to a
new file with the last part cut off (incorrect but it will play at
least), those "stream_ptr out of bounds" messages will disappear, and
the palette changes will occur as expected.
TOON.AVI:
https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 6440fffa2d5b7f8b354c6307baaf506cbe754609 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Tue, 8 Mar 2016 11:37:34 +0100
Subject: [PATCH 2/2] lavf/avienc: New AVOption write_keyframe_palette
---
libavformat/avienc.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..2367d80 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -66,6 +66,7 @@ typedef struct AVIContext {
int64_t frames_hdr_all;
int riff_id;
int write_channel_mask;
+int write_keyframe_palette;
} AVIContext;
typedef struct AVIStream {
@@ -674,6 +675,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
AVIStream *avist = s->streams[stream_index]->priv_data;
+AVIContext *avi = s->priv_data;
AVIOContext *pb = s->pb;
AVPacket *opkt = pkt;
if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
@@ -688,13 +690,13 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
if (ret2 < 0)
return ret2;
-if (ret2) {
+if (ret2 || (avi->write_keyframe_palette && (pkt->flags & AV_PKT_FLAG_KEY))) {
int pal_size = 1 << enc->bits_per_coded_sample;
int pc_tag, i;
av_assert0(enc->bits_per_coded_sample >= 0 && enc->bits_per_coded_sample <= 8);
-if (pb->seekable && avist->pal_offset) {
+if (ret2 && pb->seekable && avist->pal_offset) {
int64_t cur_offset = avio_tell(pb);
avio_seek(pb, avist->pal_offset, SEEK_SET);
for (i = 0; i < pal_size; i++) {
@@ -705,7 +707,8 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
memcpy(avist->old_palette, avist->palette, pal_size * 4);
avist->pal_offset = 0;
}
-if (memcmp(avist->palette, avist->old_palette, pal_size * 4)) {
+if (memcmp(avist->palette, avist->old_palette, pal_size * 4) ||
+(avi->write_keyframe_palette && (pkt->flags & AV_PKT_FLAG_KEY))) {
unsigned char tag[5];
avi_stream2fourcc(tag, stream_index, enc->codec_type);
tag[2] = 'p'; tag[3] = 'c';
@@ -875,6 +878,7 @@ static int avi_write_trailer(AVFormatContext *s)
#define ENC AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
{ "write_channel_mask", "write channel mask into wave format header", OFFSET(write_channel_mask), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, ENC },
+{ "write_keyframe_palette", "write palette at keyframes", OFFSET(write_keyframe_palette), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
{ NULL },
};
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] GSOC
Hey, I'd like to work on the Project to implement missing AAC decoder features as a part of GSOC'16. This project has been listed under unmentored projects. So I'm looking for somebody to mentor me if possible. Also, can I directly start working to fix a bug on AAC issues or will I be assigned a qualification task by my mentor. Regards, Arth Patel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
On Tue, Mar 08, 2016 at 11:42:48AM +0100, Mats Peterson wrote: > Forget the old one. Refactored some variables to more appropriate > locations as well. > > Mats > > -- > Mats Peterson > http://matsp888.no-ip.org/~mats/ > avienc.c | 15 +-- > 1 file changed, 5 insertions(+), 10 deletions(-) > 6636f641c269c2365e65007213c143a3426e325c > 0001-lavf-avienc-Palette-changing-code-only-concerns-AV_P.patch > From 766dc9c46ed9d528d41505f8b67e18ef261f8f0e Mon Sep 17 00:00:00 2001 > From: Mats Peterson > Date: Tue, 8 Mar 2016 11:26:32 +0100 > Subject: [PATCH 1/2] lavf/avienc: Palette changing code only concerns > AV_PIX_FMT_PAL8 are pcXX chunks forbidden for other cases ? i mean 4bits per sample and such ? i dont see anything in the spec saying so, but it quite possibly might be [...] -- 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 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
On 03/08/2016 12:51 PM, Michael Niedermayer wrote: On Tue, Mar 08, 2016 at 11:42:48AM +0100, Mats Peterson wrote: Forget the old one. Refactored some variables to more appropriate locations as well. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ avienc.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) 6636f641c269c2365e65007213c143a3426e325c 0001-lavf-avienc-Palette-changing-code-only-concerns-AV_P.patch From 766dc9c46ed9d528d41505f8b67e18ef261f8f0e Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Tue, 8 Mar 2016 11:26:32 +0100 Subject: [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8 are pcXX chunks forbidden for other cases ? i mean 4bits per sample and such ? i dont see anything in the spec saying so, but it quite possibly might be [...] No, they are allowed. But those bit depths will use AV_PIX_FMT_PAL8 in FFmpeg, since that's currently the only palettized mode. AV_PIX_FMT_MONOWHITE/MONOBLACK won't have a palette, so it's unnecessary to enter the block for these pixel formats. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
On 03/08/2016 12:54 PM, Mats Peterson wrote: On 03/08/2016 12:51 PM, Michael Niedermayer wrote: On Tue, Mar 08, 2016 at 11:42:48AM +0100, Mats Peterson wrote: Forget the old one. Refactored some variables to more appropriate locations as well. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ avienc.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) 6636f641c269c2365e65007213c143a3426e325c 0001-lavf-avienc-Palette-changing-code-only-concerns-AV_P.patch From 766dc9c46ed9d528d41505f8b67e18ef261f8f0e Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Tue, 8 Mar 2016 11:26:32 +0100 Subject: [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8 are pcXX chunks forbidden for other cases ? i mean 4bits per sample and such ? i dont see anything in the spec saying so, but it quite possibly might be [...] No, they are allowed. But those bit depths will use AV_PIX_FMT_PAL8 in FFmpeg, since that's currently the only palettized mode. AV_PIX_FMT_MONOWHITE/MONOBLACK won't have a palette, so it's unnecessary to enter the block for these pixel formats. I'm only writing 1 << bits_per_coded_sample entries to the file, although it will currently be exclusively 8. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
On 03/08/2016 12:56 PM, Mats Peterson wrote: I'm only writing 1 << bits_per_coded_sample entries to the file, although it will currently be exclusively 8. The bit depth, that is. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
On 03/08/2016 12:58 PM, Mats Peterson wrote: On 03/08/2016 12:56 PM, Mats Peterson wrote: I'm only writing 1 << bits_per_coded_sample entries to the file, although it will currently be exclusively 8. The bit depth, that is. No, that's probably wrong of me. On stream copy, the bit depth will be the same as the source bit depth, but the pixel format will be AV_PIX_FMT_PAL8. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
On 03/08/2016 01:01 PM, Mats Peterson wrote: On 03/08/2016 12:58 PM, Mats Peterson wrote: On 03/08/2016 12:56 PM, Mats Peterson wrote: I'm only writing 1 << bits_per_coded_sample entries to the file, although it will currently be exclusively 8. The bit depth, that is. No, that's probably wrong of me. On stream copy, the bit depth will be the same as the source bit depth, but the pixel format will be AV_PIX_FMT_PAL8. Mats It's not only *probably* wrong, it *is* wrong. I just stream copied a 4 bpp file. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: New AVOption write_keyframe_palette
On 03/08/2016 11:47 AM, Mats Peterson wrote: Here's a somewhat experimental patch with a new AVOption write_keyframe_palette that allows you to write the palette to every keyframe. It is disabled by default, but it is needed for any file that contains palette changes in order to switch palette properly in FFplay (and, in the future, probably MPlayer, unless it manages to solve it in a different way). It's interesting to note that Windows Media Player doesn't need xxpc chunks at keyframes in order to seek properly in the original file TOON.AVI below from Sierra's King's Quest VI. I have of course no idea how they solve that. In this context, it would be interesting to know whether there's some way to detect the strh flag AVISF_VIDEO_PALCHANGES in the demuxer, and transfer the state to the muxer? Is there any type of global area in FFmpeg where this state could be recorded? Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/avienc: New AVOption write_keyframe_palette
Hi Mats, On Mon, Mar 7, 2016 at 8:59 PM, Mats Peterson < matsp888-at-yahoo@ffmpeg.org> wrote: > On 03/07/2016 07:48 PM, Mats Peterson wrote: > >> On 03/07/2016 07:43 PM, Mats Peterson wrote: >> >>> Here's a somewhat experimental patch with a new AVOption >>> write_keyframe_palette that allows you to write the palette to every >>> keyframe. It is disabled by default, but it is needed for any file that >>> contains palette changes. >>> >>> >> It is needed in order to switch palette properly when seeking, that is. >> >> > It's interesting to note that Windows Media Player doesn't need xxpc > chunks at keyframes in order to seek properly in the following original > file from Sierra's King's Quest VI. I have of course no idea how they solve > that. > > This original file doesn't work properly in FFplay for some reason. It > generates "stream_ptr out of bounds" messages at the locations of the xxpc > chunks. > > File: > https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU Please don't wrote so many messages in response to yourself. If you want, I can look at the file. My assumption is that it either indexes or otherwise caches the xxpc chunks so it knows what the last xxpc before-or-on each keyframe seekpoint is. That should be trivial to do in our demuxer also. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/avienc: New AVOption write_keyframe_palette
On 03/08/2016 01:43 PM, Ronald S. Bultje wrote: Hi Mats, On Mon, Mar 7, 2016 at 8:59 PM, Mats Peterson < matsp888-at-yahoo@ffmpeg.org> wrote: On 03/07/2016 07:48 PM, Mats Peterson wrote: On 03/07/2016 07:43 PM, Mats Peterson wrote: Here's a somewhat experimental patch with a new AVOption write_keyframe_palette that allows you to write the palette to every keyframe. It is disabled by default, but it is needed for any file that contains palette changes. It is needed in order to switch palette properly when seeking, that is. It's interesting to note that Windows Media Player doesn't need xxpc chunks at keyframes in order to seek properly in the following original file from Sierra's King's Quest VI. I have of course no idea how they solve that. This original file doesn't work properly in FFplay for some reason. It generates "stream_ptr out of bounds" messages at the locations of the xxpc chunks. File: https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU Please don't wrote so many messages in response to yourself. If you want, I can look at the file. My assumption is that it either indexes or otherwise caches the xxpc chunks so it knows what the last xxpc before-or-on each keyframe seekpoint is. That should be trivial to do in our demuxer also. Ronald ___ It would be nice if you could have a look at it, Ronald, when you have the time for it. Yes, I suppose the xxpc chunks might perhaps be indexed. In any case, it currently won't play correctly in FFplay. I'll try to limit my messages (I have said it before, but I'm fully aware of this problem). Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Use lowercase includes and library names for schannel check
This fixes cross-build on Linux with mingw-w64. Patch attached. This
will not break MSVC because Windows is case-insensitive unlike Linux.
Please review.
Regards,
ismail
From e30470da6c21bb57c2a067660c613356cdbf6b92 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C4=B0smail=20D=C3=B6nmez?=
Date: Tue, 8 Mar 2016 14:45:16 +0200
Subject: [PATCH] Use lowercase includes/library names for schannel check.
Fixes cross-build on Linux with mingw-w64.
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 3299b1b..03906fb 100755
--- a/configure
+++ b/configure
@@ -5769,8 +5769,8 @@ disabled securetransport || { check_func SecIdentityCreate "-Wl,-framework,CoreF
check_lib2 "Security/SecureTransport.h Security/Security.h" "SSLCreateContext SecItemImport" "-Wl,-framework,CoreFoundation -Wl,-framework,Security" &&
enable securetransport; }
-disabled schannel || { check_func_headers "windows.h Security.h" InitializeSecurityContext -DSECURITY_WIN32 -lSecur32 &&
- enable schannel && add_extralibs -lSecur32; }
+disabled schannel || { check_func_headers "windows.h security.h" InitializeSecurityContext -DSECURITY_WIN32 -lsecur32 &&
+ enable schannel && add_extralibs -lsecur32; }
makeinfo --version > /dev/null 2>&1 && enable makeinfo || disable makeinfo
enabled makeinfo \
--
2.7.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/avienc: New AVOption write_keyframe_palette
On 03/08/2016 01:44 PM, Mats Peterson wrote: On 03/08/2016 01:43 PM, Ronald S. Bultje wrote: Hi Mats, On Mon, Mar 7, 2016 at 8:59 PM, Mats Peterson < matsp888-at-yahoo@ffmpeg.org> wrote: On 03/07/2016 07:48 PM, Mats Peterson wrote: On 03/07/2016 07:43 PM, Mats Peterson wrote: Here's a somewhat experimental patch with a new AVOption write_keyframe_palette that allows you to write the palette to every keyframe. It is disabled by default, but it is needed for any file that contains palette changes. It is needed in order to switch palette properly when seeking, that is. It's interesting to note that Windows Media Player doesn't need xxpc chunks at keyframes in order to seek properly in the following original file from Sierra's King's Quest VI. I have of course no idea how they solve that. This original file doesn't work properly in FFplay for some reason. It generates "stream_ptr out of bounds" messages at the locations of the xxpc chunks. File: https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU Please don't wrote so many messages in response to yourself. If you want, I can look at the file. My assumption is that it either indexes or otherwise caches the xxpc chunks so it knows what the last xxpc before-or-on each keyframe seekpoint is. That should be trivial to do in our demuxer also. Ronald ___ It would be nice if you could have a look at it, Ronald, when you have the time for it. Yes, I suppose the xxpc chunks might perhaps be indexed. In any case, it currently won't play correctly in FFplay. I'll try to limit my messages (I have said it before, but I'm fully aware of this problem). Mats ___ The xxpc chunks are indexed alright. I checked the index in the file. Why FFplay will barf on it is another question. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/avienc: New AVOption write_keyframe_palette
Hi, On Tue, Mar 8, 2016 at 7:48 AM, Mats Peterson < matsp888-at-yahoo@ffmpeg.org> wrote: > On 03/08/2016 01:44 PM, Mats Peterson wrote: > >> On 03/08/2016 01:43 PM, Ronald S. Bultje wrote: >> >>> Hi Mats, >>> >>> On Mon, Mar 7, 2016 at 8:59 PM, Mats Peterson < >>> matsp888-at-yahoo@ffmpeg.org> wrote: >>> >>> On 03/07/2016 07:48 PM, Mats Peterson wrote: On 03/07/2016 07:43 PM, Mats Peterson wrote: > > Here's a somewhat experimental patch with a new AVOption >> write_keyframe_palette that allows you to write the palette to every >> keyframe. It is disabled by default, but it is needed for any file >> that >> contains palette changes. >> >> >> It is needed in order to switch palette properly when seeking, that > is. > > > It's interesting to note that Windows Media Player doesn't need xxpc chunks at keyframes in order to seek properly in the following original file from Sierra's King's Quest VI. I have of course no idea how they solve that. This original file doesn't work properly in FFplay for some reason. It generates "stream_ptr out of bounds" messages at the locations of the xxpc chunks. File: https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU >>> >>> >>> Please don't wrote so many messages in response to yourself. >>> >>> If you want, I can look at the file. My assumption is that it either >>> indexes or otherwise caches the xxpc chunks so it knows what the last >>> xxpc >>> before-or-on each keyframe seekpoint is. That should be trivial to do in >>> our demuxer also. >>> >>> Ronald >>> ___ >>> >> >> It would be nice if you could have a look at it, Ronald, when you have >> the time for it. Yes, I suppose the xxpc chunks might perhaps be >> indexed. In any case, it currently won't play correctly in FFplay. I'll >> try to limit my messages (I have said it before, but I'm fully aware of >> this problem). >> >> Mats >> >> ___ >> > > The xxpc chunks are indexed alright. I checked the index in the file. Why > FFplay will barf on it is another question. It's probably simply not aware that such index chunks are valid. Check libavformat/avidec.c and add relevant code to index parsing (on read_header) and index usage (on seek) there. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/avienc: New AVOption write_keyframe_palette
On 03/08/2016 02:06 PM, Ronald S. Bultje wrote: Hi, On Tue, Mar 8, 2016 at 7:48 AM, Mats Peterson < matsp888-at-yahoo@ffmpeg.org> wrote: On 03/08/2016 01:44 PM, Mats Peterson wrote: On 03/08/2016 01:43 PM, Ronald S. Bultje wrote: Hi Mats, On Mon, Mar 7, 2016 at 8:59 PM, Mats Peterson < matsp888-at-yahoo@ffmpeg.org> wrote: On 03/07/2016 07:48 PM, Mats Peterson wrote: On 03/07/2016 07:43 PM, Mats Peterson wrote: Here's a somewhat experimental patch with a new AVOption write_keyframe_palette that allows you to write the palette to every keyframe. It is disabled by default, but it is needed for any file that contains palette changes. It is needed in order to switch palette properly when seeking, that is. It's interesting to note that Windows Media Player doesn't need xxpc chunks at keyframes in order to seek properly in the following original file from Sierra's King's Quest VI. I have of course no idea how they solve that. This original file doesn't work properly in FFplay for some reason. It generates "stream_ptr out of bounds" messages at the locations of the xxpc chunks. File: https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU Please don't wrote so many messages in response to yourself. If you want, I can look at the file. My assumption is that it either indexes or otherwise caches the xxpc chunks so it knows what the last xxpc before-or-on each keyframe seekpoint is. That should be trivial to do in our demuxer also. Ronald ___ It would be nice if you could have a look at it, Ronald, when you have the time for it. Yes, I suppose the xxpc chunks might perhaps be indexed. In any case, it currently won't play correctly in FFplay. I'll try to limit my messages (I have said it before, but I'm fully aware of this problem). Mats ___ The xxpc chunks are indexed alright. I checked the index in the file. Why FFplay will barf on it is another question. It's probably simply not aware that such index chunks are valid. Check libavformat/avidec.c and add relevant code to index parsing (on read_header) and index usage (on seek) there. Ronald ___ That was my thought too. It would probably be sensible to index xxpc chunks in the muxer as well. Thanks, anyway. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
On 03/08/2016 11:42 AM, Mats Peterson wrote: Forget the old one. Refactored some variables to more appropriate locations as well. Even if you won't apply patch 2/2, please apply this one. It's a no-brainer. The same logic checking for AV_PIX_FMT_PAL8 only is already used in movenc.c. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: add performance debugging log
On Sun, Mar 6, 2016 at 5:01 PM, Muhammad Faiz wrote: > for easier development > > Signed-off-by: Muhammad Faiz > --- > libavfilter/avf_showcqt.c | 64 > +++ > libavfilter/avf_showcqt.h | 9 +++ > 2 files changed, 68 insertions(+), 5 deletions(-) > applied thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/mjpegdec: avoid printing useless message in default log level
The change of bps from 0 doesn't contain any info useful to the
user. This message is now at info log level only if the original
value is !=0, otherwise pushed back to debug log level. The
original value is displayed additionally.
Signed-off-by: Moritz Barsnick
---
libavcodec/mjpegdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 1e83e88..3e4b6f0 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -282,7 +282,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
if (s->avctx->bits_per_raw_sample != bits) {
-av_log(s->avctx, AV_LOG_INFO, "Changing bps to %d\n", bits);
+av_log(s->avctx, s->avctx->bits_per_raw_sample > 0 ? AV_LOG_INFO :
AV_LOG_DEBUG, "Changing bps from %d to %d\n", s->avctx->bits_per_raw_sample,
bits);
s->avctx->bits_per_raw_sample = bits;
init_idct(s->avctx);
}
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/mp3dec: avoid printing useless message in default log level
"Skipping 0 bytes of junk" is useless to the user, and essentially
indicates a NOP. At 0 bytes, this message is now pushed back to
the debug log level.
Signed-off-by: Moritz Barsnick
---
libavformat/mp3dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index adc3d2a..2caf78b 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -388,7 +388,7 @@ static int mp3_read_header(AVFormatContext *s)
if (ret >= 0 &&
(header & SAME_HEADER_MASK) == (header2 & SAME_HEADER_MASK))
{
-av_log(s, AV_LOG_INFO, "Skipping %d bytes of junk at
%"PRId64".\n", i, off);
+av_log(s, i > 0 ? AV_LOG_INFO : AV_LOG_DEBUG, "Skipping %d
bytes of junk at %"PRId64".\n", i, off);
ret = avio_seek(s->pb, off + i, SEEK_SET);
if (ret < 0)
return ret;
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
On Tue, Mar 08, 2016 at 11:42:48AM +0100, Mats Peterson wrote: > Forget the old one. Refactored some variables to more appropriate > locations as well. > > Mats > > -- > Mats Peterson > http://matsp888.no-ip.org/~mats/ > avienc.c | 15 +-- > 1 file changed, 5 insertions(+), 10 deletions(-) > 6636f641c269c2365e65007213c143a3426e325c > 0001-lavf-avienc-Palette-changing-code-only-concerns-AV_P.patch > From 766dc9c46ed9d528d41505f8b67e18ef261f8f0e Mon Sep 17 00:00:00 2001 > From: Mats Peterson > Date: Tue, 8 Mar 2016 11:26:32 +0100 > Subject: [PATCH 1/2] lavf/avienc: Palette changing code only concerns > AV_PIX_FMT_PAL8 applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. 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/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8
On 03/08/2016 03:28 PM, Michael Niedermayer wrote: On Tue, Mar 08, 2016 at 11:42:48AM +0100, Mats Peterson wrote: Forget the old one. Refactored some variables to more appropriate locations as well. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ avienc.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) 6636f641c269c2365e65007213c143a3426e325c 0001-lavf-avienc-Palette-changing-code-only-concerns-AV_P.patch From 766dc9c46ed9d528d41505f8b67e18ef261f8f0e Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Tue, 8 Mar 2016 11:26:32 +0100 Subject: [PATCH 1/2] lavf/avienc: Palette changing code only concerns AV_PIX_FMT_PAL8 applied thanks Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: avoid printing useless message in default log level
On Tue, 8 Mar 2016 15:36:06 +0100
Moritz Barsnick wrote:
> "Skipping 0 bytes of junk" is useless to the user, and essentially
> indicates a NOP. At 0 bytes, this message is now pushed back to
> the debug log level.
>
> Signed-off-by: Moritz Barsnick
> ---
> libavformat/mp3dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index adc3d2a..2caf78b 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -388,7 +388,7 @@ static int mp3_read_header(AVFormatContext *s)
> if (ret >= 0 &&
> (header & SAME_HEADER_MASK) == (header2 & SAME_HEADER_MASK))
> {
> -av_log(s, AV_LOG_INFO, "Skipping %d bytes of junk at
> %"PRId64".\n", i, off);
> +av_log(s, i > 0 ? AV_LOG_INFO : AV_LOG_DEBUG, "Skipping %d
> bytes of junk at %"PRId64".\n", i, off);
> ret = avio_seek(s->pb, off + i, SEEK_SET);
> if (ret < 0)
> return ret;
AV_LOG_INFO is effectively a verbose level anyway, because FFmpeg
prints a lot of stuff at level INFO, so I'm not sure how useful it is.
But AV_LOG_LEVEL_DEBUG should definitely be replaced with
AV_LOG_LEVEL_VERBOSE.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] TOON.AVI not playing correctly with FFplay
Perhaps you could fix the index parsing of this file, Michael? It's clearly over my head. It's a file with xxpc chunks from Sierra's King's Quest VI, and it plays fine with Windows Media Player. It has the xxpc chunks indexed, and somehow the demuxer will barf on them. File: https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] TOON.AVI not playing correctly with FFplay
On 03/08/2016 03:55 PM, Mats Peterson wrote: Perhaps you could fix the index parsing of this file, Michael? It's clearly over my head. It's a file with xxpc chunks from Sierra's King's Quest VI, and it plays fine with Windows Media Player. It has the xxpc chunks indexed, and somehow the demuxer will barf on them. File: https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU Mats Ronald, you are welcome as well, or anyone who feels interested enough in fixing this index parsing stuff in lavf/avidec.c. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: avoid printing useless message in default log level
On Tue, Mar 08, 2016 at 15:53:15 +0100, wm4 wrote: > AV_LOG_INFO is effectively a verbose level anyway, because FFmpeg > prints a lot of stuff at level INFO, so I'm not sure how useful it is. It is verbose, but it's the default, and has recently been cluttered with this confusing information. I just meant to continue to provide the information, just not at default. > But AV_LOG_LEVEL_DEBUG should definitely be replaced with > AV_LOG_LEVEL_VERBOSE. Ah, indeed, big fail by me. I personally use loglevel debug too often... AV_LOG_LEVEL_VERBOSE is what I meant. Will fix. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSOC
On Tue, Mar 08, 2016 at 05:07:04PM +0530, Arth Patel wrote: > Hey, > > I'd like to work on the Project to implement missing AAC decoder > features as a part > of GSOC'16. This project has been listed under unmentored projects. So > I'm looking for somebody to mentor me if possible. > > Also, can I directly start working to fix a bug on AAC issues or will > I be assigned a > qualification task by my mentor. for the record, this was awnsered by durandal and others on IRC [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- 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] lavc/mjpegdec: avoid printing useless message in default log level
On Tue, Mar 08, 2016 at 03:36:27PM +0100, Moritz Barsnick wrote: > The change of bps from 0 doesn't contain any info useful to the > user. This message is now at info log level only if the original > value is !=0, otherwise pushed back to debug log level. The > original value is displayed additionally. > > Signed-off-by: Moritz Barsnick > --- > libavcodec/mjpegdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] lavf/mp3dec: avoid printing useless message in default log level
"Skipping 0 bytes of junk" is useless to the user, and essentially
indicates a NOP. At 0 bytes, this message is now pushed back to
the verbose log level.
Signed-off-by: Moritz Barsnick
---
libavformat/mp3dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index adc3d2a..672d643 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -388,7 +388,7 @@ static int mp3_read_header(AVFormatContext *s)
if (ret >= 0 &&
(header & SAME_HEADER_MASK) == (header2 & SAME_HEADER_MASK))
{
-av_log(s, AV_LOG_INFO, "Skipping %d bytes of junk at
%"PRId64".\n", i, off);
+av_log(s, i > 0 ? AV_LOG_INFO : AV_LOG_VERBOSE, "Skipping %d
bytes of junk at %"PRId64".\n", i, off);
ret = avio_seek(s->pb, off + i, SEEK_SET);
if (ret < 0)
return ret;
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] lavc/mjpegdec: avoid printing useless message in default log level
The change of bps from 0 doesn't contain any useful information.
This message is now at info log level only if the original value
is !=0, otherwise pushed back to verbose log level. The original
value is displayed additionally.
Signed-off-by: Moritz Barsnick
---
libavcodec/mjpegdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 1e83e88..000d90c 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -282,7 +282,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
if (s->avctx->bits_per_raw_sample != bits) {
-av_log(s->avctx, AV_LOG_INFO, "Changing bps to %d\n", bits);
+av_log(s->avctx, s->avctx->bits_per_raw_sample > 0 ? AV_LOG_INFO :
AV_LOG_VERBOSE, "Changing bps from %d to %d\n", s->avctx->bits_per_raw_sample,
bits);
s->avctx->bits_per_raw_sample = bits;
init_idct(s->avctx);
}
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavc/mjpegdec: avoid printing useless message in default log level
On Tue, Mar 08, 2016 at 16:55:02 +0100, Moritz Barsnick wrote: > The change of bps from 0 doesn't contain any useful information. > This message is now at info log level only if the original value > is !=0, otherwise pushed back to verbose log level. The original > value is displayed additionally. Sorry, v2 came too late, after wm4's remark. Perhaps fine either way. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavf/mp3dec: avoid printing useless message in default log level
On Tue, 8 Mar 2016 16:54:42 +0100
Moritz Barsnick wrote:
> "Skipping 0 bytes of junk" is useless to the user, and essentially
> indicates a NOP. At 0 bytes, this message is now pushed back to
> the verbose log level.
>
> Signed-off-by: Moritz Barsnick
> ---
> libavformat/mp3dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index adc3d2a..672d643 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -388,7 +388,7 @@ static int mp3_read_header(AVFormatContext *s)
> if (ret >= 0 &&
> (header & SAME_HEADER_MASK) == (header2 & SAME_HEADER_MASK))
> {
> -av_log(s, AV_LOG_INFO, "Skipping %d bytes of junk at
> %"PRId64".\n", i, off);
> +av_log(s, i > 0 ? AV_LOG_INFO : AV_LOG_VERBOSE, "Skipping %d
> bytes of junk at %"PRId64".\n", i, off);
> ret = avio_seek(s->pb, off + i, SEEK_SET);
> if (ret < 0)
> return ret;
Applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] TOON.AVI not playing correctly with FFplay
Hi, On Tue, Mar 8, 2016 at 10:21 AM, Mats Peterson < matsp888-at-yahoo@ffmpeg.org> wrote: > On 03/08/2016 03:55 PM, Mats Peterson wrote: > >> Perhaps you could fix the index parsing of this file, Michael? It's >> clearly over my head. It's a file with xxpc chunks from Sierra's King's >> Quest VI, and it plays fine with Windows Media Player. It has the xxpc >> chunks indexed, and somehow the demuxer will barf on them. >> >> File: >> https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU >> >> Mats >> >> > Ronald, you are welcome as well, or anyone who feels interested enough in > fixing this index parsing stuff in lavf/avidec.c. Again, please don't send the same message (responding to yourself) multiple times in such short time frames. Please file a bug on trac with this sample attached, if it doesn't exist already. When anyone has time, we'll get to it. There's no need rushing, this stuff tends to take time. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: build fix for P5600 with mips code restructuring
On Mon, Mar 07, 2016 at 07:49:10PM +0530, shivraj.pa...@imgtec.com wrote: > From: Shivraj Patil > > Signed-off-by: Shivraj Patil > --- > configure | 312 > +++-- > 1 file changed, 117 insertions(+), 195 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Set sar for multiscope videos
On Tue, Mar 08, 2016 at 10:41:03AM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes the samples in > samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4535 for me. > > Please comment, Carl Eugen > mjpegdec.c |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > 88ce4aaf4530ae0442cb76b6659bec1332c9e5a8 patchmultiscopesar.diff > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Subtitles for GSoC
Hello, my own ideas seems not to be suitable for GSoC, so I looked again on the ideas page, because I have high interest to do something for FFmpeg this summer. The project, that I find most interesting, unfortunately is a unmentored one, the subtitle support. Is someone willing to mentor this? On the ideas page the mentioned subtitle for the qualification task is Spruce subtitle. It seems, it is already supported, so I would try to implement the corepart of usf. I know it is not widely used, but very powerful with similar features as SSA, if I get it right. Do you think, that is suitable? And then another question. You mentioned as ultimate goal the libavfilter integration. If I get it right, ATM no rendering is implemented, and libavfilter would allow an (automatic) rendering from SSA to e.g. dvdsub. Would the rendering itself part of the project (because this is very extensive, I think)? regards, Gerion ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] "OPAtom misinterpreted as OP1a"
Hi,
I have an MXF file (originally generated from Avid Media Composer I
believe) on which ffmpeg fails to correctly read the second audio track.
The file is called test_Stereo.mxf and has two audio channels: on 0:a:0
there are 5s of tone, then 5s silence, then 5s tone, then 5s silence,
while 0:a:1 is reversed (5s of silence then 5s of tone). Outputting
0:a:0 gives a 1kHz tone as expected but 0:a:1 gives a file that is
shorter than expected and sounds garbled (like a fax machine or modem
connecting).
Other programs (eg. Media Composer, QuickTime with the Calibrated{Q} MXF
components, Adobe Premiere) play the original file correctly with a 1kHz
tone on both tracks.
I have just uploaded test_Stereo.mxf (315MB) to ftp://upload.ffmpeg.org
as requested, and include the output of the latest snapshot build below.
Best regards,
-Rolf
PS. Thanks for all your hard work on such a fantastic tool !
% ffmpeg -i test_Stereo.mxf -map 0:a:1 out0a1.mp3
ffmpeg version N-79129-gb3dc51d-tessus Copyright (c) 2000-2016 the
FFmpeg developers
built with Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg --as=yasm
--extra-version=tessus --enable-avisynth --enable-fontconfig
--enable-gpl --enable-libass --enable-libbluray --enable-libfreetype
--enable-libgsm --enable-libmodplug --enable-libmp3lame
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus
--enable-libschroedinger --enable-libsnappy --enable-libsoxr
--enable-libspeex --enable-libtheora --enable-libvidstab
--enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx
--enable-libwavpack --enable-libx264 --enable-libx265 --enable-libxavs
--enable-libxvid --enable-libzmq --enable-version3 --disable-ffplay
--disable-indev=qtkit --disable-indev=x11grab_xcb
libavutil 55. 19.100 / 55. 19.100
libavcodec 57. 27.101 / 57. 27.101
libavformat57. 28.100 / 57. 28.100
libavdevice57. 0.101 / 57. 0.101
libavfilter 6. 39.100 / 6. 39.100
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc54. 0.100 / 54. 0.100
[mxf @ 0x7fa059805600] OPAtom misinterpreted as OP1a? KLV for edit unit
0 extending into next edit unit is not implemented. Update your FFmpeg
version to the newest one from Git. If the problem still occurs, it
means that your file has a feature which has not been implemented.
[mxf @ 0x7fa059805600] If you want to help, upload a sample of this file
to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel
mailing list. (ffmpeg-devel@ffmpeg.org)
...
[mxf @ 0x7fa059805600] OPAtom misinterpreted as OP1a? KLV for edit unit
7 extending into next edit unit is not implemented. Update your FFmpeg
version to the newest one from Git. If the problem still occurs, it
means that your file has a feature which has not been implemented.
[mxf @ 0x7fa059805600] If you want to help, upload a sample of this file
to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel
mailing list. (ffmpeg-devel@ffmpeg.org)
Guessed Channel Layout for Input Stream #0.1 : mono
Guessed Channel Layout for Input Stream #0.2 : mono
Input #0, mxf, from '/Users/rolf/Desktop/FFmpeg Audio
160216-051529-364/test_Stereo.mxf':
Metadata:
product_uid : 60eb8921-2a02-4406-891c-d9b6a6ae0645
uid : e96bf281-cfee-11e5-86f8-2837370a7ed1
generation_uid : e96bf282-cfee-11e5-9684-2837370a7ed1
company_name: Avid Technology, Inc.
product_name: MSP_MXF DLL
product_version : 1.11.0
application_platform: Mac OS X
modification_date: 2016-02-10 12:07:53
material_package_umid:
0x060A2B340101010501010D1213B116D390699A02287405A568F82837370A7ED1
timecode: 01:00:00:00
Duration: 00:00:20.00, start: 0.00, bitrate: 126175 kb/s
Stream #0:0: Video: dnxhd, yuv422p(bt709/unknown/unknown),
1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 25 tbn, 25 tbc
Metadata:
file_package_umid:
0x060A2B340101010501010D1213F2CA4590699A02287405A58AE62837370A7ED1
file_package_name: Source Package
Stream #0:1: Audio: pcm_s24le, 48000 Hz, 1 channels, s32 (24 bit),
1152 kb/s
Metadata:
file_package_umid:
0x060A2B340101010501010D1213F2CA4590699A02287405A58AE62837370A7ED1
file_package_name: Source Package
Stream #0:2: Audio: pcm_s24le, 48000 Hz, 1 channels, s32 (24 bit),
1152 kb/s
Metadata:
file_package_umid:
0x060A2B340101010501010D1213F2CA4590699A02287405A58AE62837370A7ED1
file_package_name: Source Package
Output #0, mp3, to '/Users/rolf/Desktop/out.mp3':
Metadata:
product_uid : 60eb8921-2a02-4406-891c-d9b6a6ae0645
uid : e96bf281-cfee-11e5-86f8-2837370a7ed1
generation_uid : e96bf282-cfee-11e5-9684-2837370a7ed1
company_name: Avid Technology, Inc.
product_name: MSP_MXF DLL
product_version : 1.11.0
application_platform: Mac OS X
modification_date: 2
Re: [FFmpeg-devel] [PATCH 1/6] lavu: improve documentation of some AVFrame functions
On Tue, Mar 01, 2016 at 07:21:36PM +0100, wm4 wrote: > --- > libavutil/frame.h | 12 > 1 file changed, 12 insertions(+) > > diff --git a/libavutil/frame.h b/libavutil/frame.h > index 76a8123..2d6299b 100644 > --- a/libavutil/frame.h > +++ b/libavutil/frame.h > @@ -591,6 +591,10 @@ void av_frame_free(AVFrame **frame); > * If src is not reference counted, new buffers are allocated and the data is > * copied. > * > + * @warning: dst MUST have been either unreferenced with av_frame_unref(dst), > + * or newly allocated with av_frame_alloc() before calling this > + * function, or undefined behavior will occur. > + * > * @return 0 on success, a negative AVERROR on error > */ > int av_frame_ref(AVFrame *dst, const AVFrame *src); > @@ -611,6 +615,10 @@ void av_frame_unref(AVFrame *frame); > > /** > * Move everything contained in src to dst and reset src. > + * > + * @warning: dst is not unreferenced, but directly overwritten without > reading > + * or deallocating its contents. Call av_frame_unref(dst) manually > + * before calling this function to ensure that no memory is leaked. > */ > void av_frame_move_ref(AVFrame *dst, AVFrame *src); > > @@ -626,6 +634,10 @@ void av_frame_move_ref(AVFrame *dst, AVFrame *src); > * necessary, allocate and fill AVFrame.extended_data and > AVFrame.extended_buf. > * For planar formats, one buffer will be allocated for each plane. > * > + * @warning: if frame already has been allocated, calling this function will > + * leak memory. In addition, undefined behavior can occur in > certain > + * cases. > + * > * @param frame frame in which to store the new buffers. > * @param align required buffer size alignment > * > -- > 2.7.0 LGTM, it would be better though if these cases would have defined behavior, be that a error code or clear abort()/assert(), undefined behavior always sucks [...] -- 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
[FFmpeg-devel] [PATCH]lavc/hevc_ps: Fix offset for yuv422 and yuv444
Hi!
Attached patch fixes ticket #4980 for me.
Debugged by Kurosu and Hendrik.
Please comment, Carl Eugen
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 64d6e2f..b4e5c5b 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -856,11 +856,11 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
return ret;
if (get_bits1(gb)) { // pic_conformance_flag
-//TODO: * 2 is only valid for 420
-sps->pic_conf_win.left_offset = get_ue_golomb_long(gb) * 2;
-sps->pic_conf_win.right_offset = get_ue_golomb_long(gb) * 2;
-sps->pic_conf_win.top_offset= get_ue_golomb_long(gb) * 2;
-sps->pic_conf_win.bottom_offset = get_ue_golomb_long(gb) * 2;
+int mult = 1 + (sps->chroma_format_idc < 2);
+sps->pic_conf_win.left_offset = get_ue_golomb_long(gb) * mult;
+sps->pic_conf_win.right_offset = get_ue_golomb_long(gb) * mult;
+sps->pic_conf_win.top_offset= get_ue_golomb_long(gb) * mult;
+sps->pic_conf_win.bottom_offset = get_ue_golomb_long(gb) * mult;
if (avctx->flags2 & AV_CODEC_FLAG2_IGNORE_CROP) {
av_log(avctx, AV_LOG_DEBUG,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Motion interpolation in libavfilter
On Tue, 8 Mar 2016 09:26:22 +0100 Paul B Mahol wrote: > On 3/8/16, Subhashish Pradhan wrote: > > Hello, > > > > I am Subhashish Pradhan, a CS undergrad from India. I want to take > > up the project "Motion interpolation in libavfilter" for GSoC 2016 > > and I'd like to understand the goals for this project. > > Goals are already written on wiki, if you have more specific > questions ask them. the goals on the wiki for motion interpolation in libavfilter are here: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016#Motioninterpolationinlibavfilter some students have been having trouble finding the wiki page. maybe we could put a news entry about it ? -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Motion interpolation in libavfilter
On Tue, Mar 08, 2016 at 01:21:16PM -0500, compn wrote: > On Tue, 8 Mar 2016 09:26:22 +0100 > Paul B Mahol wrote: > > > On 3/8/16, Subhashish Pradhan wrote: > > > Hello, > > > > > > I am Subhashish Pradhan, a CS undergrad from India. I want to take > > > up the project "Motion interpolation in libavfilter" for GSoC 2016 > > > and I'd like to understand the goals for this project. > > > > Goals are already written on wiki, if you have more specific > > questions ask them. > > the goals on the wiki for motion interpolation in libavfilter are here: > https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016#Motioninterpolationinlibavfilter > > some students have been having trouble finding the wiki page. > maybe we could put a news entry about it ? i would be a good idea to have a news entry about GSoC in general [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- 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]lavc/hevc_ps: Fix offset for yuv422 and yuv444
Hi, On Tue, Mar 8, 2016 at 12:56 PM, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #4980 for me. > Debugged by Kurosu and Hendrik. That fixes 444, but not 422. For 422 (idc_fmt=2), horiz_mult (for l/r) should be 2, but vert_mult (for t/b) should be 1. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Motion interpolation in libavfilter
On Tue, Mar 08, 2016 at 07:26:23PM +0100, Michael Niedermayer wrote: > On Tue, Mar 08, 2016 at 01:21:16PM -0500, compn wrote: > > On Tue, 8 Mar 2016 09:26:22 +0100 > > Paul B Mahol wrote: > > > > > On 3/8/16, Subhashish Pradhan wrote: > > > > Hello, > > > > > > > > I am Subhashish Pradhan, a CS undergrad from India. I want to take > > > > up the project "Motion interpolation in libavfilter" for GSoC 2016 > > > > and I'd like to understand the goals for this project. > > > > > > Goals are already written on wiki, if you have more specific > > > questions ask them. > > > > the goals on the wiki for motion interpolation in libavfilter are here: > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016#Motioninterpolationinlibavfilter > > > > some students have been having trouble finding the wiki page. > > maybe we could put a news entry about it ? > > i would be a good idea to have a news entry about GSoC in general and outreachy of course [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: Fwd: libavformat/segment : add option to increment timecode
On date Sunday 2016-02-28 21:41:32 +0100, Martin Vignali encoded:
> 2016-02-23 20:08 GMT+01:00 Martin Vignali :
[...]
> Hello,
>
> New patch attached, with the timecode incrementation inside segment_end()
> Use this time start_time and end_time (from SegmentListEntry) to calculate
> the duration of the segment.
>
>
> Best regards
>
> Martin
> From 6aab70f629ae8b951574c27d70f06e80334a9309 Mon Sep 17 00:00:00 2001
> From: Martin Vignali
> Date: Sun, 28 Feb 2016 21:36:42 +0100
> Subject: [PATCH] lavf/segment: add increment timecode option
>
> for example you can split a file, keeping a continuous timecode between
> each segment :
>
> ffmpeg -i src.mov -timecode 10:00:00:00 -vcodec copy -f segment \
> -segment_time 2 -reset_timestamps 1 -increment_tc 1 target_%03d.mov
> ---
> doc/muxers.texi | 6 ++
> libavformat/segment.c | 32
> 2 files changed, 38 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 2e6bb4c..c2d26a8 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1017,6 +1017,12 @@ implementation for HLS segmentation.
> The segment muxer supports the following options:
>
> @table @option
> +@item increment_tc @var{1|0}
> +if set to @code{1}, increment timecode between each segment
> +If this is selected, the input need to have
> +a timecode in the first video stream. Default value is
> +@code{0}.
> +
> @item reference_stream @var{specifier}
> Set the reference stream, as specified by the string @var{specifier}.
> If @var{specifier} is set to @code{auto}, the reference is chosen
> diff --git a/libavformat/segment.c b/libavformat/segment.c
> index dd3b092..6335c89 100644
> --- a/libavformat/segment.c
> +++ b/libavformat/segment.c
> @@ -41,6 +41,7 @@
> #include "libavutil/parseutils.h"
> #include "libavutil/mathematics.h"
> #include "libavutil/time.h"
> +#include "libavutil/timecode.h"
> #include "libavutil/time_internal.h"
> #include "libavutil/timestamp.h"
>
> @@ -95,6 +96,7 @@ typedef struct SegmentContext {
> char *time_str;///< segment duration specification string
> int64_t time; ///< segment duration
> int use_strftime; ///< flag to expand filename with strftime
> +int increment_tc; ///< flag to increment timecode if found
>
> char *times_str; ///< segment times specification string
> int64_t *times;///< list of segment interval specification
> @@ -337,6 +339,12 @@ static int segment_end(AVFormatContext *s, int
> write_trailer, int is_last)
> SegmentContext *seg = s->priv_data;
> AVFormatContext *oc = seg->avf;
> int ret = 0;
> +AVTimecode tc;
> +AVRational rate;
> +AVDictionaryEntry *tcr;
> +char buf[AV_TIMECODE_STR_SIZE];
> +int i;
> +int err;
>
> av_write_frame(oc, NULL); /* Flush any buffered data (fragmented mp4) */
> if (write_trailer)
> @@ -390,6 +398,29 @@ static int segment_end(AVFormatContext *s, int
> write_trailer, int is_last)
> seg->avf->filename, seg->segment_count);
> seg->segment_count++;
>
> +if (seg->increment_tc) {
> +tcr = av_dict_get(s->metadata, "timecode", NULL, 0);
> +if (tcr) {
> +/* search the first video stream */
> +for (i = 0; i < s->nb_streams; i++) {
> +if (s->streams[i]->codec->codec_type == AVMEDIA_TYPE_VIDEO) {
> +rate = s->streams[i]->avg_frame_rate;/* Get fps from the
> video stream */
> +err = av_timecode_init_from_string(&tc, rate,
> tcr->value, s);
> +if (err < 0) {
> +av_log(s, AV_LOG_WARNING, "Could not increment
> timecode, error occured during timecode creation.");
> +break;
> +}
> +tc.start += (int)((seg->cur_entry.end_time -
> seg->cur_entry.start_time) * av_q2d(rate));/* increment timecode */
> +av_dict_set(&s->metadata, "timecode",
> +av_timecode_make_string(&tc, buf, 0), 0);
> +break;
> +}
> +}
> +} else {
> +av_log(s, AV_LOG_WARNING, "Could not increment timecode, no
> timecode metadata found");
> +}
> +}
> +
> end:
> ff_format_io_close(oc, &oc->pb);
>
> @@ -948,6 +979,7 @@ static const AVOption options[] = {
> { "segment_start_number", "set the sequence number of the first
> segment", OFFSET(segment_idx), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, E },
> { "segment_wrap_number", "set the number of wrap before the first
> segment", OFFSET(segment_idx_wrap_nb), AV_OPT_TYPE_INT, {.i64 = 0}, 0,
> INT_MAX, E },
> { "strftime", "set filename expansion with strftime at segment
> creation", OFFSET(use_strftime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
> +{ "increment_tc", "increment timecode between each segment",
> OFFSET(increment_tc), AV_O
Re: [FFmpeg-devel] [PATCH]lavc/hevc_ps: Fix offset for yuv422 and yuv444
On Tuesday 08 March 2016 07:26:31 pm Ronald S. Bultje wrote:
> On Tue, Mar 8, 2016 at 12:56 PM, Carl Eugen Hoyos wrote:
> > Attached patch fixes ticket #4980 for me.
> > Debugged by Kurosu and Hendrik.
>
> That fixes 444, but not 422. For 422 (idc_fmt=2), horiz_mult (for l/r)
> should be 2, but vert_mult (for t/b) should be 1.
New patch attached.
Thank you for the review, Carl Eugen
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 64d6e2f..bcb63a3 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -856,11 +856,12 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
return ret;
if (get_bits1(gb)) { // pic_conformance_flag
-//TODO: * 2 is only valid for 420
-sps->pic_conf_win.left_offset = get_ue_golomb_long(gb) * 2;
-sps->pic_conf_win.right_offset = get_ue_golomb_long(gb) * 2;
-sps->pic_conf_win.top_offset= get_ue_golomb_long(gb) * 2;
-sps->pic_conf_win.bottom_offset = get_ue_golomb_long(gb) * 2;
+int vert_mult = 1 + (sps->chroma_format_idc < 2);
+int horiz_mult = 1 + (sps->chroma_format_idc < 3);
+sps->pic_conf_win.left_offset = get_ue_golomb_long(gb) * horiz_mult;
+sps->pic_conf_win.right_offset = get_ue_golomb_long(gb) * horiz_mult;
+sps->pic_conf_win.top_offset= get_ue_golomb_long(gb) * vert_mult;
+sps->pic_conf_win.bottom_offset = get_ue_golomb_long(gb) * vert_mult;
if (avctx->flags2 & AV_CODEC_FLAG2_IGNORE_CROP) {
av_log(avctx, AV_LOG_DEBUG,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc_utils: unroll loops to allow compiler to use SIMD.
On Mon, Mar 07, 2016 at 10:50:53PM -0500, Ganesh Ajjanagadde wrote: > On Mon, Mar 7, 2016 at 2:54 AM, Reimar Döffinger > wrote: > >> Can you be more specific, and are you sure about this? > > > > Just run your favourite performance analysis tool and you'll see. > > As it is non-inlined libc code I'm fairly sure the numbers are accurate > > enough. > > I am still puzzled by the remarks; and hence asked for specific > examples. In aac code, cosf is only called for table generation, same > with cos, so still don't see why cos is relevant. You seem to have missed ff_lpc_calc_ref_coefs_f. At least it's that function that is to blame for the cos calls I saw in the profiler. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Subtitles for GSoC
On Tue, Mar 08, 2016 at 06:21:12PM +0100, Gerion Entrup wrote:
> Hello,
>
Hi,
> my own ideas seems not to be suitable for GSoC, so I looked again on the
> ideas page,
> because I have high interest to do something for FFmpeg this summer.
>
> The project, that I find most interesting, unfortunately is a unmentored one,
> the subtitle
> support. Is someone willing to mentor this?
>
I added this task for previous OPW (and maybe GSoC, can't remember). I'm
unfortunately not available for mentoring (too much time, energy and
responsibility). Though, I can provide standard help as a developer.
The main issue with this task is that it involves API redesign, which is
often not a good idea for a GSoC task.
That said, a bunch of core limitations have been solved in the past so
it's starting to be comfortable to work on top of the current stack.
I'm summarizing the current state at the end of this mail, which can be
useful for any potential mentor and eventually student.
> On the ideas page the mentioned subtitle for the qualification task is Spruce
> subtitle. It
> seems, it is already supported, so I would try to implement the corepart of
> usf. I know
> it is not widely used, but very powerful with similar features as SSA, if I
> get it right. Do you
> think, that is suitable?
>
Spruce has indeed been added in last OPW as a qualification task. USF is
more painful but a basic support could be a potential qualification task
indeed. You might be able to figure out something playing with the
ff_smil_* functions for the demuxing part.
So basically you would have to:
- an USF demuxer which extracts the timing and text (with its markup) of
every event, and put them into an AVPacket
- introduce an USF codec and write a decoder that will transform the
xml-like markup into ASS markup (see below)
Again, I'm not a mentor, so you need confirmation from someone else.
> And then another question. You mentioned as ultimate goal the libavfilter
> integration.
> If I get it right, ATM no rendering is implemented, and libavfilter would
> allow an (automatic)
> rendering from SSA to e.g. dvdsub. Would the rendering itself part of the
> project (because
> this is very extensive, I think)?
>
So, yeah, currently the subtitles are decoded into an AVSubtitle
structure, which hold one or several AVSubtitleRect (AVSubtitle.rects[N]).
For graphic subtitles, each rectangle contains a paletted buffer and its
position, size, ...
For text subtitles, the ass field contains the text in ASS markup: indeed,
we consider the ASS markup to be the best/least worst superset supporting
almost every style of every other subtitles formats have, so it's used as
the "decoded" form for all text subtitles. For example, the SubRip (the
"codec", or markup you find in SRT files) decoder will transform
"foo" into "{\i1}foo{\i0}".
So far so good. Unfortunately, this is not sufficient, because the
AVSubtitle* structs are old and not convenient for several reasons:
- they are allocated on the stack by the users, so we can't extend them
(add fields) without breaking the ABI (= angry users).
- they are defined in libavcodec, and we do not want libavfilter to
depend on libavcodec for a core feature (we have a few filters
depending on it, but that's optional). As such, libavutil is a much
better place for this, which already contains the AVFrame.
- the graphic subtitles are kind of limited (palette only, can't hold YUV
or RGB32 pixel formats for instance)
- the handling of the timing is inconsistent: pts is in AV_TIME_BASE and
start/end display time are relative and in ms.
When these issues are sorted out, we can finally work on the integration
within libavfilter, which is yet another topic where other developers
might want to comment. Typically, I'm not sure what is the state of
dealing with the sparse property of the subtitles. Nicolas may know :)
Anyway, there are multiple ways of dealing with the previous mentioned
issues.
The first one is to create an AVSubtitle2 or something in libavutil,
copying most of the current AVSubtitle layout but making sure the user
allocates it with av_subtitle_alloc() or whatever, so we can add fields
and extend it (mostly) at will.
The second one, which I'm currently wondering about these days is to try
to hold the subtitles data into the existing AVFrame structure. We will
for example have the frame->extended_data[N] (currently used by audio
frames to hold the channels) point on a instances of a newly defined
rectangle structure. Having the subtitles into AVFrame might simplify a
lot the future integration within libavfilter since they are already
supported as audio and video. This needs careful thinking, but it might
be doable.
But again, these are ideas, which need to be discussed and experimented. I
don't know if it's a good idea for a GSoC, and I don't know who would be
up for mentoring.
It's nice to finally see some interest into this topic though.
> regards,
Regards,
> Ge
Re: [FFmpeg-devel] [PATCH]lavc/hevc_ps: Fix offset for yuv422 and yuv444
Hi, On Tue, Mar 8, 2016 at 2:03 PM, Carl Eugen Hoyos wrote: > On Tuesday 08 March 2016 07:26:31 pm Ronald S. Bultje wrote: > > On Tue, Mar 8, 2016 at 12:56 PM, Carl Eugen Hoyos wrote: > > > Attached patch fixes ticket #4980 for me. > > > Debugged by Kurosu and Hendrik. > > > > That fixes 444, but not 422. For 422 (idc_fmt=2), horiz_mult (for l/r) > > should be 2, but vert_mult (for t/b) should be 1. > > New patch attached. lgtm (I think). Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/frame: Assert that width/height/channels is 0 for the destination of av_frame*_ref()
This should detect caes where these functions are called in unclean destinations
---
libavutil/frame.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 5607206..dde32b0 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -375,6 +375,9 @@ int av_frame_ref(AVFrame *dst, const AVFrame *src)
{
int i, ret = 0;
+av_assert0(dst->width == 0 && dst->height == 0);
+av_assert0(dst->channels == 0);
+
dst->format = src->format;
dst->width = src->width;
dst->height = src->height;
@@ -504,6 +507,9 @@ void av_frame_unref(AVFrame *frame)
void av_frame_move_ref(AVFrame *dst, AVFrame *src)
{
+av_assert0(dst->width == 0 && dst->height == 0);
+av_assert0(dst->channels == 0);
+
*dst = *src;
if (src->extended_data == src->data)
dst->extended_data = dst->data;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] tests/gapless: add gapless aac tests
On Tue, 8 Mar 2016, Michael Niedermayer wrote: On Tue, Mar 08, 2016 at 01:49:43AM +0100, Marton Balint wrote: Signed-off-by: Marton Balint --- tests/fate-run.sh | 30 + tests/fate/gapless.mak| 20 - tests/ref/fate/gapless2-ipod-aac1 | 88 +++ tests/ref/fate/gapless2-ipod-aac2 | 88 +++ tests/ref/fate/gapless2-mov-aac | 88 +++ 5 files changed, 313 insertions(+), 1 deletion(-) create mode 100644 tests/ref/fate/gapless2-ipod-aac1 create mode 100644 tests/ref/fate/gapless2-ipod-aac2 create mode 100644 tests/ref/fate/gapless2-mov-aac seems not to pass here, or is there some other patch needed before? No this should work as is. I'll just remove the size from the ffprobe output, I guess it is not bitexact because of floating point arithmetic and/or VBR. Will send a new patch series soon. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2 1/3] tests/gapless: add gapless aac tests
Signed-off-by: Marton Balint
---
tests/fate-run.sh | 30 ++
tests/fate/gapless.mak| 20 -
tests/ref/fate/gapless2-ipod-aac1 | 86 +++
tests/ref/fate/gapless2-ipod-aac2 | 86 +++
tests/ref/fate/gapless2-mov-aac | 86 +++
5 files changed, 307 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/gapless2-ipod-aac1
create mode 100644 tests/ref/fate/gapless2-ipod-aac2
create mode 100644 tests/ref/fate/gapless2-mov-aac
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 16087cb..9b76275 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -96,6 +96,21 @@ probeframes(){
run ffprobe${PROGSUF} -show_frames -v 0 "$@"
}
+probegaplessinfo(){
+filename=$1
+shift
+run ffprobe${PROGSUF} -bitexact -select_streams a -show_entries
format=format_name,start_time,duration:stream=index,codec_name,start_pts,duration_ts
-v 0 "$filename" "$@"
+pktfile1="${filename}.pkts"
+framefile1="${filename}.frames"
+cleanfiles="$cleanfiles $pktfile1 $framefile1"
+run ffprobe${PROGSUF} -bitexact -select_streams a -of compact
-show_entries packet=pts,dts,duration -v 0 "$filename" "$@" | nl -w 1 -s '|' >
$pktfile1
+head -n 8 $pktfile1
+tail -n 8 $pktfile1
+run ffprobe${PROGSUF} -bitexact -select_streams a -of compact
-show_entries
frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples -v 0
"$filename" "$@" | nl -w 1 -s '|' > $framefile1
+head -n 8 $framefile1
+tail -n 8 $framefile1
+}
+
ffmpeg(){
dec_opts="-hwaccel $hwaccel -threads $threads -thread_type $thread_type"
ffmpeg_args="-nostdin -nostats -cpuflags $cpuflags"
@@ -249,6 +264,21 @@ gapless(){
do_md5sum $decfile3
}
+gapless2(){
+sample=$(target_path $1)
+format=$2
+codec=$3
+
+file1="${outdir}/${test}.out-1"
+cleanfiles="$cleanfiles $file1"
+
+# test source data
+probegaplessinfo "$sample" | sed 's/^/source|/'
+# test data after reencoding
+ffmpeg -i "$sample" -flags +bitexact -fflags +bitexact -map 0:a -c:a
$codec -f $format -y $file1
+probegaplessinfo "$file1" | sed 's/^/target|/'
+}
+
concat(){
template=$1
sample=$2
diff --git a/tests/fate/gapless.mak b/tests/fate/gapless.mak
index 2fb005f..8d819bd 100644
--- a/tests/fate/gapless.mak
+++ b/tests/fate/gapless.mak
@@ -3,5 +3,23 @@ fate-gapless-mp3: CMD = gapless
$(TARGET_SAMPLES)/gapless/gapless.mp3
FATE_GAPLESS = $(FATE_GAPLESS-yes)
+FATE_GAPLESS2_PROBE-$(call ENCDEC, AAC, MOV) += fate-gapless2-ipod-aac1
+fate-gapless2-ipod-aac1: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gapless2-ipod-aac1: CMD = gapless2
$(TARGET_SAMPLES)/cover_art/Owner-iTunes_9.0.3.15.m4a ipod aac
+
+FATE_GAPLESS2_PROBE-$(call ENCDEC, AAC, MOV) += fate-gapless2-ipod-aac2
+fate-gapless2-ipod-aac2: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gapless2-ipod-aac2: CMD = gapless2
$(TARGET_SAMPLES)/gapless/102400samples_qt-lc-aac.m4a ipod aac
+
+FATE_GAPLESS2_PROBE-$(call ENCDEC, AAC, MOV) += fate-gapless2-mov-aac
+fate-gapless2-mov-aac: $(AREF)
+fate-gapless2-mov-aac: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gapless2-mov-aac: CMD = gapless2 $(AREF) mov aac
+
+FATE_GAPLESS2-$(CONFIG_FFPROBE) = $(FATE_GAPLESS2_PROBE-yes)
+FATE_GAPLESS2 = $(FATE_GAPLESS2-yes)
+
FATE_SAMPLES_AVCONV += $(FATE_GAPLESS)
-fate-gapless: $(FATE_GAPLESS)
+FATE_SAMPLES_AVCONV += $(FATE_GAPLESS2)
+
+fate-gapless: $(FATE_GAPLESS) $(FATE_GAPLESS2)
diff --git a/tests/ref/fate/gapless2-ipod-aac1
b/tests/ref/fate/gapless2-ipod-aac1
new file mode 100644
index 000..fff46d2
--- /dev/null
+++ b/tests/ref/fate/gapless2-ipod-aac1
@@ -0,0 +1,86 @@
+source|[STREAM]
+source|index=0
+source|codec_name=aac
+source|start_pts=0
+source|duration_ts=1294336
+source|[/STREAM]
+source|[FORMAT]
+source|format_name=mov,mp4,m4a,3gp,3g2,mj2
+source|start_time=0.00
+source|duration=29.350023
+source|[/FORMAT]
+source|1|packet|pts=0|dts=0|duration=1024
+source|2|packet|pts=1024|dts=1024|duration=1024
+source|3|packet|pts=2048|dts=2048|duration=1024
+source|4|packet|pts=3072|dts=3072|duration=1024
+source|5|packet|pts=4096|dts=4096|duration=1024
+source|6|packet|pts=5120|dts=5120|duration=1024
+source|7|packet|pts=6144|dts=6144|duration=1024
+source|8|packet|pts=7168|dts=7168|duration=1024
+source|1257|packet|pts=1286144|dts=1286144|duration=1024
+source|1258|packet|pts=1287168|dts=1287168|duration=1024
+source|1259|packet|pts=1288192|dts=1288192|duration=1024
+source|1260|packet|pts=1289216|dts=1289216|duration=1024
+source|1261|packet|pts=1290240|dts=1290240|duration=1024
+source|1262|packet|pts=1291264|dts=1291264|duration=1024
+source|1263|packet|pts=1292288|dts=1292288|duration=1024
+source|1264|packet|pts=1293312|dts=1293312|duration=1024
+source|1|frame|pkt_pts=2112|pkt_dts=2112|best_effort_timestamp=2048|pkt_duration=960|nb_samples=960
+source|2|frame|pkt_pts=3072|pkt_dts=3072|best_effort_timestamp=3072|p
[FFmpeg-devel] [PATCHv2 3/3] avformat/mov: read start_pad from edit list start time if codec is aac
Related to ticket #2324, #2325. Stream duration still need to be fixed... Signed-off-by: Marton Balint --- libavformat/mov.c | 3 +++ tests/ref/fate/gapless2-ipod-aac1 | 36 ++-- tests/ref/fate/gapless2-ipod-aac2 | 36 ++-- tests/ref/fate/gapless2-mov-aac | 36 ++-- 4 files changed, 57 insertions(+), 54 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 752bc12..73e3f30 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2688,6 +2688,9 @@ static void mov_build_index(MOVContext *mov, AVStream *st) st->codec->has_b_frames = 1; } } + +if (!unsupported && st->codec->codec_id == AV_CODEC_ID_AAC && start_time > 0) +sc->start_pad = start_time; } /* only use old uncompressed audio chunk demuxing when stts specifies it */ diff --git a/tests/ref/fate/gapless2-ipod-aac1 b/tests/ref/fate/gapless2-ipod-aac1 index ee7f126..890b617 100644 --- a/tests/ref/fate/gapless2-ipod-aac1 +++ b/tests/ref/fate/gapless2-ipod-aac1 @@ -44,12 +44,12 @@ source|1262|frame|pkt_pts=1293312|pkt_dts=1293312|best_effort_timestamp=1293312| target|[STREAM] target|index=0 target|codec_name=aac -target|start_pts=-1024 +target|start_pts=0 target|duration_ts=1293248 target|[/STREAM] target|[FORMAT] target|format_name=mov,mp4,m4a,3gp,3g2,mj2 -target|start_time=-0.023220 +target|start_time=0.00 target|duration=29.326000 target|[/FORMAT] target|1|packet|pts=-1024|dts=-1024|duration=1024 @@ -68,19 +68,19 @@ target|1260|packet|pts=1288192|dts=1288192|duration=1024 target|1261|packet|pts=1289216|dts=1289216|duration=1024 target|1262|packet|pts=1290240|dts=1290240|duration=1024 target|1263|packet|pts=1291264|dts=1291264|duration=1984 -target|1|frame|pkt_pts=-1024|pkt_dts=-1024|best_effort_timestamp=-1024|pkt_duration=1024|nb_samples=1024 -target|2|frame|pkt_pts=0|pkt_dts=0|best_effort_timestamp=0|pkt_duration=1024|nb_samples=1024 -target|3|frame|pkt_pts=1024|pkt_dts=1024|best_effort_timestamp=1024|pkt_duration=1024|nb_samples=1024 -target|4|frame|pkt_pts=2048|pkt_dts=2048|best_effort_timestamp=2048|pkt_duration=1024|nb_samples=1024 -target|5|frame|pkt_pts=3072|pkt_dts=3072|best_effort_timestamp=3072|pkt_duration=1024|nb_samples=1024 -target|6|frame|pkt_pts=4096|pkt_dts=4096|best_effort_timestamp=4096|pkt_duration=1024|nb_samples=1024 -target|7|frame|pkt_pts=5120|pkt_dts=5120|best_effort_timestamp=5120|pkt_duration=1024|nb_samples=1024 -target|8|frame|pkt_pts=6144|pkt_dts=6144|best_effort_timestamp=6144|pkt_duration=1024|nb_samples=1024 -target|1256|frame|pkt_pts=1284096|pkt_dts=1284096|best_effort_timestamp=1284096|pkt_duration=1024|nb_samples=1024 -target|1257|frame|pkt_pts=1285120|pkt_dts=1285120|best_effort_timestamp=1285120|pkt_duration=1024|nb_samples=1024 -target|1258|frame|pkt_pts=1286144|pkt_dts=1286144|best_effort_timestamp=1286144|pkt_duration=1024|nb_samples=1024 -target|1259|frame|pkt_pts=1287168|pkt_dts=1287168|best_effort_timestamp=1287168|pkt_duration=1024|nb_samples=1024 -target|1260|frame|pkt_pts=1288192|pkt_dts=1288192|best_effort_timestamp=1288192|pkt_duration=1024|nb_samples=1024 -target|1261|frame|pkt_pts=1289216|pkt_dts=1289216|best_effort_timestamp=1289216|pkt_duration=1024|nb_samples=1024 -target|1262|frame|pkt_pts=1290240|pkt_dts=1290240|best_effort_timestamp=1290240|pkt_duration=1024|nb_samples=1024 -target|1263|frame|pkt_pts=1291264|pkt_dts=1291264|best_effort_timestamp=1291264|pkt_duration=1984|nb_samples=1024 +target|1|frame|pkt_pts=0|pkt_dts=0|best_effort_timestamp=0|pkt_duration=1024|nb_samples=1024 +target|2|frame|pkt_pts=1024|pkt_dts=1024|best_effort_timestamp=1024|pkt_duration=1024|nb_samples=1024 +target|3|frame|pkt_pts=2048|pkt_dts=2048|best_effort_timestamp=2048|pkt_duration=1024|nb_samples=1024 +target|4|frame|pkt_pts=3072|pkt_dts=3072|best_effort_timestamp=3072|pkt_duration=1024|nb_samples=1024 +target|5|frame|pkt_pts=4096|pkt_dts=4096|best_effort_timestamp=4096|pkt_duration=1024|nb_samples=1024 +target|6|frame|pkt_pts=5120|pkt_dts=5120|best_effort_timestamp=5120|pkt_duration=1024|nb_samples=1024 +target|7|frame|pkt_pts=6144|pkt_dts=6144|best_effort_timestamp=6144|pkt_duration=1024|nb_samples=1024 +target|8|frame|pkt_pts=7168|pkt_dts=7168|best_effort_timestamp=7168|pkt_duration=1024|nb_samples=1024 +target|1255|frame|pkt_pts=1284096|pkt_dts=1284096|best_effort_timestamp=1284096|pkt_duration=1024|nb_samples=1024 +target|1256|frame|pkt_pts=1285120|pkt_dts=1285120|best_effort_timestamp=1285120|pkt_duration=1024|nb_samples=1024 +target|1257|frame|pkt_pts=1286144|pkt_dts=1286144|best_effort_timestamp=1286144|pkt_duration=1024|nb_samples=1024 +target|1258|frame|pkt_pts=1287168|pkt_dts=1287168|best_effort_timestamp=1287168|pkt_duration=1024|nb_samples=1024 +target|1259|frame|pkt_pts=1288192|pkt_dts=1288192|best_effort_timestamp=1288192|pkt_duration=1024|nb_samples=1024 +target|1260|frame|pkt_
[FFmpeg-devel] [PATCHv2 2/3] avformat/utils: increase detected start_time with skip_samples
Signed-off-by: Marton Balint
---
libavformat/utils.c | 10 --
tests/ref/fate/gapless2-ipod-aac1 | 72 +++
tests/ref/fate/gapless2-ipod-aac2 | 72 +++
3 files changed, 80 insertions(+), 74 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index f4ae8b4..bb1c290 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -971,8 +971,11 @@ static void update_initial_timestamps(AVFormatContext *s,
int stream_index,
if (is_relative(pktl->pkt.dts))
pktl->pkt.dts += shift;
-if (st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts !=
AV_NOPTS_VALUE)
+if (st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts !=
AV_NOPTS_VALUE) {
st->start_time = pktl->pkt.pts;
+if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
st->codec->sample_rate)
+st->start_time += av_rescale_q(st->skip_samples,
(AVRational){1, st->codec->sample_rate}, st->time_base);
+}
if (pktl->pkt.pts != AV_NOPTS_VALUE && delay <= MAX_REORDER_DELAY &&
has_decode_delay_been_guessed(st)) {
pts_buffer[0] = pktl->pkt.pts;
@@ -983,8 +986,11 @@ static void update_initial_timestamps(AVFormatContext *s,
int stream_index,
}
}
-if (st->start_time == AV_NOPTS_VALUE)
+if (st->start_time == AV_NOPTS_VALUE) {
st->start_time = pts;
+if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
st->codec->sample_rate)
+st->start_time += av_rescale_q(st->skip_samples, (AVRational){1,
st->codec->sample_rate}, st->time_base);
+}
}
static void update_initial_durations(AVFormatContext *s, AVStream *st,
diff --git a/tests/ref/fate/gapless2-ipod-aac1
b/tests/ref/fate/gapless2-ipod-aac1
index fff46d2..ee7f126 100644
--- a/tests/ref/fate/gapless2-ipod-aac1
+++ b/tests/ref/fate/gapless2-ipod-aac1
@@ -1,12 +1,12 @@
source|[STREAM]
source|index=0
source|codec_name=aac
-source|start_pts=0
+source|start_pts=2112
source|duration_ts=1294336
source|[/STREAM]
source|[FORMAT]
source|format_name=mov,mp4,m4a,3gp,3g2,mj2
-source|start_time=0.00
+source|start_time=0.047889
source|duration=29.350023
source|[/FORMAT]
source|1|packet|pts=0|dts=0|duration=1024
@@ -44,43 +44,43 @@
source|1262|frame|pkt_pts=1293312|pkt_dts=1293312|best_effort_timestamp=1293312|
target|[STREAM]
target|index=0
target|codec_name=aac
-target|start_pts=1058
+target|start_pts=-1024
target|duration_ts=1293248
target|[/STREAM]
target|[FORMAT]
target|format_name=mov,mp4,m4a,3gp,3g2,mj2
-target|start_time=0.023991
+target|start_time=-0.023220
target|duration=29.326000
target|[/FORMAT]
-target|1|packet|pts=1058|dts=1058|duration=1024
-target|2|packet|pts=2082|dts=2082|duration=1024
-target|3|packet|pts=3106|dts=3106|duration=1024
-target|4|packet|pts=4130|dts=4130|duration=1024
-target|5|packet|pts=5154|dts=5154|duration=1024
-target|6|packet|pts=6178|dts=6178|duration=1024
-target|7|packet|pts=7202|dts=7202|duration=1024
-target|8|packet|pts=8226|dts=8226|duration=1024
-target|1256|packet|pts=1286178|dts=1286178|duration=1024
-target|1257|packet|pts=1287202|dts=1287202|duration=1024
-target|1258|packet|pts=1288226|dts=1288226|duration=1024
-target|1259|packet|pts=1289250|dts=1289250|duration=1024
-target|1260|packet|pts=1290274|dts=1290274|duration=1024
-target|1261|packet|pts=1291298|dts=1291298|duration=1024
-target|1262|packet|pts=1292322|dts=1292322|duration=1024
-target|1263|packet|pts=1293346|dts=1293346|duration=-98
-target|1|frame|pkt_pts=1058|pkt_dts=1058|best_effort_timestamp=1058|pkt_duration=1024|nb_samples=1024
-target|2|frame|pkt_pts=2082|pkt_dts=2082|best_effort_timestamp=2082|pkt_duration=1024|nb_samples=1024
-target|3|frame|pkt_pts=3106|pkt_dts=3106|best_effort_timestamp=3106|pkt_duration=1024|nb_samples=1024
-target|4|frame|pkt_pts=4130|pkt_dts=4130|best_effort_timestamp=4130|pkt_duration=1024|nb_samples=1024
-target|5|frame|pkt_pts=5154|pkt_dts=5154|best_effort_timestamp=5154|pkt_duration=1024|nb_samples=1024
-target|6|frame|pkt_pts=6178|pkt_dts=6178|best_effort_timestamp=6178|pkt_duration=1024|nb_samples=1024
-target|7|frame|pkt_pts=7202|pkt_dts=7202|best_effort_timestamp=7202|pkt_duration=1024|nb_samples=1024
-target|8|frame|pkt_pts=8226|pkt_dts=8226|best_effort_timestamp=8226|pkt_duration=1024|nb_samples=1024
-target|1256|frame|pkt_pts=1286178|pkt_dts=1286178|best_effort_timestamp=1286178|pkt_duration=1024|nb_samples=1024
-target|1257|frame|pkt_pts=1287202|pkt_dts=1287202|best_effort_timestamp=1287202|pkt_duration=1024|nb_samples=1024
-target|1258|frame|pkt_pts=1288226|pkt_dts=1288226|best_effort_timestamp=1288226|pkt_duration=1024|nb_samples=1024
-target|1259|frame|pkt_pts=1289250|pkt_dts=1289250|best_effort_timestamp=1289250|pkt_duration=1024|nb_samples=1024
-target|1260|frame|pkt_pts=1290274|pkt_dts=1290274|best_effort_timestamp=1290274|pkt_duration=1024|nb_samples=1024
-target|1261|frame|pkt_pts=1291298|
[FFmpeg-devel] Looking for FFmpeg automation specialist
Looking to fill a 6 month contract position (Toronto, ON CANADA), to assist with design and building of FFmpeg based media transcoding system - thorough understanding of media processing and transcoding optimizations - integrate with Java based automation framework (expand API, errors/status handling) - filter chain handling in multi output executions (sequence, splits, mappings, etc) - 40 audio language support (map, pan, volume, etc) - expand subtitles support - integrate with hardware acceleration (QSV, CUDA, etc) Please email your resume and questions to toronto.ffm...@gmail.com If you don't have the ability to work in Canada, we can figure out a way to mange it remotely. Good luck and thank you Dennis P.S. Говорим по русски. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Support seek in encrypted MP4
> > check tests/fate/seek.mak > also you can pass parameters to seek-test see fate-seek-cache-pipe > i dont know if there is anything else special needed for this > Thanks Michael, I looked at this some more, and there's one thing that I'm still missing - where do I get the sample encrypted file from ? As I understand, I can either: 1. Generate one on the machine running the tests - in this case, where do I write the ffmpeg command line for doing that ? 2. Upload a sample, that will later be pulled by 'make fate-rsync' - in this option, what is the process for submitting such samples ? Thanks Eran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 2/3] avformat/utils: increase detected start_time with skip_samples
On Tue, 8 Mar 2016 21:29:52 +0100
Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> libavformat/utils.c | 10 --
> tests/ref/fate/gapless2-ipod-aac1 | 72
> +++
> tests/ref/fate/gapless2-ipod-aac2 | 72
> +++
> 3 files changed, 80 insertions(+), 74 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index f4ae8b4..bb1c290 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -971,8 +971,11 @@ static void update_initial_timestamps(AVFormatContext
> *s, int stream_index,
> if (is_relative(pktl->pkt.dts))
> pktl->pkt.dts += shift;
>
> -if (st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts !=
> AV_NOPTS_VALUE)
> +if (st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts !=
> AV_NOPTS_VALUE) {
> st->start_time = pktl->pkt.pts;
> +if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
> st->codec->sample_rate)
> +st->start_time += av_rescale_q(st->skip_samples,
> (AVRational){1, st->codec->sample_rate}, st->time_base);
> +}
>
> if (pktl->pkt.pts != AV_NOPTS_VALUE && delay <= MAX_REORDER_DELAY &&
> has_decode_delay_been_guessed(st)) {
> pts_buffer[0] = pktl->pkt.pts;
> @@ -983,8 +986,11 @@ static void update_initial_timestamps(AVFormatContext
> *s, int stream_index,
> }
> }
>
> -if (st->start_time == AV_NOPTS_VALUE)
> +if (st->start_time == AV_NOPTS_VALUE) {
> st->start_time = pts;
> +if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
> st->codec->sample_rate)
> +st->start_time += av_rescale_q(st->skip_samples, (AVRational){1,
> st->codec->sample_rate}, st->time_base);
> +}
> }
I'm a probably bit late here, but what's the rationale of increasing the
start time?
Maybe it's like this: the first packet has a negative timestamp, so
utils.c sets the start_time to something negative, so this has to be
compensated again so that the start time is 0?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Subtitles for GSoC
On Dienstag, 8. März 2016 20:42:39 CET Clément Bœsch wrote:
> On Tue, Mar 08, 2016 at 06:21:12PM +0100, Gerion Entrup wrote:
> > Hello,
> >
>
> Hi,
Thank you for your answer.
>
> > my own ideas seems not to be suitable for GSoC, so I looked again on the
> > ideas page,
> > because I have high interest to do something for FFmpeg this summer.
> >
> > The project, that I find most interesting, unfortunately is a unmentored
> > one, the subtitle
> > support. Is someone willing to mentor this?
> >
>
> I added this task for previous OPW (and maybe GSoC, can't remember). I'm
> unfortunately not available for mentoring (too much time, energy and
> responsibility). Though, I can provide standard help as a developer.
>
> The main issue with this task is that it involves API redesign, which is
> often not a good idea for a GSoC task.
>
> That said, a bunch of core limitations have been solved in the past so
> it's starting to be comfortable to work on top of the current stack.
>
> I'm summarizing the current state at the end of this mail, which can be
> useful for any potential mentor and eventually student.
>
> > On the ideas page the mentioned subtitle for the qualification task is
> > Spruce subtitle. It
> > seems, it is already supported, so I would try to implement the corepart of
> > usf. I know
> > it is not widely used, but very powerful with similar features as SSA, if I
> > get it right. Do you
> > think, that is suitable?
> >
>
> Spruce has indeed been added in last OPW as a qualification task. USF is
> more painful but a basic support could be a potential qualification task
> indeed. You might be able to figure out something playing with the
> ff_smil_* functions for the demuxing part.
>
> So basically you would have to:
>
> - an USF demuxer which extracts the timing and text (with its markup) of
> every event, and put them into an AVPacket
>
> - introduce an USF codec and write a decoder that will transform the
> xml-like markup into ASS markup (see below)
This would be more less exactly the task I have tought of / expected.
>
> Again, I'm not a mentor, so you need confirmation from someone else.
>
> > And then another question. You mentioned as ultimate goal the libavfilter
> > integration.
> > If I get it right, ATM no rendering is implemented, and libavfilter would
> > allow an (automatic)
> > rendering from SSA to e.g. dvdsub. Would the rendering itself part of the
> > project (because
> > this is very extensive, I think)?
> >
>
> So, yeah, currently the subtitles are decoded into an AVSubtitle
> structure, which hold one or several AVSubtitleRect (AVSubtitle.rects[N]).
>
> For graphic subtitles, each rectangle contains a paletted buffer and its
> position, size, ...
>
> For text subtitles, the ass field contains the text in ASS markup: indeed,
> we consider the ASS markup to be the best/least worst superset supporting
> almost every style of every other subtitles formats have, so it's used as
> the "decoded" form for all text subtitles. For example, the SubRip (the
> "codec", or markup you find in SRT files) decoder will transform
> "foo" into "{\i1}foo{\i0}".
I personally find the syntax a little unfamiliar (most styled text subtitles
seem
to use html), but ASS seems to be the most used text subtitle format with
(advanced)
styling capabilities.
As a sidenode (not necessary related to this gsoc task): If someday a renderer
is available,
the renderer has to parse and interprete it. My naive approuch would then be
some kind
of tree based structure (because all markup languages I know are tree based).
Would it
be an idea, to parse on the decoder side already and let the internal structure
be not text,
but a tree (independent of the subtitleformat)?
>
> So far so good. Unfortunately, this is not sufficient, because the
> AVSubtitle* structs are old and not convenient for several reasons:
>
> - they are allocated on the stack by the users, so we can't extend them
> (add fields) without breaking the ABI (= angry users).
>
> - they are defined in libavcodec, and we do not want libavfilter to
> depend on libavcodec for a core feature (we have a few filters
> depending on it, but that's optional). As such, libavutil is a much
> better place for this, which already contains the AVFrame.
>
> - the graphic subtitles are kind of limited (palette only, can't hold YUV
> or RGB32 pixel formats for instance)
>
> - the handling of the timing is inconsistent: pts is in AV_TIME_BASE and
> start/end display time are relative and in ms.
>
> When these issues are sorted out, we can finally work on the integration
> within libavfilter, which is yet another topic where other developers
> might want to comment. Typically, I'm not sure what is the state of
> dealing with the sparse property of the subtitles. Nicolas may know :)
>
> Anyway, there are multiple ways of dealing with the previous mentioned
> issues.
>
> The first one is to create an AVSubtitle2 or some
Re: [FFmpeg-devel] Motion interpolation in libavfilter
compn wrote: On Tue, 8 Mar 2016 09:26:22 +0100 Paul B Mahol wrote: On 3/8/16, Subhashish Pradhan wrote: Hello, I am Subhashish Pradhan, a CS undergrad from India. I want to take up the project "Motion interpolation in libavfilter" for GSoC 2016 and I'd like to understand the goals for this project. Goals are already written on wiki, if you have more specific questions ask them. the goals on the wiki for motion interpolation in libavfilter are here: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016#Motioninterpolationinlibavfilter "Expected results: State of the art frame interpolation in the libavfilter" !!! So what's considered state of the art in 2016? It's years ago, but I've read of some pretty complicated methods for doing this. Maybe random old PHD papers like below are misleading but what is someone expected to do in a summer? http://www.blivdatalog.dk/forskning/Publikationer/tekniske_rapporter/2007/07-03.pdf ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 2/3] avformat/utils: increase detected start_time with skip_samples
On Tue, 8 Mar 2016, wm4 wrote: On Tue, 8 Mar 2016 21:29:52 +0100 Marton Balint wrote: Signed-off-by: Marton Balint --- libavformat/utils.c | 10 -- tests/ref/fate/gapless2-ipod-aac1 | 72 +++ tests/ref/fate/gapless2-ipod-aac2 | 72 +++ 3 files changed, 80 insertions(+), 74 deletions(-) I'm a probably bit late here, but what's the rationale of increasing the start time? According to docs, start time is supposed to be the pts of the first decoded frame, therefore skipped samples must be taken into account, when the start time is determined based on the first packet pts. Maybe it's like this: the first packet has a negative timestamp, so utils.c sets the start_time to something negative, so this has to be compensated again so that the start time is 0? I am not sure I understand what you mean. In the gapless samples above, the first packet pts is 0, and not negative. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Subtitles for GSoC
On Tue, Mar 08, 2016 at 10:33:44PM +0100, Gerion Entrup wrote:
[...]
> > For text subtitles, the ass field contains the text in ASS markup: indeed,
> > we consider the ASS markup to be the best/least worst superset supporting
> > almost every style of every other subtitles formats have, so it's used as
> > the "decoded" form for all text subtitles. For example, the SubRip (the
> > "codec", or markup you find in SRT files) decoder will transform
> > "foo" into "{\i1}foo{\i0}".
> I personally find the syntax a little unfamiliar (most styled text subtitles
> seem
> to use html), but ASS seems to be the most used text subtitle format with
> (advanced)
> styling capabilities.
>
> As a sidenode (not necessary related to this gsoc task): If someday a
> renderer is available,
> the renderer has to parse and interprete it. My naive approuch would then be
> some kind
> of tree based structure (because all markup languages I know are tree based).
> Would it
> be an idea, to parse on the decoder side already and let the internal
> structure be not text,
> but a tree (independent of the subtitleformat)?
I submitted a prototype for exactly that a few years ago¹, but in the end,
a common markup is actually pretty much fine. The thing is, libass is
available everywhere, and that's what most players use for rendering
subtitles (that's the reason why when you can find many ASS tags into
random SRT file, which are actually correctly rendered).
You can look at how the ass filter (libavfilter/subtitles.c) currently
does just passthrough the decoded AVSubtitle to the libass renderer.
[...]
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2012-November/134607.html
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 2/3] avformat/utils: increase detected start_time with skip_samples
On Tue, Mar 8, 2016 at 10:54 PM, Marton Balint wrote: > > On Tue, 8 Mar 2016, wm4 wrote: > >> On Tue, 8 Mar 2016 21:29:52 +0100 >> Marton Balint wrote: >> >>> Signed-off-by: Marton Balint >>> --- >>> libavformat/utils.c | 10 -- >>> tests/ref/fate/gapless2-ipod-aac1 | 72 >>> +++ >>> tests/ref/fate/gapless2-ipod-aac2 | 72 >>> +++ >>> 3 files changed, 80 insertions(+), 74 deletions(-) >>> > >> I'm a probably bit late here, but what's the rationale of increasing the >> start time? >> > > According to docs, start time is supposed to be the pts of the first > decoded frame, therefore skipped samples must be taken into account, when > the start time is determined based on the first packet pts. > But the skipping is performed by avcodec, not avformat, isn't it? start_time should be the PTS of the first avpacket coming out of avformat, never mind what a decoder might do to that later. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)
On 8 March 2016 at 03:48, Ganesh Ajjanagadde wrote: > This is ~2x faster for y not an integer on Haswell+GCC, and should > generally be faster due to the fact that anyway powf essentially does > this under the hood. > > Note that there are some accuracy differences, that should generally be > negligible. In particular, FATE still passes on this platform. > > Results in ~ 7% speedup in aac encoding with -march=native, Haswell+GCC. > before: > ffmpeg -i sin.flac -acodec aac -y sin_new.aac 6.05s user 0.06s system > 104% cpu 5.821 total > > after: > ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.67s user 0.03s system > 105% cpu 5.416 total > > This is also faster than an alternative approach that pulls in powf, gets > rid of > the crufty NaN checks and other special cases, exploits knowledge about > the intervals, etc. > This of course does not exclude smarter approaches; just suggests that > there would need to be significant work on this front of lower utility than > searches for hotspots elsewhere. LGTM, thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc: use generational cache instead of resetting.
On 6 March 2016 at 16:29, Reimar Döffinger wrote: > Approximately 11% faster transcoding from mp3 with > default settings. > > Signed-off-by: Reimar Döffinger > Very nice, thanks. LGTM, feel free to apply whenever you can. Can confirm I get a speedup and the output is still bit-identical before and after the patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 2/3] avformat/utils: increase detected start_time with skip_samples
On Tue, 8 Mar 2016, Hendrik Leppkes wrote: On Tue, Mar 8, 2016 at 10:54 PM, Marton Balint wrote: On Tue, 8 Mar 2016, wm4 wrote: On Tue, 8 Mar 2016 21:29:52 +0100 Marton Balint wrote: Signed-off-by: Marton Balint --- libavformat/utils.c | 10 -- tests/ref/fate/gapless2-ipod-aac1 | 72 +++ tests/ref/fate/gapless2-ipod-aac2 | 72 +++ 3 files changed, 80 insertions(+), 74 deletions(-) I'm a probably bit late here, but what's the rationale of increasing the start time? According to docs, start time is supposed to be the pts of the first decoded frame, therefore skipped samples must be taken into account, when the start time is determined based on the first packet pts. But the skipping is performed by avcodec, not avformat, isn't it? Yes. start_time should be the PTS of the first avpacket coming out of avformat, never mind what a decoder might do to that later. Not according to the docs: "AVStream->start_time: decoding: pts of the first frame of the stream in presentation order, in stream time base. Only set this if you are absolutely 100% sure that the value you set it to really is the pts of the first frame." If here frame refers to a packet, why the docs is talking about presentation order? Also check the libavformat/mp3dec.c, it does the same kind of start_time adjustment based on the skipped samples. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc_utils: Use temporary variable.
On 6 March 2016 at 20:26, Reimar Döffinger wrote: > This ensures gcc does not create unnecessary > loads or stores and possibly even does not vectorize > the negation. > Speeds up mp3 to aac transcoding with default settings > by 10% when using "gcc (Debian 5.3.1-10) 5.3.1 20160224". > > Signed-off-by: Reimar Döffinger Nice, tested it and it does give a speedup. LGTM, apply whenever you have the time ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc: use generational cache instead of resetting.
On Tue, Mar 08, 2016 at 10:40:18PM +, Rostislav Pehlivanov wrote: > On 6 March 2016 at 16:29, Reimar Döffinger wrote: > > > Approximately 11% faster transcoding from mp3 with > > default settings. > > > > Signed-off-by: Reimar Döffinger > > > > Very nice, thanks. > LGTM, feel free to apply whenever you can. Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc_utils: Use temporary variable.
On Tue, Mar 08, 2016 at 10:45:41PM +, Rostislav Pehlivanov wrote: > On 6 March 2016 at 20:26, Reimar Döffinger wrote: > > > This ensures gcc does not create unnecessary > > loads or stores and possibly even does not vectorize > > the negation. > > Speeds up mp3 to aac transcoding with default settings > > by 10% when using "gcc (Debian 5.3.1-10) 5.3.1 20160224". > > > > Signed-off-by: Reimar Döffinger > > > Nice, tested it and it does give a speedup. > > LGTM, apply whenever you have the time Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add tests for functions in hash.c
Please review the latest patch. the DST_BUF_SIZE is not AV_HASH_MAX_SIZE *
8 since AV_HASH_MAX_SIZE is 64.
Thank you,
Naga
On Sun, Mar 6, 2016 at 9:45 PM, James Almer wrote:
> On 3/7/2016 12:26 AM, NagaChaitanya Vellanki wrote:
> > ---
> > libavutil/Makefile | 1 +
> > libavutil/hash.c | 45
> +
> > tests/fate/libavutil.mak | 4
> > tests/ref/fate/hash | 45
> +
> > 4 files changed, 95 insertions(+)
> > create mode 100644 tests/ref/fate/hash
> >
> > diff --git a/libavutil/Makefile b/libavutil/Makefile
> > index 934564f..58df75a 100644
> > --- a/libavutil/Makefile
> > +++ b/libavutil/Makefile
> > @@ -186,6 +186,7 @@ TESTPROGS = adler32
>\
> > file
> \
> > fifo
> \
> > float_dsp
> \
> > +hash
> \
> > hmac
> \
> > lfg
> \
> > lls
> \
> > diff --git a/libavutil/hash.c b/libavutil/hash.c
> > index 7037b0d..ac35e88 100644
> > --- a/libavutil/hash.c
> > +++ b/libavutil/hash.c
> > @@ -237,3 +237,48 @@ void av_hash_freep(AVHashContext **ctx)
> > av_freep(&(*ctx)->ctx);
> > av_freep(ctx);
> > }
> > +
> > +#ifdef TEST
> > +// LCOV_EXCL_START
> > +#define SRC_BUF_SIZE 64
> > +#define DST_BUF_SIZE 512
>
> You should use AV_HASH_MAX_SIZE for dst. If someone goes and adds a new
> algorithm
> with a digest bigger than 64 bytes that value will change and the dst
> buffer here
> may not be enough anymore.
> AV_HASH_MAX_SIZE*4 should do it i think.
>
> > +
> > +int main(void)
> > +{
> > + struct AVHashContext *ctx = NULL;
> > + int i, j;
> > + static const uint8_t src[SRC_BUF_SIZE] = { 0 };
> > + uint8_t dst[DST_BUF_SIZE];
> > + for(i = 0; i < NUM_HASHES; i++) {
>
> Nit: Space after for.
>
> > + if(av_hash_alloc(&ctx, av_hash_names(i)) < 0) {
>
> Nit: Space after if, and no need for brackets.
>
> > + return 1;
> > + }
> > +
> > + av_hash_init(ctx);
> > + av_hash_update(ctx, src, SRC_BUF_SIZE);
> > + memset(dst, 0, DST_BUF_SIZE);
>
> memset (or even zero initializing dst) is probably not needed at all.
> hash.h doxy says hex and b64 digests are always 0-terminated, and you never
> read more than av_hash_get_size(ctx) for the binary digest.
>
> > + av_hash_final_hex(ctx, dst, DST_BUF_SIZE);
> > + printf("%s hex: %s\n", av_hash_get_name(ctx), dst);
> > +
> > + av_hash_init(ctx);
> > + av_hash_update(ctx, src, SRC_BUF_SIZE);
> > + memset(dst, 0, DST_BUF_SIZE);
> > + av_hash_final_bin(ctx, dst, DST_BUF_SIZE);
> > + printf("%s bin: ", av_hash_get_name(ctx));
> > + for(j = 0; j < av_hash_get_size(ctx); j++) {
>
> Nit: Space after for.
>
> > + printf("%#x ", dst[j]);
>
> Indentation should be four spaces.
>
> > + }
> > + printf("\n");
> > +
> > + av_hash_init(ctx);
> > + av_hash_update(ctx, src, SRC_BUF_SIZE);
> > + memset(dst, 0, DST_BUF_SIZE);
> > + av_hash_final_b64(ctx, dst, DST_BUF_SIZE);
> > + printf("%s b64: %s\n", av_hash_get_name(ctx), dst);
> > + av_hash_freep(&ctx);
> > + }
> > + return 0;
> > +}
> > +
> > +// LCOV_EXCL_STOP
> > +#endif
>
> ___
> 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] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)
Hi,
On Mon, Mar 7, 2016 at 10:48 PM, Ganesh Ajjanagadde
wrote:
> This is ~2x faster for y not an integer on Haswell+GCC, and should
> generally be faster due to the fact that anyway powf essentially does
> this under the hood.
>
> Note that there are some accuracy differences, that should generally be
> negligible. In particular, FATE still passes on this platform.
>
> Results in ~ 7% speedup in aac encoding with -march=native, Haswell+GCC.
> before:
> ffmpeg -i sin.flac -acodec aac -y sin_new.aac 6.05s user 0.06s system
> 104% cpu 5.821 total
>
> after:
> ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.67s user 0.03s system
> 105% cpu 5.416 total
>
> This is also faster than an alternative approach that pulls in powf, gets
> rid of
> the crufty NaN checks and other special cases, exploits knowledge about
> the intervals, etc.
> This of course does not exclude smarter approaches; just suggests that
> there would need to be significant work on this front of lower utility than
> searches for hotspots elsewhere.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavcodec/aacenc_utils.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
> index 56e3462..b7f80c6 100644
> --- a/libavcodec/aacenc_utils.h
> +++ b/libavcodec/aacenc_utils.h
> @@ -121,7 +121,10 @@ static inline float find_form_factor(int group_len,
> int swb_size, float thresh,
> if (s >= ethresh) {
> nzl += 1.0f;
> } else {
> -nzl += powf(s / ethresh, nzslope);
> +if (nzslope == 2.f)
> +nzl += (s / ethresh) * (s / ethresh);
> +else
> +nzl += expf(logf(s / ethresh) * nzslope);
> }
> }
>
There's two changes here. Which gives the speedup? I don't like the second
(pow -> exp(log())) if it doesn't give a speedup (I don't see why it would,
also).
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Assert that width/height/channels is 0 for the destination of av_frame*_ref()
El 08/03/16 a las 17:14, Michael Niedermayer escribió:
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 5607206..dde32b0 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -375,6 +375,9 @@ int av_frame_ref(AVFrame *dst, const AVFrame *src)
{
int i, ret = 0;
+av_assert0(dst->width == 0 && dst->height == 0);
+av_assert0(dst->channels == 0);
+
dst->format = src->format;
dst->width = src->width;
dst->height = src->height;
Why does it matter what dst->width/height is originally? They are
overwritten right after.
--
Gonzalo Garramuño
ggarr...@gmail.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Support seek in encrypted MP4
On Tue, Mar 08, 2016 at 09:13:30PM +, Eran Kornblau wrote: > > > > check tests/fate/seek.mak > > also you can pass parameters to seek-test see fate-seek-cache-pipe > > i dont know if there is anything else special needed for this > > > Thanks Michael, I looked at this some more, and there's one thing that I'm > still > missing - where do I get the sample encrypted file from ? > > As I understand, I can either: > 1. Generate one on the machine running the tests - in this case, where do I > write > the ffmpeg command line for doing that ? see for example: fate-filter-hls > 2. Upload a sample, that will later be pulled by 'make fate-rsync' - in this > option, > what is the process for submitting such samples ? you can just add a url to the file, i can add it to the fate samples but in that case the file should be small as thousands of samples add up ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add tests for functions in hash.c
On 3/8/2016 2:21 AM, NagaChaitanya Vellanki wrote: > --- > libavutil/Makefile | 1 + > libavutil/hash.c | 42 ++ > tests/fate/libavutil.mak | 4 > tests/ref/fate/hash | 45 + > 4 files changed, 92 insertions(+) > create mode 100644 tests/ref/fate/hash LGTM. I'll let the maintainer give the final ok and push it (CCing him as well). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/avidec: Skip xxpc entries in index
Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
entries.
Implementation of 'xxpc' index entry storage for seeking will come in
the future (provided I can manage it).
Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks which
would previously cause "stream_ptr out of bounds" error messages to be
emitted in the msvideo1 decoder:
https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 956242f96307f3b145c3570bccf250299a455e59 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 9 Mar 2016 02:44:55 +0100
Subject: [PATCH] lavf/avidec: Skip xxpc entries in index
---
libavformat/avidec.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index eaf8421..49c97d9 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -1581,6 +1581,9 @@ static int avi_read_idx1(AVFormatContext *s, int size)
st = s->streams[index];
ast = st->priv_data;
+if ((tag >> 16 & 0xff) == 'p' && (tag >> 24 & 0xff) == 'c')
+continue;
+
if (first_packet && first_packet_pos) {
if (avi->movi_list + 4 != pos || pos + 500 > first_packet_pos)
data_offset = first_packet_pos - pos;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: Assert that width/height/channels is 0 for the destination of av_frame*_ref()
On Tue, Mar 08, 2016 at 10:24:55PM -0300, Gonzalo wrote:
>
>
> El 08/03/16 a las 17:14, Michael Niedermayer escribió:
> >diff --git a/libavutil/frame.c b/libavutil/frame.c
> >index 5607206..dde32b0 100644
> >--- a/libavutil/frame.c
> >+++ b/libavutil/frame.c
> >@@ -375,6 +375,9 @@ int av_frame_ref(AVFrame *dst, const AVFrame *src)
> > {
> > int i, ret = 0;
> >+av_assert0(dst->width == 0 && dst->height == 0);
> >+av_assert0(dst->channels == 0);
> >+
> > dst->format = src->format;
> > dst->width = src->width;
> > dst->height = src->height;
> Why does it matter what dst->width/height is originally? They are
> overwritten right after.
it is to detect if the user calls the functions in the wrong order
which would otherwise trigger memleaks and or undefined behavior
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/avidec: Skip xxpc entries in index
On 03/09/2016 02:54 AM, Mats Peterson wrote: Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change) entries. Indices, not indexes. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)
On 9 March 2016 at 01:02, Ronald S. Bultje wrote: > Hi, > > On Mon, Mar 7, 2016 at 10:48 PM, Ganesh Ajjanagadde > wrote: > > > This is ~2x faster for y not an integer on Haswell+GCC, and should > > generally be faster due to the fact that anyway powf essentially does > > this under the hood. > There's two changes here. Which gives the speedup? I don't like the second > (pow -> exp(log())) if it doesn't give a speedup (I don't see why it would, > also). > > Ronald Since the function is supposed to be inlined maybe GCC is clever enough not to have a separate branch for the case where nzslope == 2 for that particular usage of the function? Not sure though. I did see a slight speed increase just above the noise. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)
On Tue, Mar 8, 2016 at 9:10 PM, Rostislav Pehlivanov wrote: > On 9 March 2016 at 01:02, Ronald S. Bultje wrote: > >> Hi, >> >> On Mon, Mar 7, 2016 at 10:48 PM, Ganesh Ajjanagadde >> wrote: >> >> > This is ~2x faster for y not an integer on Haswell+GCC, and should >> > generally be faster due to the fact that anyway powf essentially does >> > this under the hood. >> > There's two changes here. Which gives the speedup? I don't like the second >> (pow -> exp(log())) if it doesn't give a speedup (I don't see why it would, >> also). >> >> Ronald > > > Since the function is supposed to be inlined maybe GCC is clever enough not > to have a separate branch for the case where nzslope == 2 for that > particular usage of the function? Not sure though. I did see a slight speed > increase just above the noise. As discussed with Reimar, there are integer power optimizations for powf. The speedup actually comes from the pow -> exp(log()) as suggested by the commit heading. The reason the branch now needs to be manually inserted is that exp(log()*) can't use the integer optimizations. > ___ > 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] aacenc_utils: unroll loops to allow compiler to use SIMD.
On Tue, Mar 8, 2016 at 2:30 PM, Reimar Döffinger wrote: > On Mon, Mar 07, 2016 at 10:50:53PM -0500, Ganesh Ajjanagadde wrote: >> On Mon, Mar 7, 2016 at 2:54 AM, Reimar Döffinger >> wrote: >> >> Can you be more specific, and are you sure about this? >> > >> > Just run your favourite performance analysis tool and you'll see. >> > As it is non-inlined libc code I'm fairly sure the numbers are accurate >> > enough. >> >> I am still puzzled by the remarks; and hence asked for specific >> examples. In aac code, cosf is only called for table generation, same >> with cos, so still don't see why cos is relevant. > > You seem to have missed ff_lpc_calc_ref_coefs_f. > At least it's that function that is to blame for > the cos calls I saw in the profiler. Ah, now I understand - ff_lpc_calc_refs_coefs_f' is defined in lavc/lpc, I was only looking internally at lavc/aac*. Thanks for the heads up. Seems like cos() symmetry can be exploited at the very least. Does not seem like len is a power of 2, so can't directly use cos tables. > ___ > 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] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)
On Tue, Mar 8, 2016 at 8:02 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Mar 7, 2016 at 10:48 PM, Ganesh Ajjanagadde
> wrote:
>>
>> This is ~2x faster for y not an integer on Haswell+GCC, and should
>> generally be faster due to the fact that anyway powf essentially does
>> this under the hood.
>>
>> Note that there are some accuracy differences, that should generally be
>> negligible. In particular, FATE still passes on this platform.
>>
>> Results in ~ 7% speedup in aac encoding with -march=native, Haswell+GCC.
>> before:
>> ffmpeg -i sin.flac -acodec aac -y sin_new.aac 6.05s user 0.06s system
>> 104% cpu 5.821 total
>>
>> after:
>> ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.67s user 0.03s system
>> 105% cpu 5.416 total
>>
>> This is also faster than an alternative approach that pulls in powf, gets
>> rid of
>> the crufty NaN checks and other special cases, exploits knowledge about
>> the intervals, etc.
>> This of course does not exclude smarter approaches; just suggests that
>> there would need to be significant work on this front of lower utility
>> than
>> searches for hotspots elsewhere.
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavcodec/aacenc_utils.h | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
>> index 56e3462..b7f80c6 100644
>> --- a/libavcodec/aacenc_utils.h
>> +++ b/libavcodec/aacenc_utils.h
>> @@ -121,7 +121,10 @@ static inline float find_form_factor(int group_len,
>> int swb_size, float thresh,
>> if (s >= ethresh) {
>> nzl += 1.0f;
>> } else {
>> -nzl += powf(s / ethresh, nzslope);
>> +if (nzslope == 2.f)
>> +nzl += (s / ethresh) * (s / ethresh);
>> +else
>> +nzl += expf(logf(s / ethresh) * nzslope);
>> }
>> }
>
>
> There's two changes here. Which gives the speedup? I don't like the second
> (pow -> exp(log())) if it doesn't give a speedup (I don't see why it would,
> also).
The empirical fact of 2x speedup for non-integer is already mentioned.
The rationale was also briefly explained in the message.
More verbosely, there is no "fundamental" reason why it should, but
empirically it is reasonable since pow needs to handle a ton of edge
cases, and needs correction terms around what it is "morally" doing,
i.e exp(log(x)). Just look at
https://github.com/JuliaLang/openlibm/blob/master/src/e_powf.c
(implementation used in GNU/BSD/Apple libm).
>
> Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function
Yields 2x improvement in function performance, and boosts aac encoding
speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native):
after:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.22s user 0.03s system 105% cpu
4.970 total
before:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.40s user 0.05s system 105% cpu
5.162 total
Big shame that len-1 is -1 mod 4; 0 mod 4 would have yielded a further 2x
through
additional symmetry. Of course, one could approximate with the 0 mod 4 variant,
error would essentially be ~ 1/len in the worst case.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/lpc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/lpc.c b/libavcodec/lpc.c
index 3839119..052aeaa 100644
--- a/libavcodec/lpc.c
+++ b/libavcodec/lpc.c
@@ -176,9 +176,10 @@ double ff_lpc_calc_ref_coefs_f(LPCContext *s, const float
*samples, int len,
const double a = 0.5f, b = 1.0f - a;
/* Apply windowing */
-for (i = 0; i < len; i++) {
+for (i = 0; i <= len / 2; i++) {
double weight = a - b*cos((2*M_PI*i)/(len - 1));
s->windowed_samples[i] = weight*samples[i];
+s->windowed_samples[len-1-i] = weight*samples[len-1-i];
}
s->lpc_compute_autocorr(s->windowed_samples, len, order, autoc);
--
2.7.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)
On 08.03.2016, at 04:48, Ganesh Ajjanagadde wrote: > +nzl += expf(logf(s / ethresh) * nzslope); Shouldn't log2f/exp2f be faster? log2f at least has CPU support on x86 AFAICT. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/lpc: exploit even symmetry of window function
On 09.03.2016, at 04:16, Ganesh Ajjanagadde wrote: > Yields 2x improvement in function performance, and boosts aac encoding > speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native): > after: > ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.22s user 0.03s system 105% > cpu 4.970 total > > before: > ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.40s user 0.05s system 105% > cpu 5.162 total > > Big shame that len-1 is -1 mod 4; 0 mod 4 would have yielded a further 2x > through > additional symmetry. Of course, one could approximate with the 0 mod 4 > variant, > error would essentially be ~ 1/len in the worst case. Note that I have no idea why we are using double here (is there a good reason?) It doesn't really matter for the rest of the code, but cosf is also at least twice as fast as cos... Probably has smaller error than fudging for symmetry and should be enough to push the speed cost of this function close to negligible. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
