Re: [FFmpeg-devel] [PATCH 1/4] lavc/h264: move green meta logging out of the sei decoding
On Tue, Jun 14, 2016 at 12:01:25AM +0200, Hendrik Leppkes wrote: > On Mon, Jun 13, 2016 at 11:02 PM, Clément Bœsch wrote: > > This will simplify the next Libav merge where SEI decoding doesn't have > > access to the debug level anymore. > > This whole business looks rather fragile and wtf'ish, but its better > then before and should be fine. So the entire set LGTM. patchset applied, thanks -- 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] [PATCH 1/5] rtpdec_vp9: Make sure to free the temp buffer on close
On 13.06.2016 21:03, Thomas Volkert wrote:
From: Martin Storsjö
Signed-off-by: Martin Storsjö
---
libavformat/rtpdec_vp9.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/rtpdec_vp9.c b/libavformat/rtpdec_vp9.c
index e50bede..7b1c38f 100644
--- a/libavformat/rtpdec_vp9.c
+++ b/libavformat/rtpdec_vp9.c
@@ -279,11 +279,17 @@ static int vp9_handle_packet(AVFormatContext *ctx,
PayloadContext *rtp_vp9_ctx,
return 0;
}
+static void vp9_close_context(PayloadContext *vp9)
+{
+ffio_free_dyn_buf(&vp9->buf);
+}
+
RTPDynamicProtocolHandler ff_vp9_dynamic_handler = {
.enc_name = "VP9",
.codec_type = AVMEDIA_TYPE_VIDEO,
.codec_id = AV_CODEC_ID_VP9,
.priv_data_size = sizeof(PayloadContext),
.init = vp9_init,
+.close= vp9_close_context,
.parse_packet = vp9_handle_packet
};
all 5 patches pushed
Best regards,
Thomas.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/os_support.h: Fix for unicode filenames on windows.
This patch seems to break build with decklink in MinGW: In file included from C:/builds/ab-full/build/ffmpeg-git/libavformat/internal.h:28:0, from C:/builds/ab-full/build/ffmpeg-git/libavdevice/decklink_common.cpp:34: C:/builds/ab-full/build/ffmpeg-git/libavformat/os_support.h: In function 'int win32_stat(const char*, _stati64*)': C:/builds/ab-full/build/ffmpeg-git/libavformat/os_support.h:196:32: error: cannot convert '_stati64*' to '_stat64*' for argument '2' to 'int _wstat64(const wchar_t*, _stat64*)' ret = wfunc(filename_w, par); \ ^ C:/builds/ab-full/build/ffmpeg-git/libavformat/os_support.h:206:1: note: in expansion of macro 'DEF_FS_FUNCTION2' DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*) ^ C:/builds/ab-full/build/ffmpeg-git/libavformat/os_support.h:202:36: error: cannot convert '_stati64*' to '_stat64*' for argument '2' to 'int _stat64(const char*, _stat64*)' return afunc(filename_utf8, par); \ ^ C:/builds/ab-full/build/ffmpeg-git/libavformat/os_support.h:206:1: note: in expansion of macro 'DEF_FS_FUNCTION2' DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*) ^ make: *** [/build/ffmpeg-git/common.mak:63: libavdevice/decklink_common.o] Error 1 $ make CXX libavdevice/decklink_common.o cc1plus.exe: warning: command line option '-Wdeclaration-after-statement' is valid for C/ObjC but not for C++ cc1plus.exe: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ cc1plus.exe: warning: command line option '-Wno-pointer-to-int-cast' is valid for C/ObjC but not for C++ cc1plus.exe: warning: command line option '-Wstrict-prototypes' is valid for C/ObjC but not for C++ cc1plus.exe: warning: command line option '-Wno-pointer-sign' is valid for C/ObjC but not for C++ cc1plus.exe: warning: command line option '-std=c99' is valid for C/ObjC but not for C++ In file included from C:/builds/ab-full/build/ffmpeg-git/libavformat/os_support.h:112:0, from C:/builds/ab-full/build/ffmpeg-git/libavformat/internal.h:28, from C:/builds/ab-full/build/ffmpeg-git/libavdevice/decklink_common.cpp:34: C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h [-Wcpp] #warning Please include winsock2.h before windows.h ^ In file included from C:/builds/ab-full/build/ffmpeg-git/libavdevice/decklink_common.cpp:22:0: C:/builds/ab-full/local32/include/DeckLinkAPI.h:20697:69: warning: redundant redeclaration of 'ULONG BSTR_UserSize(ULONG*, ULONG, OLECHAR**)' in same scope [-Wredundant-decls] ULONG __RPC_USER BSTR_UserSize (ULONG *, ULONG, BSTR *); ^ In file included from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/objbase.h:164:0, from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/ole2.h:17, from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/wtypes.h:12, from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/winscard.h:10, from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/windows.h:97, from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/rpc.h:16, from C:/builds/ab-full/local32/include/DeckLinkAPI.h:7, from C:/builds/ab-full/build/ffmpeg-git/libavdevice/decklink_common.cpp:22: C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/propidl.h:1287:28: note: previous declaration of 'ULONG BSTR_UserSize(ULONG*, ULONG, OLECHAR**)' ULONG __RPC_USER BSTR_UserSize (ULONG *, ULONG, BSTR *); ^ In file included from C:/builds/ab-full/build/ffmpeg-git/libavdevice/decklink_common.cpp:22:0: C:/builds/ab-full/local32/include/DeckLinkAPI.h:20698:79: warning: redundant redeclaration of 'unsigned char* BSTR_UserMarshal(ULONG*, unsigned char*, OLECHAR**)' in same scope [-Wredundant-decls] unsigned char * __RPC_USER BSTR_UserMarshal (ULONG *, unsigned char *, BSTR *); ^ In file included from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/objbase.h:164:0, from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/ole2.h:17, from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/wtypes.h:12, from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/winscard.h:10, from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/windows.h:97, from C:/builds/ab-full/msys64/mingw32/i686-w64-mingw32/include/rpc.h:16, from C:/builds/ab-full/local32/include/DeckLinkAPI.h:7, from C:/builds/ab-full/
Re: [FFmpeg-devel] [PATCH] fate: add afade tes
On Mon, Jun 13, 2016 at 01:34:39PM +0700, Muhammad Faiz wrote: > On Sun, Jun 12, 2016 at 8:14 PM, Michael Niedermayer > wrote: > > On Sun, Jun 12, 2016 at 09:37:28AM +, Petru Rares Sincraian wrote: > >> Hi there, > >> > >> I'm sorry, I hadn't considered mingw. Here is the patch without the > >> filter-afade-ihsin. > > > > applied > > > fail without SAMPLES should be fixed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] lavc/h264: move green meta logging out of the sei decoding
On Mon, Jun 13, 2016 at 11:02 PM, Clément Bœsch wrote: > This will simplify the next Libav merge where SEI decoding doesn't have > access to the debug level anymore. This whole business looks rather fragile and wtf'ish, but its better then before and should be fine. So the entire set LGTM. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] rtpdec_h264: Use avpriv_report_missing_feature instead of a manual av_log
On Mon, Jun 13, 2016 at 09:03:21PM +0200, Thomas Volkert wrote: > From: Martin Storsjö > > Signed-off-by: Martin Storsjö > --- > libavformat/rtpdec_h264.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FTP graceful close data connection to avoid server abort
On 02.06.2016 14:29, Camille Gonnet wrote:
When writing files to FTP, if the data connection is closed before the
control connection, the server may handle it as an aborted file transfer
and create and leave the file empty.
---
libavformat/ftp.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavformat/ftp.c b/libavformat/ftp.c
index 0663b47..00747bb 100644
--- a/libavformat/ftp.c
+++ b/libavformat/ftp.c
@@ -220,15 +220,21 @@ static int ftp_send_command(FTPContext *s, const char
*command,
static void ftp_close_data_connection(FTPContext *s)
{
-ffurl_closep(&s->conn_data);
+static const int close_codes[] = {225, 226, 0};
+
+if (s->conn_data) {
+ffurl_closep(&s->conn_data);
+// Need to wait for status, or file transfer might be aborted on
server side
+ftp_status(s, NULL, close_codes);
+}
s->position = 0;
s->state = DISCONNECTED;
}
This is not working. ./ffplay ftp://user:pass@localhost/1.avi hangs at
startup. It was working for you because (probably) your writing
operation didn't perform seeking (did you enabled ftp-write-seekable?).
During seek operation, when seek is really done, ftp_abort is called and
there is ftp_close_data_connection called with status check followed. So
status is checked twice while sent by server just once.
I can work it out, but just tell what server has this issue. Perfectly
setup some account for me. You can of course work it out yourself, but
please test also other scenarios and other servers.
First thing to check is to revert patch completely and replace
ftp_close_both_connections by ftp_abort inside ftp_close function.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] Add support for vp9 in iso-bmff
Implemented according to the draft specification
"VP Codec ISO Media File Format Binding":
http://www.webmproject.org/vp9/#draft-vp-codec-iso-media-file-format-binding
Change-Id: Iaa7ddf5524b17e8d79cd1923b26f096d6e91
---
libavformat/Makefile | 2 +-
libavformat/isom.c | 3 +
libavformat/movenc.c | 26 +
libavformat/vpc.c| 151 +++
libavformat/vpc.h| 44 +++
5 files changed, 225 insertions(+), 1 deletion(-)
create mode 100644 libavformat/vpc.c
create mode 100644 libavformat/vpc.h
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6684ead..be8c261 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -276,7 +276,7 @@ OBJS-$(CONFIG_MM_DEMUXER)+= mm.o
OBJS-$(CONFIG_MMF_DEMUXER) += mmf.o
OBJS-$(CONFIG_MMF_MUXER) += mmf.o rawenc.o
OBJS-$(CONFIG_MOV_DEMUXER) += mov.o mov_chan.o replaygain.o
-OBJS-$(CONFIG_MOV_MUXER) += movenc.o avc.o hevc.o \
+OBJS-$(CONFIG_MOV_MUXER) += movenc.o avc.o hevc.o vpc.o \
movenchint.o mov_chan.o rtp.o \
movenccenc.o rawutils.o
OBJS-$(CONFIG_MP2_MUXER) += mp3enc.o rawenc.o id3v2enc.o
diff --git a/libavformat/isom.c b/libavformat/isom.c
index b1757e2..9a65268 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -59,6 +59,7 @@ const AVCodecTag ff_mp4_obj_type[] = {
{ AV_CODEC_ID_AC3 , 0xA5 },
{ AV_CODEC_ID_EAC3, 0xA6 },
{ AV_CODEC_ID_DTS , 0xA9 }, /* mp4ra.org */
+{ AV_CODEC_ID_VP9 , 0xC0 }, /* non standard, update when there is
a standard value */
{ AV_CODEC_ID_TSCC2 , 0xD0 }, /* non standard, camtasia uses it */
{ AV_CODEC_ID_VORBIS , 0xDD }, /* non standard, gpac uses it */
{ AV_CODEC_ID_DVD_SUBTITLE, 0xE0 }, /* non standard, see
unsupported-embedded-subs-2.mp4 */
@@ -179,6 +180,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
{ AV_CODEC_ID_H264, MKTAG('a', 'i', 'v', 'x') }, /* XAVC 4:2:2 10bit */
{ AV_CODEC_ID_H264, MKTAG('r', 'v', '6', '4') }, /* X-Com Radvision */
+{ AV_CODEC_ID_VP9, MKTAG('v', 'p', '0', '9') }, /* VP9 */
+
{ AV_CODEC_ID_MPEG1VIDEO, MKTAG('m', '1', 'v', ' ') },
{ AV_CODEC_ID_MPEG1VIDEO, MKTAG('m', '1', 'v', '1') }, /* Apple MPEG-1
Camcorder */
{ AV_CODEC_ID_MPEG1VIDEO, MKTAG('m', 'p', 'e', 'g') }, /* MPEG */
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 2f00091..551f0e6 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -49,6 +49,7 @@
#include "hevc.h"
#include "rtpenc.h"
#include "mov_chan.h"
+#include "vpc.h"
static const AVOption options[] = {
{ "movflags", "MOV muxer flags", offsetof(MOVMuxContext, flags),
AV_OPT_TYPE_FLAGS, {.i64 = 0}, INT_MIN, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM,
"movflags" },
@@ -1039,6 +1040,17 @@ static int mov_write_avcc_tag(AVIOContext *pb, MOVTrack
*track)
return update_size(pb, pos);
}
+static int mov_write_vpcc_tag(AVIOContext *pb, MOVTrack *track)
+{
+int64_t pos = avio_tell(pb);
+
+avio_wb32(pb, 0);
+ffio_wfourcc(pb, "vpcC");
+avio_wb32(pb, 0); /* version & flags */
+ff_isom_write_vpcc(pb, track->par);
+return update_size(pb, pos);
+}
+
static int mov_write_hvcc_tag(AVIOContext *pb, MOVTrack *track)
{
int64_t pos = avio_tell(pb);
@@ -1143,6 +1155,7 @@ static int mp4_get_codec_tag(AVFormatContext *s, MOVTrack
*track)
if (track->par->codec_id == AV_CODEC_ID_H264) tag =
MKTAG('a','v','c','1');
else if (track->par->codec_id == AV_CODEC_ID_HEVC) tag =
MKTAG('h','e','v','1');
+else if (track->par->codec_id == AV_CODEC_ID_VP9) tag =
MKTAG('v','p','0','9');
else if (track->par->codec_id == AV_CODEC_ID_AC3) tag =
MKTAG('a','c','-','3');
else if (track->par->codec_id == AV_CODEC_ID_EAC3) tag =
MKTAG('e','c','-','3');
else if (track->par->codec_id == AV_CODEC_ID_DIRAC) tag =
MKTAG('d','r','a','c');
@@ -1758,6 +1771,8 @@ static int mov_write_video_tag(AVIOContext *pb,
MOVMuxContext *mov, MOVTrack *tr
mov_write_avcc_tag(pb, track);
if (track->mode == MODE_IPOD)
mov_write_uuid_tag_ipod(pb);
+} else if (track->par->codec_id == AV_CODEC_ID_VP9) {
+mov_write_vpcc_tag(pb, track);
} else if (track->par->codec_id == AV_CODEC_ID_VC1 && track->vos_len > 0)
mov_write_dvc1_tag(pb, track);
else if (track->par->codec_id == AV_CODEC_ID_VP6F ||
@@ -5369,6 +5384,17 @@ static int mov_write_header(AVFormatContext *s)
pix_fmt == AV_PIX_FMT_MONOWHITE ||
pix_fmt == AV_PIX_FMT_MONOBLACK;
}
+if (track->mode == MODE_MP4 &&
+track->par->codec_id == AV_CODEC_ID_VP9) {
+ if (s->strict_std_compliance > FF_COMPLIANCE_EXPERIMEN
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/os_support.h: Fix for unicode filenames on windows.
On Tue, Jun 14, 2016 at 07:08:58AM +1000, Matt Oliver wrote:
> On 13 June 2016 at 18:29, Benoit Fouet wrote:
>
> > Hi,
> >
> >
> >
> > On 13/06/2016 10:21, Clément Bœsch wrote:
> >
> >> On Mon, Jun 13, 2016 at 05:50:18AM +0200, Matt Oliver wrote:
> >>
> >>> ffmpeg | branch: master | Matt Oliver | Mon Jun
> >>> 6 17:04:39 2016 +1000| [37787f261639c53998487400e874741c17e85fc6] |
> >>> committer: Matt Oliver
> >>>
> >>> lavf/os_support.h: Fix for unicode filenames on windows.
> >>>
> >>> Fixes #819 #5256 #5281
> >>>
> >>> Signed-off-by: Matt Oliver
> >>>
> >>>
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=37787f261639c53998487400e874741c17e85fc6
>
> >>> ---
> >>>
> >>> libavformat/file.c |4
> >>> libavformat/os_support.h | 24
> >>> 2 files changed, 28 insertions(+)
> >>>
> >>> diff --git a/libavformat/file.c b/libavformat/file.c
> >>> index 5765ce7..264542a 100644
> >>> --- a/libavformat/file.c
> >>> +++ b/libavformat/file.c
> >>> @@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
> >>> ret |= AVIO_FLAG_WRITE;
> >>> #else
> >>> struct stat st;
> >>> +# ifndef _WIN32
> >>> ret = stat(filename, &st);
> >>> +# else
> >>> +ret = win32_stat(filename, &st);
> >>> +# endif
> >>>
> >> why this chunk?
> >>
> >> if (ret < 0)
> >>> return AVERROR(errno);
> >>> diff --git a/libavformat/os_support.h b/libavformat/os_support.h
> >>> index a332911..9e312a5 100644
> >>> --- a/libavformat/os_support.h
> >>> +++ b/libavformat/os_support.h
> >>> @@ -182,6 +182,29 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
> >>> DEF_FS_FUNCTION(mkdir, _wmkdir, _mkdir)
> >>> DEF_FS_FUNCTION(rmdir, _wrmdir , _rmdir)
> >>> +#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
> >>> +static inline int win32_##name(const char *filename_utf8, partype par) \
> >>> +{ \
> >>> +wchar_t *filename_w; \
> >>> +int ret; \
> >>> + \
> >>> +if (utf8towchar(filename_utf8, &filename_w)) \
> >>> +return -1;\
> >>> +if (!filename_w) \
> >>> +goto fallback;\
> >>> + \
> >>> +ret = wfunc(filename_w, par); \
> >>> +av_free(filename_w); \
> >>> +return ret; \
> >>> + \
> >>> +fallback: \
> >>> +/* filename may be be in CP_ACP */\
> >>> +return afunc(filename_utf8, par); \
> >>> +}
> >>> +
> >>> +DEF_FS_FUNCTION2(access, _waccess, _access, int)
> >>> +DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*)
> >>> +
> >>> static inline int win32_rename(const char *src_utf8, const char
> >>> *dest_utf8)
> >>> {
> >>> wchar_t *src_w, *dest_w;
> >>> @@ -231,6 +254,7 @@ fallback:
> >>> #define rename win32_rename
> >>> #define rmdir win32_rmdir
> >>> #define unlink win32_unlink
> >>> +#define access win32_access
> >>>
> >>>
> >> ...instead of #define stat win32_stat here?
> >>
> >
> > as already noted by someone else, this should be
> > #define stat(a, b) win32_stat((a), (b))
> > in order not to conflict with "struct stat" definition.
> >
>
> As stated in the original patch thread a define for the win32_stat function
> can not be used as there is already a define for the 'stat' struct.
> So using:
> #define stat(a, b) win32_stat((a), (b))
> clashes with the existing
> #define stat _stat64
>
> Since there is a stat function and a stat struct then a macro can only be
> used for one of them and there is already an object macro for the stat
> struct.
> If the suggested "#define stat(a, b) win32_stat((a), (b))" was added this
> overrides the struct macro causing the compiler not to use _stat64 and use
> a 32 variant instead which results in memory corruption.
Sorry, I wasn't following the thread, I just happened to read cvslog.
A comment in the source would probably be welcome though, no one is going
to be aware of these discussions in the future.
--
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] [FFmpeg-cvslog] lavf/os_support.h: Fix for unicode filenames on windows.
On 13 June 2016 at 18:29, Benoit Fouet wrote:
> Hi,
>
>
>
> On 13/06/2016 10:21, Clément Bœsch wrote:
>
>> On Mon, Jun 13, 2016 at 05:50:18AM +0200, Matt Oliver wrote:
>>
>>> ffmpeg | branch: master | Matt Oliver | Mon Jun
>>> 6 17:04:39 2016 +1000| [37787f261639c53998487400e874741c17e85fc6] |
>>> committer: Matt Oliver
>>>
>>> lavf/os_support.h: Fix for unicode filenames on windows.
>>>
>>> Fixes #819 #5256 #5281
>>>
>>> Signed-off-by: Matt Oliver
>>>
>>>
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=37787f261639c53998487400e874741c17e85fc6
>>> ---
>>>
>>> libavformat/file.c |4
>>> libavformat/os_support.h | 24
>>> 2 files changed, 28 insertions(+)
>>>
>>> diff --git a/libavformat/file.c b/libavformat/file.c
>>> index 5765ce7..264542a 100644
>>> --- a/libavformat/file.c
>>> +++ b/libavformat/file.c
>>> @@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
>>> ret |= AVIO_FLAG_WRITE;
>>> #else
>>> struct stat st;
>>> +# ifndef _WIN32
>>> ret = stat(filename, &st);
>>> +# else
>>> +ret = win32_stat(filename, &st);
>>> +# endif
>>>
>> why this chunk?
>>
>> if (ret < 0)
>>> return AVERROR(errno);
>>> diff --git a/libavformat/os_support.h b/libavformat/os_support.h
>>> index a332911..9e312a5 100644
>>> --- a/libavformat/os_support.h
>>> +++ b/libavformat/os_support.h
>>> @@ -182,6 +182,29 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
>>> DEF_FS_FUNCTION(mkdir, _wmkdir, _mkdir)
>>> DEF_FS_FUNCTION(rmdir, _wrmdir , _rmdir)
>>> +#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
>>> +static inline int win32_##name(const char *filename_utf8, partype par) \
>>> +{ \
>>> +wchar_t *filename_w; \
>>> +int ret; \
>>> + \
>>> +if (utf8towchar(filename_utf8, &filename_w)) \
>>> +return -1;\
>>> +if (!filename_w) \
>>> +goto fallback;\
>>> + \
>>> +ret = wfunc(filename_w, par); \
>>> +av_free(filename_w); \
>>> +return ret; \
>>> + \
>>> +fallback: \
>>> +/* filename may be be in CP_ACP */\
>>> +return afunc(filename_utf8, par); \
>>> +}
>>> +
>>> +DEF_FS_FUNCTION2(access, _waccess, _access, int)
>>> +DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*)
>>> +
>>> static inline int win32_rename(const char *src_utf8, const char
>>> *dest_utf8)
>>> {
>>> wchar_t *src_w, *dest_w;
>>> @@ -231,6 +254,7 @@ fallback:
>>> #define rename win32_rename
>>> #define rmdir win32_rmdir
>>> #define unlink win32_unlink
>>> +#define access win32_access
>>>
>>>
>> ...instead of #define stat win32_stat here?
>>
>
> as already noted by someone else, this should be
> #define stat(a, b) win32_stat((a), (b))
> in order not to conflict with "struct stat" definition.
>
As stated in the original patch thread a define for the win32_stat function
can not be used as there is already a define for the 'stat' struct.
So using:
#define stat(a, b) win32_stat((a), (b))
clashes with the existing
#define stat _stat64
Since there is a stat function and a stat struct then a macro can only be
used for one of them and there is already an object macro for the stat
struct.
If the suggested "#define stat(a, b) win32_stat((a), (b))" was added this
overrides the struct macro causing the compiler not to use _stat64 and use
a 32 variant instead which results in memory corruption.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] rtpdec: Use AVERROR_PATCHWELCOME instead of AVERROR(ENOSYS) for unimplemented features
On Mon, Jun 13, 2016 at 09:03:20PM +0200, Thomas Volkert wrote: > From: Martin Storsjö > > Signed-off-by: Martin Storsjö > --- > libavformat/rtpdec_h264.c | 2 +- LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] lavc/h264_sei: fix broken style around green metadata code
---
libavcodec/h264.h | 10 +-
libavcodec/h264_sei.c | 30 ++
2 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index 8c7a537..b156805 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -293,13 +293,13 @@ typedef struct FPA {
} FPA;
/**
- * Green MetaData Information Type
+ * Green MetaData Information Type
*/
typedef struct H264SEIGreenMetaData {
-uint8_t green_metadata_type;
-uint8_t period_type;
-uint16_t num_seconds;
-uint16_t num_pictures;
+uint8_t green_metadata_type;
+uint8_t period_type;
+uint16_t num_seconds;
+uint16_t num_pictures;
uint8_t percent_non_zero_macroblocks;
uint8_t percent_intra_coded_macroblocks;
uint8_t percent_six_tap_filtering;
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index ab98c27..8fcaa61 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -363,28 +363,26 @@ static int decode_display_orientation(H264Context *h)
return 0;
}
-static int decode_GreenMetadata(H264SEIGreenMetaData *h, GetBitContext *gb)
+static int decode_green_metadata(H264SEIGreenMetaData *h, GetBitContext *gb)
{
-h->green_metadata_type=get_bits(gb, 8);
+h->green_metadata_type = get_bits(gb, 8);
-if (h->green_metadata_type==0){
-h->period_type=get_bits(gb, 8);
+if (h->green_metadata_type == 0) {
+h->period_type = get_bits(gb, 8);
-if (h->period_type==2){
+if (h->period_type == 2)
h->num_seconds = get_bits(gb, 16);
-}
-else if (h->period_type==3){
+else if (h->period_type == 3)
h->num_pictures = get_bits(gb, 16);
-}
-h->percent_non_zero_macroblocks=get_bits(gb, 8);
-h->percent_intra_coded_macroblocks=get_bits(gb, 8);
-h->percent_six_tap_filtering=get_bits(gb, 8);
-h->percent_alpha_point_deblocking_instance=get_bits(gb, 8);
+h->percent_non_zero_macroblocks= get_bits(gb, 8);
+h->percent_intra_coded_macroblocks = get_bits(gb, 8);
+h->percent_six_tap_filtering = get_bits(gb, 8);
+h->percent_alpha_point_deblocking_instance = get_bits(gb, 8);
-}else if( h->green_metadata_type==1){
-h->xsd_metric_type=get_bits(gb, 8);
-h->xsd_metric_value=get_bits(gb, 16);
+} else if (h->green_metadata_type == 1) {
+h->xsd_metric_type = get_bits(gb, 8);
+h->xsd_metric_value = get_bits(gb, 16);
}
return 0;
@@ -443,7 +441,7 @@ int ff_h264_decode_sei(H264Context *h)
ret = decode_display_orientation(h);
break;
case SEI_TYPE_GREEN_METADATA:
-ret = decode_GreenMetadata(&h->sei_green_metadata, &h->gb);
+ret = decode_green_metadata(&h->sei_green_metadata, &h->gb);
break;
default:
av_log(h->avctx, AV_LOG_DEBUG, "unknown SEI type %d\n", type);
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] lavc/h264: move green meta logging out of the sei decoding
This will simplify the next Libav merge where SEI decoding doesn't have
access to the debug level anymore.
---
libavcodec/h264.c | 30 ++
libavcodec/h264_sei.c | 33 -
2 files changed, 30 insertions(+), 33 deletions(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 367f6bf..46eaec2 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -959,6 +959,34 @@ static int get_last_needed_nal(H264Context *h)
return nals_needed;
}
+static void debug_green_metadata(const GreenMetaData *gm, void *logctx)
+{
+av_log(logctx, AV_LOG_DEBUG, "Green Metadata Info SEI message\n");
+av_log(logctx, AV_LOG_DEBUG, " green_metadata_type: %d\n",
gm->green_metadata_type);
+
+if (gm->green_metadata_type == 0) {
+av_log(logctx, AV_LOG_DEBUG, " green_metadata_period_type: %d\n",
gm->period_type);
+
+if (gm->period_type == 2)
+av_log(logctx, AV_LOG_DEBUG, " green_metadata_num_seconds: %d\n",
gm->num_seconds);
+else if (gm->period_type == 3)
+av_log(logctx, AV_LOG_DEBUG, " green_metadata_num_pictures:
%d\n", gm->num_pictures);
+
+av_log(logctx, AV_LOG_DEBUG, " SEI GREEN Complexity Metrics: %f %f %f
%f\n",
+ (float)gm->percent_non_zero_macroblocks/255,
+ (float)gm->percent_intra_coded_macroblocks/255,
+ (float)gm->percent_six_tap_filtering/255,
+ (float)gm->percent_alpha_point_deblocking_instance/255);
+
+} else if (gm->green_metadata_type == 1) {
+av_log(logctx, AV_LOG_DEBUG, " xsd_metric_type: %d\n",
gm->xsd_metric_type);
+
+if (gm->xsd_metric_type == 0)
+av_log(logctx, AV_LOG_DEBUG, " xsd_metric_value: %f\n",
+ (float)gm->xsd_metric_value/100);
+}
+}
+
static int decode_nal_units(H264Context *h, const uint8_t *buf, int buf_size,
int parse_extradata)
{
@@ -1141,6 +1169,8 @@ again:
case NAL_SEI:
h->gb = nal->gb;
ret = ff_h264_decode_sei(h);
+if (avctx->debug & FF_DEBUG_GREEN_MD)
+debug_green_metadata(&h->sei_green_metadata, h->avctx);
if (ret < 0 && (h->avctx->err_recognition & AV_EF_EXPLODE))
goto end;
break;
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 3c6d988..b23878c 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -365,33 +365,16 @@ static int decode_display_orientation(H264Context *h)
static int decode_GreenMetadata(H264Context *h)
{
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "Green Metadata Info SEI
message\n");
-
h->sei_green_metadata.green_metadata_type=get_bits(&h->gb, 8);
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_type
= %d\n",
- h->sei_green_metadata.green_metadata_type);
-
if (h->sei_green_metadata.green_metadata_type==0){
h->sei_green_metadata.period_type=get_bits(&h->gb, 8);
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_period_type
= %d\n",
- h->sei_green_metadata.period_type);
-
if (h->sei_green_metadata.period_type==2){
h->sei_green_metadata.num_seconds = get_bits(&h->gb, 16);
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_num_seconds
= %d\n",
- h->sei_green_metadata.num_seconds);
}
else if (h->sei_green_metadata.period_type==3){
h->sei_green_metadata.num_pictures = get_bits(&h->gb, 16);
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_num_pictures
= %d\n",
- h->sei_green_metadata.num_pictures);
}
h->sei_green_metadata.percent_non_zero_macroblocks=get_bits(&h->gb, 8);
@@ -399,25 +382,9 @@ static int decode_GreenMetadata(H264Context *h)
h->sei_green_metadata.percent_six_tap_filtering=get_bits(&h->gb, 8);
h->sei_green_metadata.percent_alpha_point_deblocking_instance=get_bits(&h->gb,
8);
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "SEI GREEN Complexity Metrics
= %f %f %f %f\n",
-
(float)h->sei_green_metadata.percent_non_zero_macroblocks/255,
-
(float)h->sei_green_metadata.percent_intra_coded_macroblocks/255,
-
(float)h->sei_green_metadata.percent_six_tap_filtering/255,
-
(float)h->sei_green_metadata.percent_alpha_point_deblocking_
[FFmpeg-devel] [PATCH 2/4] lavc/h264_sei: reduce scope of parameters for green meta decode
This is again will help the merge as ff_h264_decode_sei will not have
access to H264Context anymore.
---
libavcodec/h264_sei.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index b23878c..46d1814 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -363,28 +363,28 @@ static int decode_display_orientation(H264Context *h)
return 0;
}
-static int decode_GreenMetadata(H264Context *h)
+static int decode_GreenMetadata(GreenMetaData *h, GetBitContext *gb)
{
-h->sei_green_metadata.green_metadata_type=get_bits(&h->gb, 8);
+h->green_metadata_type=get_bits(gb, 8);
-if (h->sei_green_metadata.green_metadata_type==0){
-h->sei_green_metadata.period_type=get_bits(&h->gb, 8);
+if (h->green_metadata_type==0){
+h->period_type=get_bits(gb, 8);
-if (h->sei_green_metadata.period_type==2){
-h->sei_green_metadata.num_seconds = get_bits(&h->gb, 16);
+if (h->period_type==2){
+h->num_seconds = get_bits(gb, 16);
}
-else if (h->sei_green_metadata.period_type==3){
-h->sei_green_metadata.num_pictures = get_bits(&h->gb, 16);
+else if (h->period_type==3){
+h->num_pictures = get_bits(gb, 16);
}
-h->sei_green_metadata.percent_non_zero_macroblocks=get_bits(&h->gb, 8);
-h->sei_green_metadata.percent_intra_coded_macroblocks=get_bits(&h->gb,
8);
-h->sei_green_metadata.percent_six_tap_filtering=get_bits(&h->gb, 8);
-
h->sei_green_metadata.percent_alpha_point_deblocking_instance=get_bits(&h->gb,
8);
+h->percent_non_zero_macroblocks=get_bits(gb, 8);
+h->percent_intra_coded_macroblocks=get_bits(gb, 8);
+h->percent_six_tap_filtering=get_bits(gb, 8);
+h->percent_alpha_point_deblocking_instance=get_bits(gb, 8);
-}else if( h->sei_green_metadata.green_metadata_type==1){
-h->sei_green_metadata.xsd_metric_type=get_bits(&h->gb, 8);
-h->sei_green_metadata.xsd_metric_value=get_bits(&h->gb, 16);
+}else if( h->green_metadata_type==1){
+h->xsd_metric_type=get_bits(gb, 8);
+h->xsd_metric_value=get_bits(gb, 16);
}
return 0;
@@ -443,7 +443,7 @@ int ff_h264_decode_sei(H264Context *h)
ret = decode_display_orientation(h);
break;
case SEI_TYPE_GREEN_METADATA:
-ret = decode_GreenMetadata(h);
+ret = decode_GreenMetadata(&h->sei_green_metadata, &h->gb);
break;
default:
av_log(h->avctx, AV_LOG_DEBUG, "unknown SEI type %d\n", type);
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] lavc/h264: rename GreenMetaData to H264SEIGreenMetaData
Reduces diff for the next merge with Libav.
---
libavcodec/h264.c | 2 +-
libavcodec/h264.h | 6 +++---
libavcodec/h264_sei.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 46eaec2..795e599 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -959,7 +959,7 @@ static int get_last_needed_nal(H264Context *h)
return nals_needed;
}
-static void debug_green_metadata(const GreenMetaData *gm, void *logctx)
+static void debug_green_metadata(const H264SEIGreenMetaData *gm, void *logctx)
{
av_log(logctx, AV_LOG_DEBUG, "Green Metadata Info SEI message\n");
av_log(logctx, AV_LOG_DEBUG, " green_metadata_type: %d\n",
gm->green_metadata_type);
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index da8a92f..8c7a537 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -295,7 +295,7 @@ typedef struct FPA {
/**
* Green MetaData Information Type
*/
-typedef struct GreenMetaData {
+typedef struct H264SEIGreenMetaData {
uint8_t green_metadata_type;
uint8_t period_type;
uint16_t num_seconds;
@@ -306,7 +306,7 @@ typedef struct GreenMetaData {
uint8_t percent_alpha_point_deblocking_instance;
uint8_t xsd_metric_type;
uint16_t xsd_metric_value;
-} GreenMetaData;
+} H264SEIGreenMetaData;
/**
* Memory management control operation opcode.
@@ -831,7 +831,7 @@ typedef struct H264Context {
qpel_mc_func (*qpel_avg)[16];
/*Green Metadata */
-GreenMetaData sei_green_metadata;
+H264SEIGreenMetaData sei_green_metadata;
} H264Context;
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 46d1814..ab98c27 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -363,7 +363,7 @@ static int decode_display_orientation(H264Context *h)
return 0;
}
-static int decode_GreenMetadata(GreenMetaData *h, GetBitContext *gb)
+static int decode_GreenMetadata(H264SEIGreenMetaData *h, GetBitContext *gb)
{
h->green_metadata_type=get_bits(gb, 8);
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avformat/mux: call deinit if write_header fails
On Sat, 11 Jun 2016, Marton Balint wrote:
Docs clearly states that av_write_trailer should only be called if
avformat_write_header was successful, therefore we have to deinit if we return
failure.
Signed-off-by: Marton Balint
---
libavformat/mux.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 91388e3..bef230f 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -485,14 +485,14 @@ int avformat_write_header(AVFormatContext *s,
AVDictionary **options)
if (ret >= 0 && s->pb && s->pb->error < 0)
ret = s->pb->error;
if (ret < 0)
-return ret;
+goto fail;
if (s->flush_packets && s->pb && s->pb->error >= 0 && s->flags &
AVFMT_FLAG_FLUSH_PACKETS)
avio_flush(s->pb);
s->internal->header_written = 1;
}
if ((ret = init_pts(s)) < 0)
-return ret;
+goto fail;
if (s->avoid_negative_ts < 0) {
av_assert2(s->avoid_negative_ts == AVFMT_AVOID_NEG_TS_AUTO);
@@ -503,6 +503,11 @@ int avformat_write_header(AVFormatContext *s, AVDictionary
**options)
}
return 0;
+
+fail:
+if (s->oformat->deinit)
+s->oformat->deinit(s);
+return ret;
}
I have applied this as well, as Rodger sent a similar patch to the list
and that was approved.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avformat/mux: factorize header writing code
On Sat, 11 Jun 2016, Michael Niedermayer wrote: On Sat, Jun 11, 2016 at 08:33:41PM +0200, Marton Balint wrote: Signed-off-by: Marton Balint --- libavformat/mux.c | 44 ++-- 1 file changed, 22 insertions(+), 22 deletions(-) LGTM thx Thanks, applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: check if source_package is NULL
On Sun, 12 Jun 2016, Tomas Härdin wrote:
On Tue, 2016-05-31 at 23:02 +0200, Marton Balint wrote:
Fixes ticket #5554.
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index f8cf922..9bf676c 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1914,7 +1914,7 @@ static int
mxf_parse_structural_metadata(MXFContext *mxf)
break;
}
}
-if (!source_track || !component)
+if (!source_track || !component || !source_package)
continue;
if (!(source_track->sequence = mxf_resolve_strong_ref(mxf,
&source_track->sequence_ref, Sequence))) {
Looks OK. Crashes are important
Thanks, applied.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/h264_sei: fix green metadata typo
On Mon, Jun 13, 2016 at 07:51:39PM +0200, Michael Niedermayer wrote: > On Mon, Jun 13, 2016 at 05:42:00PM +0200, Clément Bœsch wrote: > > From: Clément Bœsch > > > > --- > > I'm guessing this is what was wanted. > > --- > > libavcodec/h264_sei.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > should be ok, i found a draft that matches this but not the > number of bits oddly > > either way patch should be better than before > thanks, applied -- 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] [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt
On Mon, Jun 13, 2016 at 08:44:36PM +0200, Jerome Martinez wrote:
> Le 13/06/2016 à 19:55, Michael Niedermayer a écrit :
> >On Mon, Jun 13, 2016 at 07:31:15PM +0200, Jerome Martinez wrote:
> >>FFV1 decoder:
> >>
> >>When checking pix_fmt mapping, some bitstreams are mapped to an
> >>incorrect pix_fmt instead of being rejected (ENOSYS).
> >>Actually, such bitstreams are not supported (FFmpeg encoder does not
> >>produce such bitstream, such bitstream may come only from another
> >>encoder for the moment).
> >>
> >>- JPEG 2000 RCT 11/13/15/16 bit depths are mapped to a 8-bit FFmpeg
> >>pix_fmt (e.g. bgr0), which is not expected.
> >>- JPEG 2000 RCT 9/10/12/14 bit depths with alpha are mapped to a
> >>FFmpeg pix_fmt without alpha (e.g. AV_PIX_FMT_GBRP9 for 9-bit with
> >>alpha), which is not expected.
> >>
> >>The order for choosing the pix_fmt is changed to the one used by
> >>YCbCr selection (<=8 bit first).
> >>" && !f->transparency" is added to the other lines.
> >>
> >> ffv1dec.c | 15 ---
> >> 1 file changed, 8 insertions(+), 7 deletions(-)
> >>27efc1a9821576a2a5bd8d1feaaf6c584fc69a62
> >>0001-avcodec-ffv1dec-fix-some-unsupported-pix_fmt.patch
> >> From 90bfd748b0e25d7a0be037280f4a0a40242f8d27 Mon Sep 17 00:00:00 2001
> >>From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
> >>Date: Mon, 13 Jun 2016 19:18:22 +0200
> >>Subject: [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt
> >>MIME-Version: 1.0
> >>Content-Type: text/plain; charset=UTF-8
> >>Content-Transfer-Encoding: 8bit
> >>
> >>Signed-off-by: Jérôme Martinez
> >>---
> >> libavcodec/ffv1dec.c | 15 ---
> >> 1 file changed, 8 insertions(+), 7 deletions(-)
> >>
> >>diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
> >>index d2bf3a8..6a932b2 100644
> >>--- a/libavcodec/ffv1dec.c
> >>+++ b/libavcodec/ffv1dec.c
> >>@@ -768,17 +768,18 @@ static int read_header(FFV1Context *f)
> >> "chroma subsampling not supported in this
> >> colorspace\n");
> >> return AVERROR(ENOSYS);
> >> }
> >>-if ( f->avctx->bits_per_raw_sample == 9)
> >>+if ( f->avctx->bits_per_raw_sample <= 8 && !f->transparency)
> >>+f->avctx->pix_fmt = AV_PIX_FMT_0RGB32;
> >>+else if (f->avctx->bits_per_raw_sample <= 8 && f->transparency)
> >>+f->avctx->pix_fmt = AV_PIX_FMT_RGB32;
> >>+else if (f->avctx->bits_per_raw_sample == 9 && !f->transparency)
> >> f->avctx->pix_fmt = AV_PIX_FMT_GBRP9;
> >>-else if (f->avctx->bits_per_raw_sample == 10)
> >>+else if (f->avctx->bits_per_raw_sample == 10 && !f->transparency)
> >> f->avctx->pix_fmt = AV_PIX_FMT_GBRP10;
> >>-else if (f->avctx->bits_per_raw_sample == 12)
> >>+else if (f->avctx->bits_per_raw_sample == 12 && !f->transparency)
> >> f->avctx->pix_fmt = AV_PIX_FMT_GBRP12;
> >>-else if (f->avctx->bits_per_raw_sample == 14)
> >>+else if (f->avctx->bits_per_raw_sample == 14 && !f->transparency)
> >> f->avctx->pix_fmt = AV_PIX_FMT_GBRP14;
> >>-else
> >>-if (f->transparency) f->avctx->pix_fmt = AV_PIX_FMT_RGB32;
> >>-else f->avctx->pix_fmt = AV_PIX_FMT_0RGB32;
> >an else "error" feels missing
>
> I did exactly as the code few lines above: if f->colorspace == 0 and
> f->avctx->bits_per_raw_sample >=17, there is also no else:
> } else if (f->avctx->bits_per_raw_sample == 16 && f->transparency){
> switch(16 * f->chroma_h_shift + f->chroma_v_shift) {
> case 0x00: f->avctx->pix_fmt = AV_PIX_FMT_YUVA444P16; break;
> case 0x10: f->avctx->pix_fmt = AV_PIX_FMT_YUVA422P16; break;
> case 0x11: f->avctx->pix_fmt = AV_PIX_FMT_YUVA420P16; break;
> }
> } // an else "error" feels missing here too.
>
>
>
> >pix_fmt would not be initialized after the patch
>
> When I test the code, pix_fmt is initialized to -1 (AV_PIX_FMT_NONE)
> before running this part, and the error is caught by the "format not
> supported" message, which looks like a good message for that.
>
>
> I have no problem with adding such else in the patch, but the code
> would not be coherent (an else "error" feels missing if
> f->colorspace == 0, and else "error" does not feel missing if
> f->colorspace == 1), so I would like to have the confirmation that
> this is what you really want.
>
> Note: BTW about missing things, there is no av_log() message when
> f->colorspace == 0 && f->transparency && !f->chroma_plane &&
> ->avctx->bits_per_raw_sample >8 (=gray+alpha with a bit depth of
> more than 8), just a "else return AVERROR(ENOSYS);", I was actually
> willing to remove these 2 lines in order to have more coherency (no
> "else" so "format not supported" message a bit later in the code)
> but I did not want to add different fixes in the same patch.
ok
patch applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730B
Re: [FFmpeg-devel] [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt
Le 13/06/2016 à 19:31, Jerome Martinez a écrit :
[...]
- JPEG 2000 RCT 9/10/12/14 bit depths with alpha are mapped to a
FFmpeg pix_fmt without alpha (e.g. AV_PIX_FMT_GBRP9 for 9-bit with
alpha), which is not expected.
Sorry, I forgot a remark about this part of the patch: the decoder can
decode the bitstream, the issue is that the alpha content is trashed:
if (lbd)
*((uint32_t*)(src[0] + x*4 + stride[0]*y)) = b + (g<<8)
+ (r<<16) + (a<<24);
else {
*((uint16_t*)(src[0] + x*2 + stride[0]*y)) = b;
*((uint16_t*)(src[1] + x*2 + stride[1]*y)) = g;
*((uint16_t*)(src[2] + x*2 + stride[2]*y)) = r;
}
(lbd is 1 if s->avctx->bits_per_raw_sample <= 8, "a" is used in that case)
In my patch, I chose to forbid the decoding in order to not let the user
think that the decoding is lossless, but another possibility is to add a
warning.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] MetaData in Sun AU format
On Wed, Jun 08, 2016 at 04:16:31PM +0200, miniupnp wrote:
> Le 08/06/2016 15:37, Michael Niedermayer a écrit :
> > On Wed, Jun 08, 2016 at 12:03:10AM +0200, miniupnp wrote:
> On 6/1/16, miniupnp wrote:
> > Hello,
> >
> > I'm using the .AU audio file format and noticed that FFmpeg always put 8
> > zero's in the annotation field.
> > SOX does use the annotation field to put metadata
> > (Title/Author/Album/Genre/Track)
> >
> > I don't think there is any precise specification for this AU annotation
> > field as long as it is a null terminated character string, but what SOX
> > does looks good.
> >
> > Attached are my patches to write metadata to AU files.
> look fine to me.
> >>> applied
> >>> thx
> >> And now is the patch to READ theses metadata in AU files.
> >>
> >> Regards,
> >>
> >> Thomas Bernard
> >>
> >>
> >> au.c | 69
> >> +--
> >> 1 file changed, 67 insertions(+), 2 deletions(-)
> >> 501f81b2747e0758344d189918af2863d76c774d
> >> 0001-Read-MetaData-from-AU-Sun-audio-file-header.patch
> >> From 10ca03e6a944b6a5385a92d72f633e98a0c1b57f Mon Sep 17 00:00:00 2001
> >> From: Thomas Bernard
> >> Date: Tue, 7 Jun 2016 00:25:38 +0200
> >> Subject: [PATCH] Read MetaData from AU Sun audio file header
> >>
> >> recognize title= album= artist= genre= track=
> >> ---
> >> libavformat/au.c | 69
> >> --
> >> 1 file changed, 67 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/au.c b/libavformat/au.c
> >> index 4a0400b..dba2a83 100644
> >> --- a/libavformat/au.c
> >> +++ b/libavformat/au.c
> >> @@ -66,6 +66,71 @@ static int au_probe(AVProbeData *p)
> >> return 0;
> >> }
> >>
> >> +static int au_read_annotation(AVFormatContext *s, int size)
> >> +{
> >> +static const char * keys[] = {
> >> +"title",
> >> +"artist",
> >> +"album",
> >> +"track",
> >> +"genre",
> >> +NULL };
> >> +AVIOContext *pb = s->pb;
> >> +enum { PARSE_KEY, PARSE_VALUE, PARSE_FINISHED } state = PARSE_KEY;
> >> +char c;
> >> +AVBPrint bprint;
> >> +char * key = NULL;
> >> +char * value = NULL;
> >> +int i;
> >> +
> >> +av_bprint_init(&bprint, 64, AV_BPRINT_SIZE_UNLIMITED);
> >> +
> >> +while (size-- > 0) {
> >> +c = avio_r8(pb);
> >> +switch(state) {
> >> +case PARSE_KEY:
> >> +if (c == '\0') {
> >> +state = PARSE_FINISHED;
> >> +} else if (c == '=') {
> >> +av_bprint_finalize(&bprint, &key);
> >> +av_bprint_init(&bprint, 64, AV_BPRINT_SIZE_UNLIMITED);
> >> +state = PARSE_VALUE;
> >> +} else {
> >> +av_bprint_chars(&bprint, c, 1);
> >> +}
> >> +break;
> >> +case PARSE_VALUE:
> >> +if (c == '\0' || c == '\n') {
> >> +if (av_bprint_finalize(&bprint, &value) != 0) {
> >> +av_log(s, AV_LOG_ERROR, "Memory error while parsing
> >> AU metadata.\n");
> >> +} else {
> >> +av_bprint_init(&bprint, 64, AV_BPRINT_SIZE_UNLIMITED);
> >> +for (i = 0; keys[i] != NULL && key != NULL; i++) {
> >> +if (av_strcasecmp(keys[i], key) == 0) {
> >> +av_dict_set(&(s->metadata), keys[i], value,
> >> AV_DICT_DONT_STRDUP_VAL);
> >> +av_freep(&key);
> >> +value = NULL;
> >> +}
> >> +}
> >> +}
> >> +if (key != NULL) av_freep(&key);
> >> +if (value != NULL) av_freep(&value);
> > redundant if()
>
> I was not sure of what av_freep(&key) does when key==NULL.
>
> here is the patch, plus a potential memory leak fix.
> au.c | 69
> +--
> 1 file changed, 67 insertions(+), 2 deletions(-)
> 7d31a805e88e97900e5bcc78962afb280a89ebf6
> 0001-Read-MetaData-from-AU-Sun-audio-file-header.patch
> From 10ca03e6a944b6a5385a92d72f633e98a0c1b57f Mon Sep 17 00:00:00 2001
> From: Thomas Bernard
> Date: Tue, 7 Jun 2016 00:25:38 +0200
> Subject: [PATCH 1/2] Read MetaData from AU Sun audio file header
>
> recognize title= album= artist= genre= track=
patches applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/5] rtpdec_h264: Use avpriv_report_missing_feature instead of a manual av_log
From: Martin Storsjö Signed-off-by: Martin Storsjö --- libavformat/rtpdec_h264.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c index 7216dd8..4ab0eee 100644 --- a/libavformat/rtpdec_h264.c +++ b/libavformat/rtpdec_h264.c @@ -351,9 +351,7 @@ static int h264_handle_packet(AVFormatContext *ctx, PayloadContext *data, case 26: // MTAP-16 case 27: // MTAP-24 case 29: // FU-B -av_log(ctx, AV_LOG_ERROR, - "Unhandled type (%d) (See RFC for implementation details)\n", - type); +avpriv_report_missing_feature(ctx, "RTP H.264 NAL unit type %d", type); result = AVERROR_PATCHWELCOME; break; -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/5] rtpdec_vp9: Update header parsing to spec draft 02
From: Martin Storsjö
Signed-off-by: Martin Storsjö
---
libavformat/rtpdec_vp9.c | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/libavformat/rtpdec_vp9.c b/libavformat/rtpdec_vp9.c
index 7b1c38f..506a5cd 100644
--- a/libavformat/rtpdec_vp9.c
+++ b/libavformat/rtpdec_vp9.c
@@ -1,5 +1,5 @@
/*
- * RTP parser for VP9 payload format (draft version 0) - experimental
+ * RTP parser for VP9 payload format (draft version 02) - experimental
* Copyright (c) 2015 Thomas Volkert
*
* This file is part of FFmpeg.
@@ -45,8 +45,8 @@ static int vp9_handle_packet(AVFormatContext *ctx,
PayloadContext *rtp_vp9_ctx,
const uint8_t *buf, int len, uint16_t seq,
int flags)
{
-int has_pic_id, has_layer_idc, has_ref_idc, has_ss_data, has_su_data;
-av_unused int pic_id = 0, non_key_frame = 0;
+int has_pic_id, has_layer_idc, has_ref_idc, has_ss_data;
+av_unused int pic_id = 0, non_key_frame = 0, inter_picture_layer_frame;
av_unused int layer_temporal = -1, layer_spatial = -1, layer_quality = -1;
int ref_fields = 0, has_ref_field_ext_pic_id = 0;
int first_fragment, last_fragment;
@@ -68,24 +68,24 @@ static int vp9_handle_packet(AVFormatContext *ctx,
PayloadContext *rtp_vp9_ctx,
*
* 0 1 2 3 4 5 6 7
* +-+-+-+-+-+-+-+-+
- * |I|L|F|B|E|V|U|-| (REQUIRED)
+ * |I|P|L|F|B|E|V|-| (REQUIRED)
* +-+-+-+-+-+-+-+-+
*
* I: PictureID present
+ * P: Inter-picture predicted layer frame
* L: Layer indices present
- * F: Reference indices present
+ * F: Flexible mode
* B: Start of VP9 frame
* E: End of picture
* V: Scalability Structure (SS) present
- * U: Scalability Structure Update (SU) present
*/
has_pic_id = !!(buf[0] & 0x80);
-has_layer_idc = !!(buf[0] & 0x40);
-has_ref_idc= !!(buf[0] & 0x20);
-first_fragment = !!(buf[0] & 0x10);
-last_fragment = !!(buf[0] & 0x08);
-has_ss_data= !!(buf[0] & 0x04);
-has_su_data= !!(buf[0] & 0x02);
+inter_picture_layer_frame = !!(buf[0] & 0x40);
+has_layer_idc = !!(buf[0] & 0x20);
+has_ref_idc= !!(buf[0] & 0x10);
+first_fragment = !!(buf[0] & 0x08);
+last_fragment = !!(buf[0] & 0x04);
+has_ss_data= !!(buf[0] & 0x02);
rtp_m = !!(flags & RTP_FLAG_MARKER);
@@ -227,16 +227,6 @@ static int vp9_handle_packet(AVFormatContext *ctx,
PayloadContext *rtp_vp9_ctx,
}
/*
- * decode the scalability update structure (SU)
- *
- * spec. is tbd
- */
-if (has_su_data) {
-avpriv_report_missing_feature(ctx, "VP9 scalability update structure
data");
-return AVERROR(ENOSYS);
-}
-
-/*
* decode the VP9 payload header
*
* spec. is tbd
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/5] rtpdec: Use AVERROR_PATCHWELCOME instead of AVERROR(ENOSYS) for unimplemented features
From: Martin Storsjö
Signed-off-by: Martin Storsjö
---
libavformat/rtpdec_h264.c | 2 +-
libavformat/rtpdec_vp9.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c
index c5eb341..7216dd8 100644
--- a/libavformat/rtpdec_h264.c
+++ b/libavformat/rtpdec_h264.c
@@ -354,7 +354,7 @@ static int h264_handle_packet(AVFormatContext *ctx,
PayloadContext *data,
av_log(ctx, AV_LOG_ERROR,
"Unhandled type (%d) (See RFC for implementation details)\n",
type);
-result = AVERROR(ENOSYS);
+result = AVERROR_PATCHWELCOME;
break;
case 28: // FU-A (fragmented nal)
diff --git a/libavformat/rtpdec_vp9.c b/libavformat/rtpdec_vp9.c
index 506a5cd..d02c8b8 100644
--- a/libavformat/rtpdec_vp9.c
+++ b/libavformat/rtpdec_vp9.c
@@ -223,7 +223,7 @@ static int vp9_handle_packet(AVFormatContext *ctx,
PayloadContext *rtp_vp9_ctx,
*/
if (has_ss_data) {
avpriv_report_missing_feature(ctx, "VP9 scalability structure data");
-return AVERROR(ENOSYS);
+return AVERROR_PATCHWELCOME;
}
/*
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/5] rtpdec_vp9: Support parsing the scalability structure
From: Martin Storsjö
We still only support one single layer though, but this allows
receiving streams that have this structure present even for
single layer streams.
Signed-off-by: Martin Storsjö
---
libavformat/rtpdec_vp9.c | 60 ++--
1 file changed, 58 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtpdec_vp9.c b/libavformat/rtpdec_vp9.c
index d02c8b8..4a7f934 100644
--- a/libavformat/rtpdec_vp9.c
+++ b/libavformat/rtpdec_vp9.c
@@ -222,8 +222,64 @@ static int vp9_handle_packet(AVFormatContext *ctx,
PayloadContext *rtp_vp9_ctx,
* X: 1 if this layer index has an extended relative Picture ID.
*/
if (has_ss_data) {
-avpriv_report_missing_feature(ctx, "VP9 scalability structure data");
-return AVERROR_PATCHWELCOME;
+int n_s, y, g, i;
+if (len < 1) {
+av_log(ctx, AV_LOG_ERROR, "Too short RTP/VP9 packet\n");
+return AVERROR_INVALIDDATA;
+}
+n_s = buf[0] >> 5;
+y = !!(buf[0] & 0x10);
+g = !!(buf[0] & 0x08);
+buf++;
+len--;
+if (n_s > 0) {
+avpriv_report_missing_feature(ctx, "VP9 scalability structure with
multiple layers");
+return AVERROR_PATCHWELCOME;
+}
+if (y) {
+if (len < 4 * (n_s + 1)) {
+av_log(ctx, AV_LOG_ERROR, "Too short RTP/VP9 packet\n");
+return AVERROR_INVALIDDATA;
+}
+for (i = 0; i < n_s + 1; i++) {
+av_unused int w, h;
+w = AV_RB16(buf);
+h = AV_RB16(buf + 2);
+buf += 4;
+len -= 4;
+}
+}
+if (g) {
+int n_g;
+if (len < 1) {
+av_log(ctx, AV_LOG_ERROR, "Too short RTP/VP9 packet\n");
+return AVERROR_INVALIDDATA;
+}
+n_g = buf[0];
+buf++;
+len--;
+for (i = 0; i < n_g; i++) {
+av_unused int t, u, r, j;
+if (len < 1) {
+av_log(ctx, AV_LOG_ERROR, "Too short RTP/VP9 packet\n");
+return AVERROR_INVALIDDATA;
+}
+t = buf[0] >> 5;
+u = !!(buf[0] & 0x10);
+r = (buf[0] >> 2) & 0x03;
+buf++;
+len--;
+if (len < r) {
+av_log(ctx, AV_LOG_ERROR, "Too short RTP/VP9 packet\n");
+return AVERROR_INVALIDDATA;
+}
+for (j = 0; j < r; j++) {
+av_unused int p_diff = buf[0];
+buf++;
+len--;
+}
+}
+}
}
/*
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/5] rtpdec_vp9: Make sure to free the temp buffer on close
From: Martin Storsjö
Signed-off-by: Martin Storsjö
---
libavformat/rtpdec_vp9.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/rtpdec_vp9.c b/libavformat/rtpdec_vp9.c
index e50bede..7b1c38f 100644
--- a/libavformat/rtpdec_vp9.c
+++ b/libavformat/rtpdec_vp9.c
@@ -279,11 +279,17 @@ static int vp9_handle_packet(AVFormatContext *ctx,
PayloadContext *rtp_vp9_ctx,
return 0;
}
+static void vp9_close_context(PayloadContext *vp9)
+{
+ffio_free_dyn_buf(&vp9->buf);
+}
+
RTPDynamicProtocolHandler ff_vp9_dynamic_handler = {
.enc_name = "VP9",
.codec_type = AVMEDIA_TYPE_VIDEO,
.codec_id = AV_CODEC_ID_VP9,
.priv_data_size = sizeof(PayloadContext),
.init = vp9_init,
+.close= vp9_close_context,
.parse_packet = vp9_handle_packet
};
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for vp9 in iso-bmff
Hi guys, On Mon, Jun 13, 2016 at 2:42 PM, Yang Kongqun wrote: > I am thinking of naming it as vpc instead, which aligns with avc.c and > hevc.c. What do you think? > > On Mon, Jun 13, 2016 at 11:39 AM, Vignesh Venkatasubramanian < > vigneshv-at-google@ffmpeg.org> wrote: > > > On Sat, Jun 11, 2016 at 2:22 PM, Ronald S. Bultje > > wrote: > > > > > > Hi, > > > > > > On Fri, Jun 10, 2016 at 6:25 PM, Kongqun Yang > > wrote: > > > > > > > Implemented according to the draft specification > > > > "VP Codec ISO Media File Format Binding": > > > > > > > > > > > http://www.webmproject.org/vp9/#draft-vp-codec-iso-media-file-format-binding > > > > > > > > Change-Id: Iaa7ddf5524b17e8d79cd1923b26f096d6e91 > > > > --- > > > > libavformat/Makefile | 2 +- > > > > libavformat/isom.c | 3 + > > > > libavformat/movenc.c | 15 + > > > > libavformat/vpx.c| 170 > > > > +++ > > > > libavformat/vpx.h| 33 ++ > > > > > > > > > I don't particularly love the name "vpx.c" and "vpx.h", because they > will > > > make people think this is related to libvpx instead of just generic > > > vp-something helpers. To prevent that, let's call it vpn. > > > > umm, vpn seems weird. how about 'vpcc' given that the functions in > > this file are about writing out the vpcc atom? > vpc or vpcc is both fine with me, thanks. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt
Le 13/06/2016 à 19:55, Michael Niedermayer a écrit :
On Mon, Jun 13, 2016 at 07:31:15PM +0200, Jerome Martinez wrote:
FFV1 decoder:
When checking pix_fmt mapping, some bitstreams are mapped to an
incorrect pix_fmt instead of being rejected (ENOSYS).
Actually, such bitstreams are not supported (FFmpeg encoder does not
produce such bitstream, such bitstream may come only from another
encoder for the moment).
- JPEG 2000 RCT 11/13/15/16 bit depths are mapped to a 8-bit FFmpeg
pix_fmt (e.g. bgr0), which is not expected.
- JPEG 2000 RCT 9/10/12/14 bit depths with alpha are mapped to a
FFmpeg pix_fmt without alpha (e.g. AV_PIX_FMT_GBRP9 for 9-bit with
alpha), which is not expected.
The order for choosing the pix_fmt is changed to the one used by
YCbCr selection (<=8 bit first).
" && !f->transparency" is added to the other lines.
ffv1dec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
27efc1a9821576a2a5bd8d1feaaf6c584fc69a62
0001-avcodec-ffv1dec-fix-some-unsupported-pix_fmt.patch
From 90bfd748b0e25d7a0be037280f4a0a40242f8d27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Mon, 13 Jun 2016 19:18:22 +0200
Subject: [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Jérôme Martinez
---
libavcodec/ffv1dec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index d2bf3a8..6a932b2 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -768,17 +768,18 @@ static int read_header(FFV1Context *f)
"chroma subsampling not supported in this colorspace\n");
return AVERROR(ENOSYS);
}
-if ( f->avctx->bits_per_raw_sample == 9)
+if ( f->avctx->bits_per_raw_sample <= 8 && !f->transparency)
+f->avctx->pix_fmt = AV_PIX_FMT_0RGB32;
+else if (f->avctx->bits_per_raw_sample <= 8 && f->transparency)
+f->avctx->pix_fmt = AV_PIX_FMT_RGB32;
+else if (f->avctx->bits_per_raw_sample == 9 && !f->transparency)
f->avctx->pix_fmt = AV_PIX_FMT_GBRP9;
-else if (f->avctx->bits_per_raw_sample == 10)
+else if (f->avctx->bits_per_raw_sample == 10 && !f->transparency)
f->avctx->pix_fmt = AV_PIX_FMT_GBRP10;
-else if (f->avctx->bits_per_raw_sample == 12)
+else if (f->avctx->bits_per_raw_sample == 12 && !f->transparency)
f->avctx->pix_fmt = AV_PIX_FMT_GBRP12;
-else if (f->avctx->bits_per_raw_sample == 14)
+else if (f->avctx->bits_per_raw_sample == 14 && !f->transparency)
f->avctx->pix_fmt = AV_PIX_FMT_GBRP14;
-else
-if (f->transparency) f->avctx->pix_fmt = AV_PIX_FMT_RGB32;
-else f->avctx->pix_fmt = AV_PIX_FMT_0RGB32;
an else "error" feels missing
I did exactly as the code few lines above: if f->colorspace == 0 and
f->avctx->bits_per_raw_sample >=17, there is also no else:
} else if (f->avctx->bits_per_raw_sample == 16 && f->transparency){
switch(16 * f->chroma_h_shift + f->chroma_v_shift) {
case 0x00: f->avctx->pix_fmt = AV_PIX_FMT_YUVA444P16; break;
case 0x10: f->avctx->pix_fmt = AV_PIX_FMT_YUVA422P16; break;
case 0x11: f->avctx->pix_fmt = AV_PIX_FMT_YUVA420P16; break;
}
} // an else "error" feels missing here too.
pix_fmt would not be initialized after the patch
When I test the code, pix_fmt is initialized to -1 (AV_PIX_FMT_NONE)
before running this part, and the error is caught by the "format not
supported" message, which looks like a good message for that.
I have no problem with adding such else in the patch, but the code would
not be coherent (an else "error" feels missing if f->colorspace == 0,
and else "error" does not feel missing if f->colorspace == 1), so I
would like to have the confirmation that this is what you really want.
Note: BTW about missing things, there is no av_log() message when
f->colorspace == 0 && f->transparency && !f->chroma_plane &&
->avctx->bits_per_raw_sample >8 (=gray+alpha with a bit depth of more
than 8), just a "else return AVERROR(ENOSYS);", I was actually willing
to remove these 2 lines in order to have more coherency (no "else" so
"format not supported" message a bit later in the code) but I did not
want to add different fixes in the same patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for vp9 in iso-bmff
I am thinking of naming it as vpc instead, which aligns with avc.c and hevc.c. What do you think? On Mon, Jun 13, 2016 at 11:39 AM, Vignesh Venkatasubramanian < vigneshv-at-google@ffmpeg.org> wrote: > On Sat, Jun 11, 2016 at 2:22 PM, Ronald S. Bultje > wrote: > > > > Hi, > > > > On Fri, Jun 10, 2016 at 6:25 PM, Kongqun Yang > wrote: > > > > > Implemented according to the draft specification > > > "VP Codec ISO Media File Format Binding": > > > > > > > http://www.webmproject.org/vp9/#draft-vp-codec-iso-media-file-format-binding > > > > > > Change-Id: Iaa7ddf5524b17e8d79cd1923b26f096d6e91 > > > --- > > > libavformat/Makefile | 2 +- > > > libavformat/isom.c | 3 + > > > libavformat/movenc.c | 15 + > > > libavformat/vpx.c| 170 > > > +++ > > > libavformat/vpx.h| 33 ++ > > > > > > I don't particularly love the name "vpx.c" and "vpx.h", because they will > > make people think this is related to libvpx instead of just generic > > vp-something helpers. To prevent that, let's call it vpn. > > umm, vpn seems weird. how about 'vpcc' given that the functions in > this file are about writing out the vpcc atom? > > > > > Ronald > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > -- > Vignesh > ___ > 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] hls muxer doc: clarify segment splitting option
Hi, Le 08/06/2016 11:46, Benoit Fouet a écrit : Hi, find attached a patch to $subj This would have been useful at least to me :-) Anyone against this patch? If not, can someone please apply it? Thanks, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for vp9 in iso-bmff
On Sat, Jun 11, 2016 at 2:22 PM, Ronald S. Bultje wrote: > > Hi, > > On Fri, Jun 10, 2016 at 6:25 PM, Kongqun Yang wrote: > > > Implemented according to the draft specification > > "VP Codec ISO Media File Format Binding": > > > > http://www.webmproject.org/vp9/#draft-vp-codec-iso-media-file-format-binding > > > > Change-Id: Iaa7ddf5524b17e8d79cd1923b26f096d6e91 > > --- > > libavformat/Makefile | 2 +- > > libavformat/isom.c | 3 + > > libavformat/movenc.c | 15 + > > libavformat/vpx.c| 170 > > +++ > > libavformat/vpx.h| 33 ++ > > > I don't particularly love the name "vpx.c" and "vpx.h", because they will > make people think this is related to libvpx instead of just generic > vp-something helpers. To prevent that, let's call it vpn. umm, vpn seems weird. how about 'vpcc' given that the functions in this file are about writing out the vpcc atom? > > Ronald > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Vignesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 04/13] lavf/mux: run AVCodec::deinit if write_header fails
On Sun, Jun 12, 2016 at 04:30:52PM -0500, Rodger Combs wrote: > --- > libavformat/mux.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) should be ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat/dump: Show coded dimensions again
On Sun, Jun 05, 2016 at 05:13:28AM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/dump.c |2 ++ > 1 file changed, 2 insertions(+) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/h264_sei: fix green metadata typo
On Mon, Jun 13, 2016 at 05:42:00PM +0200, Clément Bœsch wrote: > From: Clément Bœsch > > --- > I'm guessing this is what was wanted. > --- > libavcodec/h264_sei.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) should be ok, i found a draft that matches this but not the number of bits oddly either way patch should be better than before [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt
On Mon, Jun 13, 2016 at 07:31:15PM +0200, Jerome Martinez wrote: > FFV1 decoder: > > When checking pix_fmt mapping, some bitstreams are mapped to an > incorrect pix_fmt instead of being rejected (ENOSYS). > Actually, such bitstreams are not supported (FFmpeg encoder does not > produce such bitstream, such bitstream may come only from another > encoder for the moment). > > - JPEG 2000 RCT 11/13/15/16 bit depths are mapped to a 8-bit FFmpeg > pix_fmt (e.g. bgr0), which is not expected. > - JPEG 2000 RCT 9/10/12/14 bit depths with alpha are mapped to a > FFmpeg pix_fmt without alpha (e.g. AV_PIX_FMT_GBRP9 for 9-bit with > alpha), which is not expected. > > The order for choosing the pix_fmt is changed to the one used by > YCbCr selection (<=8 bit first). > " && !f->transparency" is added to the other lines. > > ffv1dec.c | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) > 27efc1a9821576a2a5bd8d1feaaf6c584fc69a62 > 0001-avcodec-ffv1dec-fix-some-unsupported-pix_fmt.patch > From 90bfd748b0e25d7a0be037280f4a0a40242f8d27 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= > Date: Mon, 13 Jun 2016 19:18:22 +0200 > Subject: [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Signed-off-by: Jérôme Martinez > --- > libavcodec/ffv1dec.c | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c > index d2bf3a8..6a932b2 100644 > --- a/libavcodec/ffv1dec.c > +++ b/libavcodec/ffv1dec.c > @@ -768,17 +768,18 @@ static int read_header(FFV1Context *f) > "chroma subsampling not supported in this colorspace\n"); > return AVERROR(ENOSYS); > } > -if ( f->avctx->bits_per_raw_sample == 9) > +if ( f->avctx->bits_per_raw_sample <= 8 && !f->transparency) > +f->avctx->pix_fmt = AV_PIX_FMT_0RGB32; > +else if (f->avctx->bits_per_raw_sample <= 8 && f->transparency) > +f->avctx->pix_fmt = AV_PIX_FMT_RGB32; > +else if (f->avctx->bits_per_raw_sample == 9 && !f->transparency) > f->avctx->pix_fmt = AV_PIX_FMT_GBRP9; > -else if (f->avctx->bits_per_raw_sample == 10) > +else if (f->avctx->bits_per_raw_sample == 10 && !f->transparency) > f->avctx->pix_fmt = AV_PIX_FMT_GBRP10; > -else if (f->avctx->bits_per_raw_sample == 12) > +else if (f->avctx->bits_per_raw_sample == 12 && !f->transparency) > f->avctx->pix_fmt = AV_PIX_FMT_GBRP12; > -else if (f->avctx->bits_per_raw_sample == 14) > +else if (f->avctx->bits_per_raw_sample == 14 && !f->transparency) > f->avctx->pix_fmt = AV_PIX_FMT_GBRP14; > -else > -if (f->transparency) f->avctx->pix_fmt = AV_PIX_FMT_RGB32; > -else f->avctx->pix_fmt = AV_PIX_FMT_0RGB32; an else "error" feels missing pix_fmt would not be initialized after the patch [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FFmpeg Decklink input connection options
On Mon, 13 Jun 2016, Amnon wrote: Is this really applied? I think this patch never reached the ML, and Michael actually applied a different decklink patch (Convert decklink input module to use codecpar), but replied to the wrong thread. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt
FFV1 decoder:
When checking pix_fmt mapping, some bitstreams are mapped to an
incorrect pix_fmt instead of being rejected (ENOSYS).
Actually, such bitstreams are not supported (FFmpeg encoder does not
produce such bitstream, such bitstream may come only from another
encoder for the moment).
- JPEG 2000 RCT 11/13/15/16 bit depths are mapped to a 8-bit FFmpeg
pix_fmt (e.g. bgr0), which is not expected.
- JPEG 2000 RCT 9/10/12/14 bit depths with alpha are mapped to a FFmpeg
pix_fmt without alpha (e.g. AV_PIX_FMT_GBRP9 for 9-bit with alpha),
which is not expected.
The order for choosing the pix_fmt is changed to the one used by YCbCr
selection (<=8 bit first).
" && !f->transparency" is added to the other lines.
From 90bfd748b0e25d7a0be037280f4a0a40242f8d27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?=
Date: Mon, 13 Jun 2016 19:18:22 +0200
Subject: [PATCH] avcodec/ffv1dec: fix some unsupported pix_fmt
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Jérôme Martinez
---
libavcodec/ffv1dec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index d2bf3a8..6a932b2 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -768,17 +768,18 @@ static int read_header(FFV1Context *f)
"chroma subsampling not supported in this colorspace\n");
return AVERROR(ENOSYS);
}
-if ( f->avctx->bits_per_raw_sample == 9)
+if ( f->avctx->bits_per_raw_sample <= 8 && !f->transparency)
+f->avctx->pix_fmt = AV_PIX_FMT_0RGB32;
+else if (f->avctx->bits_per_raw_sample <= 8 && f->transparency)
+f->avctx->pix_fmt = AV_PIX_FMT_RGB32;
+else if (f->avctx->bits_per_raw_sample == 9 && !f->transparency)
f->avctx->pix_fmt = AV_PIX_FMT_GBRP9;
-else if (f->avctx->bits_per_raw_sample == 10)
+else if (f->avctx->bits_per_raw_sample == 10 && !f->transparency)
f->avctx->pix_fmt = AV_PIX_FMT_GBRP10;
-else if (f->avctx->bits_per_raw_sample == 12)
+else if (f->avctx->bits_per_raw_sample == 12 && !f->transparency)
f->avctx->pix_fmt = AV_PIX_FMT_GBRP12;
-else if (f->avctx->bits_per_raw_sample == 14)
+else if (f->avctx->bits_per_raw_sample == 14 && !f->transparency)
f->avctx->pix_fmt = AV_PIX_FMT_GBRP14;
-else
-if (f->transparency) f->avctx->pix_fmt = AV_PIX_FMT_RGB32;
-else f->avctx->pix_fmt = AV_PIX_FMT_0RGB32;
} else {
av_log(f->avctx, AV_LOG_ERROR, "colorspace not supported\n");
return AVERROR(ENOSYS);
--
2.7.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] rtpenc: packetizer for VP9 RTP payload format (draft v2)
On 30.05.2016 16:41, Thomas Volkert wrote: From: Thomas Volkert --- libavformat/Makefile | 1 + libavformat/rtpenc.c | 14 + libavformat/rtpenc.h | 1 + libavformat/rtpenc_vp9.c | 54 libavformat/sdp.c| 4 5 files changed, 74 insertions(+) create mode 100644 libavformat/rtpenc_vp9.c ..pushed. Best regards, Thomas. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/h264_sei: fix green metadata typo
From: Clément Bœsch
---
I'm guessing this is what was wanted.
---
libavcodec/h264_sei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index bdc5c9f..3c6d988 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -381,7 +381,7 @@ static int decode_GreenMetadata(H264Context *h)
av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_period_type
= %d\n",
h->sei_green_metadata.period_type);
-if (h->sei_green_metadata.green_metadata_type==2){
+if (h->sei_green_metadata.period_type==2){
h->sei_green_metadata.num_seconds = get_bits(&h->gb, 16);
if (h->avctx->debug & FF_DEBUG_GREEN_MD)
av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_num_seconds
= %d\n",
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
On Sun, Jun 12, 2016 at 10:58:37PM +0200, Paul B Mahol wrote: > Hi, > > As requested in the IRC meeting I hereby request for the > voting committee to begin voting on whatever to ban Carl > Eugen Hoyos from mailing list, trac and IRC for 4 months, > starting after the voting has finished. > > Voting will last 7 days from now. > In order for the vote to pass, at least 50% of all votes > from committee need to agree to do so. > > All developers and users are welcome to write about their > experiences with Carl. I suggest that if you want a vote to rather do it like this: 1. a [RFC] for penalty suggestions for the case of a developer causing another to leave by some kind of action that is generally considered wrong. Collect all suggestions that have at least one secundant for 1-2 weeks 2. a [VOTE] about which of the suggested penalties if any to apply to past cases, there must be the option of "no penalty" of course 3. a [VOTE] to select an impartial judge (preferably someone from outside FFmpeg) to make the decission about to which people the penalty applies, you dont want a "how many friends does X have" vote and voting about ones peers can alienate and split communties or something along these lines, not saying i consider such a vote a good idea nor that i dont ... but giving fair and appropriate penalties is hard [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
Le sextidi 26 prairial, an CCXXIV, Paul B Mahol a écrit : > Looks like you prefer to loose valuable developers instead of punishing > bad behaviour, so be it. Be very careful: this message could be parsed as a threat, "satisfy my personal vendetta or I will leave". I am sure this was not what you meant, but I urge you to use a more unambiguous wording in the future. My reaction would be "good riddance to the blackmailers". Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
On Sun, May 29, 2016 at 01:32:54AM +0200, Michael Niedermayer wrote: > Hi > > It was suggested in the IRC meeting today that i start a vote to > resolve if AVClass & AVOption should be added to AVCodecParameters > This question needs to be awnsered before the next release because > the ABI would be broken if its added afterwards > the lack of any decission blocks the release which is worse than > either decission, otherwise a vote might be silly for such technical > question but eve a bad decission is better than no decission here > > > The disadvanatges are: > 1 more field in the struct > a high level API that some feel is unneeded for AVCodecParameters > it could be confusing to some that there are 2 different ways to > access the fields > people might use it as av_log() context when they intended to use a > different context for it > There are probably more please help fill the list if you know more > > The advanatges are: > More consistent availability of AVOptions and AVClass in public > structs > Makes supporting multiple FFmpeg versions and distros easier and > cleaner for applications. (reduces lists of #if version checks) > Provides default/min/max values, allows basic validity checking within > min/max > Avoids mysterious crashes if an application uses avoption functions > on AVCodecParameters > Introspection > Serialization support that may be usefull for ffserver or an application > replacing ffserver > > > An application that doesnt want to use AVOptions or AVClass can > completey ignore them. > > Please state clearly if you agree to add AVClass&AVOption to > AVCodecParameters or if you disagree about adding it or if you dont > care either way > > The vote will end 1 week from now, simple 50% majority (Yes vs no) > I dont really know who should be eligible for voting, so i suggest > everyone from the vote comittee but iam happy with anything, just > stating somethng ... Results: Clément Bœsch Yes Carl Eugen HoyosYes Rostislav PehlivanovNo Hendrik Leppkes No Ronald S. BultjeNo Marton Balint Yes wm4 No Michael Niedermayer Yes Nicolas George No (this one was i belive a few hours too late but we need a tie breaking vote) The results are 5:4 and the winner is "No" [...] -- 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
Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: refactor ff_AMediaCodecList_getCodecByType
On Wed, Jun 08, 2016 at 11:19:51PM +0200, Matthieu Bouron wrote: > From: Matthieu Bouron > > Allows to select a codec (encoder or decoder) only if it supports a > specific profile. > > Adds ff_AMediaCodecProfile_getProfileFromAVCodecContext to convert an > AVCodecContext profile to a MediaCodec profile. It only supports H264 > for now. > > The codepath using MediaCodecList.findDecoderForFormat() (Android >= 5.0) > has been dropped as this method does not allow to select a decoder > compatible with a specific profile. > --- If there is no objection, I will push this patch in one day. Matthieu [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec_h264: use ff_h264_decode_extradata to extract PPS/SPS
On Mon, Jun 13, 2016 at 12:23:07PM +0200, Hendrik Leppkes wrote:
> On Mon, Jun 13, 2016 at 11:51 AM, Matthieu Bouron
> wrote:
> > On Fri, Jun 10, 2016 at 03:08:48PM +0200, Matthieu Bouron wrote:
> >> From: Matthieu Bouron
> >>
> >> Fixes playback of HLS streams on MediaTek devices which requires PPS/SPS
> >> to be set in their respective csd-{0,1} buffers.
> >> ---
> >>
> >> Hello,
> >>
> >> The attached patch fixes playback of HLS streams on MediaTek devices which
> >> requires PPS/SPS to be set in their respetive csd-{0,1} buffers (instead of
> >> having sps+pps in the csd-0 which works on other devices).
> >>
> >> I'm not sure if I can use the ff_h264_decode_extradata this way (or at
> >> least
> >> initialize the H264Context with zeroes minus the avctx field).
> >
> > Rebased patch (after the h264 ps merged) attached.
> >
> > I still have the same question, is my use of
> > H264Context + ff_h264_decode_extradata correct ?
> >
>
> Using H264 decoder internals seems to be a rather unfortunate
> solution, as its prone to breakage, often subtle, as the h264 decoder
> gets changed and not all inter-module dependencies are known.
> So if possible at all, not using something that uses H264Context for
> example would be nice.
>
> For the record, ff_h264_decode_extradata is scheduled for refactoring
> to make it independent of H264Context so it can be more easily shared
> with the h264 decoder and the h264 parser.
> Once that is done, it may give you a cleaner interface to use it from
> mediacodec as well.
Ok. I can wait for the refactor to be merged but the MediaCodec decoder
will remain broken on those devices. I'm not too happy about that if a
release is to be made in those following days. Do we have an ETA ? I'm
also not too happy to write the same parsing code as I did before for the
AVCC format to split/extract the PPS/SPS.
Or ..., I can push this code (if its use is valid) and update it when the
merge lands (I'm helping Clément with the merges, so I will take care
about this part).
Matthieu
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
Hi, On Mon, Jun 13, 2016 at 4:31 AM, Thilo Borgmann wrote: > Hi, > > > As requested in the IRC meeting I hereby request for the > > voting committee to begin voting on whatever to ban Carl > > Eugen Hoyos from mailing list, trac and IRC for 4 months, > > starting after the voting has finished. > > I don't remember and don't have time to investigate if there has been such > a > request. At least, the 4 months period that comes out of nowhere as well as > applying a new regulation to older misbehavior seem highly inappropriate. > And that's just for the objective side of the medal... personally I think > you're > running a bit too mad about punishing CE here. You're both right actually (and Ivan is wrong). Search for "carl" in the IRC logs [1], and you'll see sentences like: "so, I think we should formally ban carl from the ML for 24 hrs and ban his commit access for the same period" "Well Carl hasn't been treated kindly but the situation has actually been rotting for years now" "I'm ok for a vote on Carl, after the CoC contains repercussions (is it a warning? A 1 day ban? Etc)" Ivan was already aware of all this (so I have no idea why he tried to spread doubt about this in response to Paul's original email), because as part of that discussion, he says: we are not discussing things on principle, we are looking for a way to punish Carl. Back to what you (Thilo) said: indeed, the IRC meeting suggested 1 day (not 4 months) but/and there was no positive or negative response. The only suggestion from people was that maybe it should be in accordance with the documented punishments in the CoC (see third quote above). But that never happened, as in, I don't see anyone pulling that bandwagon. And the second quote is certainly true (this is rotting), which should cause great concern to all of us... Ronald [1] https://trac.ffmpeg.org/wiki/FFmeeting/2016-05 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
Paul B Mahol wrote: >Looks like you prefer to loose valuable developers instead >of punishing bad behaviour, so be it. We like to loose nobody, neither you nor Carl. Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
On 6/13/16, Thilo Borgmann wrote: > Am 13.06.16 um 10:23 schrieb Paul B Mahol: >> On 6/13/16, Ivan Kalvachev wrote: >>> On 6/13/16, Paul B Mahol wrote: On 6/13/16, Ivan Kalvachev wrote: > On 6/12/16, Paul B Mahol wrote: >> Hi, >> >> As requested in the IRC meeting I hereby request for the >> voting committee to begin voting on whatever to ban Carl >> Eugen Hoyos from mailing list, trac and IRC for 4 months, >> starting after the voting has finished. > > I don't remember such thing to have been requested on the IRC meeting. > Would you kindly quote the relevant parts of the logs? It was requested to act because of Carl misbehaviour. Logs are available on net. >>> >>> I was on the meeting and I checked the published logs >>> before sending my first mail. >>> That's why I requested that you QUOTE the relevant part. >>> >>> Let me be blunt. Nobody have requested Carl to be banned, >>> and definitely not from ML, trac, IRC for 4 months. >>> >>> Feel free to prove me wrong, by providing the quotes I requested. >> >> Nobody requested explicitly that they want to ban Carl for 4 months, >> but they all want that his behaviour is punished. > > "all"? > > > Also, I would like to know on what grounds and > on what charges you request that punishment. On grounds that he was badmouthing others. >>> >>> That's way too vague... >>> >>> 1. I'd like to see links and quotes of him doing the things you accuse >>> him >>> of. >> >> It was all private. The last one about Derek, which was public, is just >> top of >> iceberg. > > "all private"? Private behaviour, no matter how much we dislike it, can > hardly > be a subject here. Even if it correlates to other devs and the FFmpeg > development process, it would be the task of the offended person to publish > it > and ask for actions if it really exceeds a behaviour that can not be > privately > ignored by the offended. > > >>> 2. I'd like to know why we have to ban him for 4 months exactly? Why >>> ban him from ML, IRC, Trac, but not git? >> >> Then we will ban him from git too. >> >>> How did you determined that this punishment is the one that is most >>> fitting the crimes he has done? >> >> By careful examination. > > Just a phrase. There is no possible examination if it's "all private". And > there > is no careful determination possible for a punishment because we don't have > mappings for misbehavior. Thus, what you propose is just your personal > arbitrary > opinion of a suitable punishment. Aside that applying any part of the CoC to > misbehavior of the past is inappropriate IMHO. > > >>> I can give you a lot of repeated incidents where people have badmouthed >>> Carl. >>> Should we ban them all in a similar way? Months and years after the fact? >> >> They were not first to do that, they got provoked. > > It is never this easy. Even if being provoked, reaction in an unsuitable > manner > are not justified (just human). > > >>> Also, If we are going to punish somebody, there should be a due >>> process before that. >>> Witch hunts are nasty things. >>> Many devs requested punishment. >>> Did they? >> >> Yes, on IRC meeting many requested something about him to be done. > > Above you said "all". > > >>> Many people wanted breaking CoC to have consequences. >>> But I do not remember anybody requesting Carl to be banned for 4 months. >> >> 4 months is very realistic, symbolic amount would not be good for project. > > As long as you don't explain what makes 4 months realistic, it is just your > subjective assessment. > > >>> Feel free to prove me wrong, with quotes. >> >> If you want quotes, ask Carl to give you all his private emails. > > Do you even realize what you are saying? The accused person has to prove > anything? Paul, honestly, this sentence should stay in the 18th century and > you > should really reflect your ambitions about all this. > > Many people dislike CE's behavior and that's just fine - they are free to > feel > that way. However, everyone should keep proportionality in mind and accuse > someone for _specific_ misbehavior conducted after the CoC has been adopted > and > not call for generalized, inappropriate and severe punishment. Looks like you prefer to loose valuable developers instead of punishing bad behaviour, so be it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/version: Change the version bumping comment
Signed-off-by: Michael Niedermayer --- libavformat/version.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/version.h b/libavformat/version.h index 5679cce..c5635b7 100644 --- a/libavformat/version.h +++ b/libavformat/version.h @@ -29,8 +29,8 @@ #include "libavutil/version.h" -// When bumping major check Ticket5467, 5421, 5451(compatibility with Chromium) for regressing -// Also please add any ticket numbers that you belive might regress here +// Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium) +// Also please add any ticket numbers that you belive might be affected here #define LIBAVFORMAT_VERSION_MAJOR 57 #define LIBAVFORMAT_VERSION_MINOR 37 #define LIBAVFORMAT_VERSION_MICRO 101 -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: Export coded dimensions unconditionally
On Mon, Jun 06, 2016 at 09:02:34AM +0200, Hendrik Leppkes wrote:
> On Mon, Jun 6, 2016 at 9:01 AM, Hendrik Leppkes wrote:
> > On Sun, Jun 5, 2016 at 5:13 AM, Michael Niedermayer
> > wrote:
> >> This fixes a API regression
> >> Probably fixes Ticket5451
> >>
> >> Signed-off-by: Michael Niedermayer
> >> ---
> >> libavformat/utils.c |4 ++--
> >> libavformat/version.h |2 +-
> >> 2 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavformat/utils.c b/libavformat/utils.c
> >> index ac056c4..7ca0a12 100644
> >> --- a/libavformat/utils.c
> >> +++ b/libavformat/utils.c
> >> @@ -3789,8 +3789,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
> >> av_codec_set_lowres(st->codec,
> >> av_codec_get_lowres(st->internal->avctx));
> >> st->codec->width = st->internal->avctx->width;
> >> st->codec->height = st->internal->avctx->height;
> >> -st->codec->coded_width = st->internal->avctx->coded_width;
> >> -st->codec->coded_height = st->internal->avctx->coded_height;
> >> }
> >>
> >> if (st->codec->codec_tag != MKTAG('t','m','c','d'))
> >> @@ -3807,6 +3805,8 @@ FF_DISABLE_DEPRECATION_WARNINGS
> >> }
> >>
> >> // Fields unavailable in AVCodecParameters
> >> +st->codec->coded_width = st->internal->avctx->coded_width;
> >> +st->codec->coded_height = st->internal->avctx->coded_height;
> >> st->codec->properties = st->internal->avctx->properties;
> >> FF_ENABLE_DEPRECATION_WARNINGS
> >> #endif
> >> diff --git a/libavformat/version.h b/libavformat/version.h
> >> index c92a23f..2f79b7f 100644
> >> --- a/libavformat/version.h
> >> +++ b/libavformat/version.h
> >> @@ -29,7 +29,7 @@
> >>
> >> #include "libavutil/version.h"
> >>
> >> -// When bumping major check Ticket5467, 5421 for regressing
> >> +// When bumping major check Ticket5467, 5421, 5451 for regressing
> >> // Also please add any ticket numbers that you belive might regress here
> >> #define LIBAVFORMAT_VERSION_MAJOR 57
> >> #define LIBAVFORMAT_VERSION_MINOR 37
> >> --
> >> 1.7.9.5
> >
> > The ticket in question accesses st->codec to get this field. st->codec
> > is going away, so there is no point in testing this "regression",
> > since they need to update their API usage first for it to even
> > compile.
> > Heck the same thing applies to the other tickets you listed here, all
> > of those access information from st->codec which is going away
> > entirely, so you can't really "test" these cases. Someone would have
> > to update the code to use codecpar first, and while doing this
> > migration they would need to preserve whatever behavior exists today.
> >
>
>
> What I forgot to write, patch is otherwise fine, exporting information
> into st->codec that was previously available to avoid regressions for
> people that still use st->codec is OK.
patch applied with some rewording
i will post a patch with unrelated to this ticket rewording of
the note about bumps
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
Paul B Mahol wrote: >As requested in the IRC meeting I hereby request for the >voting committee to begin voting on whatever to ban Carl >Eugen Hoyos from mailing list, trac and IRC for 4 months, >starting after the voting has finished. If I have the right to vote, then I vote no. Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
Thilo Borgmann wrote: >Am 13.06.16 um 10:23 schrieb Paul B Mahol: >> On 6/13/16, Ivan Kalvachev wrote: [...] >>> Feel free to prove me wrong, with quotes. >> >> If you want quotes, ask Carl to give you all his private >> emails. > >Do you even realize what you are saying? The accused person >has to prove anything? Paul, honestly, this sentence should >stay in the 18th century and you should really reflect your >ambitions about all this. I agree with Thilo. [...] Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec_h264: use ff_h264_decode_extradata to extract PPS/SPS
On Mon, Jun 13, 2016 at 11:51 AM, Matthieu Bouron
wrote:
> On Fri, Jun 10, 2016 at 03:08:48PM +0200, Matthieu Bouron wrote:
>> From: Matthieu Bouron
>>
>> Fixes playback of HLS streams on MediaTek devices which requires PPS/SPS
>> to be set in their respective csd-{0,1} buffers.
>> ---
>>
>> Hello,
>>
>> The attached patch fixes playback of HLS streams on MediaTek devices which
>> requires PPS/SPS to be set in their respetive csd-{0,1} buffers (instead of
>> having sps+pps in the csd-0 which works on other devices).
>>
>> I'm not sure if I can use the ff_h264_decode_extradata this way (or at least
>> initialize the H264Context with zeroes minus the avctx field).
>
> Rebased patch (after the h264 ps merged) attached.
>
> I still have the same question, is my use of
> H264Context + ff_h264_decode_extradata correct ?
>
Using H264 decoder internals seems to be a rather unfortunate
solution, as its prone to breakage, often subtle, as the h264 decoder
gets changed and not all inter-module dependencies are known.
So if possible at all, not using something that uses H264Context for
example would be nice.
For the record, ff_h264_decode_extradata is scheduled for refactoring
to make it independent of H264Context so it can be more easily shared
with the h264 decoder and the h264 parser.
Once that is done, it may give you a cleaner interface to use it from
mediacodec as well.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FTP graceful close data connection to avoid server abort
2016-06-09 1:19 GMT+02:00 Lukasz Marek : > On 09.06.2016 00:25, Michael Niedermayer wrote: > > On Thu, Jun 02, 2016 at 02:29:47PM +0200, Camille Gonnet wrote: > >> When writing files to FTP, if the data connection is closed before the > >> control connection, the server may handle it as an aborted file transfer > >> and create and leave the file empty. > > > > which ftp server, or is that in the RFC, if so please refer to it > This is in RFC959. §4.1.1 (page 26) *An unexpected close* on the control connection will cause the server to take the effective *action of an abort (ABOR)* and a logout (QUIT). §5.2 (page 45): To prevent a race condition here, *the server sends a reply (226) after closing the data connection* (or if the connection is left open, a "file transfer completed" reply (250) and the user-PI should wait for one of these replies before issuing a new transfer command). §5.4 (page 49) Certain commands require a second reply for which *the user should also wait*. These replies may, for example, report on the progress or completion of file transfer or the closing of the data connection. They are secondary replies to file transfer commands. §4.2 (page 37) 1yz Positive Preliminary reply The requested action is being initiated; *expect another reply before proceeding with a new command*. (The user-process sending another command before the completion reply would be in violation of protocol; but server-FTP processes should queue any commands that arrive while a preceding command is in progress.) On a STOR command, we expect a "150 Accepted Data connection". So the 226 or 250 should always been replied, or an error. RFC is good for reference, unfortunately even popular linux > implementations don't follow it strictly (sometimes it is hard to say > they follow at all some aspects). Regarding aborting and stuff it is > really implementation dependent. I can't remember now which > implementation and what version, but one was totally unresponsive on > control connection while active transfer on data connection, so the only > way to abort it was to close data connection. > > > Reverting order of closing should be OK, but I'm not really sure > expecting all implementation to send 225/226 code is correct. I would > suggest to at least check state if it is UPLOADING and apply that change > only for this case. Perfectly this behaviour could be enabled by an > option and autodetected in ftp_connect_control_connection when server > send its name (note 220 code's message may be overwritten so an option > to enforce is needed) > I understand that it may cause some problems depending on implementations, but closing the data connection and the control connection without any check, considering that those are on different ports and can be re-ordered, this will lead to transfer aborted in many situations. > ___ > 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] [VOTE] Ban Carl Eugen Hoyos
On Sun, Jun 12, 2016 at 10:58:37PM +0200, Paul B Mahol wrote: > Hi, > > As requested in the IRC meeting I hereby request for the > voting committee to begin voting on whatever to ban Carl > Eugen Hoyos from mailing list, trac and IRC for 4 months, > starting after the voting has finished. > > Voting will last 7 days from now. > In order for the vote to pass, at least 50% of all votes > from committee need to agree to do so. > > All developers and users are welcome to write about their > experiences with Carl. I'm against for several reasons: - there is not a single reason provided in this mail (not saying there isn't any but it seems you're expecting people to provide them) - 4 months is extremely long, there is no proof Carl Eugen is a criminal - I don't think we should consider the CoC retroactive While I disagree with Carl Eugen on various aspects (mainly the toxic attitude towards certain other developers and at times users), this chastisement request sounds completely out of the reality, and illustrate very well the problem of overreacting in this community. Regards, -- 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] [PATCH] lavc/mediacodecdec_h264: use ff_h264_decode_extradata to extract PPS/SPS
On Fri, Jun 10, 2016 at 03:08:48PM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> Fixes playback of HLS streams on MediaTek devices which requires PPS/SPS
> to be set in their respective csd-{0,1} buffers.
> ---
>
> Hello,
>
> The attached patch fixes playback of HLS streams on MediaTek devices which
> requires PPS/SPS to be set in their respetive csd-{0,1} buffers (instead of
> having sps+pps in the csd-0 which works on other devices).
>
> I'm not sure if I can use the ff_h264_decode_extradata this way (or at least
> initialize the H264Context with zeroes minus the avctx field).
Rebased patch (after the h264 ps merged) attached.
I still have the same question, is my use of
H264Context + ff_h264_decode_extradata correct ?
Thanks in advance,
Matthieu
[...]
>From 30d70187e10f09231a59a255204c810d1662336b Mon Sep 17 00:00:00 2001
From: Matthieu Bouron
Date: Fri, 10 Jun 2016 13:16:09 +0200
Subject: [PATCH] lavc/mediacodecdec_h264: use ff_h264_decode_extradata to
extract PPS/SPS
Fixes playback of HLS streams on MediaTek devices which requires PPS/SPS
to be set in their respective csd-{0,1} buffers.
---
configure | 2 +-
libavcodec/mediacodecdec_h264.c | 140 +---
2 files changed, 30 insertions(+), 112 deletions(-)
diff --git a/configure b/configure
index a220fa1..eb08478 100755
--- a/configure
+++ b/configure
@@ -2548,7 +2548,7 @@ h264_d3d11va_hwaccel_select="h264_decoder"
h264_dxva2_hwaccel_deps="dxva2"
h264_dxva2_hwaccel_select="h264_decoder"
h264_mediacodec_decoder_deps="mediacodec"
-h264_mediacodec_decoder_select="h264_mp4toannexb_bsf h264_parser"
+h264_mediacodec_decoder_select="h264_mp4toannexb_bsf h264_decoder h264_parser"
h264_mmal_decoder_deps="mmal"
h264_mmal_decoder_select="mmal"
h264_mmal_hwaccel_deps="mmal"
diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index 52e48ae..b63b395 100644
--- a/libavcodec/mediacodecdec_h264.c
+++ b/libavcodec/mediacodecdec_h264.c
@@ -32,6 +32,7 @@
#include "libavutil/atomic.h"
#include "avcodec.h"
+#include "h264.h"
#include "internal.h"
#include "mediacodecdec.h"
#include "mediacodec_wrapper.h"
@@ -50,104 +51,6 @@ typedef struct MediaCodecH264DecContext {
} MediaCodecH264DecContext;
-static int h264_extradata_to_annexb_sps_pps(AVCodecContext *avctx,
-uint8_t **extradata_annexb, int *extradata_annexb_size,
-int *sps_offset, int *sps_size,
-int *pps_offset, int *pps_size)
-{
-uint16_t unit_size;
-uint64_t total_size = 0;
-
-uint8_t i, j, unit_nb;
-uint8_t sps_seen = 0;
-uint8_t pps_seen = 0;
-
-const uint8_t *extradata;
-static const uint8_t nalu_header[4] = { 0x00, 0x00, 0x00, 0x01 };
-
-if (avctx->extradata_size < 8) {
-av_log(avctx, AV_LOG_ERROR,
-"Too small extradata size, corrupted stream or invalid MP4/AVCC bitstream\n");
-return AVERROR(EINVAL);
-}
-
-*extradata_annexb = NULL;
-*extradata_annexb_size = 0;
-
-*sps_offset = *sps_size = 0;
-*pps_offset = *pps_size = 0;
-
-extradata = avctx->extradata + 4;
-
-/* skip length size */
-extradata++;
-
-for (j = 0; j < 2; j ++) {
-
-if (j == 0) {
-/* number of sps unit(s) */
-unit_nb = *extradata++ & 0x1f;
-} else {
-/* number of pps unit(s) */
-unit_nb = *extradata++;
-}
-
-for (i = 0; i < unit_nb; i++) {
-int err;
-
-unit_size = AV_RB16(extradata);
-total_size += unit_size + 4;
-
-if (total_size > INT_MAX) {
-av_log(avctx, AV_LOG_ERROR,
-"Too big extradata size, corrupted stream or invalid MP4/AVCC bitstream\n");
-av_freep(extradata_annexb);
-return AVERROR(EINVAL);
-}
-
-if (extradata + 2 + unit_size > avctx->extradata + avctx->extradata_size) {
-av_log(avctx, AV_LOG_ERROR, "Packet header is not contained in global extradata, "
-"corrupted stream or invalid MP4/AVCC bitstream\n");
-av_freep(extradata_annexb);
-return AVERROR(EINVAL);
-}
-
-if ((err = av_reallocp(extradata_annexb, total_size)) < 0) {
-return err;
-}
-
-memcpy(*extradata_annexb + total_size - unit_size - 4, nalu_header, 4);
-memcpy(*extradata_annexb + total_size - unit_size, extradata + 2, unit_size);
-extradata += 2 + unit_size;
-}
-
-if (unit_nb) {
-if (j == 0) {
-sps_seen = 1;
-*sps_size = total_size;
-} else {
-pps_seen = 1;
-*pps_size = total_size - *sps_size;
-*pps_offset = *sps_size;
-}
-}
-}
-
-*extradata_annexb_size = total_size;
-
-if (!sps_seen)
-av_log(avctx, AV_LOG_W
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
Le quintidi 25 prairial, an CCXXIV, Paul B Mahol a écrit : > As requested in the IRC meeting I hereby request for the > voting committee to begin voting on whatever to ban Carl > Eugen Hoyos from mailing list, trac and IRC for 4 months, > starting after the voting has finished. > > Voting will last 7 days from now. > In order for the vote to pass, at least 50% of all votes > from committee need to agree to do so. > > All developers and users are welcome to write about their > experiences with Carl. I vote no, since I have not seen actual elements regarding the alleged misbehaviours. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
Le primidi 11 prairial, an CCXXIV, Michael Niedermayer a écrit : > Please state clearly if you agree to add AVClass&AVOption to > AVCodecParameters or if you disagree about adding it or if you dont > care either way Since it is necessary to break the tie, I express clearly that I am against, because I have not seen benefits regarding the primary goal of AVOption (user interaction) and I consider supporting compatibility across binary version a waste of efforts. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/graphparser: remove '\n' from parse_filter
On Sun, Jun 12, 2016 at 3:09 PM, Muhammad Faiz wrote:
> On Mon, Jun 6, 2016 at 12:19 AM, Muhammad Faiz wrote:
>> On Sun, Jun 5, 2016 at 12:33 AM, Michael Niedermayer
>> wrote:
>>> On Thu, Jun 02, 2016 at 03:32:49PM +0700, Muhammad Faiz wrote:
On Thu, May 5, 2016 at 2:21 PM, Muhammad Faiz wrote:
> this allow a filter to be written like this:
> aformat =
> sample_fmts = fltp|flt:
> sample_rates = 44100|44800
>
> Signed-off-by: Muhammad Faiz
> ---
> libavfilter/graphparser.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/graphparser.c b/libavfilter/graphparser.c
> index 8d15b5d..03062af 100644
> --- a/libavfilter/graphparser.c
> +++ b/libavfilter/graphparser.c
> @@ -165,12 +165,12 @@ static int parse_filter(AVFilterContext
> **filt_ctx, const char **buf, AVFilterGr
> int index, void *log_ctx)
> {
> char *opts = NULL;
> -char *name = av_get_token(buf, "=,;[\n");
> +char *name = av_get_token(buf, "=,;[");
> int ret;
>
> if (**buf == '=') {
> (*buf)++;
> -opts = av_get_token(buf, "[],;\n");
> +opts = av_get_token(buf, "[],;");
> }
>
> ret = create_filter(filt_ctx, graph, index, name, opts, log_ctx);
> --
> 2.5.0
>
No response. So, I will try to explain this patch.
It allows filter definition to span across multiple lines.
This behaviour is useful to make filter graph more readable,
especially when stored on file.
For example, using lavfi
ffplay -graph_file filter.txt -f lavfi my_lavfi
filter.txt:
amovie=audio.mp3,
aformat=
channel_layouts = stereo:
sample_rates= 48000:
sample_fmts = flt|fltp,
asplit [out0],
showcqt =
tc = 0.33:
fps = 60
[out1]
>>>
>>> Can this break (realistic) existing and documented as working cases ?
>>>
>>
>> This should not break any existing filter graph.
>> Previously, filter graph written like above will generate error.
>
> Is it OK if I apply this patch?
>
> Thank's
Applied anyway. It doesn't break fate.
Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
Am 13.06.16 um 10:23 schrieb Paul B Mahol: > On 6/13/16, Ivan Kalvachev wrote: >> On 6/13/16, Paul B Mahol wrote: >>> On 6/13/16, Ivan Kalvachev wrote: On 6/12/16, Paul B Mahol wrote: > Hi, > > As requested in the IRC meeting I hereby request for the > voting committee to begin voting on whatever to ban Carl > Eugen Hoyos from mailing list, trac and IRC for 4 months, > starting after the voting has finished. I don't remember such thing to have been requested on the IRC meeting. Would you kindly quote the relevant parts of the logs? >>> >>> It was requested to act because of Carl misbehaviour. >>> Logs are available on net. >> >> I was on the meeting and I checked the published logs >> before sending my first mail. >> That's why I requested that you QUOTE the relevant part. >> >> Let me be blunt. Nobody have requested Carl to be banned, >> and definitely not from ML, trac, IRC for 4 months. >> >> Feel free to prove me wrong, by providing the quotes I requested. > > Nobody requested explicitly that they want to ban Carl for 4 months, > but they all want that his behaviour is punished. "all"? Also, I would like to know on what grounds and on what charges you request that punishment. >>> >>> On grounds that he was badmouthing others. >> >> That's way too vague... >> >> 1. I'd like to see links and quotes of him doing the things you accuse him >> of. > > It was all private. The last one about Derek, which was public, is just top of > iceberg. "all private"? Private behaviour, no matter how much we dislike it, can hardly be a subject here. Even if it correlates to other devs and the FFmpeg development process, it would be the task of the offended person to publish it and ask for actions if it really exceeds a behaviour that can not be privately ignored by the offended. >> 2. I'd like to know why we have to ban him for 4 months exactly? Why >> ban him from ML, IRC, Trac, but not git? > > Then we will ban him from git too. > >> How did you determined that this punishment is the one that is most >> fitting the crimes he has done? > > By careful examination. Just a phrase. There is no possible examination if it's "all private". And there is no careful determination possible for a punishment because we don't have mappings for misbehavior. Thus, what you propose is just your personal arbitrary opinion of a suitable punishment. Aside that applying any part of the CoC to misbehavior of the past is inappropriate IMHO. >> I can give you a lot of repeated incidents where people have badmouthed >> Carl. >> Should we ban them all in a similar way? Months and years after the fact? > > They were not first to do that, they got provoked. It is never this easy. Even if being provoked, reaction in an unsuitable manner are not justified (just human). >> Also, If we are going to punish somebody, there should be a due >> process before that. >> Witch hunts are nasty things. >> >>> Many devs requested punishment. >> Did they? > > Yes, on IRC meeting many requested something about him to be done. Above you said "all". >> Many people wanted breaking CoC to have consequences. >> But I do not remember anybody requesting Carl to be banned for 4 months. > > 4 months is very realistic, symbolic amount would not be good for project. As long as you don't explain what makes 4 months realistic, it is just your subjective assessment. >> Feel free to prove me wrong, with quotes. > > If you want quotes, ask Carl to give you all his private emails. Do you even realize what you are saying? The accused person has to prove anything? Paul, honestly, this sentence should stay in the 18th century and you should really reflect your ambitions about all this. Many people dislike CE's behavior and that's just fine - they are free to feel that way. However, everyone should keep proportionality in mind and accuse someone for _specific_ misbehavior conducted after the CoC has been adopted and not call for generalized, inappropriate and severe punishment. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FFmpeg Decklink input connection options
Is this really applied? > On 11 May 2016, at 2:14 AM, Michael Niedermayer > wrote: > > On Tue, May 10, 2016 at 11:44:00PM +0200, Deti Fliegl wrote: >> Hi, >> >> thank you. Patch approved. > > applied > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Breaking DRM is a little like attempting to break through a door even > though the window is wide open and the only thing in the house is a bunch > of things you dont want and which you would get tomorrow for free anyway > ___ > 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] [FFmpeg-cvslog] lavf/os_support.h: Fix for unicode filenames on windows.
Hi,
On 13/06/2016 10:21, Clément Bœsch wrote:
On Mon, Jun 13, 2016 at 05:50:18AM +0200, Matt Oliver wrote:
ffmpeg | branch: master | Matt Oliver | Mon Jun 6
17:04:39 2016 +1000| [37787f261639c53998487400e874741c17e85fc6] | committer: Matt
Oliver
lavf/os_support.h: Fix for unicode filenames on windows.
Fixes #819 #5256 #5281
Signed-off-by: Matt Oliver
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=37787f261639c53998487400e874741c17e85fc6
---
libavformat/file.c |4
libavformat/os_support.h | 24
2 files changed, 28 insertions(+)
diff --git a/libavformat/file.c b/libavformat/file.c
index 5765ce7..264542a 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
ret |= AVIO_FLAG_WRITE;
#else
struct stat st;
+# ifndef _WIN32
ret = stat(filename, &st);
+# else
+ret = win32_stat(filename, &st);
+# endif
why this chunk?
if (ret < 0)
return AVERROR(errno);
diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index a332911..9e312a5 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -182,6 +182,29 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
DEF_FS_FUNCTION(mkdir, _wmkdir, _mkdir)
DEF_FS_FUNCTION(rmdir, _wrmdir , _rmdir)
+#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
+static inline int win32_##name(const char *filename_utf8, partype par) \
+{ \
+wchar_t *filename_w; \
+int ret; \
+ \
+if (utf8towchar(filename_utf8, &filename_w)) \
+return -1;\
+if (!filename_w) \
+goto fallback;\
+ \
+ret = wfunc(filename_w, par); \
+av_free(filename_w); \
+return ret; \
+ \
+fallback: \
+/* filename may be be in CP_ACP */\
+return afunc(filename_utf8, par); \
+}
+
+DEF_FS_FUNCTION2(access, _waccess, _access, int)
+DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*)
+
static inline int win32_rename(const char *src_utf8, const char *dest_utf8)
{
wchar_t *src_w, *dest_w;
@@ -231,6 +254,7 @@ fallback:
#define rename win32_rename
#define rmdir win32_rmdir
#define unlink win32_unlink
+#define access win32_access
...instead of #define stat win32_stat here?
as already noted by someone else, this should be
#define stat(a, b) win32_stat((a), (b))
in order not to conflict with "struct stat" definition.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
Hi, > As requested in the IRC meeting I hereby request for the > voting committee to begin voting on whatever to ban Carl > Eugen Hoyos from mailing list, trac and IRC for 4 months, > starting after the voting has finished. I don't remember and don't have time to investigate if there has been such a request. At least, the 4 months period that comes out of nowhere as well as applying a new regulation to older misbehavior seem highly inappropriate. And that's just for the objective side of the medal... personally I think you're running a bit too mad about punishing CE here. > Voting will last 7 days from now. > In order for the vote to pass, at least 50% of all votes > from committee need to agree to do so. > All developers and users are welcome to write about their > experiences with Carl. Somebody said 'Wichhunt' and this sentence indicates that you're just on a personal campaign. Either this should be a vote for the committee or a discussion but for sure not both. But at least you've invited me to write what I think about that proposal, thanks. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
On 6/13/16, Ivan Kalvachev wrote: > On 6/13/16, Paul B Mahol wrote: >> On 6/13/16, Ivan Kalvachev wrote: >>> On 6/12/16, Paul B Mahol wrote: Hi, As requested in the IRC meeting I hereby request for the voting committee to begin voting on whatever to ban Carl Eugen Hoyos from mailing list, trac and IRC for 4 months, starting after the voting has finished. >>> >>> I don't remember such thing to have been requested on the IRC meeting. >>> Would you kindly quote the relevant parts of the logs? >> >> It was requested to act because of Carl misbehaviour. >> Logs are available on net. > > I was on the meeting and I checked the published logs > before sending my first mail. > That's why I requested that you QUOTE the relevant part. > > Let me be blunt. Nobody have requested Carl to be banned, > and definitely not from ML, trac, IRC for 4 months. > > Feel free to prove me wrong, by providing the quotes I requested. Nobody requested explicitly that they want to ban Carl for 4 months, but they all want that his behaviour is punished. > >>> Also, I would like to know on what grounds and >>> on what charges you request that punishment. >> >> On grounds that he was badmouthing others. > > That's way too vague... > > 1. I'd like to see links and quotes of him doing the things you accuse him > of. It was all private. The last one about Derek, which was public, is just top of iceberg. > > 2. I'd like to know why we have to ban him for 4 months exactly? Why > ban him from ML, IRC, Trac, but not git? Then we will ban him from git too. > How did you determined that this punishment is the one that is most > fitting the crimes he has done? By careful examination. > > I can give you a lot of repeated incidents where people have badmouthed > Carl. > Should we ban them all in a similar way? Months and years after the fact? They were not first to do that, they got provoked. > > Also, If we are going to punish somebody, there should be a due > process before that. > Witch hunts are nasty things. > >> Many devs requested punishment. > Did they? Yes, on IRC meeting many requested something about him to be done. > > Many people wanted breaking CoC to have consequences. > But I do not remember anybody requesting Carl to be banned for 4 months. 4 months is very realistic, symbolic amount would not be good for project. > Feel free to prove me wrong, with quotes. If you want quotes, ask Carl to give you all his private emails. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tools: update normalize script example to use loudnorm
On Sun, Jun 12, 2016 at 10:44:15PM -0500, Kyle Swanson wrote: > Signed-off-by: Kyle Swanson > --- > tools/normalize.py | 33 -- > tools/normalize.rb | 60 > ++ > 2 files changed, 60 insertions(+), 33 deletions(-) > delete mode 100755 tools/normalize.py > create mode 100644 tools/normalize.rb > Please de not delete normalize.py Regards, -- 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] [FFmpeg-cvslog] lavf/os_support.h: Fix for unicode filenames on windows.
On Mon, Jun 13, 2016 at 05:50:18AM +0200, Matt Oliver wrote:
> ffmpeg | branch: master | Matt Oliver | Mon Jun 6
> 17:04:39 2016 +1000| [37787f261639c53998487400e874741c17e85fc6] | committer:
> Matt Oliver
>
> lavf/os_support.h: Fix for unicode filenames on windows.
>
> Fixes #819 #5256 #5281
>
> Signed-off-by: Matt Oliver
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=37787f261639c53998487400e874741c17e85fc6
> ---
>
> libavformat/file.c |4
> libavformat/os_support.h | 24
> 2 files changed, 28 insertions(+)
>
> diff --git a/libavformat/file.c b/libavformat/file.c
> index 5765ce7..264542a 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
> ret |= AVIO_FLAG_WRITE;
> #else
> struct stat st;
> +# ifndef _WIN32
> ret = stat(filename, &st);
> +# else
> +ret = win32_stat(filename, &st);
> +# endif
why this chunk?
> if (ret < 0)
> return AVERROR(errno);
>
> diff --git a/libavformat/os_support.h b/libavformat/os_support.h
> index a332911..9e312a5 100644
> --- a/libavformat/os_support.h
> +++ b/libavformat/os_support.h
> @@ -182,6 +182,29 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
> DEF_FS_FUNCTION(mkdir, _wmkdir, _mkdir)
> DEF_FS_FUNCTION(rmdir, _wrmdir , _rmdir)
>
> +#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
> +static inline int win32_##name(const char *filename_utf8, partype par) \
> +{ \
> +wchar_t *filename_w; \
> +int ret; \
> + \
> +if (utf8towchar(filename_utf8, &filename_w)) \
> +return -1;\
> +if (!filename_w) \
> +goto fallback;\
> + \
> +ret = wfunc(filename_w, par); \
> +av_free(filename_w); \
> +return ret; \
> + \
> +fallback: \
> +/* filename may be be in CP_ACP */\
> +return afunc(filename_utf8, par); \
> +}
> +
> +DEF_FS_FUNCTION2(access, _waccess, _access, int)
> +DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*)
> +
> static inline int win32_rename(const char *src_utf8, const char *dest_utf8)
> {
> wchar_t *src_w, *dest_w;
> @@ -231,6 +254,7 @@ fallback:
> #define rename win32_rename
> #define rmdir win32_rmdir
> #define unlink win32_unlink
> +#define access win32_access
>
...instead of #define stat win32_stat here?
Regards,
--
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] [VOTE] Ban Carl Eugen Hoyos
Hi, On 12/06/2016 22:58, Paul B Mahol wrote: Hi, As requested in the IRC meeting I hereby request for the voting committee to begin voting on whatever to ban Carl Eugen Hoyos from mailing list, trac and IRC for 4 months, starting after the voting has finished. Voting will last 7 days from now. In order for the vote to pass, at least 50% of all votes from committee need to agree to do so. Disclaimer: I'm not part of this committee All developers and users are welcome to write about their experiences with Carl. My feeling here is that all the things that have been discussed about the CoC are a consequence of Carl's behaviour on the ML. I can understand (I think) your feelings, but this is still problematic to me as a rule of thumb. It does not seem fair to decide on a CoC because of certain facts and then rule on those very facts on the charge that they fail to follow the rules that they have led to create. In addition to this, I really feel that 4 months is way too long for a ban, as in "forever". In short, I feel that this is unfair and too long a period, though I can understand your feelings on this. Cheers, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
