Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: Warn if a encoder is missing the pix_fmts or sample_fmts list
On Sun, 28 Feb 2016 02:14:20 +0100 Michael Niedermayer wrote: > On Sun, Feb 28, 2016 at 01:26:16AM +0100, Hendrik Leppkes wrote: > > On Sun, Feb 28, 2016 at 12:17 AM, Michael Niedermayer > > wrote: > > > This would require listing supported formats for rawvideo and > > > wrapped_avframe > > > > > > Signed-off-by: Michael Niedermayer > > > --- > > > libavcodec/utils.c |5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c > > > index 2690d0d..267c973 100644 > > > --- a/libavcodec/utils.c > > > +++ b/libavcodec/utils.c > > > @@ -188,6 +188,11 @@ av_cold void avcodec_register(AVCodec *codec) > > > > > > if (codec->init_static_data) > > > codec->init_static_data(codec); > > > + > > > +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_VIDEO > > > && !codec->pix_fmts) > > > +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the pix_fmts > > > field\n", codec->name); > > > +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_AUDIO > > > && !codec->sample_fmts) > > > +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the > > > sample_fmts field\n", codec->name); > > > } > > > > It seems kinda silly to write code to check if other code is correct. > > i dont think i understand because what you say would mean that > fate and all self tests are a bad idea if i dont misunderstand > > > > Apparently all encoders today are correct, so lets just pay attention > > rawvideo and wrapped_avframe dont list pix_fmts, they would need to > be fixed first if we apply this > Really, for 2 encoders? > > > in the future when adding new ones? > > a self test like this would detect that reliably without the need for > (less reliable and limited) human resources. > This can be done externally, no need to litter utils.c with more effectively dead code. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 1/2] lavf/avienc: Add support for palette side data packets
On 02/28/2016 05:38 AM, Mats Peterson wrote: On 02/28/2016 05:27 AM, Mats Peterson wrote: Use "palette side data" instead of "palette extradata" in error message. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Michael, I would like to add that ff_reshuffle_raw_rgb() that you wrote has the benefit of taking care of the correct stride when using stream copy as well. Thus, it won't be an "identical" stream copy, but it will be a valid one for the output file format in question. Mats And Reimar, the AVI muxer libavformat/avienc.c uses *lots* of avio_seek() all over the place, so it won't work well on stdout regardless of my patch. I have checked for avio_seek() returning >= 0 in my part of the code in any case, but it won't make much of a difference. 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 v3 1/2] lavf/avienc: Add support for palette side data packets
On 02/28/2016 05:27 AM, Mats Peterson wrote: Use "palette side data" instead of "palette extradata" in error message. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Michael, I would like to add that ff_reshuffle_raw_rgb() that you wrote has the benefit of taking care of the correct stride when using stream copy as well. Thus, it won't be an "identical" stream copy, but it will be a valid one for the output file format in question. 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 v3 2/2] lavf/movenc: Add support for palette side data packets
Use "palette side data" instead of "palette extradata" in error message. -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From 506fe35051a51e0a4a42579b0a5f3d974531c1ae Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sun, 28 Feb 2016 05:25:53 +0100 Subject: [PATCH v3 2/2] lavf/movenc: Add support for palette side data packets --- libavformat/movenc.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index e0223b2..2ca445e 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -4760,19 +4760,29 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt) } } -if (trk->is_unaligned_qt_rgb) { +if (trk->is_unaligned_qt_rgb && pkt->size) { const uint8_t *data = pkt->data; int size = pkt->size; int64_t bpc = trk->enc->bits_per_coded_sample != 15 ? trk->enc->bits_per_coded_sample : 16; int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2; +const uint8_t *pal = NULL; +int pkt_pal_size; int ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc, expected_stride); if (ret < 0) return ret; -if (ret == CONTAINS_PAL && !trk->pal_done) { -int pal_size = 1 << trk->enc->bits_per_coded_sample; -memset(trk->palette, 0, AVPALETTE_SIZE); -memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size); -trk->pal_done++; +if (!trk->pal_done) { +pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, + &pkt_pal_size); +if (pal && pkt_pal_size != AVPALETTE_SIZE) { +av_log(s, AV_LOG_ERROR, "Invalid palette side data\n"); +return AVERROR_INVALIDDATA; +} +if (!pal && ret == CONTAINS_PAL) +pal = data + size - AVPALETTE_SIZE; +if (pal) { +memcpy(trk->palette, pal, AVPALETTE_SIZE); +trk->pal_done++; +} } else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 || trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) { for (i = 0; i < pkt->size; i++) -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 1/2] lavf/avienc: Add support for palette side data packets
Use "palette side data" instead of "palette extradata" in error message. -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From 962582ec4c265573a3230c089929854e1058c4af Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sun, 28 Feb 2016 05:25:36 +0100 Subject: [PATCH v3 1/2] lavf/avienc: Add support for palette side data packets --- libavformat/avienc.c | 54 ++ 1 file changed, 32 insertions(+), 22 deletions(-) diff --git a/libavformat/avienc.c b/libavformat/avienc.c index ca505f4..9ac190a 100644 --- a/libavformat/avienc.c +++ b/libavformat/avienc.c @@ -668,39 +668,49 @@ 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) { +if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0 && size) { int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16; int expected_stride = ((enc->width * bpc + 31) >> 5)*4; - +const uint8_t *pal = NULL; +int pal_size = 1 << enc->bits_per_coded_sample; +int pkt_pal_size, i; ret = ff_reshuffle_raw_rgb(s, &pkt, enc, expected_stride); if (ret < 0) return ret; -if (ret) { -if (ret == CONTAINS_PAL) { -int pc_tag, i; -int pal_size = 1 << enc->bits_per_coded_sample; -if (!avist->hdr_pal_done) { -int64_t cur_offset = avio_tell(pb); -avio_seek(pb, avist->pal_offset, SEEK_SET); +pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, + &pkt_pal_size); +if (pal && pkt_pal_size != AVPALETTE_SIZE) { +av_log(s, AV_LOG_ERROR, "Invalid palette side data\n"); +return AVERROR_INVALIDDATA; +} +if (!pal && ret == CONTAINS_PAL) +pal = data + size - AVPALETTE_SIZE; +if (pal) { +int pc_tag; +if (!avist->hdr_pal_done) { +int64_t cur_offset = avio_tell(pb); +if (avio_seek(pb, avist->pal_offset, SEEK_SET) >= 0) { for (i = 0; i < pal_size; i++) { -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); +uint32_t v = AV_RL32(pal + 4*i); avio_wl32(pb, v & 0xff); } avio_seek(pb, cur_offset, SEEK_SET); -avist->hdr_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++) { -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); -avio_wb32(pb, v<<8); } -ff_end_tag(pb, pc_tag); +avist->hdr_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++) { +uint32_t v = AV_RL32(pal + 4*i); +avio_wb32(pb, v<<8); +} +ff_end_tag(pb, pc_tag); +} +if (ret) { ret = avi_write_packet_internal(s, pkt); av_packet_free(&pkt); return ret; -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 2/2] lavf/movenc: Add support for palette side data packets
Check for palette side data being AVPALETTE_SIZE bytes. -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From 1e6f27735442ddac19775fe5e03d8429fe6f3448 Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sun, 28 Feb 2016 05:16:56 +0100 Subject: [PATCH v2 2/2] lavf/movenc: Add support for palette side data packets --- libavformat/movenc.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index e0223b2..c20797c 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -4760,19 +4760,29 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt) } } -if (trk->is_unaligned_qt_rgb) { +if (trk->is_unaligned_qt_rgb && pkt->size) { const uint8_t *data = pkt->data; int size = pkt->size; int64_t bpc = trk->enc->bits_per_coded_sample != 15 ? trk->enc->bits_per_coded_sample : 16; int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2; +const uint8_t *pal = NULL; +int pkt_pal_size; int ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc, expected_stride); if (ret < 0) return ret; -if (ret == CONTAINS_PAL && !trk->pal_done) { -int pal_size = 1 << trk->enc->bits_per_coded_sample; -memset(trk->palette, 0, AVPALETTE_SIZE); -memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size); -trk->pal_done++; +if (!trk->pal_done) { +pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, + &pkt_pal_size); +if (pal && pkt_pal_size != AVPALETTE_SIZE) { +av_log(s, AV_LOG_ERROR, "Invalid palette extradata\n"); +return AVERROR_INVALIDDATA; +} +if (!pal && ret == CONTAINS_PAL) +pal = data + size - AVPALETTE_SIZE; +if (pal) { +memcpy(trk->palette, pal, AVPALETTE_SIZE); +trk->pal_done++; +} } else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 || trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) { for (i = 0; i < pkt->size; i++) -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 1/2] lavf/avienc: Add support for palette side data packets
Check for palette side data being AVPALETTE_SIZE bytes. -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From 8c72d4c41615dcc651913f83154e5df1d884af8d Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sun, 28 Feb 2016 05:16:38 +0100 Subject: [PATCH v2 1/2] lavf/avienc: Add support for palette side data packets --- libavformat/avienc.c | 54 ++ 1 file changed, 32 insertions(+), 22 deletions(-) diff --git a/libavformat/avienc.c b/libavformat/avienc.c index ca505f4..8d261c0 100644 --- a/libavformat/avienc.c +++ b/libavformat/avienc.c @@ -668,39 +668,49 @@ 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) { +if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0 && size) { int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16; int expected_stride = ((enc->width * bpc + 31) >> 5)*4; - +const uint8_t *pal = NULL; +int pal_size = 1 << enc->bits_per_coded_sample; +int pkt_pal_size, i; ret = ff_reshuffle_raw_rgb(s, &pkt, enc, expected_stride); if (ret < 0) return ret; -if (ret) { -if (ret == CONTAINS_PAL) { -int pc_tag, i; -int pal_size = 1 << enc->bits_per_coded_sample; -if (!avist->hdr_pal_done) { -int64_t cur_offset = avio_tell(pb); -avio_seek(pb, avist->pal_offset, SEEK_SET); +pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, + &pkt_pal_size); +if (pal && pkt_pal_size != AVPALETTE_SIZE) { +av_log(s, AV_LOG_ERROR, "Invalid palette extradata\n"); +return AVERROR_INVALIDDATA; +} +if (!pal && ret == CONTAINS_PAL) +pal = data + size - AVPALETTE_SIZE; +if (pal) { +int pc_tag; +if (!avist->hdr_pal_done) { +int64_t cur_offset = avio_tell(pb); +if (avio_seek(pb, avist->pal_offset, SEEK_SET) >= 0) { for (i = 0; i < pal_size; i++) { -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); +uint32_t v = AV_RL32(pal + 4*i); avio_wl32(pb, v & 0xff); } avio_seek(pb, cur_offset, SEEK_SET); -avist->hdr_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++) { -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); -avio_wb32(pb, v<<8); } -ff_end_tag(pb, pc_tag); +avist->hdr_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++) { +uint32_t v = AV_RL32(pal + 4*i); +avio_wb32(pb, v<<8); +} +ff_end_tag(pb, pc_tag); +} +if (ret) { ret = avi_write_packet_internal(s, pkt); av_packet_free(&pkt); return ret; -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] x86/constants: extend pw_128 to 256 bits
On 2/28/2016 12:43 AM, Michael Niedermayer wrote: > On Mon, Feb 08, 2016 at 11:27:51AM -0800, Timothy Gu wrote: >> --- >> libavcodec/x86/constants.c | 3 ++- >> libavcodec/x86/constants.h | 2 +- >> 2 files changed, 3 insertions(+), 2 deletions(-) > > LGTM if these are or will be used > > thx Not by this patchset. Nothing in avcodec needs it this wide for now. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] x86/constants: extend pw_128 to 256 bits
On Mon, Feb 08, 2016 at 11:27:51AM -0800, Timothy Gu wrote: > --- > libavcodec/x86/constants.c | 3 ++- > libavcodec/x86/constants.h | 2 +- > 2 files changed, 3 insertions(+), 2 deletions(-) LGTM if these are or will be used thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] movenc: Enable timecode tracks in MP4
On Thu, Feb 04, 2016 at 04:45:09PM +, Carl Eugen Hoyos wrote: > Syed Andaleeb Roomy gmail.com> writes: > > > I worked on the attached patch to enable timecode tracks in MP4 files > > written by ffmpeg. Could someone please take a look to see if it is > > acceptable? > > Ping, see ticket #4704. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add direct detection of libopencv
On Mon, Feb 15, 2016 at 06:25:01PM -0300, James Almer wrote: > On 2/7/2016 8:24 PM, wm4 wrote: > > On Sun, 7 Feb 2016 23:25:53 +0100 > > Andreas Cadhalpun wrote: > > > >> The pkg-config file contains all opencv libraries, not only the > >> neccessary ones. > >> > >> This change makes it possible to use the libopencv-imgproc-dev Debian > >> package instead of libopencv-dev, saving about 200 MB of useless > >> build-dependencies. > >> > >> In particular one doesn't need to install the parts of opencv that > >> depend on ffmpeg libraries. > >> > >> Signed-off-by: Andreas Cadhalpun > >> --- > >> configure | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/configure b/configure > >> index 1000cb1..36ab7e5 100755 > >> --- a/configure > >> +++ b/configure > >> @@ -5488,7 +5488,8 @@ enabled libnut&& require libnut libnut.h > >> nut_demuxer_init -lnut > >> enabled libopencore_amrnb && require libopencore_amrnb > >> opencore-amrnb/interf_dec.h Decoder_Interface_init -lopencore-amrnb > >> enabled libopencore_amrwb && require libopencore_amrwb > >> opencore-amrwb/dec_if.h D_IF_init -lopencore-amrwb > >> enabled libopencv && { check_header opencv2/core/core_c.h && > >> - require_pkg_config opencv > >> opencv2/core/core_c.h cvCreateImageHeader || > >> + { use_pkg_config opencv > >> opencv2/core/core_c.h cvCreateImageHeader || > >> + require opencv opencv2/core/core_c.h > >> cvCreateImageHeader -lopencv_core -lopencv_imgproc; } || > >> require_pkg_config opencv opencv/cxcore.h > >> cvCreateImageHeader; } > >> enabled libopenh264 && require_pkg_config openh264 wels/codec_api.h > >> WelsGetCodecVersion > >> enabled libopenjpeg && { check_lib openjpeg-2.1/openjpeg.h > >> opj_version -lopenjp2 -DOPJ_STATIC || > > > > Why not send a patch to opencv? > > Doesn't hurt adding this in the meantime. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Add support for palette side data packets
On 02/28/2016 03:00 AM, Mats Peterson wrote: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Why is the packet data in AVI packets sometimes zero bytes when using stream copy, Michael? There certainly must be some reason for it? 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 2/2] lavf/movenc: Add support for palette side data packets
-- Mats Peterson http://matsp888.no-ip.org/~mats/ >From ec165732b5677f412112c114b09760d26f1f96bd Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sun, 28 Feb 2016 02:58:57 +0100 Subject: [PATCH 2/2] lavf/movenc: Add support for palette side data packets --- libavformat/movenc.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index e0223b2..b6b6a99 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -4760,19 +4760,23 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt) } } -if (trk->is_unaligned_qt_rgb) { +if (trk->is_unaligned_qt_rgb && pkt->size) { const uint8_t *data = pkt->data; int size = pkt->size; int64_t bpc = trk->enc->bits_per_coded_sample != 15 ? trk->enc->bits_per_coded_sample : 16; int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2; +const uint8_t *pal = NULL; int ret = ff_reshuffle_raw_rgb(s, &pkt, trk->enc, expected_stride); if (ret < 0) return ret; -if (ret == CONTAINS_PAL && !trk->pal_done) { -int pal_size = 1 << trk->enc->bits_per_coded_sample; -memset(trk->palette, 0, AVPALETTE_SIZE); -memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size); -trk->pal_done++; +if (!trk->pal_done) { +pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, NULL); +if (!pal && ret == CONTAINS_PAL) +pal = data + size - AVPALETTE_SIZE; +if (pal) { +memcpy(trk->palette, pal, AVPALETTE_SIZE); +trk->pal_done++; +} } else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 || trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) { for (i = 0; i < pkt->size; i++) -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavf/avienc: Add support for palette side data packets
-- Mats Peterson http://matsp888.no-ip.org/~mats/ >From 40adfd0b3be94dfaf88187ee9f71bd85ad858f9d Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sun, 28 Feb 2016 02:58:36 +0100 Subject: [PATCH 1/2] lavf/avienc: Add support for palette side data packets --- libavformat/avienc.c | 49 +++-- 1 file changed, 27 insertions(+), 22 deletions(-) diff --git a/libavformat/avienc.c b/libavformat/avienc.c index ca505f4..10c4413 100644 --- a/libavformat/avienc.c +++ b/libavformat/avienc.c @@ -668,39 +668,44 @@ 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) { +if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0 && size) { int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16; int expected_stride = ((enc->width * bpc + 31) >> 5)*4; - +const uint8_t *pal = NULL; +int pal_size = 1 << enc->bits_per_coded_sample; +int i; ret = ff_reshuffle_raw_rgb(s, &pkt, enc, expected_stride); if (ret < 0) return ret; -if (ret) { -if (ret == CONTAINS_PAL) { -int pc_tag, i; -int pal_size = 1 << enc->bits_per_coded_sample; -if (!avist->hdr_pal_done) { -int64_t cur_offset = avio_tell(pb); -avio_seek(pb, avist->pal_offset, SEEK_SET); +pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, NULL); +if (!pal && ret == CONTAINS_PAL) +pal = data + size - AVPALETTE_SIZE; +if (pal) { +int pc_tag; +if (!avist->hdr_pal_done) { +int64_t cur_offset = avio_tell(pb); +if (avio_seek(pb, avist->pal_offset, SEEK_SET) >= 0) { for (i = 0; i < pal_size; i++) { -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); +uint32_t v = AV_RL32(pal + 4*i); avio_wl32(pb, v & 0xff); } avio_seek(pb, cur_offset, SEEK_SET); -avist->hdr_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++) { -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); -avio_wb32(pb, v<<8); } -ff_end_tag(pb, pc_tag); +avist->hdr_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++) { +uint32_t v = AV_RL32(pal + 4*i); +avio_wb32(pb, v<<8); +} +ff_end_tag(pb, pc_tag); +} +if (ret) { ret = avi_write_packet_internal(s, pkt); av_packet_free(&pkt); return ret; -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: forward protocol_whitelist for the remaining cases
On Wed, Feb 03, 2016 at 11:20:05PM +0100, Andreas Cadhalpun wrote: > On 03.02.2016 03:41, Michael Niedermayer wrote: > > On Wed, Feb 03, 2016 at 01:51:55AM +0100, Andreas Cadhalpun wrote: > >> @@ -274,4 +282,5 @@ URLProtocol ff_ffrtmphttp_protocol = { > >> .priv_data_size = sizeof(RTMP_HTTPContext), > >> .flags = URL_PROTOCOL_FLAG_NETWORK, > >> .priv_data_class= &ffrtmphttp_class, > >> +.default_whitelist = "https,http,tcp", > > > > if it needs https it might need tls too > > Yes, updated patch attached. > > Best regards, > Andreas > > mmsh.c |9 + > rtmphttp.c |9 + > rtsp.c |8 > 3 files changed, 26 insertions(+) > ac9de87a225e549ae03722a3fc487cb22be5802a > 0001-lavf-forward-protocol_whitelist-for-the-remaining-ca.patch > From 595133afad21a4e264642259e8c74708dd4a72ba Mon Sep 17 00:00:00 2001 > From: Andreas Cadhalpun > Date: Wed, 3 Feb 2016 01:01:34 +0100 > Subject: [PATCH] lavf: forward protocol_whitelist for the remaining cases > > Also set a default_whitelist for mmsh and ffrtmphttp. > > Signed-off-by: Andreas Cadhalpun LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavf/avienc: Use palette side data packet if available
On 02/28/2016 02:15 AM, Reimar Döffinger wrote: +for (i = 0; i < pkt->side_data_elems; i++) { +if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) { +pal = pkt->side_data[i].data; +break; +} +} av_frame_get_side_data No frames available in a muxer (as far as I know). But thanks anyway... av_packet_get_side_data then. Yes, that's more elegant of course. I just "copied" a snippet from nutenc.c in the meantime... -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); -avio_wb32(pb, v<<8); +uint32_t v = AV_RL32(pal + 4*i); +avio_wl32(pb, v & 0xff); You'll probably still need the if to use the one or the avio_w... depending on format. Unless it's possible to change the embedded format to match the side data one. Don't know what you mean by "Probably still need the if". Forget this and the rest, I simply misread the patch diff. No problem, Reimar. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: Warn if a encoder is missing the pix_fmts or sample_fmts list
On Sun, Feb 28, 2016 at 01:26:16AM +0100, Hendrik Leppkes wrote: > On Sun, Feb 28, 2016 at 12:17 AM, Michael Niedermayer > wrote: > > This would require listing supported formats for rawvideo and > > wrapped_avframe > > > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/utils.c |5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c > > index 2690d0d..267c973 100644 > > --- a/libavcodec/utils.c > > +++ b/libavcodec/utils.c > > @@ -188,6 +188,11 @@ av_cold void avcodec_register(AVCodec *codec) > > > > if (codec->init_static_data) > > codec->init_static_data(codec); > > + > > +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_VIDEO && > > !codec->pix_fmts) > > +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the pix_fmts > > field\n", codec->name); > > +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_AUDIO > > && !codec->sample_fmts) > > +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the > > sample_fmts field\n", codec->name); > > } > > It seems kinda silly to write code to check if other code is correct. i dont think i understand because what you say would mean that fate and all self tests are a bad idea if i dont misunderstand > Apparently all encoders today are correct, so lets just pay attention rawvideo and wrapped_avframe dont list pix_fmts, they would need to be fixed first if we apply this > in the future when adding new ones? a self test like this would detect that reliably without the need for (less reliable and limited) human resources. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill hundred thousands of innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavf/avienc: Use palette side data packet if available
On 28.02.2016, at 01:13, Mats Peterson wrote: > On 02/28/2016 12:34 AM, Reimar Döffinger wrote: > >> On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote: >>> -if (!avist->hdr_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); >>> -avio_wl32(pb, v & 0xff); >>> -} >>> -avio_seek(pb, cur_offset, SEEK_SET); >>> -avist->hdr_pal_done++; >>> -} >> >> Hadn't seen this before. >> In principle it is a bit unfortunate as it means that streaming via >> stdout is not possible. >> It should at least be suppressed when seeking the output stream >> is not possible. > > Right. Good point. > >> >> >>> +for (i = 0; i < pkt->side_data_elems; i++) { >>> +if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) { >>> +pal = pkt->side_data[i].data; >>> +break; >>> +} >>> +} >> >> av_frame_get_side_data > > No frames available in a muxer (as far as I know). But thanks anyway... av_packet_get_side_data then. > >> >>> -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); >>> -avio_wb32(pb, v<<8); >>> +uint32_t v = AV_RL32(pal + 4*i); >>> +avio_wl32(pb, v & 0xff); >> >> You'll probably still need the if to use the one or the avio_w... >> depending on format. >> Unless it's possible to change the embedded format to match >> the side data one. >> > > Don't know what you mean by "Probably still need the if". Forget this and the rest, I simply misread the patch diff. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavf/avienc: Use palette side data packet if available
On 02/28/2016 01:13 AM, Mats Peterson wrote: On 02/28/2016 12:34 AM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote: -if (!avist->hdr_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); -avio_wl32(pb, v & 0xff); -} -avio_seek(pb, cur_offset, SEEK_SET); -avist->hdr_pal_done++; -} Hadn't seen this before. In principle it is a bit unfortunate as it means that streaming via stdout is not possible. It should at least be suppressed when seeking the output stream is not possible. Right. Good point. +for (i = 0; i < pkt->side_data_elems; i++) { +if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) { +pal = pkt->side_data[i].data; +break; +} +} av_frame_get_side_data No frames available in a muxer (as far as I know). But thanks anyway... -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); -avio_wb32(pb, v<<8); +uint32_t v = AV_RL32(pal + 4*i); +avio_wl32(pb, v & 0xff); You'll probably still need the if to use the one or the avio_w... depending on format. Unless it's possible to change the embedded format to match the side data one. Don't know what you mean by "Probably still need the if". +for (i = 0; i < pal_size; i++) { +uint32_t v = AV_RL32(pal + 4*i); +avio_wb32(pb, v<<8); Why is the header format different? That seems a bit weird. ___ The palette uses a RGBQUAD (BGRA) structure for the entries in the palette after the BITMAPINFOHEADER, but it uses an AVIPALCHANGE structure (RGBA) for those 'xxpc' chunks. It may seem a bit confusing, Well, the AVIPALCHANGE structure uses a PALETTEENTRY structure, that's the core of it, and it uses RGB order, with a flag byte afterwards. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: Warn if a encoder is missing the pix_fmts or sample_fmts list
On Sun, Feb 28, 2016 at 12:17 AM, Michael Niedermayer wrote: > This would require listing supported formats for rawvideo and wrapped_avframe > > Signed-off-by: Michael Niedermayer > --- > libavcodec/utils.c |5 + > 1 file changed, 5 insertions(+) > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c > index 2690d0d..267c973 100644 > --- a/libavcodec/utils.c > +++ b/libavcodec/utils.c > @@ -188,6 +188,11 @@ av_cold void avcodec_register(AVCodec *codec) > > if (codec->init_static_data) > codec->init_static_data(codec); > + > +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_VIDEO && > !codec->pix_fmts) > +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the pix_fmts > field\n", codec->name); > +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_AUDIO && > !codec->sample_fmts) > +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the sample_fmts > field\n", codec->name); > } It seems kinda silly to write code to check if other code is correct. Apparently all encoders today are correct, so lets just pay attention in the future when adding new ones? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On 02/28/2016 12:22 AM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 09:24:14PM +0100, Mats Peterson wrote: On 02/27/2016 09:21 PM, Mats Peterson wrote: On 02/27/2016 08:42 PM, Reimar Döffinger wrote: Well, then we know I can only blame Mats for "only" making it better instead of perfect :) ___ Well, before my patches, there was no palette inclusion whatsoever in AVI or QuickTime on muxing. Anyway, you're right about the stream copying not working. Just tried it here. Another issue to take care of... phew. Solving the stream copying issues obviously requires using side data packets in the muxers, correct me if I'm wrong. Well, that is one option. It's obviously the only option considering the current state of FFmpeg. Then again, I don't see the point with stream copying raw palettized data, since the strides are different between the file formats. Although I agree that the palette transfer should work. It's up to the user to determine if what he/she is doing is sensible when using stream copy for raw palettized data. It's already stated in the FFmpeg documentation that stream copy can be problematic. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavf/avienc: Use palette side data packet if available
On 02/28/2016 12:34 AM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote: -if (!avist->hdr_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); -avio_wl32(pb, v & 0xff); -} -avio_seek(pb, cur_offset, SEEK_SET); -avist->hdr_pal_done++; -} Hadn't seen this before. In principle it is a bit unfortunate as it means that streaming via stdout is not possible. It should at least be suppressed when seeking the output stream is not possible. Right. Good point. +for (i = 0; i < pkt->side_data_elems; i++) { +if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) { +pal = pkt->side_data[i].data; +break; +} +} av_frame_get_side_data No frames available in a muxer (as far as I know). But thanks anyway... -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); -avio_wb32(pb, v<<8); +uint32_t v = AV_RL32(pal + 4*i); +avio_wl32(pb, v & 0xff); You'll probably still need the if to use the one or the avio_w... depending on format. Unless it's possible to change the embedded format to match the side data one. Don't know what you mean by "Probably still need the if". +for (i = 0; i < pal_size; i++) { +uint32_t v = AV_RL32(pal + 4*i); +avio_wb32(pb, v<<8); Why is the header format different? That seems a bit weird. ___ The palette uses a RGBQUAD (BGRA) structure for the entries in the palette after the BITMAPINFOHEADER, but it uses an AVIPALCHANGE structure (RGBA) for those 'xxpc' chunks. It may seem a bit confusing, but I'm doing everything by the book. It's all in the AVI specification. I should probably never have said "I'm new at this". I know the specs alright. I still got no answer to why the packet data is sometimes zero bytes when doing stream copy, but I suppose Michael knows. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavf/avienc: Use palette side data packet if available
On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote: > -if (!avist->hdr_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); > -avio_wl32(pb, v & 0xff); > -} > -avio_seek(pb, cur_offset, SEEK_SET); > -avist->hdr_pal_done++; > -} Hadn't seen this before. In principle it is a bit unfortunate as it means that streaming via stdout is not possible. It should at least be suppressed when seeking the output stream is not possible. > +for (i = 0; i < pkt->side_data_elems; i++) { > +if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) { > +pal = pkt->side_data[i].data; > +break; > +} > +} av_frame_get_side_data > -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); > -avio_wb32(pb, v<<8); > +uint32_t v = AV_RL32(pal + 4*i); > +avio_wl32(pb, v & 0xff); You'll probably still need the if to use the one or the avio_w... depending on format. Unless it's possible to change the embedded format to match the side data one. > +for (i = 0; i < pal_size; i++) { > +uint32_t v = AV_RL32(pal + 4*i); > +avio_wb32(pb, v<<8); Why is the header format different? That seems a bit weird. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On Sat, Feb 27, 2016 at 09:24:14PM +0100, Mats Peterson wrote: > On 02/27/2016 09:21 PM, Mats Peterson wrote: > >On 02/27/2016 08:42 PM, Reimar Döffinger wrote: > >>Well, then we know I can only blame Mats for "only" making it > >>better instead of perfect :) > >>___ > > > >Well, before my patches, there was no palette inclusion whatsoever in > >AVI or QuickTime on muxing. Anyway, you're right about the stream > >copying not working. Just tried it here. Another issue to take care > >of... phew. > > > > Solving the stream copying issues obviously requires using side data packets > in the muxers, correct me if I'm wrong. Well, that is one option. It is also possible for the demuxers to (possibly even just in addition) append the palette - but I think that is problematic when palette isn't provided for every frame. Probably better would be for muxers to have a little magic function. const uint8_t *ff_update_get_palette(AVFormatContext *, AVFrame *, bool); That function would then do something like (possibly a bit overkill as I describe it): 1) Check if it's a paletted raw format and the palette is appended. If so extract it, possibly expand it, store it in the context and return the pointer. 2) Check if there is side data palette, and if so store it in the context too and return the pointer 3) If palette is not available in any way right now, return the one we previously stored in the palette if any. The bool could then be used to configure whether the return value should be NULL instead in case of 3) or when in 1) and 2) the new palette is identical (that way it is selectable if the palette gets stored with every frame or not, it could probably even expanded to track actual changed entries). As said, that is overkill, but it shouldn't hurt to at least have possible future "nice to haves" in mind from the start. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/imgutils: Assert that the 2nd av_image_fill_linesizes() call in av_image_fill_linesizes() still succeeds
On Wed, Feb 03, 2016 at 05:07:26PM +0100, Michael Niedermayer wrote: > Fixes CID1271742 > > Signed-off-by: Michael Niedermayer > --- > libavutil/imgutils.c |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) applied [...] -- 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
[FFmpeg-devel] [PATCH 2/2] avcodec/utils: Warn if a encoder is missing the pix_fmts or sample_fmts list
This would require listing supported formats for rawvideo and wrapped_avframe Signed-off-by: Michael Niedermayer --- libavcodec/utils.c |5 + 1 file changed, 5 insertions(+) diff --git a/libavcodec/utils.c b/libavcodec/utils.c index 2690d0d..267c973 100644 --- a/libavcodec/utils.c +++ b/libavcodec/utils.c @@ -188,6 +188,11 @@ av_cold void avcodec_register(AVCodec *codec) if (codec->init_static_data) codec->init_static_data(codec); + +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_VIDEO && !codec->pix_fmts) +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the pix_fmts field\n", codec->name); +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_AUDIO && !codec->sample_fmts) +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the sample_fmts field\n", codec->name); } #if FF_API_EMU_EDGE -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] doc/examples/transcoding: Use the decoders pixel format if the encoder does not list which are supported
This affects rawvideo and wraped_avframe, no others are affected atm Signed-off-by: Michael Niedermayer --- doc/examples/transcoding.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c index d5d410b..8633362 100644 --- a/doc/examples/transcoding.c +++ b/doc/examples/transcoding.c @@ -128,7 +128,10 @@ static int open_output_file(const char *filename) enc_ctx->width = dec_ctx->width; enc_ctx->sample_aspect_ratio = dec_ctx->sample_aspect_ratio; /* take first format from list of supported formats */ -enc_ctx->pix_fmt = encoder->pix_fmts[0]; +if (encoder->pix_fmts) +enc_ctx->pix_fmt = encoder->pix_fmts[0]; +else +enc_ctx->pix_fmt = dec_ctx->pix_fmt; /* video time_base can be set to whatever is handy and supported by encoder */ enc_ctx->time_base = dec_ctx->time_base; } else { -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Seperate x264rgb encoder and only enable when its actually supported
This avoids enabling and building the x264rgb encoder when its actually not supported and thus would not work Signed-off-by: Michael Niedermayer --- configure|3 ++- libavcodec/libx264.c | 22 -- 2 files changed, 14 insertions(+), 11 deletions(-) diff --git a/configure b/configure index f4b821a..a5416a0 100755 --- a/configure +++ b/configure @@ -2661,7 +2661,7 @@ libwebp_encoder_deps="libwebp" libwebp_anim_encoder_deps="libwebp" libx262_encoder_deps="libx262" libx264_encoder_deps="libx264" -libx264rgb_encoder_deps="libx264" +libx264rgb_encoder_deps="libx264 x264_csp_bgr" libx264rgb_encoder_select="libx264_encoder" libx265_encoder_deps="libx265" libxavs_encoder_deps="libxavs" @@ -5352,6 +5352,7 @@ check_builtin sem_timedwait semaphore.h "sem_t *s; sem_init(s,0,0); sem_timedwai check_builtin sync_val_compare_and_swap "" "int *ptr; int oldval, newval; __sync_val_compare_and_swap(ptr, oldval, newval)" check_builtin gmtime_r time.h "time_t *time; struct tm *tm; gmtime_r(time, tm)" check_builtin localtime_r time.h "time_t *time; struct tm *tm; localtime_r(time, tm)" +check_builtin x264_csp_bgr "stdint.h x264.h" "X264_CSP_BGR" case "$custom_allocator" in jemalloc) diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c index 5030d65..8a93fb1 100644 --- a/libavcodec/libx264.c +++ b/libavcodec/libx264.c @@ -430,7 +430,7 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt) case AV_PIX_FMT_YUVJ444P: case AV_PIX_FMT_YUV444P9: case AV_PIX_FMT_YUV444P10: return X264_CSP_I444; -#ifdef X264_CSP_BGR +#if CONFIG_LIBX264RGB_ENCODER case AV_PIX_FMT_BGR0: return X264_CSP_BGRA; case AV_PIX_FMT_BGR24: @@ -884,14 +884,14 @@ static const enum AVPixelFormat pix_fmts_10bit[] = { AV_PIX_FMT_NV20, AV_PIX_FMT_NONE }; +#if CONFIG_LIBX264RGB_ENCODER static const enum AVPixelFormat pix_fmts_8bit_rgb[] = { -#ifdef X264_CSP_BGR AV_PIX_FMT_BGR0, AV_PIX_FMT_BGR24, AV_PIX_FMT_RGB24, -#endif AV_PIX_FMT_NONE }; +#endif static av_cold void X264_init_static(AVCodec *codec) { @@ -1035,13 +1035,6 @@ static const AVClass x264_class = { .version= LIBAVUTIL_VERSION_INT, }; -static const AVClass rgbclass = { -.class_name = "libx264rgb", -.item_name = av_default_item_name, -.option = options, -.version= LIBAVUTIL_VERSION_INT, -}; - AVCodec ff_libx264_encoder = { .name = "libx264", .long_name= NULL_IF_CONFIG_SMALL("libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10"), @@ -1058,6 +1051,15 @@ AVCodec ff_libx264_encoder = { .caps_internal= FF_CODEC_CAP_INIT_THREADSAFE | FF_CODEC_CAP_INIT_CLEANUP, }; +#endif + +#if CONFIG_LIBX264RGB_ENCODER +static const AVClass rgbclass = { +.class_name = "libx264rgb", +.item_name = av_default_item_name, +.option = options, +.version= LIBAVUTIL_VERSION_INT, +}; AVCodec ff_libx264rgb_encoder = { .name = "libx264rgb", -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] lavf/avienc: Use palette side data packet if available
Still as experimental as the first one. Seems that the packets are empty (zero bytes) now and then when doing stream copy. It would be interesting to know why, Michael. I'm new at this. -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From a803d1d4995b371e357f3e280ee37019d77c254e Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sat, 27 Feb 2016 22:53:37 +0100 Subject: [PATCH v2] lavf/avienc: Use palette side data packet if available --- libavformat/avienc.c | 61 ++ 1 file changed, 37 insertions(+), 24 deletions(-) diff --git a/libavformat/avienc.c b/libavformat/avienc.c index ca505f4..1b76728 100644 --- a/libavformat/avienc.c +++ b/libavformat/avienc.c @@ -668,39 +668,52 @@ 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) { +if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0 && size) { int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16; int expected_stride = ((enc->width * bpc + 31) >> 5)*4; +const uint8_t *pal = NULL; +int pal_size = 1 << enc->bits_per_coded_sample; +int i; ret = ff_reshuffle_raw_rgb(s, &pkt, enc, expected_stride); if (ret < 0) return ret; -if (ret) { -if (ret == CONTAINS_PAL) { -int pc_tag, i; -int pal_size = 1 << enc->bits_per_coded_sample; -if (!avist->hdr_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); -avio_wl32(pb, v & 0xff); -} -avio_seek(pb, cur_offset, SEEK_SET); -avist->hdr_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 < pkt->side_data_elems; i++) { +if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) { +pal = pkt->side_data[i].data; +break; +} +} +if (!pal && ret == CONTAINS_PAL) +pal = data + size - AVPALETTE_SIZE; + +if (pal) { +int pc_tag, i; +if (!avist->hdr_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); -avio_wb32(pb, v<<8); +uint32_t v = AV_RL32(pal + 4*i); +avio_wl32(pb, v & 0xff); } -ff_end_tag(pb, pc_tag); +avio_seek(pb, cur_offset, SEEK_SET); +avist->hdr_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++) { +uint32_t v = AV_RL32(pal + 4*i); +avio_wb32(pb, v<<8); } +ff_end_tag(pb, pc_tag); +} + +if (ret) { ret = avi_write_packet_internal(s, pkt); av_packet_free(&pkt); return ret; -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/avienc: Use palette side data packet if available
Just for fun, here is an experimental patch that makes use of palette side data packets if they exist. I suppose the packets (including side data packets) will be unaltered from demuxing to muxing when using stream copy, right? In any case, it produces flickering output for some reason. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From 15dbacd20db011ebb3255aa2023e6132af56c0a6 Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sat, 27 Feb 2016 22:33:29 +0100 Subject: [PATCH] lavf/avienc: Use palette side data packet if available --- libavformat/avienc.c | 59 ++ 1 file changed, 36 insertions(+), 23 deletions(-) diff --git a/libavformat/avienc.c b/libavformat/avienc.c index ca505f4..c1d26c2 100644 --- a/libavformat/avienc.c +++ b/libavformat/avienc.c @@ -671,36 +671,49 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt) if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) { int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16; int expected_stride = ((enc->width * bpc + 31) >> 5)*4; +const uint8_t *pal = NULL; +int pal_size = 1 << enc->bits_per_coded_sample; +int i; ret = ff_reshuffle_raw_rgb(s, &pkt, enc, expected_stride); if (ret < 0) return ret; -if (ret) { -if (ret == CONTAINS_PAL) { -int pc_tag, i; -int pal_size = 1 << enc->bits_per_coded_sample; -if (!avist->hdr_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); -avio_wl32(pb, v & 0xff); -} -avio_seek(pb, cur_offset, SEEK_SET); -avist->hdr_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 < pkt->side_data_elems; i++) { +if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) { +pal = pkt->side_data[i].data; +break; +} +} +if (!pal && ret == CONTAINS_PAL) +pal = data + size - AVPALETTE_SIZE; + +if (pal) { +int pc_tag, i; +if (!avist->hdr_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); -avio_wb32(pb, v<<8); +uint32_t v = AV_RL32(pal + 4*i); +avio_wl32(pb, v & 0xff); } -ff_end_tag(pb, pc_tag); +avio_seek(pb, cur_offset, SEEK_SET); +avist->hdr_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++) { +uint32_t v = AV_RL32(pal + 4*i); +avio_wb32(pb, v<<8); } +ff_end_tag(pb, pc_tag); +} + +if (ret) { ret = avi_write_packet_internal(s, pkt); av_packet_free(&pkt); return ret; -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] vc2enc: clip and warn when user bitrate set too low
On Sat, Feb 27, 2016 at 19:29:05 +, Rostislav Pehlivanov wrote: > +av_log(avctx, AV_LOG_WARNING, > + "Bitrate too low, clipping to minimum = %.2lf Mbps!\n", > + (double)avctx->bit_rate/100.0f); "%lf" is undefined in C90, and otherwise identical to "%f". libavutil/softfloat.c (and only that) does also use it though. ("%f" is already double. There's no printf format specifier for float.) And if you're going to make the division produce a double, you could just as well use a double constant in it. Too much nitpicking for a warning message, sorry, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 09:33 PM, Michael Niedermayer wrote: On Sat, Feb 27, 2016 at 08:42:25PM +0100, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote: should rawvideo AVPackets palette use data[] or sidedata, honestly i do not know, but i dont think it makes a big difference even supporting both, likely only adds 3-5 lines of code or so its more a philosophical question Not sure how much was in response to my complaints, but i dont know either, i was just writing some kind of summary ... if this parts was I think that misses my point, as I agree that it doesn't matter which. What matters though is: The AVI demuxer creates AVPackets with palette in side data, and the AVI muxer supports ONLY palette appended in the data. How to fix it might be philosophical, but I think it's not philosophical and fairly clear that that's just broken. yes, though rawvideo stream copy is a bit tricky, especially when its not the same container. avi<->mov have different stride align requirements for example. Yes, I mentioned that before, regarding the stride differences. One question: For stream copying, the packets will travel unaltered from the demuxer to the muxer including the side data, right? Sorry if it sounds idiotic. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On Sat, Feb 27, 2016 at 08:42:25PM +0100, Reimar Döffinger wrote: > On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote: > > should rawvideo AVPackets palette use data[] or sidedata, honestly i > > do not know, but i dont think it makes a big difference > > even supporting both, likely only adds 3-5 lines of code or so > > its more a philosophical question > > Not sure how much was in response to my complaints, but i dont know either, i was just writing some kind of summary ... > if this parts was I think that misses my point, as I > agree that it doesn't matter which. > What matters though is: > The AVI demuxer creates AVPackets with palette in side data, > and the AVI muxer supports ONLY palette appended in the data. > How to fix it might be philosophical, but I think it's not > philosophical and fairly clear that that's just broken. yes, though rawvideo stream copy is a bit tricky, especially when its not the same container. avi<->mov have different stride align requirements for example. We currently correct that in the muxer If we similarly also handle side data and extradata palettes in the muxer (via shared code ideally) then any input would work not sure this is the best solution [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 09:21 PM, Mats Peterson wrote: On 02/27/2016 08:42 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote: should rawvideo AVPackets palette use data[] or sidedata, honestly i do not know, but i dont think it makes a big difference even supporting both, likely only adds 3-5 lines of code or so its more a philosophical question Not sure how much was in response to my complaints, but if this parts was I think that misses my point, as I agree that it doesn't matter which. What matters though is: The AVI demuxer creates AVPackets with palette in side data, and the AVI muxer supports ONLY palette appended in the data. How to fix it might be philosophical, but I think it's not philosophical and fairly clear that that's just broken. Even remuxing from AVI to AVI simply won't work without a "decoder" (which is not an issue performance-wise, but it is usability wise, how should a FFmpeg user know that for paletted video and only that a lossless stream copy requires "decoding" and "encoding"?). about existing API, i suspect there arent many applications that use ffmpegs demuxers without the decoders for raw pal8, i might of course be wrong but this seems a rather uncommon case of a uncommon case. And muxers side it was all broken before mats ... Well, then we know I can only blame Mats for "only" making it better instead of perfect :) ___ Well, before my patches, there was no palette inclusion whatsoever in AVI or QuickTime on muxing. Anyway, you're right about the stream copying not working. Just tried it here. Another issue to take care of... phew. Solving the stream copying issues obviously requires using side data packets in the muxers, correct me if I'm wrong. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 08:42 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote: should rawvideo AVPackets palette use data[] or sidedata, honestly i do not know, but i dont think it makes a big difference even supporting both, likely only adds 3-5 lines of code or so its more a philosophical question Not sure how much was in response to my complaints, but if this parts was I think that misses my point, as I agree that it doesn't matter which. What matters though is: The AVI demuxer creates AVPackets with palette in side data, and the AVI muxer supports ONLY palette appended in the data. How to fix it might be philosophical, but I think it's not philosophical and fairly clear that that's just broken. Even remuxing from AVI to AVI simply won't work without a "decoder" (which is not an issue performance-wise, but it is usability wise, how should a FFmpeg user know that for paletted video and only that a lossless stream copy requires "decoding" and "encoding"?). about existing API, i suspect there arent many applications that use ffmpegs demuxers without the decoders for raw pal8, i might of course be wrong but this seems a rather uncommon case of a uncommon case. And muxers side it was all broken before mats ... Well, then we know I can only blame Mats for "only" making it better instead of perfect :) ___ Well, before my patches, there was no palette inclusion whatsoever in AVI or QuickTime on muxing. Anyway, you're right about the stream copying not working. Just tried it here. Another issue to take care of... phew. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_copy: exclude hwaccel formats
On 2/26/16, wm4 wrote: > This does obviously not work. > > (Additions based on vf_crop.c.) > --- > libavfilter/vf_copy.c | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/libavfilter/vf_copy.c b/libavfilter/vf_copy.c > index fb9a906..b0159cf 100644 > --- a/libavfilter/vf_copy.c > +++ b/libavfilter/vf_copy.c > @@ -27,6 +27,23 @@ > #include "internal.h" > #include "video.h" > > +static int query_formats(AVFilterContext *ctx) > +{ > +AVFilterFormats *formats = NULL; > +int fmt; > + > +for (fmt = 0; av_pix_fmt_desc_get(fmt); fmt++) { > +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt); > +int ret; > +if (desc->flags & AV_PIX_FMT_FLAG_HWACCEL) > +continue; > +if ((ret = ff_add_format(&formats, fmt)) < 0) > +return ret; > +} > + > +return ff_set_common_formats(ctx, formats); > +} > + > static int filter_frame(AVFilterLink *inlink, AVFrame *in) > { > AVFilterLink *outlink = inlink->dst->outputs[0]; > @@ -64,4 +81,5 @@ AVFilter ff_vf_copy = { > .description = NULL_IF_CONFIG_SMALL("Copy the input video unchanged to > the output."), > .inputs = avfilter_vf_copy_inputs, > .outputs = avfilter_vf_copy_outputs, > +.query_formats = query_formats, > }; I guess this should be fine. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 08:44 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 07:52:52PM +0100, Mats Peterson wrote: On 02/27/2016 07:46 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote: On 02/27/2016 07:18 PM, Reimar Döffinger wrote: That's not what e.g. the matroska demuxer produces, so stream copying with some generic remuxing example I am really sure that is NOT how the packets come in. Stream copying of raw palettized data seldom works well, due to different strides of AVI (4-byte aligned), QuickTime (2-byte aligned) and nut (unnaligned). "Seldom"? That's only an issue (for 8 bpp) if the width is not a multiple of 4. It's an issue for 1 bpp data as well. Not the parsing I meant :) For 8bpp it can only happen if the width is not a multiple of 4. For 1bpp it can only happen if the width is not a multiple of 16 (which is quite a bit more likely and thus I didn't want to use that one as example). ___ I know you wouldn't want to :) Never mind, it's a minor issue compared to the others, as you say yourself. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Ignore invalid sprop-parameter-sets missing PPS
Some Hikvison RTSP cameras send wrong sprop-parameter-sets in SDP - it's missing PPS. Example of correct sprop-parameter-sets: sprop-parameter-sets=Z0IAH5W4PASaEAAAcIAAFfkAQA==,aM48gA== Example of wrong sprop-parameter-sets: sprop-parameter-sets=Z0IAH5WoPASaEAAAcIAAFfkIQA==, My patch adds a workaround that ignores invalid sprop-parameter-sets. On Sat, Feb 27, 2016 at 9:35 PM, Andrew Shulgin wrote: > Sorry, wrong From: header, sended again with correct > > On Sat, Feb 27, 2016 at 9:30 PM, Andrew Shulgin wrote: > >> --- >> libavformat/rtpdec_h264.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c >> index b399be4..e707d03 100644 >> --- a/libavformat/rtpdec_h264.c >> +++ b/libavformat/rtpdec_h264.c >> @@ -166,6 +166,10 @@ static int >> sdp_parse_fmtp_config_h264(AVFormatContext *s, >> parse_profile_level_id(s, h264_data, value); >> } else if (!strcmp(attr, "sprop-parameter-sets")) { >> int ret; >> +if (value[strlen(value) - 1] == ',') { >> +av_log(s, AV_LOG_WARNING, "Missing PPS in >> sprop-parameter-sets, ignoring\n"); >> +return 0; >> +} >> codec->extradata_size = 0; >> av_freep(&codec->extradata); >> ret = ff_h264_parse_sprop_parameter_sets(s, &codec->extradata, >> -- >> 2.4.10 >> > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On Sat, Feb 27, 2016 at 07:52:52PM +0100, Mats Peterson wrote: > On 02/27/2016 07:46 PM, Reimar Döffinger wrote: > >On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote: > >>On 02/27/2016 07:18 PM, Reimar Döffinger wrote: > >>>That's not what e.g. the matroska demuxer produces, so stream > >>>copying with some generic remuxing example I am really sure that is > >>>NOT how the packets come in. > >>> > >> > >>Stream copying of raw palettized data seldom works well, due to different > >>strides of AVI (4-byte aligned), QuickTime (2-byte aligned) and nut > >>(unnaligned). > > > >"Seldom"? That's only an issue (for 8 bpp) if the width > >is not a multiple of 4. > > It's an issue for 1 bpp data as well. Not the parsing I meant :) For 8bpp it can only happen if the width is not a multiple of 4. For 1bpp it can only happen if the width is not a multiple of 16 (which is quite a bit more likely and thus I didn't want to use that one as example). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/7] vc2enc: carry over quantization index across frames as a starting point
Previously a global average was used. Using the previous quantizer resulted in a fairly significant speedup as slice size selection settled down quicker. Signed-off-by: Rostislav Pehlivanov --- libavcodec/vc2enc.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c index b39..5e11aa1 100644 --- a/libavcodec/vc2enc.c +++ b/libavcodec/vc2enc.c @@ -132,7 +132,7 @@ typedef struct VC2EncContext { int slice_max_bytes; int slice_min_bytes; int q_ceil; -int q_start; +int q_avg; /* Options */ double tolerance; @@ -675,7 +675,7 @@ static int rate_control(AVCodecContext *avctx, void *arg) const int sx = slice_dat->x; const int sy = slice_dat->y; int bits_last = INT_MAX, quant_buf[2] = {-1, -1}; -int quant = s->q_start, range = s->q_start/3; +int quant = slice_dat->quant_idx, range = quant/5; const int top = slice_dat->bits_ceil; const int bottom = slice_dat->bits_floor; int bits = count_hq_slice(s, slice_dat->cache, &slice_dat->cached_results, @@ -791,7 +791,7 @@ static int encode_slices(VC2EncContext *s) for (slice_x = 0; slice_x < s->num_x; slice_x++) { SliceArgs *args = &enc_args[s->num_x*slice_y + slice_x]; init_put_bits(&args->pb, buf + skip, args->bytes); -s->q_start = (s->q_start + args->quant_idx)/2; +s->q_avg = (s->q_avg + args->quant_idx)/2; skip += args->bytes; } } @@ -839,8 +839,6 @@ static int encode_slices(VC2EncContext *s) * of levels. The rest of the areas can be thought as the details needed * to restore the image perfectly to its original size. */ - - static int dwt_plane(AVCodecContext *avctx, void *arg) { TransformArgs *transform_dat = arg; @@ -996,7 +994,7 @@ static av_cold int vc2_encode_end(AVCodecContext *avctx) int i; VC2EncContext *s = avctx->priv_data; -av_log(avctx, AV_LOG_INFO, "Qavg: %i\n", s->q_start); +av_log(avctx, AV_LOG_INFO, "Qavg: %i\n", s->q_avg); for (i = 0; i < 3; i++) { ff_vc2enc_free_transforms(&s->transform_args[i].t); @@ -1031,6 +1029,8 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx) s->base_vf = -1; s->strict_compliance = 1; +s->q_avg = 0; + /* Mark unknown as progressive */ s->interlaced = !((avctx->field_order == AV_FIELD_UNKNOWN) || (avctx->field_order == AV_FIELD_PROGRESSIVE)); -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/7] vc2enc: clip and warn when user bitrate set too low
The encoder crashed on verly low bitrates since there wasn't enough space allocated. Signed-off-by: Rostislav Pehlivanov --- libavcodec/vc2enc.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c index 5e11aa1..27db6c0 100644 --- a/libavcodec/vc2enc.c +++ b/libavcodec/vc2enc.c @@ -1008,12 +1008,24 @@ static av_cold int vc2_encode_end(AVCodecContext *avctx) return 0; } +static int minimum_frame_bits(VC2EncContext *s) +{ +int slice_x, slice_y, bits = 0; +s->size_scaler = 64; +for (slice_y = 0; slice_y < s->num_y; slice_y++) { +for (slice_x = 0; slice_x < s->num_x; slice_x++) { +bits += count_hq_slice(s, NULL, NULL, slice_x, slice_y, s->q_ceil); +} +} +return bits; +} static av_cold int vc2_encode_init(AVCodecContext *avctx) { Plane *p; SubBand *b; int i, j, level, o, shift; +int64_t bits_per_frame, min_bits_per_frame; VC2EncContext *s = avctx->priv_data; s->picture_number = 0; @@ -1161,6 +1173,17 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx) } } +bits_per_frame = av_rescale(avctx->bit_rate, avctx->time_base.num, + avctx->time_base.den); +min_bits_per_frame = minimum_frame_bits(s) + 8*sizeof(LIBAVCODEC_IDENT) + 8*40 + 8*2; +if (bits_per_frame < min_bits_per_frame) { +avctx->bit_rate = av_rescale(min_bits_per_frame, avctx->time_base.den, + avctx->time_base.num); +av_log(avctx, AV_LOG_WARNING, + "Bitrate too low, clipping to minimum = %.2lf Mbps!\n", + (double)avctx->bit_rate/100.0f); +} + return 0; alloc_fail: -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote: > should rawvideo AVPackets palette use data[] or sidedata, honestly i > do not know, but i dont think it makes a big difference > even supporting both, likely only adds 3-5 lines of code or so > its more a philosophical question Not sure how much was in response to my complaints, but if this parts was I think that misses my point, as I agree that it doesn't matter which. What matters though is: The AVI demuxer creates AVPackets with palette in side data, and the AVI muxer supports ONLY palette appended in the data. How to fix it might be philosophical, but I think it's not philosophical and fairly clear that that's just broken. Even remuxing from AVI to AVI simply won't work without a "decoder" (which is not an issue performance-wise, but it is usability wise, how should a FFmpeg user know that for paletted video and only that a lossless stream copy requires "decoding" and "encoding"?). > about existing API, i suspect there arent many applications that > use ffmpegs demuxers without the decoders for raw pal8, i might > of course be wrong but this seems a rather uncommon case of a uncommon > case. And muxers side it was all broken before mats ... Well, then we know I can only blame Mats for "only" making it better instead of perfect :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 7/7] vc2enc: update default settings
4 level transforms seem to work better for "real world content" although testing on images still results in 5 level transforms needing less bits. Slice sizes can now be reduced as they work better. The bits which would have been wasted are now used. Signed-off-by: Rostislav Pehlivanov --- libavcodec/vc2enc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c index df71953..023e02b 100644 --- a/libavcodec/vc2enc.c +++ b/libavcodec/vc2enc.c @@ -1244,10 +1244,10 @@ alloc_fail: #define VC2ENC_FLAGS (AV_OPT_FLAG_ENCODING_PARAM | AV_OPT_FLAG_VIDEO_PARAM) static const AVOption vc2enc_options[] = { -{"tolerance", "Max undershoot in percent", offsetof(VC2EncContext, tolerance), AV_OPT_TYPE_DOUBLE, {.dbl = 10.0f}, 0.0f, 45.0f, VC2ENC_FLAGS, "tolerance"}, -{"slice_width", "Slice width", offsetof(VC2EncContext, slice_width), AV_OPT_TYPE_INT, {.i64 = 128}, 32, 1024, VC2ENC_FLAGS, "slice_width"}, -{"slice_height", "Slice height", offsetof(VC2EncContext, slice_height), AV_OPT_TYPE_INT, {.i64 = 64}, 8, 1024, VC2ENC_FLAGS, "slice_height"}, -{"wavelet_depth", "Transform depth", offsetof(VC2EncContext, wavelet_depth), AV_OPT_TYPE_INT, {.i64 = 5}, 1, 5, VC2ENC_FLAGS, "wavelet_depth"}, +{"tolerance", "Max undershoot in percent", offsetof(VC2EncContext, tolerance), AV_OPT_TYPE_DOUBLE, {.dbl = 5.0f}, 0.0f, 45.0f, VC2ENC_FLAGS, "tolerance"}, +{"slice_width", "Slice width", offsetof(VC2EncContext, slice_width), AV_OPT_TYPE_INT, {.i64 = 64}, 32, 1024, VC2ENC_FLAGS, "slice_width"}, +{"slice_height", "Slice height", offsetof(VC2EncContext, slice_height), AV_OPT_TYPE_INT, {.i64 = 32}, 8, 1024, VC2ENC_FLAGS, "slice_height"}, +{"wavelet_depth", "Transform depth", offsetof(VC2EncContext, wavelet_depth), AV_OPT_TYPE_INT, {.i64 = 4}, 1, 5, VC2ENC_FLAGS, "wavelet_depth"}, {"wavelet_type", "Transform type", offsetof(VC2EncContext, wavelet_idx), AV_OPT_TYPE_INT, {.i64 = VC2_TRANSFORM_9_7}, 0, VC2_TRANSFORMS_NB, VC2ENC_FLAGS, "wavelet_idx"}, {"9_7", "Deslauriers-Dubuc (9,7)", 0, AV_OPT_TYPE_CONST, {.i64 = VC2_TRANSFORM_9_7},INT_MIN, INT_MAX, VC2ENC_FLAGS, "wavelet_idx"}, {"5_3", "LeGall (5,3)",0, AV_OPT_TYPE_CONST, {.i64 = VC2_TRANSFORM_5_3},INT_MIN, INT_MAX, VC2ENC_FLAGS, "wavelet_idx"}, -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/7] vc2enc: cache bits per quantizer, calculate wasted bits
Needed for following commits, also a speed increase. Signed-off-by: Rostislav Pehlivanov --- libavcodec/vc2enc.c | 37 - 1 file changed, 32 insertions(+), 5 deletions(-) diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c index fd2abd5..1d74cd5 100644 --- a/libavcodec/vc2enc.c +++ b/libavcodec/vc2enc.c @@ -36,6 +36,9 @@ * (COEF_LUT_TAB*MAX_QUANT_INDEX) since the sign is appended during encoding */ #define COEF_LUT_TAB 2048 +/* Per slice quantization bit cost cache */ +#define SLICE_CACHED_QUANTIZERS 30 + enum VC2_QM { VC2_QM_DEF = 0, VC2_QM_COL, @@ -61,14 +64,22 @@ typedef struct Plane { ptrdiff_t coef_stride; } Plane; +typedef struct BitCostCache { +int bits; +int quantizer; +} BitCostCache; + typedef struct SliceArgs { PutBitContext pb; +BitCostCache cache[SLICE_CACHED_QUANTIZERS]; +int cached_results; void *ctx; int x; int y; int quant_idx; int bits_ceil; int bits_floor; +int bytes_left; int bytes; } SliceArgs; @@ -583,13 +594,19 @@ static void encode_subband(VC2EncContext *s, PutBitContext *pb, int sx, int sy, } } -static int count_hq_slice(VC2EncContext *s, int slice_x, - int slice_y, int quant_idx) +static int count_hq_slice(VC2EncContext *s, BitCostCache *cache, + int *cached_results, int slice_x, int slice_y, + int quant_idx) { -int x, y; +int i, x, y; uint8_t quants[MAX_DWT_LEVELS][4]; int bits = 0, p, level, orientation; +if (cache && *cached_results) +for (i = 0; i < *cached_results; i++) +if (cache[i].quantizer == quant_idx) +return cache[i].bits; + bits += 8*s->prefix_bytes; bits += 8; /* quant_idx */ @@ -639,6 +656,12 @@ static int count_hq_slice(VC2EncContext *s, int slice_x, bits += pad_c*8; } +if (cache) { +cache[*cached_results].quantizer = quant_idx; +cache[*cached_results].bits = bits; +*cached_results = FFMIN(*cached_results + 1, SLICE_CACHED_QUANTIZERS); +} + return bits; } @@ -655,12 +678,14 @@ static int rate_control(AVCodecContext *avctx, void *arg) int quant = s->q_start, range = s->q_start/3; const int top = slice_dat->bits_ceil; const int bottom = slice_dat->bits_floor; -int bits = count_hq_slice(s, sx, sy, quant); +int bits = count_hq_slice(s, slice_dat->cache, &slice_dat->cached_results, + sx, sy, quant); range -= range & 1; /* Make it an even number */ while ((bits > top) || (bits < bottom)) { range *= bits > top ? +1 : -1; quant = av_clip(quant + range, 0, s->q_ceil); -bits = count_hq_slice(s, sx, sy, quant); +bits = count_hq_slice(s, slice_dat->cache, &slice_dat->cached_results, + sx, sy, quant); range = av_clip(range/2, 1, s->q_ceil); if (quant_buf[1] == quant) { quant = bits_last < bits ? quant_buf[0] : quant; @@ -673,6 +698,7 @@ static int rate_control(AVCodecContext *avctx, void *arg) } slice_dat->quant_idx = av_clip(quant, 0, s->q_ceil); slice_dat->bytes = FFALIGN((bits >> 3), s->size_scaler) + 4 + s->prefix_bytes; +slice_dat->bytes_left = s->slice_max_bytes - slice_dat->bytes; return 0; } @@ -688,6 +714,7 @@ static void calc_slice_sizes(VC2EncContext *s) args->ctx = s; args->x = slice_x; args->y = slice_y; +args->cached_results = 0; args->bits_ceil = s->slice_max_bytes << 3; args->bits_floor = s->slice_min_bytes << 3; } -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/7] vc2enc: redistribute leftover bytes
This commit redistributes the leftover bytes amongst the top 150 slices in terms of size (in the hopes that they'll be the ones bitrate starved). A more perceptual method would probably need to cut bits off from slices which don't need much, but that'll be implemented later. The cached quantizer bit cost helped to keep this search from barely taking CPU time. Signed-off-by: Rostislav Pehlivanov --- libavcodec/vc2enc.c | 52 +++- 1 file changed, 51 insertions(+), 1 deletion(-) diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c index 600a8ac..df71953 100644 --- a/libavcodec/vc2enc.c +++ b/libavcodec/vc2enc.c @@ -39,6 +39,9 @@ /* Per slice quantization bit cost cache */ #define SLICE_CACHED_QUANTIZERS 30 +/* Decides the cutoff point in # of slices to distribute the leftover bytes */ +#define SLICE_REDIST_TOTAL 150 + enum VC2_QM { VC2_QM_DEF = 0, VC2_QM_COL, @@ -780,9 +783,13 @@ static int encode_hq_slice(AVCodecContext *avctx, void *arg) static int encode_slices(VC2EncContext *s) { uint8_t *buf; -int slice_x, slice_y, skip = 0; +int i, slice_x, slice_y, skip = 0; +int bytes_left = 0; SliceArgs *enc_args = s->slice_args; +int bytes_top[SLICE_REDIST_TOTAL] = {0}; +SliceArgs *top_loc[SLICE_REDIST_TOTAL] = {NULL}; + avpriv_align_put_bits(&s->pb); flush_put_bits(&s->pb); buf = put_bits_ptr(&s->pb); @@ -790,6 +797,47 @@ static int encode_slices(VC2EncContext *s) for (slice_y = 0; slice_y < s->num_y; slice_y++) { for (slice_x = 0; slice_x < s->num_x; slice_x++) { SliceArgs *args = &enc_args[s->num_x*slice_y + slice_x]; +bytes_left += args->bytes_left; +for (i = 0; i < FFMIN(SLICE_REDIST_TOTAL, s->num_x*s->num_y); i++) { +if (args->bytes > bytes_top[i]) { +bytes_top[i] = args->bytes; +top_loc[i] = args; +break; +} +} +} +} + +while (1) { +int distributed = 0; +for (i = 0; i < FFMIN(SLICE_REDIST_TOTAL, s->num_x*s->num_y); i++) { +SliceArgs *args; +int bits, bytes, diff, prev_bytes, new_idx; +if (bytes_left <= 0) +break; +if (!top_loc[i] || !top_loc[i]->quant_idx) +break; +args = top_loc[i]; +prev_bytes = args->bytes; +new_idx = av_clip(args->quant_idx - 1, 0, s->q_ceil); +bits = count_hq_slice(s, args->cache, &args->cached_results, + args->x, args->y, new_idx); +bytes = FFALIGN((bits >> 3), s->size_scaler) + 4 + s->prefix_bytes; +diff = bytes - prev_bytes; +if ((bytes_left - diff) >= 0) { +args->quant_idx = new_idx; +args->bytes = bytes; +bytes_left -= diff; +distributed++; +} +} +if (!distributed) +break; +} + +for (slice_y = 0; slice_y < s->num_y; slice_y++) { +for (slice_x = 0; slice_x < s->num_x; slice_x++) { +SliceArgs *args = &enc_args[s->num_x*slice_y + slice_x]; init_put_bits(&args->pb, buf + skip, args->bytes); s->q_avg = (s->q_avg + args->quant_idx)/2; skip += args->bytes; @@ -1042,6 +1090,8 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx) s->strict_compliance = 1; s->q_avg = 0; +s->slice_max_bytes = 0; +s->slice_min_bytes = 0; /* Mark unknown as progressive */ s->interlaced = !((avctx->field_order == AV_FIELD_UNKNOWN) || -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/7] vc2enc: allocate the DWT context with the current plane size
Previously used the luma size only. Signed-off-by: Rostislav Pehlivanov --- libavcodec/vc2enc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c index 27db6c0..600a8ac 100644 --- a/libavcodec/vc2enc.c +++ b/libavcodec/vc2enc.c @@ -1142,8 +1142,8 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx) /* DWT init */ if (ff_vc2enc_init_transforms(&s->transform_args[i].t, -s->plane[0].coef_stride, -s->plane[0].dwt_height)) + s->plane[i].coef_stride, + s->plane[i].dwt_height)) goto alloc_fail; } -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Ignore invalid sprop-parameter-sets missing PPS
Sorry, wrong From: header, sended again with correct On Sat, Feb 27, 2016 at 9:30 PM, Andrew Shulgin wrote: > --- > libavformat/rtpdec_h264.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c > index b399be4..e707d03 100644 > --- a/libavformat/rtpdec_h264.c > +++ b/libavformat/rtpdec_h264.c > @@ -166,6 +166,10 @@ static int sdp_parse_fmtp_config_h264(AVFormatContext > *s, > parse_profile_level_id(s, h264_data, value); > } else if (!strcmp(attr, "sprop-parameter-sets")) { > int ret; > +if (value[strlen(value) - 1] == ',') { > +av_log(s, AV_LOG_WARNING, "Missing PPS in > sprop-parameter-sets, ignoring\n"); > +return 0; > +} > codec->extradata_size = 0; > av_freep(&codec->extradata); > ret = ff_h264_parse_sprop_parameter_sets(s, &codec->extradata, > -- > 2.4.10 > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Ignore invalid sprop-parameter-sets missing PPS
--- libavformat/rtpdec_h264.c | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c index b399be4..e707d03 100644 --- a/libavformat/rtpdec_h264.c +++ b/libavformat/rtpdec_h264.c @@ -166,6 +166,10 @@ static int sdp_parse_fmtp_config_h264(AVFormatContext *s, parse_profile_level_id(s, h264_data, value); } else if (!strcmp(attr, "sprop-parameter-sets")) { int ret; +if (value[strlen(value) - 1] == ',') { +av_log(s, AV_LOG_WARNING, "Missing PPS in sprop-parameter-sets, ignoring\n"); +return 0; +} codec->extradata_size = 0; av_freep(&codec->extradata); ret = ff_h264_parse_sprop_parameter_sets(s, &codec->extradata, -- 2.4.10 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/7] vc2enc: use 32 bits for quantized coefficients LUT
16 bits were definitely not enough and caused artifacts to appear on images even on high bitrates. Signed-off-by: Rostislav Pehlivanov --- libavcodec/vc2enc.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c index 1d74cd5..b39 100644 --- a/libavcodec/vc2enc.c +++ b/libavcodec/vc2enc.c @@ -118,7 +118,7 @@ typedef struct VC2EncContext { uint8_t quant[MAX_DWT_LEVELS][4]; /* Coefficient LUT */ -uint16_t *coef_lut_val; +uint32_t *coef_lut_val; uint8_t *coef_lut_len; int num_x; /* #slices horizontally */ @@ -162,7 +162,7 @@ static av_always_inline void put_padding(PutBitContext *pb, int bytes) put_bits(pb, bits, 0); } -static av_always_inline void put_vc2_ue_uint(PutBitContext *pb, uint16_t val) +static av_always_inline void put_vc2_ue_uint(PutBitContext *pb, uint32_t val) { int i; int pbits = 0, bits = 0, topbit = 1, maxval = 1; @@ -190,7 +190,7 @@ static av_always_inline void put_vc2_ue_uint(PutBitContext *pb, uint16_t val) put_bits(pb, bits*2 + 1, (pbits << 1) | 1); } -static av_always_inline int count_vc2_ue_uint(uint16_t val) +static av_always_inline int count_vc2_ue_uint(uint32_t val) { int topbit = 1, maxval = 1; @@ -206,8 +206,8 @@ static av_always_inline int count_vc2_ue_uint(uint16_t val) return ff_log2(topbit)*2 + 1; } -static av_always_inline void get_vc2_ue_uint(uint16_t val, uint8_t *nbits, - uint16_t *eval) +static av_always_inline void get_vc2_ue_uint(int val, uint8_t *nbits, + uint32_t *eval) { int i; int pbits = 0, bits = 0, topbit = 1, maxval = 1; @@ -569,14 +569,14 @@ static void encode_subband(VC2EncContext *s, PutBitContext *pb, int sx, int sy, const int qfactor = ff_dirac_qscale_tab[quant]; const uint8_t *len_lut = &s->coef_lut_len[quant*COEF_LUT_TAB]; -const uint16_t *val_lut = &s->coef_lut_val[quant*COEF_LUT_TAB]; +const uint32_t *val_lut = &s->coef_lut_val[quant*COEF_LUT_TAB]; dwtcoef *coeff = b->buf + top * b->stride; for (y = top; y < bottom; y++) { for (x = left; x < right; x++) { const int neg = coeff[x] < 0; -uint16_t c_abs = FFABS(coeff[x]); +uint32_t c_abs = FFABS(coeff[x]); if (c_abs < COEF_LUT_TAB) { const uint8_t len = len_lut[c_abs]; if (len == 1) @@ -635,7 +635,7 @@ static int count_hq_slice(VC2EncContext *s, BitCostCache *cache, for (y = top; y < bottom; y++) { for (x = left; x < right; x++) { -uint16_t c_abs = FFABS(buf[x]); +uint32_t c_abs = FFABS(buf[x]); if (c_abs < COEF_LUT_TAB) { const int len = len_lut[c_abs]; bits += len + (len != 1); @@ -1155,7 +1155,7 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx) for (i = 0; i < s->q_ceil; i++) { for (j = 0; j < COEF_LUT_TAB; j++) { uint8_t *len_lut = &s->coef_lut_len[i*COEF_LUT_TAB]; -uint16_t *val_lut = &s->coef_lut_val[i*COEF_LUT_TAB]; +uint32_t *val_lut = &s->coef_lut_val[i*COEF_LUT_TAB]; get_vc2_ue_uint(QUANT(j, ff_dirac_qscale_tab[i]), &len_lut[j], &val_lut[j]); } -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 07:51 PM, Michael Niedermayer wrote: On Sat, Feb 27, 2016 at 05:45:57PM +0100, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 04:15:10PM +0100, Mats Peterson wrote: On 02/27/2016 04:13 PM, Mats Peterson wrote: On 02/27/2016 04:08 PM, Mats Peterson wrote: On 02/27/2016 04:07 PM, Mats Peterson wrote: On 02/27/2016 04:00 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote: On 02/27/2016 03:37 PM, Mats Peterson wrote: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I suppose this is what you mean, Reimar. Treating the palette, if a packet contains one at the end of the video data, as being AVPALETTE_SIZE bytes exclusively. Well, actually not really. If the palette is part of input frame it should be sent as side data. I am not sure where this variant comes from. It might be that it should just be written as is. Or even if the palette needs to be split it might be necessary to auto-detect the palette size via packet size - (width*height*bits per pixel)/8. But as said, I am fairly unclear on what case that code is supposed to handle. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I agree that it should be stored in a side data packet myself normally, and that this is a somewhat weird construction. It probably has to do with the nut format originally, which stores raw palettized data after the video data in the packets. Anyway, I have accepted the facts. For the record, the new ff_reshuffle_raw_rgb() function written by Michael in lavf/rawutils.c that aligns strides properly for AVI and QuickTime, will set a CONTAINS_PAL flag if the packet size is larger than the actual video data. He has hardcoded the palette size to 1024 bytes in that file. Mats The nut format stores the PALETTE after the video data in the packets, nothing else :) In any case, on muxing, the packets will have the palette after the video data in the packets, whether it's AVI or QuickTime. Neither avienc.c or movenc.c uses any side data packets for the palette. Michael's intention has been to enable palette switching in the middle of the stream, hence storage of the palette in each packet, and AVI supports it by using the 'xxpc' chunks in the video data. It is also implemented by now. Mats Not that it couldn't be done with side data packets, though. If it doesn't support side data then the muxers are plain broken. If the nut muxer stores palette by appending it to the frames, then the demuxer should split it out into side data. Note that I am absolutely not a fan of this side data stuff, but since we already decided to do it like that then that's the way we need to go, not randomly doing one way in one place and differently in another, that just makes for unusable API. The only reasons to support "palette appended to data" are 1) There are some existing users of the FFmpeg API that rely on it. Ideally we should then change it so it works for all muxers, or the other way round warn that this is a deprecated way of doing things. 2) There are file formats that store it that way and we cannot easily split it into side data. Not sure that can really happen. palettes are a bit annoying, there are quite a few things the chain generally is demuxer -> decoder -> encoder -> muxer OR demuxer ---> muxer Thus there are 2 interfaces, the demuxer -> muxer and the decoder -> encoder interface For the decoder -> encoder interface, the palette is in AVFrame.data[1] the 8bit indexes as a width(stride) x height array in AVFrame.data[0] that part is still easy the demuxer -> muxer interface is more complex in case of non raw, that is compressed codecs the palette can be in a codec specific and inseprable format in AVPacket.data with the rest of the compressed image. but its also possible that there is no palette in AVPacket.data and instead its stored in AVPackets side data which would be filled from container specific chunks like avis PCxx or in the global extradata So even without rawvideo there already exist both sidedata and non sidedata cases additionally key frame AVPackets must together with the global extradata contain a full palette to be decodeable. some containers support storing "partial palettes", for example avis PCxx chunks can do that, so one should at keyframes store a full one but subequent non keyframes should only store the part that differs from the previous. The container specific compression like PCxx would semantically best fit into the muxer should rawvideo AVPackets palette use data[] or sidedata, honestly i do not know, but i dont think it makes a big difference even supporting both, likely only adds 3-5 lines of code or so its more a philosophical question is the palette like chroma or alph
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 07:46 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote: On 02/27/2016 07:18 PM, Reimar Döffinger wrote: That's not what e.g. the matroska demuxer produces, so stream copying with some generic remuxing example I am really sure that is NOT how the packets come in. Stream copying of raw palettized data seldom works well, due to different strides of AVI (4-byte aligned), QuickTime (2-byte aligned) and nut (unnaligned). "Seldom"? That's only an issue (for 8 bpp) if the width is not a multiple of 4. It's an issue for 1 bpp data as well. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On Sat, Feb 27, 2016 at 05:45:57PM +0100, Reimar Döffinger wrote: > On Sat, Feb 27, 2016 at 04:15:10PM +0100, Mats Peterson wrote: > > On 02/27/2016 04:13 PM, Mats Peterson wrote: > > >On 02/27/2016 04:08 PM, Mats Peterson wrote: > > >>On 02/27/2016 04:07 PM, Mats Peterson wrote: > > >>>On 02/27/2016 04:00 PM, Reimar Döffinger wrote: > > On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote: > > >On 02/27/2016 03:37 PM, Mats Peterson wrote: > > >> > > >> > > >> > > >>___ > > >>ffmpeg-devel mailing list > > >>ffmpeg-devel@ffmpeg.org > > >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > >> > > > > > >I suppose this is what you mean, Reimar. Treating the palette, if a > > >packet > > >contains one at the end of the video data, as being AVPALETTE_SIZE > > >bytes > > >exclusively. > > > > Well, actually not really. > > If the palette is part of input frame it should be sent as side > > data. > > I am not sure where this variant comes from. > > It might be that it should just be written as is. > > Or even if the palette needs to be split it might be > > necessary to auto-detect the palette size via > > packet size - (width*height*bits per pixel)/8. > > But as said, I am fairly unclear on what case that > > code is supposed to handle. > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > >>> > > >>>I agree that it should be stored in a side data packet myself normally, > > >>>and that this is a somewhat weird construction. It probably has to do > > >>>with the nut format originally, which stores raw palettized data after > > >>>the video data in the packets. Anyway, I have accepted the facts. For > > >>>the record, the new ff_reshuffle_raw_rgb() function written by Michael > > >>>in lavf/rawutils.c that aligns strides properly for AVI and QuickTime, > > >>>will set a CONTAINS_PAL flag if the packet size is larger than the > > >>>actual video data. He has hardcoded the palette size to 1024 bytes in > > >>>that file. > > >>> > > >>>Mats > > >>> > > >> > > >>The nut format stores the PALETTE after the video data in the packets, > > >>nothing else :) > > >> > > > > > >In any case, on muxing, the packets will have the palette after the > > >video data in the packets, whether it's AVI or QuickTime. Neither > > >avienc.c or movenc.c uses any side data packets for the palette. > > > > > >Michael's intention has been to enable palette switching in the middle > > >of the stream, hence storage of the palette in each packet, and AVI > > >supports it by using the 'xxpc' chunks in the video data. It is also > > >implemented by now. > > > > > >Mats > > > > > > > Not that it couldn't be done with side data packets, though. > > If it doesn't support side data then the muxers are plain broken. > If the nut muxer stores palette by appending it to the frames, > then the demuxer should split it out into side data. > Note that I am absolutely not a fan of this side data stuff, > but since we already decided to do it like that then that's > the way we need to go, not randomly doing one way in one > place and differently in another, that just makes for unusable > API. > The only reasons to support "palette appended to data" are > 1) There are some existing users of the FFmpeg API that rely on it. >Ideally we should then change it so it works for all muxers, or >the other way round warn that this is a deprecated way of doing >things. > 2) There are file formats that store it that way and we cannot easily >split it into side data. Not sure that can really happen. palettes are a bit annoying, there are quite a few things the chain generally is demuxer -> decoder -> encoder -> muxer OR demuxer ---> muxer Thus there are 2 interfaces, the demuxer -> muxer and the decoder -> encoder interface For the decoder -> encoder interface, the palette is in AVFrame.data[1] the 8bit indexes as a width(stride) x height array in AVFrame.data[0] that part is still easy the demuxer -> muxer interface is more complex in case of non raw, that is compressed codecs the palette can be in a codec specific and inseprable format in AVPacket.data with the rest of the compressed image. but its also possible that there is no palette in AVPacket.data and instead its stored in AVPackets side data which would be filled from container specific chunks like avis PCxx or in the global extradata So even without rawvideo there already exist both sidedata and non sidedata cases additionally key frame AVPackets must together with the global extradata contain a full palette to be decodeable. some containers support storing "partial palettes", for example avis PCxx chunks can do that, so one should at keyframes store
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote: > On 02/27/2016 07:18 PM, Reimar Döffinger wrote: > >That's not what e.g. the matroska demuxer produces, so stream > >copying with some generic remuxing example I am really sure that is > >NOT how the packets come in. > > > > Stream copying of raw palettized data seldom works well, due to different > strides of AVI (4-byte aligned), QuickTime (2-byte aligned) and nut > (unnaligned). "Seldom"? That's only an issue (for 8 bpp) if the width is not a multiple of 4. To me that sounds like a minor issue compared to "we designed our demuxers to use a format completely different from our muxers". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 07:40 PM, Mats Peterson wrote: On 02/27/2016 07:18 PM, Reimar Döffinger wrote: That's not what e.g. the matroska demuxer produces, so stream copying with some generic remuxing example I am really sure that is NOT how the packets come in. Stream copying of raw palettized data seldom works well, due to different strides of AVI (4-byte aligned), QuickTime (2-byte aligned) and nut (unnaligned). unaligned, not unnaligned. -- 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 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 07:18 PM, Reimar Döffinger wrote: That's not what e.g. the matroska demuxer produces, so stream copying with some generic remuxing example I am really sure that is NOT how the packets come in. Stream copying of raw palettized data seldom works well, due to different strides of AVI (4-byte aligned), QuickTime (2-byte aligned) and nut (unnaligned). Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 07:18 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 06:05:20PM +0100, Mats Peterson wrote: On 02/27/2016 05:45 PM, Reimar Döffinger wrote: Not that it couldn't be done with side data packets, though. If it doesn't support side data then the muxers are plain broken. The muxers should support side data, I agree on that. The thing is the packets come in to the AVI, QuickTime and nut muxers with the palette data appended to the video data in the packets. You never answered that actually... How do the come in that way?!? That's not what e.g. the matroska demuxer produces, so stream copying with some generic remuxing example I am really sure that is NOT how the packets come in. That's apparently how things work in FFmpeg at the moment. There is currently no palette side data used by the *FFmpeg* muxers. The palette is appended to the packets. Ask Michael for further details, he can probably explain this better than me. I can't see HOW they even COULD work right now?! Otherwise I wouldn't really care, but as far as I can tell I don't see how it could work at all but for some lucky exceptions. What cases have we actually tested to work? ___ In spite of the mixed use of side data and palette in packets, things work just fine. FFplay currently plays all palettized files correctly, and FFmpeg produces palettized files correctly, after my recent patches. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On Sat, Feb 27, 2016 at 06:05:20PM +0100, Mats Peterson wrote: > On 02/27/2016 05:45 PM, Reimar Döffinger wrote: > >>Not that it couldn't be done with side data packets, though. > > > >If it doesn't support side data then the muxers are plain broken. > > The muxers should support side data, I agree on that. The thing is the > packets come in to the AVI, QuickTime and nut muxers with the palette data > appended to the video data in the packets. You never answered that actually... How do the come in that way?!? That's not what e.g. the matroska demuxer produces, so stream copying with some generic remuxing example I am really sure that is NOT how the packets come in. > That's a choice Michael have > made, I think. Possibly someone else, I don't know. Anyway, Michael once > told me that he would like to view palettized frames as "self-contained", > where the palette is part of the video data in an atomic way. I'd be fine with that. Except that is simply not the way it is currently as far as I can tell. > Anyway, things work OK right now, and even if the situation is slightly > confusing, it's probably not a good idea to start messing around with things > until a clearly defined way of storing the palette for the muxers and > demuxers has been presented. I can't see HOW they even COULD work right now?! Otherwise I wouldn't really care, but as far as I can tell I don't see how it could work at all but for some lucky exceptions. What cases have we actually tested to work? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Regarding palettes in FFmpeg (again)
My observation of the current state of palette storage in FFmpeg is as follows: On the demuxer side, side data packets are usually used for the palette, except for nut, where the palette is appended to the video data in each packet, in the same way as on the muxer side. On the muxer side, the palette is appended to the video data in each packet. No side data is currently used. 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 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 05:45 PM, Reimar Döffinger wrote: I agree that it should be stored in a side data packet myself normally, and that this is a somewhat weird construction. It probably has to do with the nut format originally, which stores raw palettized data after the video data in the packets. Anyway, I have accepted the facts. For the record, the new ff_reshuffle_raw_rgb() function written by Michael in lavf/rawutils.c that aligns strides properly for AVI and QuickTime, will set a CONTAINS_PAL flag if the packet size is larger than the actual video data. He has hardcoded the palette size to 1024 bytes in that file. Mats The nut format stores the PALETTE after the video data in the packets, nothing else :) In any case, on muxing, the packets will have the palette after the video data in the packets, whether it's AVI or QuickTime. Neither avienc.c or movenc.c uses any side data packets for the palette. Michael's intention has been to enable palette switching in the middle of the stream, hence storage of the palette in each packet, and AVI supports it by using the 'xxpc' chunks in the video data. It is also implemented by now. Mats Not that it couldn't be done with side data packets, though. If it doesn't support side data then the muxers are plain broken. The muxers should support side data, I agree on that. The thing is the packets come in to the AVI, QuickTime and nut muxers with the palette data appended to the video data in the packets. That's a choice Michael have made, I think. Possibly someone else, I don't know. Anyway, Michael once told me that he would like to view palettized frames as "self-contained", where the palette is part of the video data in an atomic way. If the nut muxer stores palette by appending it to the frames, then the demuxer should split it out into side data. Note that I am absolutely not a fan of this side data stuff, but since we already decided to do it like that then that's the way we need to go, not randomly doing one way in one place and differently in another, that just makes for unusable API. I agree on that. I'm a bit confused myself about the differing ways of storing the palette... 2) There are file formats that store it that way and we cannot easily split it into side data. Not sure that can really happen. nut stores the palette in every frame in the file, in its current shape. Anyway, things work OK right now, and even if the situation is slightly confusing, it's probably not a good idea to start messing around with things until a clearly defined way of storing the palette for the muxers and demuxers has been presented. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On Sat, Feb 27, 2016 at 04:15:10PM +0100, Mats Peterson wrote: > On 02/27/2016 04:13 PM, Mats Peterson wrote: > >On 02/27/2016 04:08 PM, Mats Peterson wrote: > >>On 02/27/2016 04:07 PM, Mats Peterson wrote: > >>>On 02/27/2016 04:00 PM, Reimar Döffinger wrote: > On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote: > >On 02/27/2016 03:37 PM, Mats Peterson wrote: > >> > >> > >> > >>___ > >>ffmpeg-devel mailing list > >>ffmpeg-devel@ffmpeg.org > >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > > > >I suppose this is what you mean, Reimar. Treating the palette, if a > >packet > >contains one at the end of the video data, as being AVPALETTE_SIZE > >bytes > >exclusively. > > Well, actually not really. > If the palette is part of input frame it should be sent as side > data. > I am not sure where this variant comes from. > It might be that it should just be written as is. > Or even if the palette needs to be split it might be > necessary to auto-detect the palette size via > packet size - (width*height*bits per pixel)/8. > But as said, I am fairly unclear on what case that > code is supposed to handle. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > >>> > >>>I agree that it should be stored in a side data packet myself normally, > >>>and that this is a somewhat weird construction. It probably has to do > >>>with the nut format originally, which stores raw palettized data after > >>>the video data in the packets. Anyway, I have accepted the facts. For > >>>the record, the new ff_reshuffle_raw_rgb() function written by Michael > >>>in lavf/rawutils.c that aligns strides properly for AVI and QuickTime, > >>>will set a CONTAINS_PAL flag if the packet size is larger than the > >>>actual video data. He has hardcoded the palette size to 1024 bytes in > >>>that file. > >>> > >>>Mats > >>> > >> > >>The nut format stores the PALETTE after the video data in the packets, > >>nothing else :) > >> > > > >In any case, on muxing, the packets will have the palette after the > >video data in the packets, whether it's AVI or QuickTime. Neither > >avienc.c or movenc.c uses any side data packets for the palette. > > > >Michael's intention has been to enable palette switching in the middle > >of the stream, hence storage of the palette in each packet, and AVI > >supports it by using the 'xxpc' chunks in the video data. It is also > >implemented by now. > > > >Mats > > > > Not that it couldn't be done with side data packets, though. If it doesn't support side data then the muxers are plain broken. If the nut muxer stores palette by appending it to the frames, then the demuxer should split it out into side data. Note that I am absolutely not a fan of this side data stuff, but since we already decided to do it like that then that's the way we need to go, not randomly doing one way in one place and differently in another, that just makes for unusable API. The only reasons to support "palette appended to data" are 1) There are some existing users of the FFmpeg API that rely on it. Ideally we should then change it so it works for all muxers, or the other way round warn that this is a deprecated way of doing things. 2) There are file formats that store it that way and we cannot easily split it into side data. Not sure that can really happen. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavc: add h264 mediacodec decoder
On Fri, Feb 26, 2016 at 04:54:47PM +0100, Matthieu Bouron wrote: > On Tue, Feb 23, 2016 at 11:28:01AM +0100, wm4 wrote: > > On Tue, 23 Feb 2016 09:53:43 +0100 > > Matthieu Bouron wrote: > > > > > On Mon, Feb 22, 2016 at 01:08:49PM +0100, Michael Niedermayer wrote: > > > > On Mon, Feb 22, 2016 at 12:20:36PM +0100, Matthieu Bouron wrote: > > > > > From: Matthieu Bouron > > > > [...] > > > > > +codec = (*env)->NewObject(env, > > > > > jfields.mediacodec_list_class, jfields.init_id, 0); > > > > > +if (!codec) { > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not create media codec > > > > > list\n"); > > > > > +goto done; > > > > > +} > > > > > + > > > > > +tmp = (*env)->CallObjectMethod(env, codec, > > > > > jfields.find_decoder_for_format_id, format); > > > > > +if (!tmp) { > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not find decoder in > > > > > media codec list\n"); > > > > > +goto done; > > > > > +} > > > > > + > > > > > +name = ff_jni_jstring_to_utf_chars(env, tmp, NULL); > > > > > +if (!name) { > > > > > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not convert jstring to > > > > > utf chars\n"); > > > > > > > > some non NULL context would be better, if possible, so the user knows > > > > where an error came from > > > > > > It would require to pass the log_ctx (avctx) as an argument of > > > ff_AMediaCodecList_getCodecByName. > > > > > > All the functions of this wrapper does not take a log_ctx as argument > > > to be as close as possible to the original NDK MediaCodec API. The > > > NDK MediaCodec API does not provide any wrapper around MediaCodecList. > > > > > > I would like the whole wrapper API to be consistent but also as close as > > > possible to original one. > > > If you think it's mandatory I can add a log_ctx argument to every > > > functions of the wrapper API (so it will be used directly by av_log and > > > ff_jni_exception_check). > > > > > > On another note, I fixed locally this part of the code by adding missing > > > calls > > > to ff_jni_exception_check. > > > > > > [...] > > > > Is it possible to store the log_ctx somewhere in the JNI? > > > > We might at some point in the future forbid av_log(NULL, ...) calls, and > > then it'd get complicated. > > Patch updated with the following differences: > * All logging arguments in mediacodec_wrapper functions are now non > NULL > * The mediacodec buffer copy functions has been moved to a separate file > * The Mediacodec enum codec flags are properly retrieved from JNI > > The codec extradata conversion to annex b simplification has not been > addressed in this update. The bitstream filter api does not seem to > provide a way to do the extradata conversion without feeding an actual > packet to the api (av_bitstream_filter_filter) and i would like to keep > the codec initialization in the init function. > > The patchset has been pushed to a new branch: > https://github.com/mbouron/FFmpeg/tree/feature/mediacodec-support-v3 > > Matthieu > configure |5 > libavcodec/Makefile |3 > libavcodec/allcodecs.c|1 > libavcodec/mediacodec_sw_buffer.c | 339 +++ > libavcodec/mediacodec_sw_buffer.h | 62 + > libavcodec/mediacodec_wrapper.c | 1674 > ++ > libavcodec/mediacodec_wrapper.h | 122 ++ > libavcodec/mediacodecdec.c| 563 > libavcodec/mediacodecdec.h| 82 + > libavcodec/mediacodecdec_h264.c | 356 > 10 files changed, 3207 insertions(+) > f545068afece74d27cc04a365d9de7dcf5586a7d > 0002-lavc-add-h264-mediacodec-decoder.patch > From 805c7b95433f1bfbbc5d47fd59a1bbb755edb112 Mon Sep 17 00:00:00 2001 > From: Matthieu Bouron > Date: Thu, 21 Jan 2016 09:29:39 +0100 > Subject: [PATCH 2/2] lavc: add h264 mediacodec decoder breaks fate swr-resample_lin-fltp-48000-44100 TESTswr-resample_lin-dblp-8000-44100 TESTswr-resample_lin-dblp-8000-48000 --- ./tests/ref/fate/source 2016-02-24 22:42:26.379879152 +0100 +++ tests/data/fate/source 2016-02-27 14:44:09.176735216 +0100 @@ -27,3 +27,4 @@ compat/avisynth/windowsPorts/windows2linux.h compat/float/float.h compat/float/limits.h +libavcodec/mediacodec_sw_buffer.h Test source failed. Look at tests/data/fate/source.err for details. make: *** [fate-source] Error 1 make: *** Waiting for unfinished jobs [...] -- 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/ff
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 04:13 PM, Mats Peterson wrote: On 02/27/2016 04:08 PM, Mats Peterson wrote: On 02/27/2016 04:07 PM, Mats Peterson wrote: On 02/27/2016 04:00 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote: On 02/27/2016 03:37 PM, Mats Peterson wrote: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I suppose this is what you mean, Reimar. Treating the palette, if a packet contains one at the end of the video data, as being AVPALETTE_SIZE bytes exclusively. Well, actually not really. If the palette is part of input frame it should be sent as side data. I am not sure where this variant comes from. It might be that it should just be written as is. Or even if the palette needs to be split it might be necessary to auto-detect the palette size via packet size - (width*height*bits per pixel)/8. But as said, I am fairly unclear on what case that code is supposed to handle. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I agree that it should be stored in a side data packet myself normally, and that this is a somewhat weird construction. It probably has to do with the nut format originally, which stores raw palettized data after the video data in the packets. Anyway, I have accepted the facts. For the record, the new ff_reshuffle_raw_rgb() function written by Michael in lavf/rawutils.c that aligns strides properly for AVI and QuickTime, will set a CONTAINS_PAL flag if the packet size is larger than the actual video data. He has hardcoded the palette size to 1024 bytes in that file. Mats The nut format stores the PALETTE after the video data in the packets, nothing else :) In any case, on muxing, the packets will have the palette after the video data in the packets, whether it's AVI or QuickTime. Neither avienc.c or movenc.c uses any side data packets for the palette. Michael's intention has been to enable palette switching in the middle of the stream, hence storage of the palette in each packet, and AVI supports it by using the 'xxpc' chunks in the video data. It is also implemented by now. Mats Not that it couldn't be done with side data packets, though. -- 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 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 04:08 PM, Mats Peterson wrote: On 02/27/2016 04:07 PM, Mats Peterson wrote: On 02/27/2016 04:00 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote: On 02/27/2016 03:37 PM, Mats Peterson wrote: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I suppose this is what you mean, Reimar. Treating the palette, if a packet contains one at the end of the video data, as being AVPALETTE_SIZE bytes exclusively. Well, actually not really. If the palette is part of input frame it should be sent as side data. I am not sure where this variant comes from. It might be that it should just be written as is. Or even if the palette needs to be split it might be necessary to auto-detect the palette size via packet size - (width*height*bits per pixel)/8. But as said, I am fairly unclear on what case that code is supposed to handle. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I agree that it should be stored in a side data packet myself normally, and that this is a somewhat weird construction. It probably has to do with the nut format originally, which stores raw palettized data after the video data in the packets. Anyway, I have accepted the facts. For the record, the new ff_reshuffle_raw_rgb() function written by Michael in lavf/rawutils.c that aligns strides properly for AVI and QuickTime, will set a CONTAINS_PAL flag if the packet size is larger than the actual video data. He has hardcoded the palette size to 1024 bytes in that file. Mats The nut format stores the PALETTE after the video data in the packets, nothing else :) In any case, on muxing, the packets will have the palette after the video data in the packets, whether it's AVI or QuickTime. Neither avienc.c or movenc.c uses any side data packets for the palette. Michael's intention has been to enable palette switching in the middle of the stream, hence storage of the palette in each packet, and AVI supports it by using the 'xxpc' chunks in the video data. It is also implemented by now. 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 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 04:07 PM, Mats Peterson wrote: On 02/27/2016 04:00 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote: On 02/27/2016 03:37 PM, Mats Peterson wrote: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I suppose this is what you mean, Reimar. Treating the palette, if a packet contains one at the end of the video data, as being AVPALETTE_SIZE bytes exclusively. Well, actually not really. If the palette is part of input frame it should be sent as side data. I am not sure where this variant comes from. It might be that it should just be written as is. Or even if the palette needs to be split it might be necessary to auto-detect the palette size via packet size - (width*height*bits per pixel)/8. But as said, I am fairly unclear on what case that code is supposed to handle. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I agree that it should be stored in a side data packet myself normally, and that this is a somewhat weird construction. It probably has to do with the nut format originally, which stores raw palettized data after the video data in the packets. Anyway, I have accepted the facts. For the record, the new ff_reshuffle_raw_rgb() function written by Michael in lavf/rawutils.c that aligns strides properly for AVI and QuickTime, will set a CONTAINS_PAL flag if the packet size is larger than the actual video data. He has hardcoded the palette size to 1024 bytes in that file. Mats The nut format stores the PALETTE after the video data in the packets, nothing else :) -- 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 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 04:00 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote: On 02/27/2016 03:37 PM, Mats Peterson wrote: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I suppose this is what you mean, Reimar. Treating the palette, if a packet contains one at the end of the video data, as being AVPALETTE_SIZE bytes exclusively. Well, actually not really. If the palette is part of input frame it should be sent as side data. I am not sure where this variant comes from. It might be that it should just be written as is. Or even if the palette needs to be split it might be necessary to auto-detect the palette size via packet size - (width*height*bits per pixel)/8. But as said, I am fairly unclear on what case that code is supposed to handle. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I agree that it should be stored in a side data packet myself normally, and that this is a somewhat weird construction. It probably has to do with the nut format originally, which stores raw palettized data after the video data in the packets. Anyway, I have accepted the facts. For the record, the new ff_reshuffle_raw_rgb() function written by Michael in lavf/rawutils.c that aligns strides properly for AVI and QuickTime, will set a CONTAINS_PAL flag if the packet size is larger than the actual video data. He has hardcoded the palette size to 1024 bytes in that file. 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 1/2] lavf/avienc: Simplify palette handling
On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote: > On 02/27/2016 03:37 PM, Mats Peterson wrote: > > > > > > > >___ > >ffmpeg-devel mailing list > >ffmpeg-devel@ffmpeg.org > >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > I suppose this is what you mean, Reimar. Treating the palette, if a packet > contains one at the end of the video data, as being AVPALETTE_SIZE bytes > exclusively. Well, actually not really. If the palette is part of input frame it should be sent as side data. I am not sure where this variant comes from. It might be that it should just be written as is. Or even if the palette needs to be split it might be necessary to auto-detect the palette size via packet size - (width*height*bits per pixel)/8. But as said, I am fairly unclear on what case that code is supposed to handle. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
On 02/27/2016 03:37 PM, Mats Peterson wrote: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I suppose this is what you mean, Reimar. Treating the palette, if a packet contains one at the end of the video data, as being AVPALETTE_SIZE bytes exclusively. 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 2/2] lavf/movenc: Simplify palette handling
-- Mats Peterson http://matsp888.no-ip.org/~mats/ >From eec3d4bb49d0ac4b73a10f8436d517a130999892 Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sat, 27 Feb 2016 15:31:35 +0100 Subject: [PATCH 2/2] lavf/movenc: Simplify palette handling --- libavformat/movenc.c |9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index e0223b2..bf9e1e0 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -1718,11 +1718,12 @@ static int mov_write_video_tag(AVIOContext *pb, MOVMuxContext *mov, MOVTrack *tr if (track->is_unaligned_qt_rgb && track->enc->pix_fmt == AV_PIX_FMT_PAL8) { int i; +int pal_size = 1 << track->enc->bits_per_coded_sample; avio_wb16(pb, 0); /* Color table ID */ avio_wb32(pb, 0); /* Color table seed */ avio_wb16(pb, 0x8000);/* Color table flags */ -avio_wb16(pb, 255); /* Color table size (zero-relative) */ -for (i = 0; i < 256; i++) { +avio_wb16(pb, pal_size - 1); /* Color table size (zero-relative) */ +for (i = 0; i < pal_size; i++) { uint32_t rgb = AV_RL32(&track->palette[i]); uint16_t r = (rgb >> 16) & 0xff; uint16_t g = (rgb >> 8) & 0xff; @@ -4769,9 +4770,7 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt) if (ret < 0) return ret; if (ret == CONTAINS_PAL && !trk->pal_done) { -int pal_size = 1 << trk->enc->bits_per_coded_sample; -memset(trk->palette, 0, AVPALETTE_SIZE); -memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size); +memcpy(trk->palette, data + size - AVPALETTE_SIZE, AVPALETTE_SIZE); trk->pal_done++; } else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 || trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) { -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling
-- Mats Peterson http://matsp888.no-ip.org/~mats/ >From 309ee0932eda48b340f2da9f2bc9ac3ea667edf9 Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sat, 27 Feb 2016 15:31:08 +0100 Subject: [PATCH 1/2] lavf/avienc: Simplify palette handling --- libavformat/avienc.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/avienc.c b/libavformat/avienc.c index ca505f4..b133bee 100644 --- a/libavformat/avienc.c +++ b/libavformat/avienc.c @@ -683,7 +683,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt) 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 = AV_RL32(data + size - AVPALETTE_SIZE + 4*i); avio_wl32(pb, v & 0xff); } avio_seek(pb, cur_offset, SEEK_SET); @@ -696,7 +696,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt) avio_w8(pb, pal_size & 0xFF); avio_wl16(pb, 0); // reserved for (i = 0; i < pal_size; i++) { -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i); +uint32_t v = AV_RL32(data + size - AVPALETTE_SIZE + 4*i); avio_wb32(pb, v<<8); } ff_end_tag(pb, pc_tag); -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof
On 02/27/2016 03:11 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 02:58:39PM +0100, Mats Peterson wrote: And yes, QuickTime has a "default palette" for each bit depth that it can use, and no palette will be stored in the video sample description in that case. But that's only sensible to use for 1 bpp black & white or 8 bpp grayscale (and that's what I'm doing in movenc.c), since in other cases comparing each color of the current palette with the default Macintosh palette is a bit of overkill in my book. It's 256 comparisons to save 1 kB. It's not a big deal, but it seems like fairly cheap optimization to do. ___ Perhaps so. But it's no big deal to include the palette either, I think. 1 kb isn't a humonguous amount nowadays. To each his own, of course :) Most of the time the palette won't be the default Macintosh palette either, when converting from AVI or from other sources and pixel formats. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof
On Sat, Feb 27, 2016 at 02:58:39PM +0100, Mats Peterson wrote: > And yes, QuickTime has a "default palette" for each bit depth that it can > use, and no palette will be stored in the video sample description in that > case. But that's only sensible to use for 1 bpp black & white or 8 bpp > grayscale (and that's what I'm doing in movenc.c), since in other cases > comparing each color of the current palette with the default Macintosh > palette is a bit of overkill in my book. It's 256 comparisons to save 1 kB. It's not a big deal, but it seems like fairly cheap optimization to do. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof
On 02/27/2016 02:55 PM, Mats Peterson wrote: On 02/27/2016 02:44 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 02:35:36PM +0100, Mats Peterson wrote: On 02/27/2016 02:03 PM, Mats Peterson wrote: Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8. In case there will be other palettized formats in the future, I have "guarded" myself by using 1 << bits_per_coded_sample in avienc.c and movenc.c for calculating the number of palette entries in packets containing a palette at the end, rather than just assuming 256 entries. If we can agree on using this 1 << bits_per_coded_sample logic overall for packets containing a palette, in the same way as it is done in AVI and QuickTime, here's a patch of ff_reshuffle_raw_rgb() that makes it somewhat more future-proof. On the other hand, perhaps we should leave the palette in the packets fixed at 256 entries (1024 bytes), since it's somewhat irrelevant whether this "internal" palette contains 256 or less entries. It's when writing the files that the number of palette entries becomes important. That is the intention. How many palette entries are saved in the format is up to the format (many QT formats for example don't save one at all but instead refer to standard ones if possible). Also there would be a (minor) advantage if shorter palettes were required to be repeated in those 256 byte entries. It would save on bit masking when expanding to a non-paletted format. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Yes, Reimar. I suppose that's the intent, and we agree on the file format determining the number of entries that will be written to the file for each bit depth. Mats And yes, QuickTime has a "default palette" for each bit depth that it can use, and no palette will be stored in the video sample description in that case. But that's only sensible to use for 1 bpp black & white or 8 bpp grayscale (and that's what I'm doing in movenc.c), since in other cases comparing each color of the current palette with the default Macintosh palette is a bit of overkill in my book. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof
On 02/27/2016 02:44 PM, Reimar Döffinger wrote: On Sat, Feb 27, 2016 at 02:35:36PM +0100, Mats Peterson wrote: On 02/27/2016 02:03 PM, Mats Peterson wrote: Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8. In case there will be other palettized formats in the future, I have "guarded" myself by using 1 << bits_per_coded_sample in avienc.c and movenc.c for calculating the number of palette entries in packets containing a palette at the end, rather than just assuming 256 entries. If we can agree on using this 1 << bits_per_coded_sample logic overall for packets containing a palette, in the same way as it is done in AVI and QuickTime, here's a patch of ff_reshuffle_raw_rgb() that makes it somewhat more future-proof. On the other hand, perhaps we should leave the palette in the packets fixed at 256 entries (1024 bytes), since it's somewhat irrelevant whether this "internal" palette contains 256 or less entries. It's when writing the files that the number of palette entries becomes important. That is the intention. How many palette entries are saved in the format is up to the format (many QT formats for example don't save one at all but instead refer to standard ones if possible). Also there would be a (minor) advantage if shorter palettes were required to be repeated in those 256 byte entries. It would save on bit masking when expanding to a non-paletted format. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Yes, Reimar. I suppose that's the intent, and we agree on the file format determining the number of entries that will be written to the file for each bit depth. 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 1/3] lavu/attributes: introduce av_likely, av_unlikely
Hi, On Sat, Feb 27, 2016 at 8:11 AM, Ganesh Ajjanagadde wrote: > On Thu, Feb 25, 2016 at 8:55 AM, Hendrik Leppkes > wrote: > > On Thu, Feb 25, 2016 at 8:27 AM, wm4 wrote: > >> On Thu, 25 Feb 2016 15:48:17 +1100 > >> Matt Oliver wrote: > >> > >>> On 25 February 2016 at 13:20, Ganesh Ajjanagadde > wrote: > >>> > >>> > From: Ganesh Ajjanagadde > >>> > > >>> > These use __builtin_expect, and may be useful for optimizing nearly > >>> > certain branches, to yield size and/or speed improvements. > >>> > > >>> > Note that this is used in the Linux kernel for the same purpose. For > >>> > some idea as to potential benefits, see e.g > >>> > > http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html. > >>> > > >>> > Signed-off-by: Ganesh Ajjanagadde > >>> > --- > >>> > libavutil/attributes.h | 8 > >>> > 1 file changed, 8 insertions(+) > >>> > > >>> > diff --git a/libavutil/attributes.h b/libavutil/attributes.h > >>> > index 5c6b9de..1547033 100644 > >>> > --- a/libavutil/attributes.h > >>> > +++ b/libavutil/attributes.h > >>> > @@ -58,6 +58,14 @@ > >>> > #define av_warn_unused_result > >>> > #endif > >>> > > >>> > +#if AV_GCC_VERSION_AT_LEAST(3,0) > >>> > +#define av_likely(x) __builtin_expect(!!(x), 1) > >>> > +#define av_unlikely(x) __builtin_expect(!!(x), 0) > >>> > +#else > >>> > +#define av_likely(x) (x) > >>> > +#define av_unlikely(x) (x) > >>> > +#endif > >>> > + > >>> > #if AV_GCC_VERSION_AT_LEAST(3,1) > >>> > #define av_noinline __attribute__((noinline)) > >>> > #elif defined(_MSC_VER) > >>> > > >>> > >>> Ive used these builtins before and can confirm that they are useful > >>> (although requires devs to use them obviously). I will also point out > that > >>> these are also supported by ICC/ICL as well. > >> > >> They also make code ugly as fuck, and are more cargo-cult than anything > >> else. They might possibly be ok in some very critical parts of the > >> code, but otherwise not at all. > >> > > > > I agree with wm4 on the ugly aspect, I always hate reading code from > > projects that use it, its terrible on readability. > > If its used at all, it should be proven that (a) the function is > > performance relevant, and (b) that the improvement is actually > > tangible in the grand scheme. > > I mostly agree with the sentiments. Patchset shelved until a > non-trivial, critical use case can be found. I can think of a few. E.g. buffer overflow protection in bitstream reader (get_bits.h), maybe the arith readers (vp56.h, cabac.h) could also use these. These codepaths are actually quite performance sensitive and I'm not sure they're all running hand-coded assembly. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof
On Sat, Feb 27, 2016 at 02:35:36PM +0100, Mats Peterson wrote: > On 02/27/2016 02:03 PM, Mats Peterson wrote: > >Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8. > >In case there will be other palettized formats in the future, I have > >"guarded" myself by using 1 << bits_per_coded_sample in avienc.c and > >movenc.c for calculating the number of palette entries in packets > >containing a palette at the end, rather than just assuming 256 entries. > > > >If we can agree on using this 1 << bits_per_coded_sample logic overall > >for packets containing a palette, in the same way as it is done in AVI > >and QuickTime, here's a patch of ff_reshuffle_raw_rgb() that makes it > >somewhat more future-proof. > > On the other hand, perhaps we should leave the palette in the packets fixed > at 256 entries (1024 bytes), since it's somewhat irrelevant whether this > "internal" palette contains 256 or less entries. It's when writing the files > that the number of palette entries becomes important. That is the intention. How many palette entries are saved in the format is up to the format (many QT formats for example don't save one at all but instead refer to standard ones if possible). Also there would be a (minor) advantage if shorter palettes were required to be repeated in those 256 byte entries. It would save on bit masking when expanding to a non-paletted format. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavu/rational: add more info regarding floor(x+0.5) usage
On Thu, Feb 25, 2016 at 8:56 AM, Derek Buitenhuis wrote: > On 2/25/2016 2:20 AM, Ganesh Ajjanagadde wrote: >> -// (int64_t)rint() and llrint() do not work with gcc on ia64 and sparc64 >> +// (int64_t)rint() and llrint() do not work with gcc on ia64 and >> sparc64, >> +// see Ticket2713 for affected gcc/glibc versions > > I've never seen this comment before, but it makes me wonder: how the heck do > these > functions work in the rest of the codebase? I can only speculate here. They may not work in the rest of the codebase, but here they cause FATE regressions as per the ticket. For example, an incorrect llrint in the middle of some computation, although inconvenient, may not lead to wrong output as measured by FATE. For example, git grep -n 'llrint' (or '<\rint') don't yield many interesting hits. As for why these platforms have incorrect llrint, note on x86 it is trivial to write llrint; it just uses cvttsd2si (or some instruction like that). Maybe on sparc there is no equivalent opcode, forcing software emulation that is not trivial. BTW, if you think the above speculation is reasonable and useful, I can amend the comment (or perhaps better the patch notes) accordingly. > > - 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] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof
On 02/27/2016 02:03 PM, Mats Peterson wrote: Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8. In case there will be other palettized formats in the future, I have "guarded" myself by using 1 << bits_per_coded_sample in avienc.c and movenc.c for calculating the number of palette entries in packets containing a palette at the end, rather than just assuming 256 entries. If we can agree on using this 1 << bits_per_coded_sample logic overall for packets containing a palette, in the same way as it is done in AVI and QuickTime, here's a patch of ff_reshuffle_raw_rgb() that makes it somewhat more future-proof. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel On the other hand, perhaps we should leave the palette in the packets fixed at 256 entries (1024 bytes), since it's somewhat irrelevant whether this "internal" palette contains 256 or less entries. It's when writing the files that the number of palette entries becomes important. 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 2/3] lavu/rational: use av_unlikely in av_d2q
On Thu, Feb 25, 2016 at 7:25 AM, Nicolas George wrote: > Le sextidi 6 ventôse, an CCXXIV, Ganesh Ajjanagadde a écrit : >> Actual performance benefit is impossible to accurately quantify due to the >> context-dependence of the branch predictor. Nonetheless, as a ballpark >> estimate, it yields ~ 5% improvements in testing via FATE on x86-64, >> Haswell+GCC. > > Five percent is huge, if it is five percent of something relevant. Can you > give a few more details? Ok, here are the benches I obtained, make fate lavf-ffm, START/STOP around body of av_d2q. Platform: Haswell+GCC under -march=native. Naive stream_loop does not increase the iteration count unfortunately. As for av_d2q's relevance, max call count on any FATE test is 16 or 32 IIRC. old: 74040 decicycles in av_d2q, 1 runs, 0 skips 39480 decicycles in av_d2q, 2 runs, 0 skips 21385 decicycles in av_d2q, 4 runs, 0 skips [...] 13235 decicycles in av_d2q, 8 runs, 0 skips [...] 7571 decicycles in av_d2q, 16 runs, 0 skips new: 68660 decicycles in av_d2q, 1 runs, 0 skips 36410 decicycles in av_d2q, 2 runs, 0 skips 19815 decicycles in av_d2q, 4 runs, 0 skips [...] 12355 decicycles in av_d2q, 8 runs, 0 skips [...] 7080 decicycles in av_d2q, 16 runs, 0 skips > > Regards, > > -- > Nicolas George > > ___ > 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 1/3] lavu/attributes: introduce av_likely, av_unlikely
On Thu, Feb 25, 2016 at 8:55 AM, Hendrik Leppkes wrote: > On Thu, Feb 25, 2016 at 8:27 AM, wm4 wrote: >> On Thu, 25 Feb 2016 15:48:17 +1100 >> Matt Oliver wrote: >> >>> On 25 February 2016 at 13:20, Ganesh Ajjanagadde wrote: >>> >>> > From: Ganesh Ajjanagadde >>> > >>> > These use __builtin_expect, and may be useful for optimizing nearly >>> > certain branches, to yield size and/or speed improvements. >>> > >>> > Note that this is used in the Linux kernel for the same purpose. For >>> > some idea as to potential benefits, see e.g >>> > http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html. >>> > >>> > Signed-off-by: Ganesh Ajjanagadde >>> > --- >>> > libavutil/attributes.h | 8 >>> > 1 file changed, 8 insertions(+) >>> > >>> > diff --git a/libavutil/attributes.h b/libavutil/attributes.h >>> > index 5c6b9de..1547033 100644 >>> > --- a/libavutil/attributes.h >>> > +++ b/libavutil/attributes.h >>> > @@ -58,6 +58,14 @@ >>> > #define av_warn_unused_result >>> > #endif >>> > >>> > +#if AV_GCC_VERSION_AT_LEAST(3,0) >>> > +#define av_likely(x) __builtin_expect(!!(x), 1) >>> > +#define av_unlikely(x) __builtin_expect(!!(x), 0) >>> > +#else >>> > +#define av_likely(x) (x) >>> > +#define av_unlikely(x) (x) >>> > +#endif >>> > + >>> > #if AV_GCC_VERSION_AT_LEAST(3,1) >>> > #define av_noinline __attribute__((noinline)) >>> > #elif defined(_MSC_VER) >>> > >>> >>> Ive used these builtins before and can confirm that they are useful >>> (although requires devs to use them obviously). I will also point out that >>> these are also supported by ICC/ICL as well. >> >> They also make code ugly as fuck, and are more cargo-cult than anything >> else. They might possibly be ok in some very critical parts of the >> code, but otherwise not at all. >> > > I agree with wm4 on the ugly aspect, I always hate reading code from > projects that use it, its terrible on readability. > If its used at all, it should be proven that (a) the function is > performance relevant, and (b) that the improvement is actually > tangible in the grand scheme. I mostly agree with the sentiments. Patchset shelved until a non-trivial, critical use case can be found. @Matt: feel free to extend to ICC if/when this happens; I lack it and can't test. Thanks all. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof
Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8. In case there will be other palettized formats in the future, I have "guarded" myself by using 1 << bits_per_coded_sample in avienc.c and movenc.c for calculating the number of palette entries in packets containing a palette at the end, rather than just assuming 256 entries. If we can agree on using this 1 << bits_per_coded_sample logic overall for packets containing a palette, in the same way as it is done in AVI and QuickTime, here's a patch of ff_reshuffle_raw_rgb() that makes it somewhat more future-proof. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From 4d755a3167450f161a13fe4c6a9f74eacf5f1180 Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sat, 27 Feb 2016 14:02:34 +0100 Subject: [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof --- libavformat/rawutils.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/rawutils.c b/libavformat/rawutils.c index 26ebbb5..1424152 100644 --- a/libavformat/rawutils.c +++ b/libavformat/rawutils.c @@ -28,8 +28,8 @@ int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket **ppkt, AVCodecContext *en AVPacket *pkt = *ppkt; int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16; int min_stride = (enc->width * bpc + 7) >> 3; -int with_pal_size = min_stride * enc->height + 1024; -int contains_pal = bpc == 8 && pkt->size == with_pal_size; +int with_pal_size = min_stride * enc->height + (1 << bpc) * 4; +int contains_pal = bpc >= 1 && bpc <= 8 && pkt->size == with_pal_size; int size = contains_pal ? min_stride * enc->height : pkt->size; int stride = size / enc->height; int padding = expected_stride - FFMIN(expected_stride, stride); -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.
On Sat, 27 Feb 2016 13:01:40 +0100 Reimar Döffinger wrote: > Check that the required plane pointers and only > those are set up. > Currently does not enforce anything for the palette > pointer of pseudopal formats as I am unsure about the > requirements. > > Signed-off-by: Reimar Döffinger > --- > doc/APIchanges | 6 ++ > libavcodec/utils.c | 27 +++ > libavcodec/version.h | 2 +- > libavutil/frame.h| 3 +++ > 4 files changed, 37 insertions(+), 1 deletion(-) > > diff --git a/doc/APIchanges b/doc/APIchanges > index 4e952a8..ee407da 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -15,6 +15,12 @@ libavutil: 2015-08-28 > > API changes, most recent first: > > +2016-02-xx - xxx - lavc 57.25.101 > + Validate AVFrame returned by get_buffer2 to have required > + planes not NULL and unused planes set to NULL as crashes > + and buffer overflow are possible with certain streams if > + that is not the case. > + > 2016-xx-xx - lavc 57.25.0 - avcodec.h >Add AVCodecContext.hw_frames_ctx. > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c > index af21cdd..1967f03 100644 > --- a/libavcodec/utils.c > +++ b/libavcodec/utils.c > @@ -853,6 +853,31 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame > *frame) > return ff_init_buffer_info(avctx, frame); > } > > +static void validate_avframe_allocation(AVCodecContext *avctx, AVFrame > *frame) > +{ > +if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) { > +int i; > +int num_planes = av_pix_fmt_count_planes(frame->format); > +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format); > +int flags = desc ? desc->flags : 0; > +if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PAL)) > +num_planes = 2; > +for (i = 0; i < num_planes; i++) { > +av_assert0(frame->data[i]); > +} > +// TODO: what are the exact requirements on pseudopal formats for > get_buffer2? > +if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PSEUDOPAL)) > +num_planes = 2; This should be correct. Not allocating a palette for unpaletted but "pseudopal" formats can cause random crashes, as all code within FFmpeg seems to assume that the palette has been allocated. (An utter abomination, if you ask me.) At the same time, pixdesc will indicate that paletted formats have only 1 plane, but 2 data pointers. > +// for formats without data like hwaccel allow > +// pointers to be non-NULL. > +for (i = num_planes; num_planes > 0 && i < > FF_ARRAY_ELEMS(frame->data); i++) { > +if (frame->data[i]) > +av_log(avctx, AV_LOG_ERROR, "Buffer returned by > get_buffer2() did not zero unused plane pointers\n"); > +frame->data[i] = NULL; > +} > +} > +} > + > static int get_buffer_internal(AVCodecContext *avctx, AVFrame *frame, int > flags) > { > const AVHWAccel *hwaccel = avctx->hwaccel; > @@ -885,6 +910,8 @@ static int get_buffer_internal(AVCodecContext *avctx, > AVFrame *frame, int flags) > avctx->sw_pix_fmt = avctx->pix_fmt; > > ret = avctx->get_buffer2(avctx, frame, flags); > +if (ret >= 0) > +validate_avframe_allocation(avctx, frame); > > end: > if (avctx->codec_type == AVMEDIA_TYPE_VIDEO && !override_dimensions) { > diff --git a/libavcodec/version.h b/libavcodec/version.h > index 0856b19..c937eaf 100644 > --- a/libavcodec/version.h > +++ b/libavcodec/version.h > @@ -29,7 +29,7 @@ > > #define LIBAVCODEC_VERSION_MAJOR 57 > #define LIBAVCODEC_VERSION_MINOR 25 > -#define LIBAVCODEC_VERSION_MICRO 101 > +#define LIBAVCODEC_VERSION_MICRO 102 > > #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \ > LIBAVCODEC_VERSION_MINOR, \ > diff --git a/libavutil/frame.h b/libavutil/frame.h > index 56001a8..76a8123 100644 > --- a/libavutil/frame.h > +++ b/libavutil/frame.h > @@ -187,6 +187,9 @@ typedef struct AVFrame { > * see avcodec_align_dimensions2(). Some filters and swscale can read > * up to 16 bytes beyond the planes, if these filters are to be used, > * then 16 extra bytes must be allocated. > + * > + * NOTE: Except for hwaccel formats, pointers not needed by the format > + * MUST be set to NULL. > */ > uint8_t *data[AV_NUM_DATA_POINTERS]; > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: Check that the video data[] arrays are NULL on the input to get_buffer_internal()
On Fri, Feb 26, 2016 at 01:07:54PM +0100, Reimar Döffinger wrote: > On Fri, Feb 26, 2016 at 12:59:08PM +0100, Michael Niedermayer wrote: > > This should return an error to the decoder if the struct it tried to > > getbuffer is dirty > > It seems like a good idea, however it likely won't help > for programs providing their own getbuffer2 as they will > probably fill the data[] fields from their own shadow > structures, which this check will not discover. applied patchset thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill hundred thousands of innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/Makefile: dnxhd demuxer depends on dnxhddata.o
On Wed, Feb 24, 2016 at 04:59:51PM -0600, Rodger Combs wrote: > --- > libavcodec/Makefile | 1 + > 1 file changed, 1 insertion(+) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Consulting] Converting an Audio Visualization application to CLI using FFMpeg
On 2016-02-27 04:09, Ryan Schott wrote: > Hello, > > I am not sure if this is the right page to post this, but your consulting > page recommended I use this list. I recent built an audio visualization app > using html5. I'm currently using that app with xsplit to stream music to an > RTMP endpoint on either twitch.tv or YouTube. > > For an example check out: https://youtu.be/Zmb_fy528Uo > > I would like to be able to mimic this functionality on a server without > using window capture and a live browser window. I'm a fan of the > flexibility that my html5 solution gives me, but there's no way to spawn > streams from a CLI. I know I will most likely have to throw out my HTML5 > solution to get the data to something that can run on a command line > without a full browser. > > My dream is that I can somehow stream the audio and video that would be > coming from the browser normally to an input in ffmpeg and then output it > to an RTMP endpoint. If I could get to that point, I could easily build a > controller application with my skillset to allow any number of users to > arbitrarily stream music with visualization from our central server to > their twitch and youtube channels. > > Another use case I have is mass creating visualized mp4's from mp3's. I > currently have a static image script working using ffmpeg to batch create > videos from mp3's, but we'd rather have visualized videos than static image > videos. > > Overall, I'm looking to see if it's feasible to pipe the html5 video and > audio output to an rtmp endpoint without a browser, and if it's not what my > options are to construct visualizations in code without a desktop. If you want exactly what was shown then it can't be done right now. In the mean time you can have a look at some of FFmpeg's existing vis filters here > https://trac.ffmpeg.org/wiki/FancyFilteringExamples#Audio And you can checkout my work-in-progress vis library here > https://gitlab.com/J_Darnley/Advanced-Visualization-Studio Although this library can't t do it either, it does have a very similar spectrograph display, all it needs is a small gap between the bands. Unfortunately I need to update the libavfilter wrapper for recent changes I made. When you have the video you want you can pad the edges and draw the text, both of which can be done right now with ffmpeg. If you want to render the video using your existing HTML5 code then I find it hard to believe that nobody has yet written a headless browser which can write to some sort of output stream, stdout at the very least. 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] Document and validate AVFrame plane pointers.
On Sat, 27 Feb 2016 12:54:50 +0100 Reimar Döffinger wrote: > On Fri, Feb 26, 2016 at 11:41:41PM +0100, wm4 wrote: > > On Fri, 26 Feb 2016 22:59:17 +0100 > > Reimar Döffinger wrote: > > > > Can you move it to a separate function? Say, ff_verify_frame(). This > > > > could get much more complicated too when checking AVBufferRef usage or > > > > audio. > > > > > > Why ff_? If we've decided on it and use it in other places it > > > might become a av_* function in libavutil. > > > But until then I guess it should be a static function in that file? > > > > For now it also might be used in the encoding functions. Don't know how > > far it could go. > > They are in the same file though, so static would still be fine. > However as for encoding those are const AVFrames I think it > is much less of an issue (should only cause overreads, not > writes) and I'm more inclined to not change things that > after all might break someone's (probably quite crappy) code. If you look at avcodec_encode_audio2(), it already contains a huge chunk of code that somehow checks aspects of the AVFrame from the user. Could be unified one day. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.
On Sat, Feb 27, 2016 at 01:01:40PM +0100, Reimar Döffinger wrote: > Check that the required plane pointers and only > those are set up. > Currently does not enforce anything for the palette > pointer of pseudopal formats as I am unsure about the > requirements. > > Signed-off-by: Reimar Döffinger > --- > doc/APIchanges | 6 ++ > libavcodec/utils.c | 27 +++ > libavcodec/version.h | 2 +- > libavutil/frame.h| 3 +++ > 4 files changed, 37 insertions(+), 1 deletion(-) > > diff --git a/doc/APIchanges b/doc/APIchanges > index 4e952a8..ee407da 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -15,6 +15,12 @@ libavutil: 2015-08-28 > > API changes, most recent first: > > +2016-02-xx - xxx - lavc 57.25.101 Fixed locally to say 57.25.102 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.
Check that the required plane pointers and only those are set up. Currently does not enforce anything for the palette pointer of pseudopal formats as I am unsure about the requirements. Signed-off-by: Reimar Döffinger --- doc/APIchanges | 6 ++ libavcodec/utils.c | 27 +++ libavcodec/version.h | 2 +- libavutil/frame.h| 3 +++ 4 files changed, 37 insertions(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index 4e952a8..ee407da 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,6 +15,12 @@ libavutil: 2015-08-28 API changes, most recent first: +2016-02-xx - xxx - lavc 57.25.101 + Validate AVFrame returned by get_buffer2 to have required + planes not NULL and unused planes set to NULL as crashes + and buffer overflow are possible with certain streams if + that is not the case. + 2016-xx-xx - lavc 57.25.0 - avcodec.h Add AVCodecContext.hw_frames_ctx. diff --git a/libavcodec/utils.c b/libavcodec/utils.c index af21cdd..1967f03 100644 --- a/libavcodec/utils.c +++ b/libavcodec/utils.c @@ -853,6 +853,31 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame *frame) return ff_init_buffer_info(avctx, frame); } +static void validate_avframe_allocation(AVCodecContext *avctx, AVFrame *frame) +{ +if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) { +int i; +int num_planes = av_pix_fmt_count_planes(frame->format); +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format); +int flags = desc ? desc->flags : 0; +if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PAL)) +num_planes = 2; +for (i = 0; i < num_planes; i++) { +av_assert0(frame->data[i]); +} +// TODO: what are the exact requirements on pseudopal formats for get_buffer2? +if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PSEUDOPAL)) +num_planes = 2; +// for formats without data like hwaccel allow +// pointers to be non-NULL. +for (i = num_planes; num_planes > 0 && i < FF_ARRAY_ELEMS(frame->data); i++) { +if (frame->data[i]) +av_log(avctx, AV_LOG_ERROR, "Buffer returned by get_buffer2() did not zero unused plane pointers\n"); +frame->data[i] = NULL; +} +} +} + static int get_buffer_internal(AVCodecContext *avctx, AVFrame *frame, int flags) { const AVHWAccel *hwaccel = avctx->hwaccel; @@ -885,6 +910,8 @@ static int get_buffer_internal(AVCodecContext *avctx, AVFrame *frame, int flags) avctx->sw_pix_fmt = avctx->pix_fmt; ret = avctx->get_buffer2(avctx, frame, flags); +if (ret >= 0) +validate_avframe_allocation(avctx, frame); end: if (avctx->codec_type == AVMEDIA_TYPE_VIDEO && !override_dimensions) { diff --git a/libavcodec/version.h b/libavcodec/version.h index 0856b19..c937eaf 100644 --- a/libavcodec/version.h +++ b/libavcodec/version.h @@ -29,7 +29,7 @@ #define LIBAVCODEC_VERSION_MAJOR 57 #define LIBAVCODEC_VERSION_MINOR 25 -#define LIBAVCODEC_VERSION_MICRO 101 +#define LIBAVCODEC_VERSION_MICRO 102 #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \ LIBAVCODEC_VERSION_MINOR, \ diff --git a/libavutil/frame.h b/libavutil/frame.h index 56001a8..76a8123 100644 --- a/libavutil/frame.h +++ b/libavutil/frame.h @@ -187,6 +187,9 @@ typedef struct AVFrame { * see avcodec_align_dimensions2(). Some filters and swscale can read * up to 16 bytes beyond the planes, if these filters are to be used, * then 16 extra bytes must be allocated. + * + * NOTE: Except for hwaccel formats, pointers not needed by the format + * MUST be set to NULL. */ uint8_t *data[AV_NUM_DATA_POINTERS]; -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.
On Fri, Feb 26, 2016 at 11:41:41PM +0100, wm4 wrote: > On Fri, 26 Feb 2016 22:59:17 +0100 > Reimar Döffinger wrote: > > > Can you move it to a separate function? Say, ff_verify_frame(). This > > > could get much more complicated too when checking AVBufferRef usage or > > > audio. > > > > Why ff_? If we've decided on it and use it in other places it > > might become a av_* function in libavutil. > > But until then I guess it should be a static function in that file? > > For now it also might be used in the encoding functions. Don't know how > far it could go. They are in the same file though, so static would still be fine. However as for encoding those are const AVFrames I think it is much less of an issue (should only cause overreads, not writes) and I'm more inclined to not change things that after all might break someone's (probably quite crappy) code. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.
On Sat, Feb 27, 2016 at 02:21:18AM +0100, Michael Niedermayer wrote: > On Fri, Feb 26, 2016 at 11:06:22PM +0100, Reimar Döffinger wrote: > > +static void validate_avframe_allocation(const AVCodecContext *avctx, > > AVFrame *frame) > > +{ > > +if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) { > > +int i; > > +int num_planes = av_pix_fmt_count_planes(frame->format); > > +for (i = 0; i < num_planes; i++) { > > +av_assert0(frame->data[i]); > > +} > > +// for formats without data like hwaccel allow > > +// pointers to be non-NULL. > > > +for (i = num_planes; num_planes > 0 && i < num_planes; i++) { > > are both of i = num_planes and i < num_planes intended ? That uncovered a few more issues. > some note in APIChanges or release notes or something might make sense > too Hm. Forgot about that in latest version. Also, why can't I pass a "const AVCodecContext *" to av_log? That is kind of inconvenient. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.
Check that the required plane pointers and only those are set up. Currently does not enforce anything for the palette pointer of pseudopal formats as I am unsure about the requirements. Signed-off-by: Reimar Döffinger --- libavcodec/utils.c | 27 +++ libavutil/frame.h | 3 +++ 2 files changed, 30 insertions(+) diff --git a/libavcodec/utils.c b/libavcodec/utils.c index af21cdd..1967f03 100644 --- a/libavcodec/utils.c +++ b/libavcodec/utils.c @@ -853,6 +853,31 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame *frame) return ff_init_buffer_info(avctx, frame); } +static void validate_avframe_allocation(AVCodecContext *avctx, AVFrame *frame) +{ +if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) { +int i; +int num_planes = av_pix_fmt_count_planes(frame->format); +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format); +int flags = desc ? desc->flags : 0; +if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PAL)) +num_planes = 2; +for (i = 0; i < num_planes; i++) { +av_assert0(frame->data[i]); +} +// TODO: what are the exact requirements on pseudopal formats for get_buffer2? +if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PSEUDOPAL)) +num_planes = 2; +// for formats without data like hwaccel allow +// pointers to be non-NULL. +for (i = num_planes; num_planes > 0 && i < FF_ARRAY_ELEMS(frame->data); i++) { +if (frame->data[i]) +av_log(avctx, AV_LOG_ERROR, "Buffer returned by get_buffer2() did not zero unused plane pointers\n"); +frame->data[i] = NULL; +} +} +} + static int get_buffer_internal(AVCodecContext *avctx, AVFrame *frame, int flags) { const AVHWAccel *hwaccel = avctx->hwaccel; @@ -885,6 +910,8 @@ static int get_buffer_internal(AVCodecContext *avctx, AVFrame *frame, int flags) avctx->sw_pix_fmt = avctx->pix_fmt; ret = avctx->get_buffer2(avctx, frame, flags); +if (ret >= 0) +validate_avframe_allocation(avctx, frame); end: if (avctx->codec_type == AVMEDIA_TYPE_VIDEO && !override_dimensions) { diff --git a/libavutil/frame.h b/libavutil/frame.h index 56001a8..76a8123 100644 --- a/libavutil/frame.h +++ b/libavutil/frame.h @@ -187,6 +187,9 @@ typedef struct AVFrame { * see avcodec_align_dimensions2(). Some filters and swscale can read * up to 16 bytes beyond the planes, if these filters are to be used, * then 16 extra bytes must be allocated. + * + * NOTE: Except for hwaccel formats, pointers not needed by the format + * MUST be set to NULL. */ uint8_t *data[AV_NUM_DATA_POINTERS]; -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Question about palette size in packets
On 02/27/2016 12:02 PM, Mats Peterson wrote: On 02/27/2016 11:51 AM, Mats Peterson wrote: On 02/27/2016 11:44 AM, Mats Peterson wrote: Michael, I am currently "assuming" that the size of the palette in a packet, if included at the end of the video data, will be 1 << bits_per_coded_sample. You're saying that the size of the packet isn't Should of course be "the size of the palette". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Question about palette size in packets
On 02/27/2016 11:51 AM, Mats Peterson wrote: On 02/27/2016 11:44 AM, Mats Peterson wrote: Michael, I am currently "assuming" that the size of the palette in a packet, if included at the end of the video data, will be 1 << bits_per_coded_sample. You're saying that the size of the packet isn't fixed to 1024 bytes, but currently it seems to be 1024 (256 * 4) bytes exclusively. Will this possibly change in the future? If so, is the "1 << bits per sample" for the palette size that is already assumed decent enough to use as a future "standard"? Mats Instead of having to subtract the video data from the packet size every time, which I'm currently *not* doing, but which of course would be more fool-proof. This is mostly related to the muxer side, when calculating the palette size after returning from ff_reshuffle_raw_rgb(), by the way. 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] Question about palette size in packets
On 02/27/2016 11:44 AM, Mats Peterson wrote: Michael, I am currently "assuming" that the size of the palette in a packet, if included at the end of the video data, will be 1 << bits_per_coded_sample. You're saying that the size of the packet isn't fixed to 1024 bytes, but currently it seems to be 1024 (256 * 4) bytes exclusively. Will this possibly change in the future? If so, is the "1 << bits per sample" for the palette size that is already assumed decent enough to use as a future "standard"? Mats Instead of having to subtract the video data from the packet size every time, which I'm currently *not* doing, but which of course would be more fool-proof. -- 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] Question about palette size in packets
Michael, I am currently "assuming" that the size of the palette in a packet, if included at the end of the video data, will be 1 << bits_per_coded_sample. You're saying that the size of the packet isn't fixed to 1024 bytes, but currently it seems to be 1024 (256 * 4) bytes exclusively. Will this possibly change in the future? If so, is the "1 << bits per sample" for the palette size that is already assumed decent enough to use as a future "standard"? 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 2/2] sws/yuv2rgb: clarify precision of coeff and offset for mmx code
On Sat, Feb 27, 2016 at 01:06:08AM +0100, Michael Niedermayer wrote: > On Fri, Feb 26, 2016 at 10:34:46PM +0100, Clément Bœsch wrote: > > It makes easier looking at the difference with the generic code just > > below. > > --- > > libswscale/yuv2rgb.c | 12 ++-- > > 1 file changed, 6 insertions(+), 6 deletions(-) > > LGTM > > thx > pushed -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] sws/yuv2rgb: avoid a few ub on signed left shifts
On Sat, Feb 27, 2016 at 01:05:35AM +0100, Michael Niedermayer wrote: > On Fri, Feb 26, 2016 at 10:34:45PM +0100, Clément Bœsch wrote: > > --- > > libswscale/yuv2rgb.c | 20 ++-- > > 1 file changed, 10 insertions(+), 10 deletions(-) > > LGTM > > thanks > applied -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel