Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
Am 04.03.16 um 23:44 schrieb Timothy Gu: > [...] > So here I propose the following for the master branch: > > n3.1-dev-N-78911-gf81c81c >/ | \ \ > /| \\ > next distinguish commits since commit > release from actual the start ofhash > release time > > For comparison, versions on the release branch are as follows: > > n3.0-4-geb46065 > /| \ > / \ \ > previous commits since commit > release that releasehash > [...] > >: Current: New > Master > Full : N-78911-gf81c81c : n3.1-dev-N-78911-gf81c81c > Shallow clone : git-2016-03-04-f81c81c : n3.1-dev-gf81c81c > Gitweb tarball : 3.0.git-f81c81c: n3.1-dev-gf81c81c > Nothing: 3.0.git: n3.1-dev > > Release branch > Full : n3.0-4-geb46065: n3.0.1-dev-4-geb46065 > Shallow clone : eb46065: n3.0.1-dev-geb56065 > Nothing: 3.0: n3.0.1-dev > > Release > Full : n3.0 : n3.0 > Shallow clone : n3.0 : n3.0 > Nothing: 3.0: n3.0 I had loved to see something like this sooner, thanks! I think in that form it is in all cases better than it is now. No more objections from me. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v5 1/4 v6] lavf/avienc: Add support for palette side data
Only copy/compare enough bytes for the bit depth in question. -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From 32eaa0889f7356524d785fa7432d48dd89c32376 Mon Sep 17 00:00:00 2001 From: Mats PetersonDate: Sat, 5 Mar 2016 07:32:12 +0100 Subject: [PATCH v5 1/4 v6] lavf/avienc: Add support for palette side data --- libavformat/avienc.c | 79 -- 1 file changed, 50 insertions(+), 29 deletions(-) diff --git a/libavformat/avienc.c b/libavformat/avienc.c index ca505f4..98157fc 100644 --- a/libavformat/avienc.c +++ b/libavformat/avienc.c @@ -74,12 +74,14 @@ typedef struct AVIStream { int max_size; int sample_requested; -int64_t pal_offset; -int hdr_pal_done; - int64_t last_dts; AVIIndex indexes; + +uint32_t palette[AVPALETTE_COUNT]; +uint32_t old_palette[AVPALETTE_COUNT]; +int64_t pal_offset; +int pal_done; } AVIStream; static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt); @@ -362,7 +364,8 @@ static int avi_write_header(AVFormatContext *s) && enc->pix_fmt == AV_PIX_FMT_RGB555LE && enc->bits_per_coded_sample == 15) enc->bits_per_coded_sample = 16; -avist->pal_offset = avio_tell(pb) + 40; +if (pb->seekable) +avist->pal_offset = avio_tell(pb) + 40; ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0); pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi, enc->bits_per_coded_sample); @@ -652,11 +655,11 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt) { unsigned char tag[5]; const int stream_index = pkt->stream_index; -const uint8_t *data= pkt->data; -int size = pkt->size; AVIOContext *pb = s->pb; AVCodecContext *enc = s->streams[stream_index]->codec; AVIStream *avist= s->streams[stream_index]->priv_data; +AVPacket *opkt = pkt; +enum AVPixelFormat pix_fmt = enc->pix_fmt; int ret; if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) { @@ -668,39 +671,57 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt) if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0) return ret; -if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) { -int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16; -int expected_stride = ((enc->width * bpc + 31) >> 5)*4; - -ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride); -if (ret < 0) -return ret; -if (ret) { -if (ret == CONTAINS_PAL) { -int pc_tag, i; +if (!pkt->size) +return avi_write_packet_internal(s, pkt); /* Passthrough */ + +if (enc->codec_type == AVMEDIA_TYPE_VIDEO) { +if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) { +int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16; +int expected_stride = ((enc->width * bpc + 31) >> 5)*4; +ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride); +if (ret < 0) +return ret; +} else +ret = 0; +if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1) +pix_fmt = AV_PIX_FMT_MONOWHITE; +if (pix_fmt == AV_PIX_FMT_PAL8 || +pix_fmt == AV_PIX_FMT_MONOWHITE || +pix_fmt == AV_PIX_FMT_MONOBLACK) { +int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette); +if (ret2 < 0) +return ret2; +if (ret2) { int pal_size = 1 << enc->bits_per_coded_sample; -if (!avist->hdr_pal_done) { +int pc_tag, i; +if (pb->seekable && !avist->pal_done) { int64_t cur_offset = avio_tell(pb); avio_seek(pb, avist->pal_offset, SEEK_SET); for (i = 0; i < pal_size; i++) { -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); +uint32_t v = avist->palette[i]; avio_wl32(pb, v & 0xff); } avio_seek(pb, cur_offset, SEEK_SET); -avist->hdr_pal_done++; +memcpy(avist->old_palette, avist->palette, pal_size * 4); +avist->pal_done++; } -avi_stream2fourcc(tag, stream_index, enc->codec_type); -tag[2] = 'p'; tag[3] = 'c'; -pc_tag = ff_start_tag(pb, tag); -avio_w8(pb, 0); -avio_w8(pb, pal_size & 0xFF); -avio_wl16(pb, 0); // reserved -for (i = 0; i < pal_size; i++) { -
Re: [FFmpeg-devel] [PATCH v5 1/4 v6] lavf/avienc: Add support for palette side data
On 03/05/2016 07:33 AM, Mats Peterson wrote: Only copy/compare enough bytes for the bit depth in question. Enough bytes of the palette, that is. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API
On Fri, Mar 04, 2016 at 01:34:55PM +, Derek Buitenhuis wrote: > On 3/3/2016 7:50 PM, Michael Niedermayer wrote: > > The io_open/close callbacks afterwards seem direct access IIUC > > so its not possible to remove or add any fields prior > > > > though maybe they have been added so recently that its ok to move > > them above all "no direct access" fields > > or maybe iam missing something > > Crap. I must have screwed up when merging those callbacks. I can move > the be blacklist entry under them, or I can break ABI and move both, > since I don't think there is release. i thought it was post 3.0 but it seems, it was in 3.0 git grep io_close release/3.0:libavformat/avformat.h release/3.0:libavformat/avformat.h:#define AVFMT_FLAG_CUSTOM_IO0x0080 ///< The caller has supplied a custom AVIOContext, don't avio_close() it. release/3.0:libavformat/avformat.h: * @deprecated Use io_open and io_close. release/3.0:libavformat/avformat.h:void (*io_close)(struct AVFormatContext *s, AVIOContext *pb); > > Which do people prefer? They're both kinda meh. > > - Derek > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousands in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/4 v5] lavf/avienc: Add support for palette side data
On 03/05/2016 04:48 AM, Mats Peterson wrote: On 03/05/2016 04:43 AM, Mats Peterson wrote: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel This one only adds an xxpc chunk if it's not identical to the previosly used palette. Good enough? Mats I should add that 8bpp_129.avi is a bit of abomination, since it contains identical xxpc chunks for every frame. But it's a good test file for this purpose. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/cos_tablegen: extend table generation to 17bits
On 3/5/2016 12:36 AM, Michael Niedermayer wrote: > On Fri, Mar 04, 2016 at 11:52:50PM -0300, James Almer wrote: >> Fixes compilation of fft with hardcoded tables >> >> Signed-off-by: James Almer>> --- >> fate-fft tests only up to 12 bits, so i ran fft-test -n17 manually >> and it didn't fail (It was also very slow). >> This change also generates sine tables for 17bit which are currently >> unused, so they kinda bloat the binary. Maybe someone wants to update >> rdft like it was done for fft and give them purpose? >> >> libavcodec/cos_tablegen.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > LGTM > > thx Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/4 v5] lavf/avienc: Add support for palette side data
On 03/05/2016 04:43 AM, Mats Peterson wrote: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel This one only adds an xxpc chunk if it's not identical to the previosly used palette. Good enough? Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/4 v4] lavf/avienc: Add support for palette side data
On 03/05/2016 04:38 AM, Mats Peterson wrote: Something like this? It stores the palette in avist->old_palette, and compares every new palette chunk with it, and only adds an xxpc chunk if it differs. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Ouch, sorry for those fprintf() lines. I will remove them. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v5 1/4 v4] lavf/avienc: Add support for palette side data
Something like this? It stores the palette in avist->old_palette, and compares every new palette chunk with it, and only adds an xxpc chunk if it differs. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From abc3c5e67b1064e64d12f15b43c8063f29fb06ef Mon Sep 17 00:00:00 2001 From: Mats PetersonDate: Sat, 5 Mar 2016 04:36:27 +0100 Subject: [PATCH v5 1/4 v4] lavf/avienc: Add support for palette side data --- libavformat/avienc.c | 80 -- 1 file changed, 51 insertions(+), 29 deletions(-) diff --git a/libavformat/avienc.c b/libavformat/avienc.c index ca505f4..61621ef 100644 --- a/libavformat/avienc.c +++ b/libavformat/avienc.c @@ -74,12 +74,14 @@ typedef struct AVIStream { int max_size; int sample_requested; -int64_t pal_offset; -int hdr_pal_done; - int64_t last_dts; AVIIndex indexes; + +uint32_t palette[AVPALETTE_COUNT]; +uint32_t old_palette[AVPALETTE_COUNT]; +int64_t pal_offset; +int pal_done; } AVIStream; static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt); @@ -362,7 +364,8 @@ static int avi_write_header(AVFormatContext *s) && enc->pix_fmt == AV_PIX_FMT_RGB555LE && enc->bits_per_coded_sample == 15) enc->bits_per_coded_sample = 16; -avist->pal_offset = avio_tell(pb) + 40; +if (pb->seekable) +avist->pal_offset = avio_tell(pb) + 40; ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0); pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi, enc->bits_per_coded_sample); @@ -652,11 +655,11 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt) { unsigned char tag[5]; const int stream_index = pkt->stream_index; -const uint8_t *data= pkt->data; -int size = pkt->size; AVIOContext *pb = s->pb; AVCodecContext *enc = s->streams[stream_index]->codec; AVIStream *avist= s->streams[stream_index]->priv_data; +AVPacket *opkt = pkt; +enum AVPixelFormat pix_fmt = enc->pix_fmt; int ret; if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) { @@ -668,39 +671,58 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt) if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0) return ret; -if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) { -int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16; -int expected_stride = ((enc->width * bpc + 31) >> 5)*4; - -ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride); -if (ret < 0) -return ret; -if (ret) { -if (ret == CONTAINS_PAL) { -int pc_tag, i; +if (!pkt->size) +return avi_write_packet_internal(s, pkt); /* Passthrough */ + +if (enc->codec_type == AVMEDIA_TYPE_VIDEO) { +if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) { +int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16; +int expected_stride = ((enc->width * bpc + 31) >> 5)*4; +ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride); +if (ret < 0) +return ret; +} else +ret = 0; +if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1) +pix_fmt = AV_PIX_FMT_MONOWHITE; +if (pix_fmt == AV_PIX_FMT_PAL8 || +pix_fmt == AV_PIX_FMT_MONOWHITE || +pix_fmt == AV_PIX_FMT_MONOBLACK) { +int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette); +if (ret2 < 0) +return ret2; +if (ret2) { int pal_size = 1 << enc->bits_per_coded_sample; -if (!avist->hdr_pal_done) { +int pc_tag, i; +if (pb->seekable && !avist->pal_done) { int64_t cur_offset = avio_tell(pb); avio_seek(pb, avist->pal_offset, SEEK_SET); for (i = 0; i < pal_size; i++) { -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); +uint32_t v = avist->palette[i]; avio_wl32(pb, v & 0xff); } avio_seek(pb, cur_offset, SEEK_SET); -avist->hdr_pal_done++; +memcpy(avist->old_palette, avist->palette, AVPALETTE_SIZE); +avist->pal_done++; } -avi_stream2fourcc(tag, stream_index, enc->codec_type); -tag[2] = 'p'; tag[3] = 'c'; -pc_tag = ff_start_tag(pb, tag); -avio_w8(pb, 0); -avio_w8(pb, pal_size & 0xFF); -
Re: [FFmpeg-devel] [PATCH] avcodec/cos_tablegen: extend table generation to 17bits
On Fri, Mar 04, 2016 at 11:52:50PM -0300, James Almer wrote: > Fixes compilation of fft with hardcoded tables > > Signed-off-by: James Almer> --- > fate-fft tests only up to 12 bits, so i ran fft-test -n17 manually > and it didn't fail (It was also very slow). > This change also generates sine tables for 17bit which are currently > unused, so they kinda bloat the binary. Maybe someone wants to update > rdft like it was done for fft and give them purpose? > > libavcodec/cos_tablegen.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB For every action, there is an equal and opposite reaction. -- Newton For every man jailed for a minor crime, theres one person more that will hate the government, some of them will become terrorists. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data
On 03/05/2016 04:19 AM, Mats Peterson wrote: On 03/05/2016 01:08 AM, Michael Niedermayer wrote: On Fri, Mar 04, 2016 at 10:12:41PM +0100, Mats Peterson wrote: On 03/04/2016 10:02 PM, Mats Peterson wrote: On 03/04/2016 09:52 PM, Mats Peterson wrote: On 03/04/2016 08:44 PM, Michael Niedermayer wrote: On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote: On 03/04/2016 05:59 AM, Mats Peterson wrote: Removed some unused variables in AVIStream. I would like to remind you of the fact that this patch (and the one for riffenc.c) is needed for stream copying of Microsoft Video 1 (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are possibly more codecs using a palette, but these are the ones I can come up with at the moment. i tried CRAM and MSRLE, but these already work when streamcopied before, do you have a testcase that does not work It works, but only so much. On stream copy, it will only write the palette after BITMAPINFOHEADER to the destination file. It won't write any xxpc palette switching chunks to the file. Mats The xxpc chunks come as palette side data. Mats Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without where can i find that file ? Thought you had it already? https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk the avienc.c and riffenc.c patch. The destination file will only contain xxpc chunks with my patch applied. pc chunks are only needed when the palette changes, if its the same for the whole file and after BITMAPINFOHEADER then theres no need for pc chunks And what do you suggest in order to detect this? 1 kb more per frame isn't that much. Nut uses it all the time. You were the one who proposed to use a shared function, and the option for a calling program to deliver the palette as side data. That's why I wrote the function, to be shared by avienc, movenc and possibly more muxers. It would be nice if you could apply these remaining patches now, thank you. Or rather, it was Reimar who was first complaining at the muxers lacking the ability to handle palette side data. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data
On 03/05/2016 01:08 AM, Michael Niedermayer wrote: On Fri, Mar 04, 2016 at 10:12:41PM +0100, Mats Peterson wrote: On 03/04/2016 10:02 PM, Mats Peterson wrote: On 03/04/2016 09:52 PM, Mats Peterson wrote: On 03/04/2016 08:44 PM, Michael Niedermayer wrote: On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote: On 03/04/2016 05:59 AM, Mats Peterson wrote: Removed some unused variables in AVIStream. I would like to remind you of the fact that this patch (and the one for riffenc.c) is needed for stream copying of Microsoft Video 1 (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are possibly more codecs using a palette, but these are the ones I can come up with at the moment. i tried CRAM and MSRLE, but these already work when streamcopied before, do you have a testcase that does not work It works, but only so much. On stream copy, it will only write the palette after BITMAPINFOHEADER to the destination file. It won't write any xxpc palette switching chunks to the file. Mats The xxpc chunks come as palette side data. Mats Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without where can i find that file ? Thought you had it already? https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk the avienc.c and riffenc.c patch. The destination file will only contain xxpc chunks with my patch applied. pc chunks are only needed when the palette changes, if its the same for the whole file and after BITMAPINFOHEADER then theres no need for pc chunks And what do you suggest in order to detect this? 1 kb more per frame isn't that much. Nut uses it all the time. You were the one who proposed to use a shared function, and the option for a calling program to deliver the palette as side data. That's why I wrote the function, to be shared by avienc, movenc and possibly more muxers. It would be nice if you could apply these remaining patches now, thank you. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
On Fri, 4 Mar 2016 14:44:28 -0800 Timothy Guwrote: > So after all the email exchanges, I think there are certain things > that our version SHOULD contain: > > - The hash > - The next release (i.e. n3.1) > - A way to compare two versions > > The date is considered to be "good" but perhaps not as necessary. the problem i've seen when helping users when the date is inside the version string (in mplayer) is that the idiot distros build an old mplayer 1.1-2016-01-01 right? except mplayer 1.1 was released 3 years ago. in 2013. they just built a 3 year old tarball two months ago and users install it like it was new! which is why ffmpeg and mplayer have the copyright year in the version string to help. slightly. assuming distros dont mess with it. > > Any objections? > should put it up to a vote what devs and users want to see. otherwise its just a few vocal devs on the list dictating it for everyone :P -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/cos_tablegen: extend table generation to 17bits
Fixes compilation of fft with hardcoded tables Signed-off-by: James Almer--- fate-fft tests only up to 12 bits, so i ran fft-test -n17 manually and it didn't fail (It was also very slow). This change also generates sine tables for 17bit which are currently unused, so they kinda bloat the binary. Maybe someone wants to update rdft like it was done for fft and give them purpose? libavcodec/cos_tablegen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/cos_tablegen.c b/libavcodec/cos_tablegen.c index dbd0cc0..7206aad 100644 --- a/libavcodec/cos_tablegen.c +++ b/libavcodec/cos_tablegen.c @@ -26,7 +26,7 @@ #include "libavutil/mathematics.h" -#define BITS 16 +#define BITS 17 #define FLOATFMT "%.18e" #define FIXEDFMT "%6d" -- 2.7.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use matroska TrackNumber for populating AVStream::id
Ok, something like this for now, then? I'm new to ffmpeg development. When is the next version bump going to happen? --- libavformat/matroskadec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c index d20568c..4c3e53a 100644 --- a/libavformat/matroskadec.c +++ b/libavformat/matroskadec.c @@ -1856,6 +1856,9 @@ static int matroska_parse_tracks(AVFormatContext *s) return AVERROR(ENOMEM); } +if (track->num <= INT_MAX) + st->id = (int) track->num; + if (key_id_base64) { /* export encryption key id as base64 metadata tag */ av_dict_set(>metadata, "enc_key_id", key_id_base64, 0); -- 2.7.0.rc3.207.g0ac5344 On Thu, Mar 3, 2016 at 2:14 AM, Carl Eugen Hoyoswrote: > wm4 googlemail.com> writes: > >> > +st->id = (int) track->num; > >> Might be better after all not to set the id if it's out of range? > > Yes, please. > > While there, the id field could be changed to 64bit with the > next version bump. > > Carl Eugen > > ___ > 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 v5 1/4 v3] lavf/avienc: Add support for palette side data
On Fri, Mar 04, 2016 at 10:12:41PM +0100, Mats Peterson wrote: > On 03/04/2016 10:02 PM, Mats Peterson wrote: > >On 03/04/2016 09:52 PM, Mats Peterson wrote: > >>On 03/04/2016 08:44 PM, Michael Niedermayer wrote: > >>>On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote: > On 03/04/2016 05:59 AM, Mats Peterson wrote: > >Removed some unused variables in AVIStream. > > > > > I would like to remind you of the fact that this patch (and the one > for riffenc.c) is needed for stream copying of Microsoft Video 1 > (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are > possibly more codecs using a palette, but these are the ones I can > come up with at the moment. > >>> > >>>i tried CRAM and MSRLE, but these already work when streamcopied > >>>before, do you have a testcase that does not work > >>> > >> > >>It works, but only so much. On stream copy, it will only write the > >>palette after BITMAPINFOHEADER to the destination file. It won't write > >>any xxpc palette switching chunks to the file. > >> > >>Mats > >> > >The xxpc chunks come as palette side data. > > > >Mats > > > Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without where can i find that file ? > the avienc.c and riffenc.c patch. The destination file will only > contain xxpc chunks with my patch applied. pc chunks are only needed when the palette changes, if its the same for the whole file and after BITMAPINFOHEADER then theres no need for pc chunks a testcase with changing palette would be ideal for fate [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousands in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
On Fri, Mar 04, 2016 at 08:46:42PM +0100, Reimar Döffinger wrote: > On 04.03.2016, at 11:24, Nicolas Georgewrote: > > > The Git (short) hash carries all the information by itself, so it should be > > present. But extra, redundant, information can be added for the convenience > > of users and "supporters". > > > > Basically, the version could be something like > > "g510046c:N78879-3.0master417-H20160303": > > The formatting is rather ugly but I'd be in favour of something like that. > An attempt to order the information in increasing detail might be: > v3.0+417-D20160303-N78879-g510046c > Note that I'm not convinced the git describe info/branch info/number of > commits since release is all that useful, but the base release version > number seems nice to have. I agree. > Particularly the branch name can easily be misleading as it can be anyone's > master, not necessarily the one on ffmpeg.org. Indeed. ->8-- So after all the email exchanges, I think there are certain things that our version SHOULD contain: - The hash - The next release (i.e. n3.1) - A way to compare two versions The date is considered to be "good" but perhaps not as necessary. So here I propose the following for the master branch: n3.1-dev-N-78911-gf81c81c / | \ \ /| \\ next distinguish commits since commit release from actual the start ofhash release time For comparison, versions on the release branch are as follows: n3.0-4-geb46065 /| \ / \ \ previous commits since commit release that releasehash A few reasons why I chose this style for master branch rather than some other: - I want it to bear some resemblance to our original style - which also happens to satisfy Carl's perhaps unjustified dependency on it - I want it to be somewhat consistent with our release branch version - It should also be gitrevisions(7)-compatible I would also like to raise an awareness of versioning when full Git metadata is not available. version.sh tries its best to get information, and usually ends up with one of the following circumstances. However, the format is wildly inconsistent, and I want to fix this once and for all. I can utilize the RELEASE file to provide information on our next release, even when tags are unavailable. : Current: New Master Full : N-78911-gf81c81c : n3.1-dev-N-78911-gf81c81c Shallow clone : git-2016-03-04-f81c81c : n3.1-dev-gf81c81c Gitweb tarball : 3.0.git-f81c81c: n3.1-dev-gf81c81c Nothing: 3.0.git: n3.1-dev Release branch Full : n3.0-4-geb46065: n3.0.1-dev-4-geb46065 Shallow clone : eb46065: n3.0.1-dev-geb56065 Nothing: 3.0: n3.0.1-dev Release Full : n3.0 : n3.0 Shallow clone : n3.0 : n3.0 Nothing: 3.0: n3.0 Any objections? Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
Am 04.03.16 um 22:50 schrieb Timothy Gu: > On Fri, Mar 04, 2016 at 06:48:04PM +0100, Thilo Borgmann wrote: >> Am 04.03.16 um 17:57 schrieb Timothy Gu: >>> On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote: Am 04.03.16 um 08:58 schrieb wm4: > > Being able to see the, well, version in the version output (instead of > random numbers) sounds like a pretty convincing argument. Neither a good play on words nor elaborative; not even helpful. You say they are random numbers, CE says it is continuous. What is correct? >>> >>> It is continuous. But to the user's eye, N-71234 is no different from >>> N-41234, >>> and hence "random." >> >> I assume that if there is no difference in the user's eye between >> N-71234 and N-41234 then there is also no difference for that user >> between dev-123 and dev-346. > > That's not the point. ... From here I really can't follow you... > The point is that there is something before the dev > part, and that's what makes the difference. Do you mean the absolute anchor point for dev-123 (completely: v3.0-dev123) which leads to "from release 3.0 go 123 steps further"? If so, yes, it is different to N-12345 which leads to "go 12345 steps". In that case, I would still prefer "absolute position" above "anchor + relative position". > When I said "no different," I meant except the fact that N-71234 is obviously > newer. The fact that it fails to convey any additional information is the > issue we are trying to attack. With what I'm absolutely fine - I would like to see the release tag in front. To determine how far away the build is from that release, I would still prefer the absolute number (like said above). Why? If I understand this correctly, the dev-123 tag version has a certain disadvantage against N-tags. Let's say there is v3.0-dev123. Let's say there is v3.5-dev3. Let's assume v3.5 was released right after 3.0 (3.1, 3.2, etc are not existing) Now, the question of interest is, how big is the difference between v3.0-dev123 and v3.5-dev3? This is the question this is all about, isn't it? Since I do not know, how many commits there were at all for version 3.0, I cannot answer the question. Maybe v3.0-dev142 was the last? Maybe v3.0-dev897? Let's assume there is v3.0-N-12345 and v3.5-N-12389... I can tell you and estimate whatever 44 commits are worth estimating, no matter which commit exactly raised version minor from 0 to 5. But maybe I'm totally off-minded here. So what about the release tag? Well it is a quite useful extension because of the already mentioned possibility of determining the existing features at once. I'm pro adding it to the version string. The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is uselessly redundant to the existing hash tag in my eyes. Why add another more roughly estimation of the users repo-state? I don't think this should be added to the version string. >>> >>> Can you elaborate on this? I am not sure I understand everything you are >>> saying. Specfically, what is "devxy"? >> >> The core concern about it is that is just redundant. I assume Timo to be >> correct about: >> >> "A new dev tag is made every time a release is branched off, to indicate >> development of the next ffmpeg version started there, ..." >> >> Then there is no gain of information in the dev-123 tag if there is >> already the release number given. In that case "v4.5-gdeabdef" tells me >> the very same as "v4.5-dev-123-gdeabdef" does. If Timo is correct, the >> can never be a "4.5-dev-789-abcdefg" tag. v4.5 is just enough. >> >> Summing it all up for me, I think a release prefix would make perfect >> sense. Thus, switching from >> >> N-12345-abcdefg >> >> to >> >> v4.5-N-12345-abcdefg >> >> should be done for the sake of the users. There is at least CE wanting >> to stick with N-tags so why not? The only reason I can imagine for >> getting rid of N-tags and/or including dev-123 tags would be that a >> native git show command needs it to work properly as well as giving >> better human readable information. > > I see where you are coming from. I will address this issue in my reply to > Reimar. Eh... No - I don't understand. Maybe your reply to Raimar will explain... -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/dump.c: Print mastering display metadata
On Fri, 4 Mar 2016 23:15:52 +0100 Michael Niedermayerwrote: > On Mon, Feb 29, 2016 at 05:20:17PM -0800, Neil Birkbeck wrote: > > Signed-off-by: Neil Birkbeck > > --- > > libavformat/dump.c | 21 + > > 1 file changed, 21 insertions(+) > > applied > > thanks > > [...] This should also go into ffprobe. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests/gapless: add gapless aac tests
On Fri, Mar 04, 2016 at 10:46:33PM +0100, Marton Balint wrote: > > On Thu, 3 Mar 2016, Michael Niedermayer wrote: > > >On Thu, Mar 03, 2016 at 02:27:52AM +0100, Marton Balint wrote: > >>Signed-off-by: Marton Balint> >>--- > >> tests/fate/gapless.mak | 3 +++ > >> tests/ref/fate/gapless-aac | 5 + > >> 2 files changed, 8 insertions(+) > >> create mode 100644 tests/ref/fate/gapless-aac > > > >seems to fail on x86-32 > > > >--- ffmpeg/tests/ref/fate/gapless-aac 2016-03-03 03:06:35.306048679 +0100 > >+++ tests/data/fate/gapless-aac 2016-03-03 03:11:56.286055441 +0100 > >@@ -1,5 +1,5 @@ > >9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-1 > >-d3c3c4ea121b3f3b8a346a168d2fec0e > >+d00bed4d4a83ce1addb92c075b2fcaaf > >9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-2 > >-d3c3c4ea121b3f3b8a346a168d2fec0e > >+d00bed4d4a83ce1addb92c075b2fcaaf > >63dd86b78c8fbd22a99bf88583256bfe *tests/data/fate/gapless-aac.out-3 > >Test gapless-aac failed. Look at tests/data/fate/gapless-aac.err for details. > >make: *** [fate-gapless-aac] Error 1 > > Hmm, it seems there is a tiny difference in the 145th sample of the > first decoded frame. I thought this is not supposed to happen with > the fixed point decoder. Anybody has any ideas? in absence of better ideas 1:pepper the code with printf() run on both x86-32 and 64 and diff to find te first difference if that explains the problem then you are done else goto 1 > > Regards, > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/dump.c: Print mastering display metadata
On Mon, Feb 29, 2016 at 05:20:17PM -0800, Neil Birkbeck wrote: > Signed-off-by: Neil Birkbeck> --- > libavformat/dump.c | 21 + > 1 file changed, 21 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: Add early support for colour elements
On Thu, Mar 03, 2016 at 11:23:53PM -0800, Neil Birkbeck wrote: > And yet another revision, where the syntax lists are actually terminated... applied thanks [..] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- 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 v5 1/4 v3] lavf/avienc: Add support for palette side data
Mats Petersonskrev: (4 mars 2016 22:12:41 CET) >On 03/04/2016 10:02 PM, Mats Peterson wrote: >> On 03/04/2016 09:52 PM, Mats Peterson wrote: >>> On 03/04/2016 08:44 PM, Michael Niedermayer wrote: On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote: > On 03/04/2016 05:59 AM, Mats Peterson wrote: >> Removed some unused variables in AVIStream. >> > > > I would like to remind you of the fact that this patch (and the >one > for riffenc.c) is needed for stream copying of Microsoft Video 1 > (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are > possibly more codecs using a palette, but these are the ones I can > come up with at the moment. i tried CRAM and MSRLE, but these already work when streamcopied before, do you have a testcase that does not work >>> >>> It works, but only so much. On stream copy, it will only write the >>> palette after BITMAPINFOHEADER to the destination file. It won't >write >>> any xxpc palette switching chunks to the file. >>> >>> Mats >>> >> The xxpc chunks come as palette side data. >> >> Mats > > >Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without the >avienc.c and riffenc.c patch. The destination file will only contain >xxpc chunks with my patch applied. > >Mats > > >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel What's more, the whole idea with using a shared function for retrieval of the palette for a muxer was to enable a calling program to deliver it as side data, if desired. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
On Fri, Mar 04, 2016 at 06:48:04PM +0100, Thilo Borgmann wrote: > Am 04.03.16 um 17:57 schrieb Timothy Gu: > > On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote: > >> Am 04.03.16 um 08:58 schrieb wm4: > >>> > >>> Being able to see the, well, version in the version output (instead of > >>> random numbers) sounds like a pretty convincing argument. > >> > >> Neither a good play on words nor elaborative; not even helpful. > >> > >> You say they are random numbers, CE says it is continuous. What is correct? > > > > It is continuous. But to the user's eye, N-71234 is no different from > > N-41234, > > and hence "random." > > I assume that if there is no difference in the user's eye between > N-71234 and N-41234 then there is also no difference for that user > between dev-123 and dev-346. That's not the point. The point is that there is something before the dev part, and that's what makes the difference. When I said "no different," I meant except the fact that N-71234 is obviously newer. The fact that it fails to convey any additional information is the issue we are trying to attack. > > > >> So what about the release tag? Well it is a quite useful extension because > >> of > >> the already mentioned possibility of determining the existing features at > >> once. > >> I'm pro adding it to the version string. > >> > >> The tag-tag? (devxy) I don't see it anywhere except in git and therefore > >> it is > >> uselessly redundant to the existing hash tag in my eyes. Why add another > >> more > >> roughly estimation of the users repo-state? I don't think this should be > >> added > >> to the version string. > > > > Can you elaborate on this? I am not sure I understand everything you are > > saying. Specfically, what is "devxy"? > > The core concern about it is that is just redundant. I assume Timo to be > correct about: > > "A new dev tag is made every time a release is branched off, to indicate > development of the next ffmpeg version started there, ..." > > Then there is no gain of information in the dev-123 tag if there is > already the release number given. In that case "v4.5-gdeabdef" tells me > the very same as "v4.5-dev-123-gdeabdef" does. If Timo is correct, the > can never be a "4.5-dev-789-abcdefg" tag. v4.5 is just enough. > > Summing it all up for me, I think a release prefix would make perfect > sense. Thus, switching from > > N-12345-abcdefg > > to > > v4.5-N-12345-abcdefg > > should be done for the sake of the users. There is at least CE wanting > to stick with N-tags so why not? The only reason I can imagine for > getting rid of N-tags and/or including dev-123 tags would be that a > native git show command needs it to work properly as well as giving > better human readable information. I see where you are coming from. I will address this issue in my reply to Reimar. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: allow subtitle text format to be ASS without timing
Now with ffmpeg-devel in CC On Fri, Mar 04, 2016 at 04:37:41PM +0100, Clément Bœsch wrote: > On Fri, Mar 04, 2016 at 04:22:44PM +0100, Michael Niedermayer wrote: > > On Fri, Feb 26, 2016 at 10:01:51PM +0100, Clément Bœsch wrote: > > > ffmpeg | branch: master | Clément Bœsch| Wed Jan 6 > > > 13:43:23 2016 +0100| [29412821241050c846dbceaad4b9752857659977] | > > > committer: Clément Bœsch > > [...] > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > > > index 7a56899..d3e035a 100644 > > > --- a/libavcodec/avcodec.h > > > +++ b/libavcodec/avcodec.h > > > @@ -3285,6 +3285,10 @@ typedef struct AVCodecContext { > > > #define FF_SUB_CHARENC_MODE_AUTOMATIC0 ///< libavcodec will select > > > the mode itself > > > #define FF_SUB_CHARENC_MODE_PRE_DECODER 1 ///< the AVPacket data needs > > > to be recoded to UTF-8 before being fed to the decoder, requires iconv > > > > > > +int sub_text_format; > > > +#define FF_SUB_TEXT_FMT_ASS 0 > > > +#define FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS 1 > > > + > > > /** > > > * Skip processing alpha if supported by codec. > > > * Note that if the format uses pre-multiplied alpha (common with > > > VP6, > > > > doesnt this break ABI ? > > > > Ah, mmmh... We're not that far away from the bottom, aren't all the > following fields supposed to be accessed through AVoption or other > accessors? > > How to proceed here, should I just move it at the bottom of the struct > since it was introduced recently? moving it after all fields which can be directly accessed probably unless i miss something (fields not in 3.0 could be ignored as we just have to restore compatibility with 3.0) i suspect thats more or less the same as "move it at the bottom " [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests/gapless: add gapless aac tests
On Thu, 3 Mar 2016, Michael Niedermayer wrote: On Thu, Mar 03, 2016 at 02:27:52AM +0100, Marton Balint wrote: Signed-off-by: Marton Balint--- tests/fate/gapless.mak | 3 +++ tests/ref/fate/gapless-aac | 5 + 2 files changed, 8 insertions(+) create mode 100644 tests/ref/fate/gapless-aac seems to fail on x86-32 --- ffmpeg/tests/ref/fate/gapless-aac 2016-03-03 03:06:35.306048679 +0100 +++ tests/data/fate/gapless-aac 2016-03-03 03:11:56.286055441 +0100 @@ -1,5 +1,5 @@ 9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-1 -d3c3c4ea121b3f3b8a346a168d2fec0e +d00bed4d4a83ce1addb92c075b2fcaaf 9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-2 -d3c3c4ea121b3f3b8a346a168d2fec0e +d00bed4d4a83ce1addb92c075b2fcaaf 63dd86b78c8fbd22a99bf88583256bfe *tests/data/fate/gapless-aac.out-3 Test gapless-aac failed. Look at tests/data/fate/gapless-aac.err for details. make: *** [fate-gapless-aac] Error 1 Hmm, it seems there is a tiny difference in the 145th sample of the first decoded frame. I thought this is not supposed to happen with the fixed point decoder. Anybody has any ideas? Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: NVENC API version 6 is now required
On Fri, Mar 04, 2016 at 09:42:17PM +0100, Timo Rothenpieler wrote: > --- > configure | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB For every action, there is an equal and opposite reaction. -- Newton For every man jailed for a minor crime, theres one person more that will hate the government, some of them will become terrorists. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf: allow BSFs to drop packets.
On Fri, 4 Mar 2016 11:24:00 -0500 "Ronald S. Bultje"wrote: > Hi, > > On Wed, Mar 2, 2016 at 4:11 PM, Ronald S. Bultje wrote: > > > Hi, > > > > On Wed, Mar 2, 2016 at 3:51 PM, wm4 wrote: > > > >> On Wed, 2 Mar 2016 15:48:11 -0500 > >> "Ronald S. Bultje" wrote: > >> > >> > Hi, > >> > > >> > On Mon, Feb 29, 2016 at 10:32 AM, Ronald S. Bultje > >> > wrote: > >> > > >> > > If pkt->size == 0 && pkt->side_data_elems == 0 after bsf->filter() > >> > > returns, the packet is considered dropped. > >> > > >> > > >> > Ping? > >> > > >> > >> (Personally I'm not so fond of such subtle API changes, also doesn't > >> Libav's glorious new BSF API cover this?) > > > > > > Possibly, but it's not in yet, is it? > > > > (We can revert this piece of code when their new API lands.) > > > > Ping again? I guess you can't wait for the Libav BSF change, but admittedly that has an unknown time frame. But please add the changes in semantics to apichanges.txt. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data
On 03/04/2016 10:02 PM, Mats Peterson wrote: On 03/04/2016 09:52 PM, Mats Peterson wrote: On 03/04/2016 08:44 PM, Michael Niedermayer wrote: On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote: On 03/04/2016 05:59 AM, Mats Peterson wrote: Removed some unused variables in AVIStream. I would like to remind you of the fact that this patch (and the one for riffenc.c) is needed for stream copying of Microsoft Video 1 (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are possibly more codecs using a palette, but these are the ones I can come up with at the moment. i tried CRAM and MSRLE, but these already work when streamcopied before, do you have a testcase that does not work It works, but only so much. On stream copy, it will only write the palette after BITMAPINFOHEADER to the destination file. It won't write any xxpc palette switching chunks to the file. Mats The xxpc chunks come as palette side data. Mats Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without the avienc.c and riffenc.c patch. The destination file will only contain xxpc chunks with my patch applied. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data
On 03/04/2016 09:52 PM, Mats Peterson wrote: On 03/04/2016 08:44 PM, Michael Niedermayer wrote: On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote: On 03/04/2016 05:59 AM, Mats Peterson wrote: Removed some unused variables in AVIStream. I would like to remind you of the fact that this patch (and the one for riffenc.c) is needed for stream copying of Microsoft Video 1 (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are possibly more codecs using a palette, but these are the ones I can come up with at the moment. i tried CRAM and MSRLE, but these already work when streamcopied before, do you have a testcase that does not work It works, but only so much. On stream copy, it will only write the palette after BITMAPINFOHEADER to the destination file. It won't write any xxpc palette switching chunks to the file. Mats The xxpc chunks come as palette side data. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf: allow BSFs to drop packets.
On Fri, Mar 04, 2016 at 11:24:00AM -0500, Ronald S. Bultje wrote: > Hi, > > On Wed, Mar 2, 2016 at 4:11 PM, Ronald S. Bultjewrote: > > > Hi, > > > > On Wed, Mar 2, 2016 at 3:51 PM, wm4 wrote: > > > >> On Wed, 2 Mar 2016 15:48:11 -0500 > >> "Ronald S. Bultje" wrote: > >> > >> > Hi, > >> > > >> > On Mon, Feb 29, 2016 at 10:32 AM, Ronald S. Bultje > >> > wrote: > >> > > >> > > If pkt->size == 0 && pkt->side_data_elems == 0 after bsf->filter() > >> > > returns, the packet is considered dropped. > >> > > >> > > >> > Ping? > >> > > >> > >> (Personally I'm not so fond of such subtle API changes, also doesn't > >> Libav's glorious new BSF API cover this?) > > > > > > Possibly, but it's not in yet, is it? > > > > (We can revert this piece of code when their new API lands.) > > > > Ping again? the only thing on this patch set that gives me a slightly odd feeling is that the droped case overlaps with a case that can be stored in files, that is packets with size 0 otherwise patch LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data
On 03/04/2016 08:44 PM, Michael Niedermayer wrote: On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote: On 03/04/2016 05:59 AM, Mats Peterson wrote: Removed some unused variables in AVIStream. I would like to remind you of the fact that this patch (and the one for riffenc.c) is needed for stream copying of Microsoft Video 1 (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are possibly more codecs using a palette, but these are the ones I can come up with at the moment. i tried CRAM and MSRLE, but these already work when streamcopied before, do you have a testcase that does not work It works, but only so much. On stream copy, it will only write the palette after BITMAPINFOHEADER to the destination file. It won't write any xxpc palette switching chunks to the file. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: NVENC API version 6 is now required
--- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 81769ee..9b56a4d 100755 --- a/configure +++ b/configure @@ -5681,8 +5681,8 @@ enabled mmal && enabled netcdf&& require_pkg_config netcdf netcdf.h nc_inq_libvers enabled nvenc && { check_header nvEncodeAPI.h || die "ERROR: nvEncodeAPI.h not found."; } && - { check_cpp_condition nvEncodeAPI.h "NVENCAPI_MAJOR_VERSION >= 5" || - die "ERROR: NVENC API version 4 or older is not supported"; } && + { check_cpp_condition nvEncodeAPI.h "NVENCAPI_MAJOR_VERSION >= 6" || + die "ERROR: NVENC API version 5 or older is not supported"; } && { [ $target_os != cygwin ] || die "ERROR: NVENC is not supported on Cygwin currently."; } enabled openal&& { { for al_libs in "${OPENAL_LIBS}" "-lopenal" "-lOpenAL32"; do check_lib 'AL/al.h' alGetError "${al_libs}" && break; done } || -- 2.7.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update
On Fri, Mar 04, 2016 at 05:08:07PM +0100, Timo Rothenpieler wrote: > > breaks build here > > > > libavcodec/nvenc.c: In function ‘nvenc_encode_init’: > > libavcodec/nvenc.c:952:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > > ‘hevcVUIParameters’ > > libavcodec/nvenc.c:953:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > > ‘hevcVUIParameters’ > > libavcodec/nvenc.c:954:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > > ‘hevcVUIParameters’ > > libavcodec/nvenc.c:955:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > > ‘hevcVUIParameters’ > > libavcodec/nvenc.c:958:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > > ‘hevcVUIParameters’ > > libavcodec/nvenc.c:961:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > > ‘hevcVUIParameters’ > > libavcodec/nvenc.c:962:61: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > > ‘hevcVUIParameters’ > > libavcodec/nvenc.c:963:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > > ‘hevcVUIParameters’ > > libavcodec/nvenc.c:964:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > > ‘hevcVUIParameters’ > > CC libavcodec/sbrdsp.o > > > > Interesting, which SDK version is your nvEncodeApi.h? i think the one used is: #define NVENCAPI_MAJOR_VERSION 5 #define NVENCAPI_MINOR_VERSION 0 > I only tested this with version 6.0.1, maybe those fields aren't present > in v5 headers? > > If this is the case, I'd just bump the required SDK version. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
On 04.03.2016, at 11:24, Nicolas Georgewrote: > Le quintidi 15 ventôse, an CCXXIV, Thilo Borgmann a écrit : >> Neither a good play on words nor elaborative; not even helpful. >> >> You say they are random numbers, CE says it is continuous. What is correct? >> >> Let's assume the N-tag is not random, then it is a useful extension of the >> pinpointing short hash, since the hashes are not relative to each other (so >> to >> speak random for the human eye) and therefore the N-tags are useful for >> determining if the user is ahead or behind a certain commit. According to >> what >> CE says, this helps for user support, Not? And if not, why would someone >> spending most of the time helping users think otherwise? >> Assuming my thoughts are not based on void assumptions, I'm against removing >> the >> N-tag from the version string. >> >> So what about the release tag? Well it is a quite useful extension because of >> the already mentioned possibility of determining the existing features at >> once. >> I'm pro adding it to the version string. >> >> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it >> is >> uselessly redundant to the existing hash tag in my eyes. Why add another more >> roughly estimation of the users repo-state? I don't think this should be >> added >> to the version string. > > Replying here but not specifically to this mail. > > We do not have to choose: there is no hard limit to the amount of > information that can be encoded in the version, the version string can be > arbitrarily long, as long as it is convenient. > > The Git (short) hash carries all the information by itself, so it should be > present. But extra, redundant, information can be added for the convenience > of users and "supporters". > > Basically, the version could be something like > "g510046c:N78879-3.0master417-H20160303": The formatting is rather ugly but I'd be in favour of something like that. An attempt to order the information in increasing detail might be: v3.0+417-D20160303-N78879-g510046c Note that I'm not convinced the git describe info/branch info/number of commits since release is all that useful, but the base release version number seems nice to have. Particularly the branch name can easily be misleading as it can be anyone's master, not necessarily the one on ffmpeg.org. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data
On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote: > On 03/04/2016 05:59 AM, Mats Peterson wrote: > >Removed some unused variables in AVIStream. > > > > > I would like to remind you of the fact that this patch (and the one > for riffenc.c) is needed for stream copying of Microsoft Video 1 > (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are > possibly more codecs using a palette, but these are the ones I can > come up with at the moment. i tried CRAM and MSRLE, but these already work when streamcopied before, do you have a testcase that does not work [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
Le quintidi 15 ventôse, an CCXXIV, Timothy Gu a écrit : > One object that can be raised against this is that the current versioning and > the new versioning are both compatible with Git. Try > > git show n3.1-dev-400-g3af71ac > git show N-78863-g3af71ac "git show 3af71ac" is enough. With my proposal, depending on the terminal configuration, double-clicking on the hash would select it alone. Not having the hash is of course not an option, I am sure we all agree on this point. > But since the Git hash is already appended I don't see too much problem with > that. The thing is you have to think of convenience for everybody. Think of users who do barely know what a command line is, let alone what Git is: someone tells them to get a newer version of ffmpeg, they download it from somewhere, they need to be able to know which one is more recent, and by how much because upgrading from a three years old version to a two years and a half one is a bit useless. Think of advanced users replying on the mailing-lists, they have a Git tree near at hand at home, but they want to trim their mail in the subway on their phones. Having as much information as possible directly at a glance is a benefit (until it becomes too much information). 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] [PATCH] version.sh: Always use latest tag for generated version number
Am 04.03.16 um 17:57 schrieb Timothy Gu: > On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote: >> Am 04.03.16 um 08:58 schrieb wm4: >>> >>> Being able to see the, well, version in the version output (instead of >>> random numbers) sounds like a pretty convincing argument. >> >> Neither a good play on words nor elaborative; not even helpful. >> >> You say they are random numbers, CE says it is continuous. What is correct? > > It is continuous. But to the user's eye, N-71234 is no different from N-41234, > and hence "random." I assume that if there is no difference in the user's eye between N-71234 and N-41234 then there is also no difference for that user between dev-123 and dev-346. >> Let's assume the N-tag is not random, then it is a useful extension of the >> pinpointing short hash, since the hashes are not relative to each other (so >> to >> speak random for the human eye) and therefore the N-tags are useful for >> determining if the user is ahead or behind a certain commit. According to >> what >> CE says, this helps for user support, Not? And if not, why would someone >> spending most of the time helping users think otherwise? > > However, you miss the point that the new system allows one to do the same. > > In the old system: > > N-90001-gdeadbef > N-9-gdeadbee > N-8-gdeadbed > > In the new system: > > v4.5-dev-123-gdeadbef > v4.5-dev-122-gdeadbee > v4.0-dev-45-gdeadbed > > As you can see, they are functionally equivalent: you can immediately tell > that they are in descending order with both systems. > >> Assuming my thoughts are not based on void assumptions, I'm against removing >> the >> N-tag from the version string. > > I hope I have demonstrated that your concern is mistaken. Except for the benefit of dev-123 tags you have. Thank you! >> So what about the release tag? Well it is a quite useful extension because of >> the already mentioned possibility of determining the existing features at >> once. >> I'm pro adding it to the version string. >> >> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it >> is >> uselessly redundant to the existing hash tag in my eyes. Why add another more >> roughly estimation of the users repo-state? I don't think this should be >> added >> to the version string. > > Can you elaborate on this? I am not sure I understand everything you are > saying. Specfically, what is "devxy"? The core concern about it is that is just redundant. I assume Timo to be correct about: "A new dev tag is made every time a release is branched off, to indicate development of the next ffmpeg version started there, ..." Then there is no gain of information in the dev-123 tag if there is already the release number given. In that case "v4.5-gdeabdef" tells me the very same as "v4.5-dev-123-gdeabdef" does. If Timo is correct, the can never be a "4.5-dev-789-abcdefg" tag. v4.5 is just enough. Summing it all up for me, I think a release prefix would make perfect sense. Thus, switching from N-12345-abcdefg to v4.5-N-12345-abcdefg should be done for the sake of the users. There is at least CE wanting to stick with N-tags so why not? The only reason I can imagine for getting rid of N-tags and/or including dev-123 tags would be that a native git show command needs it to work properly as well as giving better human readable information. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
On Fri, Mar 04, 2016 at 10:20:09AM +, Carl Eugen Hoyos wrote: > Timo Rothenpieler rothenpieler.org> writes: > > > The current versioning scheme is indeed simple, but > > useless in almost all other aspects. > > FFmpeg has a linear development scheme, how can you call > a continuous versioning scheme useless? It reflects 1:1 > on how FFmpeg is developed. 1. FFmpeg does NOT have a linear development scheme. See `git log --merges`. 2. FFmpeg uses Git, which is inherently distributed and nonlinear. Therefore your argument again is flawed. > > > It gives no indication about what release it is close to > > But the development here is not release-driven (note that > I am not saying it should or shouldn't be, I am just > describing how it does work for more than a decade), > just look at how the latest release was made: A random > snapshot was chosen, not even current known possible > security issues or regressions were relevant. As I have said in my reply to your last mail, and as I will do so again, whether or not release-driven FFmpeg is irrelevant to this conversation. The versioning scheme is supposed to make people's life easier. It is NOT designed to be the epitome of FFmpeg development policies. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
On Fri, Mar 04, 2016 at 11:24:31AM +0100, Nicolas George wrote: > Basically, the version could be something like > "g510046c:N78879-3.0master417-H20160303": One object that can be raised against this is that the current versioning and the new versioning are both compatible with Git. Try git show n3.1-dev-400-g3af71ac git show N-78863-g3af71ac But since the Git hash is already appended I don't see too much problem with that. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote: > Am 04.03.16 um 08:58 schrieb wm4: > > > > Being able to see the, well, version in the version output (instead of > > random numbers) sounds like a pretty convincing argument. > > Neither a good play on words nor elaborative; not even helpful. > > You say they are random numbers, CE says it is continuous. What is correct? It is continuous. But to the user's eye, N-71234 is no different from N-41234, and hence "random." > > Let's assume the N-tag is not random, then it is a useful extension of the > pinpointing short hash, since the hashes are not relative to each other (so to > speak random for the human eye) and therefore the N-tags are useful for > determining if the user is ahead or behind a certain commit. According to what > CE says, this helps for user support, Not? And if not, why would someone > spending most of the time helping users think otherwise? However, you miss the point that the new system allows one to do the same. In the old system: N-90001-gdeadbef N-9-gdeadbee N-8-gdeadbed In the new system: v4.5-dev-123-gdeadbef v4.5-dev-122-gdeadbee v4.0-dev-45-gdeadbed As you can see, they are functionally equivalent: you can immediately tell that they are in descending order with both systems. > Assuming my thoughts are not based on void assumptions, I'm against removing > the > N-tag from the version string. I hope I have demonstrated that your concern is mistaken. > So what about the release tag? Well it is a quite useful extension because of > the already mentioned possibility of determining the existing features at > once. > I'm pro adding it to the version string. > > The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is > uselessly redundant to the existing hash tag in my eyes. Why add another more > roughly estimation of the users repo-state? I don't think this should be added > to the version string. Can you elaborate on this? I am not sure I understand everything you are saying. Specfically, what is "devxy"? Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf: allow BSFs to drop packets.
Hi, On Wed, Mar 2, 2016 at 4:11 PM, Ronald S. Bultjewrote: > Hi, > > On Wed, Mar 2, 2016 at 3:51 PM, wm4 wrote: > >> On Wed, 2 Mar 2016 15:48:11 -0500 >> "Ronald S. Bultje" wrote: >> >> > Hi, >> > >> > On Mon, Feb 29, 2016 at 10:32 AM, Ronald S. Bultje >> > wrote: >> > >> > > If pkt->size == 0 && pkt->side_data_elems == 0 after bsf->filter() >> > > returns, the packet is considered dropped. >> > >> > >> > Ping? >> > >> >> (Personally I'm not so fond of such subtle API changes, also doesn't >> Libav's glorious new BSF API cover this?) > > > Possibly, but it's not in yet, is it? > > (We can revert this piece of code when their new API lands.) > Ping again? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API
On 3/4/2016 3:02 PM, James Almer wrote: > ry to non break ABI just yet, leave it as last resort. We did it not even > half a year ago, and we'd have to push every single scheduled deprecation. > If this can be resolved moving only the new entries then that's preferable. OK I did it this way. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update
> breaks build here > > libavcodec/nvenc.c: In function ‘nvenc_encode_init’: > libavcodec/nvenc.c:952:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > ‘hevcVUIParameters’ > libavcodec/nvenc.c:953:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > ‘hevcVUIParameters’ > libavcodec/nvenc.c:954:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > ‘hevcVUIParameters’ > libavcodec/nvenc.c:955:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > ‘hevcVUIParameters’ > libavcodec/nvenc.c:958:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > ‘hevcVUIParameters’ > libavcodec/nvenc.c:961:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > ‘hevcVUIParameters’ > libavcodec/nvenc.c:962:61: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > ‘hevcVUIParameters’ > libavcodec/nvenc.c:963:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > ‘hevcVUIParameters’ > libavcodec/nvenc.c:964:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named > ‘hevcVUIParameters’ > CC libavcodec/sbrdsp.o > Interesting, which SDK version is your nvEncodeApi.h? I only tested this with version 6.0.1, maybe those fields aren't present in v5 headers? If this is the case, I'd just bump the required SDK version. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: allow subtitle text format to be ASS without timing
On Fri, Mar 04, 2016 at 04:22:44PM +0100, Michael Niedermayer wrote: > On Fri, Feb 26, 2016 at 10:01:51PM +0100, Clément Bœsch wrote: > > ffmpeg | branch: master | Clément Bœsch| Wed Jan 6 13:43:23 > > 2016 +0100| [29412821241050c846dbceaad4b9752857659977] | committer: Clément > > Bœsch > [...] > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > > index 7a56899..d3e035a 100644 > > --- a/libavcodec/avcodec.h > > +++ b/libavcodec/avcodec.h > > @@ -3285,6 +3285,10 @@ typedef struct AVCodecContext { > > #define FF_SUB_CHARENC_MODE_AUTOMATIC0 ///< libavcodec will select > > the mode itself > > #define FF_SUB_CHARENC_MODE_PRE_DECODER 1 ///< the AVPacket data needs > > to be recoded to UTF-8 before being fed to the decoder, requires iconv > > > > +int sub_text_format; > > +#define FF_SUB_TEXT_FMT_ASS 0 > > +#define FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS 1 > > + > > /** > > * Skip processing alpha if supported by codec. > > * Note that if the format uses pre-multiplied alpha (common with VP6, > > doesnt this break ABI ? > Ah, mmmh... We're not that far away from the bottom, aren't all the following fields supposed to be accessed through AVoption or other accessors? How to proceed here, should I just move it at the bottom of the struct since it was introduced recently? -- 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] nvenc Fix H264 and HEVC vui info update
On Fri, Mar 04, 2016 at 10:51:10AM +0100, Timo Rothenpieler wrote: > >> > >> In case of the git send-email sends corrupted patch again, I attach the > >> original patch file. > >> > >> Agatha Hu > >> > > > > That's strange, does anyone received my patch sent at 17:22 GMT+8? > > Looks like the first mail (sent by git sent-email, no attachment) was > > somehow blocked. > > > > Agatha Hu > > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190764.html that one? > > Also, applied. breaks build here libavcodec/nvenc.c: In function ‘nvenc_encode_init’: libavcodec/nvenc.c:952:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named ‘hevcVUIParameters’ libavcodec/nvenc.c:953:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named ‘hevcVUIParameters’ libavcodec/nvenc.c:954:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named ‘hevcVUIParameters’ libavcodec/nvenc.c:955:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named ‘hevcVUIParameters’ libavcodec/nvenc.c:958:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named ‘hevcVUIParameters’ libavcodec/nvenc.c:961:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named ‘hevcVUIParameters’ libavcodec/nvenc.c:962:61: error: ‘NV_ENC_CONFIG_HEVC’ has no member named ‘hevcVUIParameters’ libavcodec/nvenc.c:963:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named ‘hevcVUIParameters’ libavcodec/nvenc.c:964:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named ‘hevcVUIParameters’ CC libavcodec/sbrdsp.o [...] -- 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] avformat: Add a protocol blacklisting API
On 3/4/2016 10:34 AM, Derek Buitenhuis wrote: > On 3/3/2016 7:50 PM, Michael Niedermayer wrote: >> The io_open/close callbacks afterwards seem direct access IIUC >> so its not possible to remove or add any fields prior >> >> though maybe they have been added so recently that its ok to move >> them above all "no direct access" fields >> or maybe iam missing something > > Crap. I must have screwed up when merging those callbacks. I can move > the be blacklist entry under them, or I can break ABI and move both, > since I don't think there is release. Try to non break ABI just yet, leave it as last resort. We did it not even half a year ago, and we'd have to push every single scheduled deprecation. If this can be resolved moving only the new entries then that's preferable. > > Which do people prefer? They're both kinda meh. > > - Derek > ___ > 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] avcodec: Extend fft to size 2^17
Hi, On Fri, Mar 4, 2016 at 7:52 AM, Paul B Maholwrote: > On 3/4/16, wm4 wrote: > > On Fri, 4 Mar 2016 13:12:45 +0100 > > Paul B Mahol wrote: > > > >> On 3/4/16, Michael Niedermayer wrote: > >> > On Fri, Mar 04, 2016 at 11:21:23AM +0100, Paul B Mahol wrote: > >> >> On 3/4/16, Michael Niedermayer wrote: > >> >> > Hi > >> >> > > >> >> > patch to extend fft is attached (my git-send email atm doesnt work > >> >> > thanks to my ISP) > >> >> > > >> >> > -- > >> >> > Michael GnuPG fingerprint: > >> >> > 9FF2128B147EF6730BADF133611EC787040B0FAB > >> >> > > >> >> > I know you won't believe me, but the highest form of Human > Excellence > >> >> > is > >> >> > to question oneself and others. -- Socrates > >> >> > > >> >> > >> >> This crashes whenever I tried to use it with sofalizer/afftfilt: > >> > > >> > fixed with af_afftfilt and applied > >> > > >> > > >> > sofalizer just crashes here even wthout any changes: > >> > >> That's their awful library. > > > > Oh really? Are you sure they allow passing a NULL filename to their > > open function? > > > > It allows here, but Michael version is older. configure version check seems like a sane thing to add. Possibly even a runtime check just to be sure. "ffmpeg crashed" never looks good. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API
On 3/3/2016 7:50 PM, Michael Niedermayer wrote: > The io_open/close callbacks afterwards seem direct access IIUC > so its not possible to remove or add any fields prior > > though maybe they have been added so recently that its ok to move > them above all "no direct access" fields > or maybe iam missing something Crap. I must have screwed up when merging those callbacks. I can move the be blacklist entry under them, or I can break ABI and move both, since I don't think there is release. Which do people prefer? They're both kinda meh. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Extend fft to size 2^17
On 3/4/16, wm4wrote: > On Fri, 4 Mar 2016 13:12:45 +0100 > Paul B Mahol wrote: > >> On 3/4/16, Michael Niedermayer wrote: >> > On Fri, Mar 04, 2016 at 11:21:23AM +0100, Paul B Mahol wrote: >> >> On 3/4/16, Michael Niedermayer wrote: >> >> > Hi >> >> > >> >> > patch to extend fft is attached (my git-send email atm doesnt work >> >> > thanks to my ISP) >> >> > >> >> > -- >> >> > Michael GnuPG fingerprint: >> >> > 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> > >> >> > I know you won't believe me, but the highest form of Human Excellence >> >> > is >> >> > to question oneself and others. -- Socrates >> >> > >> >> >> >> This crashes whenever I tried to use it with sofalizer/afftfilt: >> > >> > fixed with af_afftfilt and applied >> > >> > >> > sofalizer just crashes here even wthout any changes: >> >> That's their awful library. > > Oh really? Are you sure they allow passing a NULL filename to their > open function? > It allows here, but Michael version is older. ___ > 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] avcodec: Extend fft to size 2^17
On Fri, 4 Mar 2016 13:12:45 +0100 Paul B Maholwrote: > On 3/4/16, Michael Niedermayer wrote: > > On Fri, Mar 04, 2016 at 11:21:23AM +0100, Paul B Mahol wrote: > >> On 3/4/16, Michael Niedermayer wrote: > >> > Hi > >> > > >> > patch to extend fft is attached (my git-send email atm doesnt work > >> > thanks to my ISP) > >> > > >> > -- > >> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > >> > > >> > I know you won't believe me, but the highest form of Human Excellence > >> > is > >> > to question oneself and others. -- Socrates > >> > > >> > >> This crashes whenever I tried to use it with sofalizer/afftfilt: > > > > fixed with af_afftfilt and applied > > > > > > sofalizer just crashes here even wthout any changes: > > That's their awful library. Oh really? Are you sure they allow passing a NULL filename to their open function? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Extend fft to size 2^17
On 3/4/16, Michael Niedermayerwrote: > On Fri, Mar 04, 2016 at 11:21:23AM +0100, Paul B Mahol wrote: >> On 3/4/16, Michael Niedermayer wrote: >> > Hi >> > >> > patch to extend fft is attached (my git-send email atm doesnt work >> > thanks to my ISP) >> > >> > -- >> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> > >> > I know you won't believe me, but the highest form of Human Excellence >> > is >> > to question oneself and others. -- Socrates >> > >> >> This crashes whenever I tried to use it with sofalizer/afftfilt: > > fixed with af_afftfilt and applied > > > sofalizer just crashes here even wthout any changes: That's their awful library. > #0 0x750b447f in clearnccache () from /usr/lib/libnetcdf.so.6 > #1 0x750af68d in freeNCDRNO3 () from /usr/lib/libnetcdf.so.6 > #2 0x750c34f7 in nc4d_open_file () from /usr/lib/libnetcdf.so.6 > #3 0x75076d1f in nc_open () from /usr/lib/libnetcdf.so.6 > #4 0x0042cf91 in load_sofa (ctx=0x7fffd8008040, filename=0x0, > samplingrate=0x7fffd8008148) at libavfilter/af_sofalizer.c:137 > #5 0x0042d8b4 in init (ctx=0x7fffd8008040) at > libavfilter/af_sofalizer.c:936 > #6 0x004cb49b in avfilter_init_str (filter=0x7fffd8008040, > args=) at libavfilter/avfilter.c:992 > #7 0x004d9052 in create_filter (filt_ctx=0x7fffddf8c6f0, > ctx=0x7fffd8129840, index=, filt_name=, > args=0x0, log_ctx=0x0) at libavfilter/graphparser.c:133 > #8 0x004da1d3 in parse_filter (log_ctx=0x0, index=0, > graph=0x7fffd8129840, buf=0x7fffddf8c6c8, filt_ctx=0x7fffddf8c6f0) at > libavfilter/graphparser.c:176 > #9 avfilter_graph_parse_ptr (graph=0x7fffd8129840, filters=0x1eda7c9 "", > open_inputs_ptr=0x7fffddf8c758, open_outputs_ptr=0x7fffddf8c750, > log_ctx=0x0) at libavfilter/graphparser.c:544 > #10 0x004a8a31 in configure_filtergraph (graph=0x7fffd8129840, > filtergraph=0x1eda7c0 "sofalizer", source_ctx=, > sink_ctx=) at ffplay.c:1884 > #11 0x004a8f2b in configure_audio_filters (is=0x7fffe1e8d040, > afilters=0x1eda7c0 "sofalizer", force_output_format=0) at ffplay.c:2062 > #12 0x004ae4e7 in stream_component_open (is=0x7fffe1e8d040, > stream_index=2) at ffplay.c:2729 > #13 0x004aef74 in read_thread (arg=0x7fffe1e8d040) at ffplay.c:2975 > #14 0x75e80055 in ?? () from > /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 > #15 0x75ec3a89 in ?? () from > /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 > #16 0x7fffecc40e9a in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #17 0x7fffec96e38d in clone () from /lib/x86_64-linux-gnu/libc.so.6 > #18 0x in ?? () > > > >> >> ==24326== Jump to the invalid address stated on the next line >> ==24326==at 0xEF83490005E6E2B8: ??? >> ==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562) >> ==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242) >> ==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123) >> ==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221) >> ==24326==by 0x50C9D4A: request_frame (buffersrc.c:450) >> ==24326==by 0x50C98A9: av_buffersrc_add_frame_internal >> (buffersrc.c:239) >> ==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164) >> ==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046) >> ==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325) >> ==24326==by 0x41E047: process_input (ffmpeg.c:3998) >> ==24326==by 0x41E047: transcode_step (ffmpeg.c:4086) >> ==24326==by 0x41E047: transcode (ffmpeg.c:4140) >> ==24326==by 0x419331: main (ffmpeg.c:4331) >> ==24326== Address 0xef83490005e6e2b8 is not stack'd, malloc'd or >> (recently) free'd >> ==24326== >> ==24326== >> ==24326== Process terminating with default action of signal 11 (SIGSEGV) >> ==24326== Bad permissions for mapped region at address >> 0xEF83490005E6E2B8 >> ==24326==at 0xEF83490005E6E2B8: ??? >> ==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562) >> ==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242) >> ==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123) >> ==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221) >> ==24326==by 0x50C9D4A: request_frame (buffersrc.c:450) >> ==24326==by 0x50C98A9: av_buffersrc_add_frame_internal >> (buffersrc.c:239) >> ==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164) >> ==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046) >> ==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325) >> ==24326==by 0x41E047: process_input (ffmpeg.c:3998) >> ==24326==by 0x41E047: transcode_step (ffmpeg.c:4086) >> ==24326==by 0x41E047: transcode (ffmpeg.c:4140) >> ==24326==by 0x419331: main (ffmpeg.c:4331) >> ==24326== >> ==24326== HEAP SUMMARY: >> ==24326== in use at exit: 10,552,359 bytes in 2,983 blocks >> ==24326== total heap usage: 4,458 allocs, 1,475 frees, 11,530,798 >>
Re: [FFmpeg-devel] [PATCH] avcodec: Extend fft to size 2^17
On Fri, Mar 04, 2016 at 11:21:23AM +0100, Paul B Mahol wrote: > On 3/4/16, Michael Niedermayerwrote: > > Hi > > > > patch to extend fft is attached (my git-send email atm doesnt work > > thanks to my ISP) > > > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > I know you won't believe me, but the highest form of Human Excellence is > > to question oneself and others. -- Socrates > > > > This crashes whenever I tried to use it with sofalizer/afftfilt: fixed with af_afftfilt and applied sofalizer just crashes here even wthout any changes: #0 0x750b447f in clearnccache () from /usr/lib/libnetcdf.so.6 #1 0x750af68d in freeNCDRNO3 () from /usr/lib/libnetcdf.so.6 #2 0x750c34f7 in nc4d_open_file () from /usr/lib/libnetcdf.so.6 #3 0x75076d1f in nc_open () from /usr/lib/libnetcdf.so.6 #4 0x0042cf91 in load_sofa (ctx=0x7fffd8008040, filename=0x0, samplingrate=0x7fffd8008148) at libavfilter/af_sofalizer.c:137 #5 0x0042d8b4 in init (ctx=0x7fffd8008040) at libavfilter/af_sofalizer.c:936 #6 0x004cb49b in avfilter_init_str (filter=0x7fffd8008040, args=) at libavfilter/avfilter.c:992 #7 0x004d9052 in create_filter (filt_ctx=0x7fffddf8c6f0, ctx=0x7fffd8129840, index=, filt_name=, args=0x0, log_ctx=0x0) at libavfilter/graphparser.c:133 #8 0x004da1d3 in parse_filter (log_ctx=0x0, index=0, graph=0x7fffd8129840, buf=0x7fffddf8c6c8, filt_ctx=0x7fffddf8c6f0) at libavfilter/graphparser.c:176 #9 avfilter_graph_parse_ptr (graph=0x7fffd8129840, filters=0x1eda7c9 "", open_inputs_ptr=0x7fffddf8c758, open_outputs_ptr=0x7fffddf8c750, log_ctx=0x0) at libavfilter/graphparser.c:544 #10 0x004a8a31 in configure_filtergraph (graph=0x7fffd8129840, filtergraph=0x1eda7c0 "sofalizer", source_ctx=, sink_ctx=) at ffplay.c:1884 #11 0x004a8f2b in configure_audio_filters (is=0x7fffe1e8d040, afilters=0x1eda7c0 "sofalizer", force_output_format=0) at ffplay.c:2062 #12 0x004ae4e7 in stream_component_open (is=0x7fffe1e8d040, stream_index=2) at ffplay.c:2729 #13 0x004aef74 in read_thread (arg=0x7fffe1e8d040) at ffplay.c:2975 #14 0x75e80055 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 #15 0x75ec3a89 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 #16 0x7fffecc40e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #17 0x7fffec96e38d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #18 0x in ?? () > > ==24326== Jump to the invalid address stated on the next line > ==24326==at 0xEF83490005E6E2B8: ??? > ==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562) > ==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242) > ==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123) > ==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221) > ==24326==by 0x50C9D4A: request_frame (buffersrc.c:450) > ==24326==by 0x50C98A9: av_buffersrc_add_frame_internal (buffersrc.c:239) > ==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164) > ==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046) > ==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325) > ==24326==by 0x41E047: process_input (ffmpeg.c:3998) > ==24326==by 0x41E047: transcode_step (ffmpeg.c:4086) > ==24326==by 0x41E047: transcode (ffmpeg.c:4140) > ==24326==by 0x419331: main (ffmpeg.c:4331) > ==24326== Address 0xef83490005e6e2b8 is not stack'd, malloc'd or > (recently) free'd > ==24326== > ==24326== > ==24326== Process terminating with default action of signal 11 (SIGSEGV) > ==24326== Bad permissions for mapped region at address 0xEF83490005E6E2B8 > ==24326==at 0xEF83490005E6E2B8: ??? > ==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562) > ==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242) > ==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123) > ==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221) > ==24326==by 0x50C9D4A: request_frame (buffersrc.c:450) > ==24326==by 0x50C98A9: av_buffersrc_add_frame_internal (buffersrc.c:239) > ==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164) > ==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046) > ==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325) > ==24326==by 0x41E047: process_input (ffmpeg.c:3998) > ==24326==by 0x41E047: transcode_step (ffmpeg.c:4086) > ==24326==by 0x41E047: transcode (ffmpeg.c:4140) > ==24326==by 0x419331: main (ffmpeg.c:4331) > ==24326== > ==24326== HEAP SUMMARY: > ==24326== in use at exit: 10,552,359 bytes in 2,983 blocks > ==24326== total heap usage: 4,458 allocs, 1,475 frees, 11,530,798 > bytes allocated > ==24326== > ==24326== LEAK SUMMARY: > ==24326==definitely lost: 0 bytes in 0 blocks > ==24326==indirectly lost: 0 bytes in 0 blocks > ==24326== possibly lost: 1,680 bytes in 5 blocks > ==24326==
Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data
On 03/04/2016 05:59 AM, Mats Peterson wrote: Removed some unused variables in AVIStream. I would like to remind you of the fact that this patch (and the one for riffenc.c) is needed for stream copying of Microsoft Video 1 (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are possibly more codecs using a palette, but these are the ones I can come up with at the moment. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Libavcodec consulting
> > Thanks for that clarification. Unfortunately the http server is a third > party camera that broadcasts a WiFi hotspot. Therefore we don't really > have control over the underlying server. However, what I do know is > that the ffmpeg command I quoted previously seems to be able to > grab a chunk of a video anywhere in the file without downloading the > whole thing. So I assume libav must also be capable. > The nginx module we develop https://github.com/kaltura/nginx-vod-module has the capability to efficiently clip MP4 files - 1. It downloads the index (moov atom) whether it's in the beginning of the file or at its end 2. It generates a new 'clipped' index for the output video 3. It determines the relevant range of the video/audio frames in the original file, and serves it to the client In addition, this module has the ability to work in remote mode - it can pull the relevant sections of the file using HTTP range requests. So, easiest solution, assuming you can set up some server (and you don't have to provide a client-only solution) would be to set up such a "clipping proxy" and have the mobile app simply download the clip from the proxy (providing the clipping from/to offsets) If a server solution is not option, you can still use our code as a reference for the implementation. Btw, nginx has a built-in module for clipping MP4 files - http://nginx.org/en/docs/http/ngx_http_mp4_module.html But our module has several advantages compared to built-in version, incl: 1. Support for remote (HTTP) MP4 files 2. Support for MP4 files in which the index is at the end of the file Hope this helps Eran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
Le quintidi 15 ventôse, an CCXXIV, Thilo Borgmann a écrit : > Neither a good play on words nor elaborative; not even helpful. > > You say they are random numbers, CE says it is continuous. What is correct? > > Let's assume the N-tag is not random, then it is a useful extension of the > pinpointing short hash, since the hashes are not relative to each other (so to > speak random for the human eye) and therefore the N-tags are useful for > determining if the user is ahead or behind a certain commit. According to what > CE says, this helps for user support, Not? And if not, why would someone > spending most of the time helping users think otherwise? > Assuming my thoughts are not based on void assumptions, I'm against removing > the > N-tag from the version string. > > So what about the release tag? Well it is a quite useful extension because of > the already mentioned possibility of determining the existing features at > once. > I'm pro adding it to the version string. > > The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is > uselessly redundant to the existing hash tag in my eyes. Why add another more > roughly estimation of the users repo-state? I don't think this should be added > to the version string. Replying here but not specifically to this mail. We do not have to choose: there is no hard limit to the amount of information that can be encoded in the version, the version string can be arbitrarily long, as long as it is convenient. The Git (short) hash carries all the information by itself, so it should be present. But extra, redundant, information can be added for the convenience of users and "supporters". Basically, the version could be something like "g510046c:N78879-3.0master417-H20160303": - the Git hash is there; - the strictly increasing count from the N tag is there, Carl Eugen is happy; - 3.0dev417 means "on branch master, 417 commits since branch 3.0 was forked" (maybe a better syntax can be found), users who want an estimate of the relation between releases and Git snapshots are happy; - H20160303 is the approximate timestamp of the head commit (preferably the CommitDate rather than the AuthorDate), users who want to know how old is their version are happy. Also, we could have a parsing script in tools to translate that into human-readable information, and possibly fill in the blanks if it has access to a Git repository. Bonus point if a version of this script is available online as a CGI. 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] [PATCH] version.sh: Always use latest tag for generated version number
Timo Rothenpieler rothenpieler.org> writes: > The current versioning scheme is indeed simple, but > useless in almost all other aspects. FFmpeg has a linear development scheme, how can you call a continuous versioning scheme useless? It reflects 1:1 on how FFmpeg is developed. > It gives no indication about what release it is close to But the development here is not release-driven (note that I am not saying it should or shouldn't be, I am just describing how it does work for more than a decade), just look at how the latest release was made: A random snapshot was chosen, not even current known possible security issues or regressions were relevant. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
You are skipping everything I think about N-tags you want to patch away... why? Am 04.03.16 um 11:07 schrieb Timo Rothenpieler: >> So what about the release tag? Well it is a quite useful extension because of >> the already mentioned possibility of determining the existing features at >> once. >> I'm pro adding it to the version string. > > The release tags are not made in the master branch, so git describe > won't pick them up. > They also don't have a meaning for master, as there are distinct commits > between the two. The reason for the version tag is the user, not? The user does not care about git describe, teh user wants teh release number in his version string. If I read you correctly you are arguing in some way against your own change? (not haveing the release tag?) >> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it >> is >> uselessly redundant to the existing hash tag in my eyes. Why add another more >> roughly estimation of the users repo-state? I don't think this should be >> added >> to the version string. > > A new dev tag is made every time a release is branched off, to indicate > development of the next ffmpeg version started there, so using it for > the version number seems natural to me. I still see no benefit in adding it. If there is the release tag, I don't need this because they are redundant. If there is no release tag, the user would manually find the release number for this tag, not? -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Extend fft to size 2^17
On 3/4/16, Michael Niedermayerwrote: > Hi > > patch to extend fft is attached (my git-send email atm doesnt work > thanks to my ISP) > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I know you won't believe me, but the highest form of Human Excellence is > to question oneself and others. -- Socrates > This crashes whenever I tried to use it with sofalizer/afftfilt: ==24326== Jump to the invalid address stated on the next line ==24326==at 0xEF83490005E6E2B8: ??? ==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562) ==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242) ==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123) ==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221) ==24326==by 0x50C9D4A: request_frame (buffersrc.c:450) ==24326==by 0x50C98A9: av_buffersrc_add_frame_internal (buffersrc.c:239) ==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164) ==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046) ==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325) ==24326==by 0x41E047: process_input (ffmpeg.c:3998) ==24326==by 0x41E047: transcode_step (ffmpeg.c:4086) ==24326==by 0x41E047: transcode (ffmpeg.c:4140) ==24326==by 0x419331: main (ffmpeg.c:4331) ==24326== Address 0xef83490005e6e2b8 is not stack'd, malloc'd or (recently) free'd ==24326== ==24326== ==24326== Process terminating with default action of signal 11 (SIGSEGV) ==24326== Bad permissions for mapped region at address 0xEF83490005E6E2B8 ==24326==at 0xEF83490005E6E2B8: ??? ==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562) ==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242) ==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123) ==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221) ==24326==by 0x50C9D4A: request_frame (buffersrc.c:450) ==24326==by 0x50C98A9: av_buffersrc_add_frame_internal (buffersrc.c:239) ==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164) ==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046) ==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325) ==24326==by 0x41E047: process_input (ffmpeg.c:3998) ==24326==by 0x41E047: transcode_step (ffmpeg.c:4086) ==24326==by 0x41E047: transcode (ffmpeg.c:4140) ==24326==by 0x419331: main (ffmpeg.c:4331) ==24326== ==24326== HEAP SUMMARY: ==24326== in use at exit: 10,552,359 bytes in 2,983 blocks ==24326== total heap usage: 4,458 allocs, 1,475 frees, 11,530,798 bytes allocated ==24326== ==24326== LEAK SUMMARY: ==24326==definitely lost: 0 bytes in 0 blocks ==24326==indirectly lost: 0 bytes in 0 blocks ==24326== possibly lost: 1,680 bytes in 5 blocks ==24326==still reachable: 10,550,679 bytes in 2,978 blocks ==24326== suppressed: 0 bytes in 0 blocks ==24326== Rerun with --leak-check=full to see details of leaked memory ==24326== ==24326== For counts of detected and suppressed errors, rerun with: -v ==24326== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Killed Setting cpuflags to 0 gives output with heavy artifacts. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
wm4 googlemail.com> writes: > Being able to see the, well, version in the version output > (instead of random numbers) What is random about the version number using current FFmpeg? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
> So what about the release tag? Well it is a quite useful extension because of > the already mentioned possibility of determining the existing features at > once. > I'm pro adding it to the version string. The release tags are not made in the master branch, so git describe won't pick them up. They also don't have a meaning for master, as there are distinct commits between the two. > The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is > uselessly redundant to the existing hash tag in my eyes. Why add another more > roughly estimation of the users repo-state? I don't think this should be added > to the version string. A new dev tag is made every time a release is branched off, to indicate development of the next ffmpeg version started there, so using it for the version number seems natural to me. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] nvenc.c Fix H264 and HEVC vui info update
On Thu, Mar 03, 2016 at 22:50:10 -0800, Timothy Gu wrote: > This patched is corrupted by your mail client. What's wrong with the first > patch you sent (with git-send-email)? While the first one was mail-technically okay (probably), the patch contained apparent whitespace changes and trailing whitespace in the new code... Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
>> Of course, this argument operates on the premise that >> making things easier for users is of utmost concern >> for us. Please inspire me if this is not the case. > > On the contrary, I believe while the current versioing > scheme is simple and understandable, the suggested one > is misleading, both for users and when reading user > questions. The current versioning scheme is indeed simple, but useless in almost all other aspects. It gives no indication about what release it is close to, so the ChangeLog becomes useless without digging through the git log first. It's also counter-intuitive, as people are used to regular version numbers. Also, releases are also continuously numbered, so I don't see what's better about the always increasing number based on some old tag. Will resend the patch without the fetch part, but still, on all of my 3 dev machines i had to manually issue a fetch for the latest tags to show up. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number
Am 04.03.16 um 08:58 schrieb wm4: > On Fri, 4 Mar 2016 08:47:14 +0100 > Thilo Borgmannwrote: > >> Am 04.03.16 um 08:23 schrieb wm4: >>> On Fri, 4 Mar 2016 00:55:35 + (UTC) >>> Carl Eugen Hoyos wrote: >>> Timothy Gu gmail.com> writes: > Of course, this argument operates on the premise that > making things easier for users is of utmost concern > for us. Please inspire me if this is not the case. On the contrary, I believe while the current versioing scheme is simple and understandable, the suggested one is misleading, both for users and when reading user questions. >>> >>> Well, duh, everyone disagrees with you. >> >> Not true. For what I've read, I can't see the benefit of the change. >> However, changing it should require a real reason and I don't see it. >> >> So, what exactly is the benefit of the proposed versioning? Can anyone >> please elaborate what the current state is and what exactly would make >> the user's life happier with the new one? > > Being able to see the, well, version in the version output (instead of > random numbers) sounds like a pretty convincing argument. Neither a good play on words nor elaborative; not even helpful. You say they are random numbers, CE says it is continuous. What is correct? Let's assume the N-tag is not random, then it is a useful extension of the pinpointing short hash, since the hashes are not relative to each other (so to speak random for the human eye) and therefore the N-tags are useful for determining if the user is ahead or behind a certain commit. According to what CE says, this helps for user support, Not? And if not, why would someone spending most of the time helping users think otherwise? Assuming my thoughts are not based on void assumptions, I'm against removing the N-tag from the version string. So what about the release tag? Well it is a quite useful extension because of the already mentioned possibility of determining the existing features at once. I'm pro adding it to the version string. The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is uselessly redundant to the existing hash tag in my eyes. Why add another more roughly estimation of the users repo-state? I don't think this should be added to the version string. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update
>> >> In case of the git send-email sends corrupted patch again, I attach the >> original patch file. >> >> Agatha Hu >> > > That's strange, does anyone received my patch sent at 17:22 GMT+8? > Looks like the first mail (sent by git sent-email, no attachment) was somehow > blocked. > > Agatha Hu http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190764.html that one? Also, applied. Thanks signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update
On 2016年03月04日 17:26, ahu wrote: > > On 2016年03月04日 17:22, ahu wrote: >> --- >> libavcodec/nvenc.c | 27 +++ >> 1 file changed, 23 insertions(+), 4 deletions(-) >> >> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c >> index a3b02fa..5d78930 100644 >> --- a/libavcodec/nvenc.c >> +++ b/libavcodec/nvenc.c > >> > > In case of the git send-email sends corrupted patch again, I attach the > original patch file. > > Agatha Hu > That's strange, does anyone received my patch sent at 17:22 GMT+8? Looks like the first mail (sent by git sent-email, no attachment) was somehow blocked. Agatha Hu --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update
On 2016年03月04日 17:22, ahu wrote: > --- > libavcodec/nvenc.c | 27 +++ > 1 file changed, 23 insertions(+), 4 deletions(-) > > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c > index a3b02fa..5d78930 100644 > --- a/libavcodec/nvenc.c > +++ b/libavcodec/nvenc.c > In case of the git send-email sends corrupted patch again, I attach the original patch file. Agatha Hu >From 3fddde4b7e3e3dab61c3ba03188ebf72e08db6cc Mon Sep 17 00:00:00 2001 From: Agatha HuDate: Fri, 4 Mar 2016 17:00:48 +0800 Subject: [PATCH] nvenc Fix H264 and HEVC vui info update --- libavcodec/nvenc.c | 27 +++ 1 file changed, 23 insertions(+), 4 deletions(-) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index a3b02fa..5d78930 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -868,14 +868,19 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx) switch (avctx->codec->id) { case AV_CODEC_ID_H264: -ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag = 1; -ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag = 1; - ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourMatrix = avctx->colorspace; ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourPrimaries = avctx->color_primaries; ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.transferCharacteristics = avctx->color_trc; +ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG +|| avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == AV_PIX_FMT_YUVJ444P); + +ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag = +(avctx->colorspace != 2 || avctx->color_primaries != 2 || avctx->color_trc != 2); -ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag = avctx->color_range == AVCOL_RANGE_JPEG; +ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag = +(ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag +|| ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFormat != 5 +|| ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag != 0); ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3; ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1; @@ -944,6 +949,20 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx) break; case AV_CODEC_ID_H265: +ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourMatrix = avctx->colorspace; +ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourPrimaries = avctx->color_primaries; +ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.transferCharacteristics = avctx->color_trc; +ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG +|| avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == AV_PIX_FMT_YUVJ444P); + +ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag = +(avctx->colorspace != 2 || avctx->color_primaries != 2 || avctx->color_trc != 2); + +ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoSignalTypePresentFlag = +(ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag +|| ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFormat != 5 +|| ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag != 0); + ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3; ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1; -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update
--- libavcodec/nvenc.c | 27 +++ 1 file changed, 23 insertions(+), 4 deletions(-) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index a3b02fa..5d78930 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -868,14 +868,19 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx) switch (avctx->codec->id) { case AV_CODEC_ID_H264: - ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag = 1; - ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag = 1; - ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourMatrix = avctx->colorspace; ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourPrimaries = avctx->color_primaries; ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.transferCharacteristics = avctx->color_trc; + ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG +|| avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == AV_PIX_FMT_YUVJ444P); + + ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag = +(avctx->colorspace != 2 || avctx->color_primaries != 2 || avctx->color_trc != 2); - ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag = avctx->color_range == AVCOL_RANGE_JPEG; + ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag = + (ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag +|| ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFormat != 5 +|| ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag != 0); ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3; ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1; @@ -944,6 +949,20 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx) break; case AV_CODEC_ID_H265: + ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourMatrix = avctx->colorspace; + ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourPrimaries = avctx->color_primaries; + ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.transferCharacteristics = avctx->color_trc; + ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG +|| avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == AV_PIX_FMT_YUVJ444P); + + ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag = +(avctx->colorspace != 2 || avctx->color_primaries != 2 || avctx->color_trc != 2); + + ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoSignalTypePresentFlag = + (ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag +|| ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFormat != 5 +|| ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag != 0); + ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3; ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1; -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Libavcodec consulting
On Thu, Mar 3, 2016 at 11:28 PM, compnwrote: > the mp4 format can either have an index at the start of the file or > at the end of the file. you cannot read (easily) an mp4 file without its > index. > > http://wiki.multimedia.cx/index.php?title=MP4 > > http servers can be made to support "request range" and thus allow > seeking to the start or end of the mp4 file. existing mp4 files can be > edited to have the index at the start or end. > > otherwise, mp4 cannot be streamed. by anyone, in any situation (well, > without serious hacks). the current way mp4 is "streamed" is to > split up mp4 files into a thousand smaller mp4 files and sent to a > player using a playlist. > > mp4 cannot be streamed. it sucks. > changing the http server would be easier than changing mp4 indexing. > or using an intermediate format would be easier (mkv perhaps). Thanks for that clarification. Unfortunately the http server is a third party camera that broadcasts a WiFi hotspot. Therefore we don't really have control over the underlying server. However, what I do know is that the ffmpeg command I quoted previously seems to be able to grab a chunk of a video anywhere in the file without downloading the whole thing. So I assume libav must also be capable. Cheers, Jon. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel