[libav-devel] [PATCH 2/2] ac3dec: change logging of skipped E-AC-3 substreams.
Change log level from warning to debug: the E-AC-3 "core"
substream can be successfully decoded without the additional
and dependent substreams, and their presence is already
indicated via avpriv_request_sample in ff_eac3_parse_header.
---
libavcodec/ac3dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 97ce287..1161992 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -1347,7 +1347,7 @@ static int ac3_decode_frame(AVCodecContext * avctx, void
*data,
/* skip frame if CRC is ok. otherwise use error concealment. */
/* TODO: add support for substreams and dependent frames */
if (s->frame_type == EAC3_FRAME_TYPE_DEPENDENT || s->substreamid) {
-av_log(avctx, AV_LOG_WARNING, "unsupported frame type : "
+av_log(avctx, AV_LOG_DEBUG, "unsupported frame type : "
"skipping frame\n");
*got_frame_ptr = 0;
return buf_size;
--
2.5.4 (Apple Git-61)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] eac3dec: don't call avpriv_request_sample every frame.
These errors neither prevent nor stop successful decoding
of the E-AC-3 stream's "core", causing avpriv_request_sample
to be called for every single frame in the bitstream.
---
libavcodec/ac3dec.h | 2 ++
libavcodec/eac3dec.c | 10 --
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/ac3dec.h b/libavcodec/ac3dec.h
index e4d443c..4c5359c 100644
--- a/libavcodec/ac3dec.h
+++ b/libavcodec/ac3dec.h
@@ -92,6 +92,8 @@ typedef struct AC3DecodeContext {
int lfe_mix_level_exists; ///< indicates if lfemixlevcod is
specified (lfemixlevcode)
int lfe_mix_level; ///< LFE mix level index
(lfemixlevcod)
int eac3; ///< indicates if current frame is
E-AC-3
+int eac3_frame_dependent_found; ///< bitstream has E-AC-3
dependent frame(s)
+int eac3_subsbtreamid_found;///< bitstream has E-AC-3
additional substream(s)
int dolby_surround_mode;///< dolby surround mode
(dsurmod)
int dolby_surround_ex_mode; ///< dolby surround ex mode
(dsurexmod)
int dolby_headphone_mode; ///< dolby headphone mode
(dheadphonmod)
diff --git a/libavcodec/eac3dec.c b/libavcodec/eac3dec.c
index b9d079c..fe52d27 100644
--- a/libavcodec/eac3dec.c
+++ b/libavcodec/eac3dec.c
@@ -300,7 +300,10 @@ int ff_eac3_parse_header(AC3DecodeContext *s)
application can select from. each independent stream can also contain
dependent streams which are used to add or replace channels. */
if (s->frame_type == EAC3_FRAME_TYPE_DEPENDENT) {
-avpriv_request_sample(s->avctx, "Dependent substream decoding");
+if (!s->eac3_frame_dependent_found) {
+s->eac3_frame_dependent_found = 1;
+avpriv_request_sample(s->avctx, "Dependent substream decoding");
+}
return AAC_AC3_PARSE_ERROR_FRAME_TYPE;
} else if (s->frame_type == EAC3_FRAME_TYPE_RESERVED) {
av_log(s->avctx, AV_LOG_ERROR, "Reserved frame type\n");
@@ -312,7 +315,10 @@ int ff_eac3_parse_header(AC3DecodeContext *s)
associated to an independent stream have matching substream id's. */
if (s->substreamid) {
/* only decode substream with id=0. skip any additional substreams. */
-avpriv_request_sample(s->avctx, "Additional substreams");
+if (!s->eac3_subsbtreamid_found) {
+s->eac3_subsbtreamid_found = 1;
+avpriv_request_sample(s->avctx, "Additional substreams");
+}
return AAC_AC3_PARSE_ERROR_FRAME_TYPE;
}
--
2.5.4 (Apple Git-61)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] [RFC] dcadec: don't check for overreads in auxiliary data.
The auxiliary data length field is not reliable,
and incorrect overread errors could be returned
for valid, real-world bitstreams.
---
libavcodec/dcadec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/dcadec.c b/libavcodec/dcadec.c
index 610857d..7e94638 100644
--- a/libavcodec/dcadec.c
+++ b/libavcodec/dcadec.c
@@ -1086,12 +1086,12 @@ static int dca_subframe_footer(DCAContext *s, int
base_channel)
align_get_bits(>gb); // byte align
skip_bits(>gb, 16); // nAUXCRC16
-// additional data (reserved, cf. ETSI TS 102 114 V1.4.1)
-if ((reserved = (aux_data_end - get_bits_count(>gb))) < 0) {
-av_log(s->avctx, AV_LOG_ERROR,
- "Overread auxiliary data by %d bits\n", -reserved);
-return AVERROR_INVALIDDATA;
-} else if (reserved) {
+/*
+ * additional data (reserved, cf. ETSI TS 102 114 V1.4.1)
+ *
+ * Note: don't check for overreads, aux_data_count can't be
trusted.
+ */
+if ((reserved = (aux_data_end - get_bits_count(>gb))) > 0) {
avpriv_request_sample(s->avctx,
"Core auxiliary data reserved content");
skip_bits_long(>gb, reserved);
--
2.4.9 (Apple Git-60)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vc1pred: remove logically dead code
On 24 Nov 2014, at 02:38, Vittorio Giovara vittorio.giov...@gmail.com wrote:
CC: libav-sta...@libav.org
Bug-Id: CID 1245699 / CID 1245700
---
libavcodec/vc1_pred.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
index 6a54fe4..87efcd2 100644
--- a/libavcodec/vc1_pred.c
+++ b/libavcodec/vc1_pred.c
@@ -648,7 +648,7 @@ void ff_vc1_pred_mv_intfr(VC1Context *v, int n, int
dmv_x, int dmv_y,
} else if (c_valid) {
px = C[0];
py = C[1];
-} else px = py = 0;
+}
} else {
if (field_a a_valid) {
px = A[0];
@@ -656,12 +656,7 @@ void ff_vc1_pred_mv_intfr(VC1Context *v, int n, int
dmv_x, int dmv_y,
} else if (field_b b_valid) {
px = B[0];
py = B[1];
-} else if (c_valid) {
-px = C[0];
-py = C[1];
-} else
-px = py = 0;
-}
+}}
Two closing braces on the same line? If this is correct, it looks as though the
block could use a re-indent?
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] matroskaenc: Fix writing zero duration subtitles
On 29 Oct 2014, at 19:06, John Stebbins stebb...@jetheaddev.com wrote: The matroska spec says blockduration == 0 means the frame is not a keyframe. Since all subtitles are keyframes, 0 blockduration should not be written. Fixes mkvalidator error messages for PGS subtitles. --- libavformat/matroskaenc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Please CC libav-stable, this bugfix is worth backporting IMO. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] matroskaenc: write correct Display{Width, Height} in stereo encoding
On 21 Oct 2014, at 13:43, Vittorio Giovara vittorio.giov...@gmail.com wrote: From the specifications: The pixel count of the track (PixelWidth/PixelHeight) should be the raw amount of pixels (for example 3840x1080 for full HD side by side) and the DisplayWidth/Height in pixels should be the amount of pixels for one plane (1920x1080 for that full HD stream), So, move the aspect ratio check in the mkv_write_stereo_mode() function and adapt the frame size appropriately when necessary. CC: libav-sta...@libav.org Found-by: Asan Usipov asan.usi...@gmail.com --- libavformat/matroskaenc.c | 28 +--- 1 file changed, 21 insertions(+), 7 deletions(-) Is MVC unaffected by this patch? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] matroskaenc: write correct Display{Width, Height} in stereo encoding
On 21 Oct 2014, at 16:02, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Tue, Oct 21, 2014 at 2:52 PM, Tim Walker tdskywal...@gmail.com wrote: On 21 Oct 2014, at 13:43, Vittorio Giovara vittorio.giov...@gmail.com wrote: From the specifications: The pixel count of the track (PixelWidth/PixelHeight) should be the raw amount of pixels (for example 3840x1080 for full HD side by side) and the DisplayWidth/Height in pixels should be the amount of pixels for one plane (1920x1080 for that full HD stream), So, move the aspect ratio check in the mkv_write_stereo_mode() function and adapt the frame size appropriately when necessary. CC: libav-sta...@libav.org Found-by: Asan Usipov asan.usi...@gmail.com --- libavformat/matroskaenc.c | 28 +--- 1 file changed, 21 insertions(+), 7 deletions(-) Is MVC unaffected by this patch? I guess so, what is the exact usecase you're referring to? Just making sure that if 1080p MVC is encountered (where the bitstream's display width/height is still 1920x1080, isn't it?), the display width/height are not set to 960x1080 or the likes ;) Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] matroskaenc: write correct Display{Width, Height} in stereo encoding
On 21 Oct 2014, at 16:14, Vittorio Giovara vittorio.giov...@gmail.com wrote: Wait, you have a MVC decoder and didn't tell us? ;) No, but we can streamcopy it, right? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] libfdk-aacdec: Enable Decoder Downmix including Downmix Metadata Support
On 17 Oct 2014, at 08:32, Martin Storsjö mar...@martin.st wrote: - if a downmix is requested, the 6-channel buffer allocated during init gets used - if no downmix is requested, the 6-channel buffer allocated during init is freed and a buffer large enough only for the actual output size is used, but, that would also be a 6-channel buffer, so what's the point of not using the initial buffer? It's not a buffer large enough only for the actual output size, it's the output AVFrame that is allocated once we know the exact number of channels, vs a generic buffer allocated with av_malloc. The point in not using the initial buffer is that we'd rather decode straight into the AVFrame if possible, to avoid an extra memcpy. That's much clearer, thanks. I'm not sure if it's kosher to request e.g. a 6 channel AVFrame and then just flip it to 2 channels after allocation - if it is, then we could of course simplify that, but that is unrelated to this patch, this is what we do already. Either way, the commit message should be reworked, IMO. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] libfdk-aacdec: Enable Decoder Downmix including Downmix Metadata Support
On 17 Oct 2014, at 10:56, Martin Storsjö mar...@martin.st wrote: On Fri, 17 Oct 2014, Tim Walker wrote: On 17 Oct 2014, at 08:32, Martin Storsjö mar...@martin.st wrote: - if a downmix is requested, the 6-channel buffer allocated during init gets used - if no downmix is requested, the 6-channel buffer allocated during init is freed and a buffer large enough only for the actual output size is used, but, that would also be a 6-channel buffer, so what's the point of not using the initial buffer? It's not a buffer large enough only for the actual output size, it's the output AVFrame that is allocated once we know the exact number of channels, vs a generic buffer allocated with av_malloc. The point in not using the initial buffer is that we'd rather decode straight into the AVFrame if possible, to avoid an extra memcpy. That's much clearer, thanks. I'm not sure if it's kosher to request e.g. a 6 channel AVFrame and then just flip it to 2 channels after allocation - if it is, then we could of course simplify that, but that is unrelated to this patch, this is what we do already. Either way, the commit message should be reworked, IMO. Suggestions welcome, I don't really see much of an issue with it. Or perhaps something like this: From: Otherwise, the initial decoder output buffer is freed and a buffer large enough only for the actual output size is used instead. Changed into: Otherwise, the initial decoder output buffer is freed and the decoder decodes straight into the output AVFrame. I guess that was the part that was most confusing? Yep, that's the only part that was confusing (to me), once you answered it all the other questions became a lot less relevant. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] libfdk-aacdec: Enable Decoder Downmix including Downmix Metadata Support
On 15 Oct 2014, at 13:40, Martin Storsjö mar...@martin.st wrote: When downmixing multichannel streams, the decoder requires the output buffer in aacDecoder_DecodeFrame call to be of fixed size in order to hold the actual number of channels contained in the stream. For example, for a 5.1ch to stereo downmix, the decoder requires that the output buffer is allocated for 6 channels, regardless of the fact that the output is in fact two channels. Due to this requirement, the output buffer is allocated for the maximum output buffer size in case a downmix is requested (and also during decoder init). When a downmix is requested, the buffer used for output during init will also be used for the entire duration the decoder is open. Otherwise, the initial decoder output buffer is freed and a buffer large enough only for the actual output size is used instead. I'm having trouble following. Let's say we have a 5.1 source: - during init, we allocate a buffer than can hold 6 channels' worth of decoded data - if a downmix is requested, the 6-channel buffer allocated during init gets used - if no downmix is requested, the 6-channel buffer allocated during init is freed and a buffer large enough only for the actual output size is used, but, that would also be a 6-channel buffer, so what's the point of not using the initial buffer? Does the commit message fail to mention we may have a downmix scenario where the maximum number of channels is greater than the actual number of channels (aka upmix)? Does the commit message fail to mention another scenario not related to the number of channels? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/1] fate-vc1_ilaced_twomv: use -flags +bitexact
On 04 Oct 2014, at 11:41, Janne Grunau janne-li...@jannau.net wrote: Also updates the reference since it was generated by the non-bitexact x86 specific code. --- tests/fate/microsoft.mak| 2 +- tests/ref/fate/vc1_ilaced_twomv | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) LGTM. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avcodec/libx265: enable psnr reporting when requested by the user
On 30 Sep 2014, at 14:52, Derek Buitenhuis derek.buitenh...@gmail.com wrote: From: Michael Niedermayer michae...@gmx.at This is similar to what is done in libx264.c Signed-off-by: Michael Niedermayer michae...@gmx.at Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com OK. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/6] dump: split audio and video probing on multiple lines
On 28 Sep 2014, at 22:37, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Sun, Sep 28, 2014 at 2:30 AM, Luca Barbato lu_z...@gentoo.org wrote: On 26/09/14 18:22, Vittorio Giovara wrote: --- What it looks like Stream #0.0(eng): Video: hevc (Main) yuv420p, tv, 1920x1072, [PAR 1:1 DAR 120:67] 23.98 fps, 1k tbn, 23.98 tbc (default) Stream #0.1(un): Audio: aac, 44100 Hz 5.1, fltp (default) Stream #0.2(eng): Subtitle: [0][0][0][0] / 0x (default) Stream #0.3(eng): Subtitle: [0][0][0][0] / 0x I updated the original patch to put samplerate on a new line, like you requested. I'd change it so it looks Stream #0.0(eng): Video: hevc (Main) [default] yuv420p, tv, 1920x1072, [PAR 1:1 DAR 120:67] 23.98 fps, 1k tbn, 23.98 tbc Stream #0.1(un): Audio: aac [default] 44100 Hz, 5.1, fltp Stream #0.2(eng): Subtitle: [0][0][0][0] / 0x [default] Stream #0.3(eng): Subtitle: [0][0][0][0] / 0x Moving disposition tag should be on a different patch and i'd rather leave the first line only for codec and profile information. Actually I have never seen a sample with a disposition different than default, is it worthwhile printing it at all? Yes. There usually is only one default track of each kind (video, audio, subtitle) and knowing which track is (or, if there are multiple default tracks of the same type, which is OK in some containers) is worthwhile IMO. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] mlpdec: support TrueHD streams with an Atmos substream
On 26 Sep 2014, at 13:49, Hendrik Leppkes h.lepp...@gmail.com wrote: The fourth substream is being discarded, since its not raw audio data, but an encoded Atmos stream which needs a specialized decoder. Fixes decoding of the true hd stream from Transformers\ -\ Age\ of\ Extinction\ 2014\ 1080P-003.mkv s/true hd/truehd Signed-off-by: Michael Niedermayer michae...@gmx.at If you believe in the patch, signed it off too ;-) --- libavcodec/mlp.h| 2 +- libavcodec/mlpdec.c | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/libavcodec/mlp.h b/libavcodec/mlp.h index 5a4ee5f..8a1584e 100644 --- a/libavcodec/mlp.h +++ b/libavcodec/mlp.h @@ -45,7 +45,7 @@ /** Maximum number of substreams that can be decoded. * MLP's limit is 2. TrueHD supports at least up to 3. */ -#define MAX_SUBSTREAMS 3 +#define MAX_SUBSTREAMS 4 /** which multiple of 48000 the maximum sample rate is */ #define MAX_RATEFACTOR 4 diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c index ad9e54f..5ace18d 100644 --- a/libavcodec/mlpdec.c +++ b/libavcodec/mlpdec.c @@ -355,7 +355,9 @@ static int read_major_sync(MLPDecodeContext *m, GetBitContext *gb) m-access_unit_size_pow2 = mh.access_unit_size_pow2; m-num_substreams= mh.num_substreams; -m-max_decoded_substream = m-num_substreams - 1; + +/* limit to decoding 3 substreams, as the 4th is used by Dolby Atmos for non-audio data */ I don't really like this comment. Maybe non-MLP data? Also, but even more minor: limit decoding to 3 substreams perhaps? And while we're at it, can be used? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 3/3] fate: Add VC-1 interlaced twomv test
CC: libav-sta...@libav.org --- tests/fate/microsoft.mak| 3 +++ tests/ref/fate/vc1_ilaced_twomv | 14 ++ 2 files changed, 17 insertions(+) create mode 100644 tests/ref/fate/vc1_ilaced_twomv diff --git a/tests/fate/microsoft.mak b/tests/fate/microsoft.mak index ea41c42..c1cedea 100644 --- a/tests/fate/microsoft.mak +++ b/tests/fate/microsoft.mak @@ -53,6 +53,9 @@ fate-vc1_sa10143: CMD = framecrc -i $(TARGET_SAMPLES)/vc1/SA10143.vc1 FATE_VC1-$(CONFIG_VC1_DEMUXER) += fate-vc1_sa20021 fate-vc1_sa20021: CMD = framecrc -i $(TARGET_SAMPLES)/vc1/SA20021.vc1 +FATE_VC1-$(CONFIG_VC1_DEMUXER) += fate-vc1_ilaced_twomv +fate-vc1_ilaced_twomv: CMD = framecrc -i $(TARGET_SAMPLES)/vc1/ilaced_twomv.vc1 + FATE_VC1-$(CONFIG_MOV_DEMUXER) += fate-vc1-ism fate-vc1-ism: CMD = framecrc -i $(TARGET_SAMPLES)/isom/vc1-wmapro.ism -an diff --git a/tests/ref/fate/vc1_ilaced_twomv b/tests/ref/fate/vc1_ilaced_twomv new file mode 100644 index 000..9a5d391 --- /dev/null +++ b/tests/ref/fate/vc1_ilaced_twomv @@ -0,0 +1,14 @@ +#tb 0: 1/25 +0, 0, 0,1, 3110400, 0x764f8856 +0, 2, 2,1, 3110400, 0x5b6680fa +0, 3, 3,1, 3110400, 0x8ee86a47 +0, 4, 4,1, 3110400, 0xc1ca8532 +0, 5, 5,1, 3110400, 0x53efd0f9 +0, 6, 6,1, 3110400, 0xa9605bc9 +0, 7, 7,1, 3110400, 0xbaa9aede +0, 8, 8,1, 3110400, 0x6035644c +0, 9, 9,1, 3110400, 0x1d6aff98 +0, 10, 10,1, 3110400, 0x7b047286 +0, 11, 11,1, 3110400, 0xa7cb2f84 +0, 12, 12,1, 3110400, 0xfba20dd1 +0, 13, 13,1, 3110400, 0x24c32a55 -- 1.9.3 (Apple Git-50) ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/3] vc1: use logical operation instead of bitwise for coded_inter
This appears to be the intended behavior. --- libavcodec/vc1dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c index 8ad4f0f..35245ab 100644 --- a/libavcodec/vc1dec.c +++ b/libavcodec/vc1dec.c @@ -3676,7 +3676,7 @@ static int vc1_decode_p_mb(VC1Context *v) vc1_mc_4mv_chroma(v, 0); v-mb_type[0][s-block_index[i]] = is_intra[i]; if (!coded_inter) -coded_inter = !is_intra[i] is_coded[i]; +coded_inter = !is_intra[i] is_coded[i]; } // if there are no coded blocks then don't do anything more dst_idx = 0; -- 1.9.3 (Apple Git-50) ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/3] vc1: use logical operation instead of bitwise for twomv
From: Michael Niedermayer michae...@gmx.at
CC: libav-sta...@libav.org
Signed-off-by: Michael Niedermayer michae...@gmx.at
Signed-off-by: Tim Walker tdskywal...@gmail.com
---
libavcodec/vc1dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 35245ab..41beaeb 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -4570,9 +4570,9 @@ static int vc1_decode_b_mb_intfr(VC1Context *v)
if (mb_has_coeffs)
cbp = 1 + get_vlc2(v-s.gb, v-cbpcy_vlc-table,
VC1_CBPCY_P_VLC_BITS, 2);
if (!direct) {
-if (bmvtype == (BMV_TYPE_INTERPOLATED twomv)) {
+if (bmvtype == BMV_TYPE_INTERPOLATED twomv) {
v-fourmvbp = get_vlc2(gb, v-fourmvbp_vlc-table,
VC1_4MV_BLOCK_PATTERN_VLC_BITS, 1);
-} else if (bmvtype == (BMV_TYPE_INTERPOLATED | twomv)) {
+} else if (bmvtype == BMV_TYPE_INTERPOLATED || twomv) {
v-twomvbp = get_vlc2(gb, v-twomvbp_vlc-table,
VC1_2MV_BLOCK_PATTERN_VLC_BITS, 1);
}
}
--
1.9.3 (Apple Git-50)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] ac3enc: allow Dolby Pro Logic IIz as the Dolby Surround EX mode.
This is actually defined in the A/52 specification.
---
libavcodec/ac3enc.h | 1 +
libavcodec/ac3enc_opts_template.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/ac3enc.h b/libavcodec/ac3enc.h
index c7b692d..76b6d7f 100644
--- a/libavcodec/ac3enc.h
+++ b/libavcodec/ac3enc.h
@@ -80,6 +80,7 @@ typedef int64_t CoefSumType;
#define AC3ENC_OPT_NOT_INDICATED0
#define AC3ENC_OPT_MODE_ON 2
#define AC3ENC_OPT_MODE_OFF 1
+#define AC3ENC_OPT_DSUREX_DPLIIZ3
/* specific option values */
#define AC3ENC_OPT_LARGE_ROOM 1
diff --git a/libavcodec/ac3enc_opts_template.c
b/libavcodec/ac3enc_opts_template.c
index 8cb5ad1..a08c70d 100644
--- a/libavcodec/ac3enc_opts_template.c
+++ b/libavcodec/ac3enc_opts_template.c
@@ -55,10 +55,11 @@ static const AVOption ac3_options[] = {
{ltrt_surmixlev, Lt/Rt Surround Mix Level,
OFFSET(ltrt_surround_mix_level), AV_OPT_TYPE_FLOAT, {.dbl = -1.0 }, -1.0, 2.0,
AC3ENC_PARAM},
{loro_cmixlev, Lo/Ro Center Mix Level, OFFSET(loro_center_mix_level),
AV_OPT_TYPE_FLOAT, {.dbl = -1.0 }, -1.0, 2.0, AC3ENC_PARAM},
{loro_surmixlev, Lo/Ro Surround Mix Level,
OFFSET(loro_surround_mix_level), AV_OPT_TYPE_FLOAT, {.dbl = -1.0 }, -1.0, 2.0,
AC3ENC_PARAM},
-{dsurex_mode, Dolby Surround EX Mode, OFFSET(dolby_surround_ex_mode),
AV_OPT_TYPE_INT, {.i64 = AC3ENC_OPT_NONE }, AC3ENC_OPT_NONE,
AC3ENC_OPT_MODE_ON, AC3ENC_PARAM, dsurex_mode},
+{dsurex_mode, Dolby Surround EX Mode, OFFSET(dolby_surround_ex_mode),
AV_OPT_TYPE_INT, {.i64 = AC3ENC_OPT_NONE }, AC3ENC_OPT_NONE,
AC3ENC_OPT_DSUREX_DPLIIZ, AC3ENC_PARAM, dsurex_mode},
{notindicated, Not Indicated (default), 0, AV_OPT_TYPE_CONST,
{.i64 = AC3ENC_OPT_NOT_INDICATED }, INT_MIN, INT_MAX, AC3ENC_PARAM,
dsurex_mode},
{on, Dolby Surround EX Encoded, 0, AV_OPT_TYPE_CONST,
{.i64 = AC3ENC_OPT_MODE_ON }, INT_MIN, INT_MAX, AC3ENC_PARAM,
dsurex_mode},
{off, Not Dolby Surround EX Encoded, 0, AV_OPT_TYPE_CONST,
{.i64 = AC3ENC_OPT_MODE_OFF }, INT_MIN, INT_MAX, AC3ENC_PARAM,
dsurex_mode},
+{dpliiz, Dolby Pro Logic IIz-encoded, 0, AV_OPT_TYPE_CONST,
{.i64 = AC3ENC_OPT_DSUREX_DPLIIZ }, INT_MIN, INT_MAX, AC3ENC_PARAM,
dsurex_mode},
{dheadphone_mode, Dolby Headphone Mode, OFFSET(dolby_headphone_mode),
AV_OPT_TYPE_INT, {.i64 = AC3ENC_OPT_NONE }, AC3ENC_OPT_NONE,
AC3ENC_OPT_MODE_ON, AC3ENC_PARAM, dheadphone_mode},
{notindicated, Not Indicated (default), 0, AV_OPT_TYPE_CONST,
{.i64 = AC3ENC_OPT_NOT_INDICATED }, INT_MIN, INT_MAX, AC3ENC_PARAM,
dheadphone_mode},
{on, Dolby Headphone Encoded, 0, AV_OPT_TYPE_CONST,
{.i64 = AC3ENC_OPT_MODE_ON }, INT_MIN, INT_MAX, AC3ENC_PARAM,
dheadphone_mode},
--
1.9.3 (Apple Git-50)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] ac3enc: allow Dolby Pro Logic II as a preferred downmix mode.
Some encoders already use this value even
though it's reserved in the A/52 specification.
---
libavcodec/ac3enc.h | 1 +
libavcodec/ac3enc_opts_template.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/ac3enc.h b/libavcodec/ac3enc.h
index 30c15d0..c7b692d 100644
--- a/libavcodec/ac3enc.h
+++ b/libavcodec/ac3enc.h
@@ -86,6 +86,7 @@ typedef int64_t CoefSumType;
#define AC3ENC_OPT_SMALL_ROOM 2
#define AC3ENC_OPT_DOWNMIX_LTRT 1
#define AC3ENC_OPT_DOWNMIX_LORO 2
+#define AC3ENC_OPT_DOWNMIX_DPLII3 // reserved value in A/52, but used by
encoders to indicate DPL2
#define AC3ENC_OPT_ADCONV_STANDARD 0
#define AC3ENC_OPT_ADCONV_HDCD 1
diff --git a/libavcodec/ac3enc_opts_template.c
b/libavcodec/ac3enc_opts_template.c
index 339a08f..8cb5ad1 100644
--- a/libavcodec/ac3enc_opts_template.c
+++ b/libavcodec/ac3enc_opts_template.c
@@ -46,10 +46,11 @@ static const AVOption ac3_options[] = {
{off, Not Dolby Surround Encoded, 0, AV_OPT_TYPE_CONST, {.i64
= AC3ENC_OPT_MODE_OFF }, INT_MIN, INT_MAX, AC3ENC_PARAM, dsur_mode},
{original, Original Bit Stream, OFFSET(original), AV_OPT_TYPE_INT, {.i64
= AC3ENC_OPT_NONE }, AC3ENC_OPT_NONE, 1, AC3ENC_PARAM},
/* extended bitstream information */
-{dmix_mode, Preferred Stereo Downmix Mode,
OFFSET(preferred_stereo_downmix), AV_OPT_TYPE_INT, {.i64 = AC3ENC_OPT_NONE },
AC3ENC_OPT_NONE, AC3ENC_OPT_DOWNMIX_LORO, AC3ENC_PARAM, dmix_mode},
+{dmix_mode, Preferred Stereo Downmix Mode,
OFFSET(preferred_stereo_downmix), AV_OPT_TYPE_INT, {.i64 = AC3ENC_OPT_NONE },
AC3ENC_OPT_NONE, AC3ENC_OPT_DOWNMIX_DPLII, AC3ENC_PARAM, dmix_mode},
{notindicated, Not Indicated (default), 0, AV_OPT_TYPE_CONST, {.i64 =
AC3ENC_OPT_NOT_INDICATED }, INT_MIN, INT_MAX, AC3ENC_PARAM, dmix_mode},
{ltrt, Lt/Rt Downmix Preferred, 0, AV_OPT_TYPE_CONST, {.i64 =
AC3ENC_OPT_DOWNMIX_LTRT }, INT_MIN, INT_MAX, AC3ENC_PARAM, dmix_mode},
{loro, Lo/Ro Downmix Preferred, 0, AV_OPT_TYPE_CONST, {.i64 =
AC3ENC_OPT_DOWNMIX_LORO }, INT_MIN, INT_MAX, AC3ENC_PARAM, dmix_mode},
+{dplii, Dolby Pro Logic II Downmix Preferred, 0, AV_OPT_TYPE_CONST,
{.i64 = AC3ENC_OPT_DOWNMIX_DPLII }, INT_MIN, INT_MAX, AC3ENC_PARAM,
dmix_mode},
{ltrt_cmixlev, Lt/Rt Center Mix Level, OFFSET(ltrt_center_mix_level),
AV_OPT_TYPE_FLOAT, {.dbl = -1.0 }, -1.0, 2.0, AC3ENC_PARAM},
{ltrt_surmixlev, Lt/Rt Surround Mix Level,
OFFSET(ltrt_surround_mix_level), AV_OPT_TYPE_FLOAT, {.dbl = -1.0 }, -1.0, 2.0,
AC3ENC_PARAM},
{loro_cmixlev, Lo/Ro Center Mix Level, OFFSET(loro_center_mix_level),
AV_OPT_TYPE_FLOAT, {.dbl = -1.0 }, -1.0, 2.0, AC3ENC_PARAM},
--
1.9.3 (Apple Git-50)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/3] vc1: use logical operation instead of bitwise for twomv
On 25 Sep 2014, at 20:36, Luca Barbato lu_z...@gentoo.org wrote:
On 25/09/14 18:47, Tim Walker wrote:
From: Michael Niedermayer michae...@gmx.at
CC: libav-sta...@libav.org
Signed-off-by: Michael Niedermayer michae...@gmx.at
Signed-off-by: Tim Walker tdskywal...@gmail.com
---
libavcodec/vc1dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 35245ab..41beaeb 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -4570,9 +4570,9 @@ static int vc1_decode_b_mb_intfr(VC1Context *v)
if (mb_has_coeffs)
cbp = 1 + get_vlc2(v-s.gb, v-cbpcy_vlc-table,
VC1_CBPCY_P_VLC_BITS, 2);
if (!direct) {
-if (bmvtype == (BMV_TYPE_INTERPOLATED twomv)) {
+if (bmvtype == BMV_TYPE_INTERPOLATED twomv) {
v-fourmvbp = get_vlc2(gb, v-fourmvbp_vlc-table,
VC1_4MV_BLOCK_PATTERN_VLC_BITS, 1);
-} else if (bmvtype == (BMV_TYPE_INTERPOLATED | twomv)) {
+} else if (bmvtype == BMV_TYPE_INTERPOLATED || twomv) {
v-twomvbp = get_vlc2(gb, v-twomvbp_vlc-table,
VC1_2MV_BLOCK_PATTERN_VLC_BITS, 1);
}
}
Hopefully ok.
lu
It does fix a fairly obvious bug (see the sample for the vc1 test added in the
patchset), and try decoding it with and without this patch ;)
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/3] vc1: use logical operation instead of bitwise for coded_inter
On 26 Sep 2014, at 01:09, Diego Biurrun di...@biurrun.de wrote: On Thu, Sep 25, 2014 at 06:47:04PM +0200, Tim Walker wrote: This appears to be the intended behavior. --- libavcodec/vc1dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) vc1: Use logical instead of bitwise or for coded_inter Diego OK. Anyone mind if I change this during push without resending? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] fate: Add VC-1 interlaced test
On 21 Sep 2014, at 18:16, Hendrik Leppkes h.lepp...@gmail.com wrote: On Sun, Sep 21, 2014 at 5:16 PM, Tim Walker tdskywal...@gmail.com wrote: --- tests/fate/microsoft.mak| 3 +++ tests/ref/fate/vc1_ilaced_twomv | 14 ++ 2 files changed, 17 insertions(+) create mode 100644 tests/ref/fate/vc1_ilaced_twomv diff --git a/tests/fate/microsoft.mak b/tests/fate/microsoft.mak index ea41c42..c1cedea 100644 --- a/tests/fate/microsoft.mak +++ b/tests/fate/microsoft.mak @@ -53,6 +53,9 @@ fate-vc1_sa10143: CMD = framecrc -i $(TARGET_SAMPLES)/vc1/SA10143.vc1 FATE_VC1-$(CONFIG_VC1_DEMUXER) += fate-vc1_sa20021 fate-vc1_sa20021: CMD = framecrc -i $(TARGET_SAMPLES)/vc1/SA20021.vc1 +FATE_VC1-$(CONFIG_VC1_DEMUXER) += fate-vc1_ilaced_twomv +fate-vc1_ilaced_twomv: CMD = framecrc -i $(TARGET_SAMPLES)/vc1/ilaced_twomv.vc1 + FATE_VC1-$(CONFIG_MOV_DEMUXER) += fate-vc1-ism fate-vc1-ism: CMD = framecrc -i $(TARGET_SAMPLES)/isom/vc1-wmapro.ism -an diff --git a/tests/ref/fate/vc1_ilaced_twomv b/tests/ref/fate/vc1_ilaced_twomv new file mode 100644 index 000..9a5d391 --- /dev/null +++ b/tests/ref/fate/vc1_ilaced_twomv @@ -0,0 +1,14 @@ +#tb 0: 1/25 +0, 0, 0,1, 3110400, 0x764f8856 +0, 2, 2,1, 3110400, 0x5b6680fa +0, 3, 3,1, 3110400, 0x8ee86a47 +0, 4, 4,1, 3110400, 0xc1ca8532 +0, 5, 5,1, 3110400, 0x53efd0f9 +0, 6, 6,1, 3110400, 0xa9605bc9 +0, 7, 7,1, 3110400, 0xbaa9aede +0, 8, 8,1, 3110400, 0x6035644c +0, 9, 9,1, 3110400, 0x1d6aff98 +0, 10, 10,1, 3110400, 0x7b047286 +0, 11, 11,1, 3110400, 0xa7cb2f84 +0, 12, 12,1, 3110400, 0xfba20dd1 +0, 13, 13,1, 3110400, 0x24c32a55 -- 1.9.3 (Apple Git-50) Just to clarify, one of the existing conformity tests (sa10143 specifically) is interlaced, your commit makes it sound like this is the first. - Hendrik I don't mind renaming it, but to what? Patch was already added to FATE, FWIW. Can we come to an agreement so I can send an updated patchset? Cheers, Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] VDD meeting notes
On 22 Sep 2014, at 16:33, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 9/21/2014 12:43 PM, Andrew Kelley wrote: more things to remove? avpicture_deinterlace I thought this was already gone? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] vc1: use logical operation instead of bitwise for twomv
From: Michael Niedermayer michae...@gmx.at
CC: libav-sta...@libav.org
Signed-off-by: Michael Niedermayer michae...@gmx.at
(cherry picked from commit 1e2ab98460761c86268993e7a7ee690876df5efd)
Signed-off-by: Tim Walker tdskywal...@gmail.com
---
libavcodec/vc1dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 8ad4f0f..00d8e4f 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -4570,9 +4570,9 @@ static int vc1_decode_b_mb_intfr(VC1Context *v)
if (mb_has_coeffs)
cbp = 1 + get_vlc2(v-s.gb, v-cbpcy_vlc-table,
VC1_CBPCY_P_VLC_BITS, 2);
if (!direct) {
-if (bmvtype == (BMV_TYPE_INTERPOLATED twomv)) {
+if (bmvtype == BMV_TYPE_INTERPOLATED twomv) {
v-fourmvbp = get_vlc2(gb, v-fourmvbp_vlc-table,
VC1_4MV_BLOCK_PATTERN_VLC_BITS, 1);
-} else if (bmvtype == (BMV_TYPE_INTERPOLATED | twomv)) {
+} else if (bmvtype == BMV_TYPE_INTERPOLATED || twomv) {
v-twomvbp = get_vlc2(gb, v-twomvbp_vlc-table,
VC1_2MV_BLOCK_PATTERN_VLC_BITS, 1);
}
}
--
1.9.3 (Apple Git-50)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] fate: Add VC-1 interlaced test
--- tests/fate/microsoft.mak| 3 +++ tests/ref/fate/vc1_ilaced_twomv | 14 ++ 2 files changed, 17 insertions(+) create mode 100644 tests/ref/fate/vc1_ilaced_twomv diff --git a/tests/fate/microsoft.mak b/tests/fate/microsoft.mak index ea41c42..c1cedea 100644 --- a/tests/fate/microsoft.mak +++ b/tests/fate/microsoft.mak @@ -53,6 +53,9 @@ fate-vc1_sa10143: CMD = framecrc -i $(TARGET_SAMPLES)/vc1/SA10143.vc1 FATE_VC1-$(CONFIG_VC1_DEMUXER) += fate-vc1_sa20021 fate-vc1_sa20021: CMD = framecrc -i $(TARGET_SAMPLES)/vc1/SA20021.vc1 +FATE_VC1-$(CONFIG_VC1_DEMUXER) += fate-vc1_ilaced_twomv +fate-vc1_ilaced_twomv: CMD = framecrc -i $(TARGET_SAMPLES)/vc1/ilaced_twomv.vc1 + FATE_VC1-$(CONFIG_MOV_DEMUXER) += fate-vc1-ism fate-vc1-ism: CMD = framecrc -i $(TARGET_SAMPLES)/isom/vc1-wmapro.ism -an diff --git a/tests/ref/fate/vc1_ilaced_twomv b/tests/ref/fate/vc1_ilaced_twomv new file mode 100644 index 000..9a5d391 --- /dev/null +++ b/tests/ref/fate/vc1_ilaced_twomv @@ -0,0 +1,14 @@ +#tb 0: 1/25 +0, 0, 0,1, 3110400, 0x764f8856 +0, 2, 2,1, 3110400, 0x5b6680fa +0, 3, 3,1, 3110400, 0x8ee86a47 +0, 4, 4,1, 3110400, 0xc1ca8532 +0, 5, 5,1, 3110400, 0x53efd0f9 +0, 6, 6,1, 3110400, 0xa9605bc9 +0, 7, 7,1, 3110400, 0xbaa9aede +0, 8, 8,1, 3110400, 0x6035644c +0, 9, 9,1, 3110400, 0x1d6aff98 +0, 10, 10,1, 3110400, 0x7b047286 +0, 11, 11,1, 3110400, 0xa7cb2f84 +0, 12, 12,1, 3110400, 0xfba20dd1 +0, 13, 13,1, 3110400, 0x24c32a55 -- 1.9.3 (Apple Git-50) ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] hevc: Fix 4K sample video
On 14 Jun 2014, at 20:24, Kieran Kunhya kier...@obe.tv wrote: Can't share a sample unfortunately Can't you ask your source for a sample that reproduces the issue and can be shared? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC/PATCH] Remove avserver.
On 09 Jun 2014, at 17:08, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 6/9/2014 1:29 PM, Anton Khirnov wrote: It has not been properly maintained for years and there is little hope of that changing in the future. It appears simpler to write a new replacement from scratch than unbreaking it. DEATH TO AVSERVER - Derek A simple git rm is not enough though, we should devise a more elaborate death. Trial by combat? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/3] h264: Move search code search functions into separate source files.
On 18 Apr 2014, at 23:30, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Fri, Apr 18, 2014 at 4:07 PM, Tim Walker tdskywal...@gmail.com wrote: On 16 Apr 2014, at 02:50, Ben Avison bavi...@riscosopen.org wrote: This permits re-use with parsers for codecs which use similar start codes. --- libavcodec/Makefile |2 +- libavcodec/arm/Makefile |2 +- libavcodec/arm/h264dsp_armv6.S| 253 - libavcodec/arm/h264dsp_init_arm.c |4 +- libavcodec/arm/startcode_armv6.S | 253 + libavcodec/h264dsp.c | 31 +- libavcodec/startcode.c| 57 + libavcodec/startcode.h| 35 + 8 files changed, 351 insertions(+), 286 deletions(-) delete mode 100644 libavcodec/arm/h264dsp_armv6.S create mode 100644 libavcodec/arm/startcode_armv6.S create mode 100644 libavcodec/startcode.c create mode 100644 libavcodec/startcode.h Note: some code in libavformat looks for startcodes too (e.g. for Annex B - MP4 conversion). Would it make sens to factor this out to libavutil? This might be a good idea. Which one would be the best place, lavcodec or lavutil? -- Vittorio Did anything come of this? I'd like to know the answer to this question too. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] hlsenc: Set the default codecs to AAC and H264
On 15 May 2014, at 20:44, Martin Storsjö mar...@martin.st wrote: Most HLS implementation only support these codecs. --- libavformat/hlsenc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) OK,but what if the only available AAC encoder is libavcodec (does the user/caller have to enable experimental encoders manually, and what happens if it doesn't)? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: check for recent dxva2api headers with fixed COBJMACROS defines
On 09 May 2014, at 13:54, Hendrik Leppkes h.lepp...@gmail.com wrote: This fixes build failures on older mingw chains (before 2012). --- configure | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 47fd690..bdf4f66 100755 --- a/configure +++ b/configure @@ -4016,6 +4017,16 @@ disabled bzlib || check_lib2 bzlib.h BZ2_bzlibVersion -lbz2 || disable bzlib check_lib math.h sin -lm LIBM=-lm enabled vaapi require vaapi va/va.h vaInitialize -lva +enabled dxva2api_h +check_cc EOF enable dxva2api_cobj +#define _WIN32_WINNT 0x0600 Nit: maybe add a comment explaining the value is _WIN32_WINNT_VISTA? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] dca: Convert dca_dmixtable to integers
On 06 May 2014, at 09:41, Niels Möller ni...@lysator.liu.se wrote: Also include zero in the table, eliminating a special case in the decoder. Signed-off-by: Niels Möller ni...@southpole.se --- This is a small step towards integer decoding, needed for other work on 7.1 xll. I think it's fairly safe. Passes make fate-dts (any other easy regression testing I can do?). Since Anton never re-introduced the FATE DTS downmix tests (he had a patch for it, but it seems to have been delayed and then forgotten), AFAIK fate-dts tests nothing affected by the patch. You should perhaps test DTS to PCM with stereo downmix enabled (-request_channel_layout 3), maybe via the framecrc muxer? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] dca xll: Working audio
On 28 Apr 2014, at 15:01, Hendrik Leppkes h.lepp...@gmail.com wrote: I also used to have a sample somewhere where all audible audio is in the lossless extension for all channels, playing just the core yielded nothing but silence. Maybe I can dig it up if its of interest. - Hendrik Please do (more out of curiosity than any other reason though). Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] dca xll: Working audio
On 28 Apr 2014, at 14:44, Kostya Shishkov kostya.shish...@gmail.com wrote: On Mon, Apr 28, 2014 at 02:35:36PM +0200, Niels Möller wrote: After implementing proper channel reorder, I think the audio is pretty close to correct. Peak sample error for Master Audio 5.0 96khz.dts is now down to 115 (for 24-bit integer output). To be compared to 7183 if the core channels are upmixed but the xll residual data is ignored. Code in my public wip repo at http://www.southpole.se/~nisse/libav.git, branch xll. What's the next steps? I guess I should rebase or merge with the master branch, maybe remove or clean up debug output, and then post the patch here for review? (It might be possible to split it in pieces, but I doubt the history in my repo is very useful). Or you can work on integer mode for DTS. Indeed, this will be needed for lossless eventually, so if you're not sure what to work on you might as well tackle it now :-) Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avformat: Be informative when returning errors
On 23 Apr 2014, at 11:43, Luca Barbato lu_z...@gentoo.org wrote: --- libavformat/mux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) I have mixed feelings about the name (reads like a general cleanup when it's a one-line diff), but the patch itself LGTM. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] fic: Use user-suplied buffer for final frame
On 22 Apr 2014, at 23:16, Derek Buitenhuis derek.buitenh...@gmail.com wrote:
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/fic.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/libavcodec/fic.c b/libavcodec/fic.c
index 0f9f798..b2e18cd 100644
--- a/libavcodec/fic.c
+++ b/libavcodec/fic.c
@@ -270,6 +270,12 @@ static int fic_decode_frame(AVCodecContext *avctx, void
*data,
return ret;
}
+ctx-final_frame = data;
+if ((ret = ff_get_buffer(avctx, ctx-final_frame, 0)) 0) {
+av_log(avctx, AV_LOG_ERROR, COuld not allocate frame buffer.\n);
Be sure to fix this typo if you plan to re-introduce this patch.
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mp2: Do not force a samplerate
On 09 Apr 2014, at 14:58, Luca Barbato lu_z...@gentoo.org wrote:
The default should be not to resample.
---
libavcodec/mpegaudioenc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/mpegaudioenc.c b/libavcodec/mpegaudioenc.c
index 3a5cdca..51a6f5b 100644
--- a/libavcodec/mpegaudioenc.c
+++ b/libavcodec/mpegaudioenc.c
@@ -744,7 +744,6 @@ static int MPA_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
static const AVCodecDefault mp2_defaults[] = {
{ b, 384000 },
-{ ar, 48000 },
{ NULL },
};
--
1.8.5.2 (Apple Git-48)
OK (though you approved the patch that introduced this).
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] libx265: Use x265_param_parse to set the SAR
On 09 Apr 2014, at 15:30, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 4/9/2014 12:42 AM, Tim W. wrote: IIRC H.265 has 16-bit fields for SAR width/height: strlen(65535) * 2 + ':' + '\n' should be 12, IMO. Well we are calling av_reduce with a max of 4096. Nobody mentioned this originally. I'll do it in a separate patch if this is true. Oh, didn't notice that. Checked the specification, sar_width and sar_height are definitely u(16), and nothing in H.265 restricts their value beyond the fact that they must be non-zero if present (i.e. if aspect_ratio_idc == EXTENDED_SAR). I agree that it warrants a separate patch. I would *maybe* check for X265_PARAM_BAD_NAME too, just in case they change the option name (however unlikely). Hmm, OK. Yeah, that was a definite maybe. I'd say maybe just log a warning instead of failing. That or drop the suggestion entirely, up to you. Patch LGTM otherwise. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mp2: match twolame default options
On 08 Apr 2014, at 02:13, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Tue, Apr 8, 2014 at 12:18 AM, Tim Walker tdskywal...@gmail.com wrote: On 07 Apr 2014, at 17:11, Luca Barbato lu_z...@gentoo.org wrote: On 07/04/14 16:25, Vittorio Giovara wrote: --- libavcodec/mpegaudioenc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Ok, 348k is a lot btw ^^; lu Indeed, are we sure following twolame defaults to the letter a good idea? Well also sample rate is high, the values are chosen so that if a user doesn't set these parameters at least output audio quality is preserved (and can be customized later when the user notices it). 48 kHz is standard. 384 Kbps for lossy Stereo is (very) high and not what most people would expect. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mp2: match twolame default options
On 08 Apr 2014, at 13:51, Kieran Kunhya kier...@obe.tv wrote: On 8 April 2014 12:08, Tim Walker tdskywal...@gmail.com wrote: On 08 Apr 2014, at 02:13, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Tue, Apr 8, 2014 at 12:18 AM, Tim Walker tdskywal...@gmail.com wrote: On 07 Apr 2014, at 17:11, Luca Barbato lu_z...@gentoo.org wrote: On 07/04/14 16:25, Vittorio Giovara wrote: --- libavcodec/mpegaudioenc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Ok, 348k is a lot btw ^^; lu Indeed, are we sure following twolame defaults to the letter a good idea? Well also sample rate is high, the values are chosen so that if a user doesn't set these parameters at least output audio quality is preserved (and can be customized later when the user notices it). 48 kHz is standard. 384 Kbps for lossy Stereo is (very) high and not what most people would expect. In the MP2 world 384 is pretty standard stuff. Admittedly some use 256. I guess I only ever checked IPTV (where MP2 was usually 192 or 256 Kbps). Patch OK then. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/3] fate: update tests for YVVU422
On 07 Apr 2014, at 23:47, Vittorio Giovara vittorio.giov...@gmail.com wrote: --- tests/ref/fate/filter-pixdesc | 1 + tests/ref/fate/filter-pixfmts-copy | 1 + tests/ref/fate/filter-pixfmts-null | 1 + tests/ref/fate/filter-pixfmts-scale | 1 + tests/ref/fate/filter-pixfmts-vflip | 1 + 5 files changed, 5 insertions(+) Are you updating existing tests after a code change, or adding new ones? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH v3] nutdec: check malloc calls()
On 07 Apr 2014, at 15:27, Nidhi Makhijani nidhim...@gmail.com wrote: --- changed commit name No, you did not :P Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mp2: match twolame default options
On 07 Apr 2014, at 17:11, Luca Barbato lu_z...@gentoo.org wrote: On 07/04/14 16:25, Vittorio Giovara wrote: --- libavcodec/mpegaudioenc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Ok, 348k is a lot btw ^^; lu Indeed, are we sure following twolame defaults to the letter a good idea? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH][FUTURE] libx265: Update API usage yet again
On 06 Apr 2014, at 21:41, Derek Buitenhuis derek.buitenh...@gmail.com wrote: Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com --- Should not be pushed until the following goes in on Monday: https://mailman.videolan.org/pipermail/x265-devel/2014-April/004116.html --- configure| 4 ++-- libavcodec/libx265.c | 2 -- 2 files changed, 2 insertions(+), 4 deletions(-) FWIW, in HandBrake I'm trying to move away from having to update the wrapper for every API change by using x265_param_parse, for example: char sar[22]; snprintf(sar, sizeof(sar), %d:%d, sar_num, sar_den); x265_param_parse(param, sar, sar); Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH v2] nutdec: Check malloc calls()
On 05 Apr 2014, at 19:11, Nidhi Makhijani nidhim...@gmail.com wrote: --- libavformat/nutdec.c | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) Also: nutdec: check malloc() calls Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] af_ashowinfo: print a more descriptive name for AV_MATRIX_ENCODING_DOLBY
On 04 Apr 2014, at 17:49, Anton Khirnov an...@khirnov.net wrote: --- libavfilter/af_ashowinfo.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) LGTM. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] simplify option handling
On 03 Apr 2014, at 08:01, Martin Storsjö mar...@martin.st wrote: On Thu, 3 Apr 2014, Tim Walker wrote: On 02 Apr 2014, at 12:15, Janne Grunau janne-li...@jannau.net wrote: The first entry in @ARGV not starting with a dash or everything after '--' is handled as gcc_cmd command. Makes ./gas-preprocessor.pl -help work as intended. --- gas-preprocessor.pl | 33 - 1 file changed, 8 insertions(+), 25 deletions(-) Please amend the commit name to indicate the affected component before pushing though. Well, this is within the gas-preprocessor repo, where there is nothing else but the gas-preprocessor, so saying that within the commit subject is a bit redundant (once committed). I do agree that it's a little non-obvious on the ML though. OK. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] simplify option handling
On 02 Apr 2014, at 12:15, Janne Grunau janne-li...@jannau.net wrote: The first entry in @ARGV not starting with a dash or everything after '--' is handled as gcc_cmd command. Makes ./gas-preprocessor.pl -help work as intended. --- gas-preprocessor.pl | 33 - 1 file changed, 8 insertions(+), 25 deletions(-) Please amend the commit name to indicate the affected component before pushing though. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] lavu: add all color-related enums to AVFrame
On 02 Apr 2014, at 01:11, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Tue, Mar 25, 2014 at 1:12 PM, wm4 nfx...@googlemail.com wrote: --- doc/APIchanges | 5 libavcodec/avcodec.h | 67 libavutil/frame.c| 10 libavutil/frame.h| 30 +++ libavutil/pixfmt.h | 62 libavutil/version.h | 2 +- 6 files changed, 108 insertions(+), 68 deletions(-) So any further opinions on this patch? I was waiting for the other patch that converts frames to pointer to land but we could see if there are further comments on this. Any preference for colorspace or color_space? The first is the name in AVCodecContext the second would be a uniform name like the newly introduced fields. What name does FFmpeg use? It would make it easier for downstreams if they match, and incompatibility for the sake of it seems pointless, IMO. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] [RFC] asettb: setting timebases for audio files
On 31 Mar 2014, at 16:37, Katerina Barone-Adesi kateri...@gmail.com wrote: 0001-Added-asettb-support-setting-timebases-for-audio.patch0002-Renamed-vf_settb.c-to-f_settb.c.patch Hi, your patches are correctly formatted, but your emails aren't - please try and use git send-email to send them. Cheers, Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] {v,a}f_showinfo: print frame side data
On 24 Mar 2014, at 06:03, Anton Khirnov an...@khirnov.net wrote:
---
Switched replaygain printing to the new API with the struct instead of binary
data
---
libavfilter/af_ashowinfo.c | 110
libavfilter/vf_showinfo.c | 55 ++
2 files changed, 165 insertions(+)
diff --git a/libavfilter/af_ashowinfo.c b/libavfilter/af_ashowinfo.c
index 99d9dde..e9649d9 100644
--- a/libavfilter/af_ashowinfo.c
+++ b/libavfilter/af_ashowinfo.c
@@ -30,7 +30,10 @@
#include libavutil/attributes.h
#include libavutil/channel_layout.h
#include libavutil/common.h
+#include libavutil/downmix_info.h
+#include libavutil/intreadwrite.h
#include libavutil/mem.h
+#include libavutil/replaygain.h
#include libavutil/samplefmt.h
#include audio.h
@@ -66,6 +69,99 @@ static av_cold void uninit(AVFilterContext *ctx)
av_freep(s-plane_checksums);
}
+static void dump_matrixenc(AVFilterContext *ctx, AVFrameSideData *sd)
+{
+enum AVMatrixEncoding enc;
+
+av_log(ctx, AV_LOG_INFO, matrix encoding: );
+
+if (sd-size sizeof(enum AVMatrixEncoding)) {
+av_log(ctx, AV_LOG_INFO, invalid data);
+return;
+}
+
+enc = *(enum AVMatrixEncoding *)sd-data;
+switch (enc) {
+case AV_MATRIX_ENCODING_NONE: av_log(ctx, AV_LOG_INFO,
none);break;
+case AV_MATRIX_ENCODING_DOLBY: av_log(ctx, AV_LOG_INFO,
Dolby); break;
Sorry for not catching this earlier, this should say Dolby Surround, IMO. I
suppose Dolby Pro Logic would also do.
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] lavu: add all color-related enums to AVFrame
On 25 Mar 2014, at 15:37, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Tue, Mar 25, 2014 at 1:12 PM, wm4 nfx...@googlemail.com wrote: --- doc/APIchanges | 5 libavcodec/avcodec.h | 67 libavutil/frame.c| 10 libavutil/frame.h| 30 +++ libavutil/pixfmt.h | 62 libavutil/version.h | 2 +- 6 files changed, 108 insertions(+), 68 deletions(-) I think this is fine, I'll wait for some more feedback and then apply it in the next days. Thanks for the contribution. Vittorio I think so too. Did you intend to push the whole patchset, or just 1/2? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] libx265: Only use one memcpy for headers
On 23 Mar 2014, at 15:47, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 3/23/2014 2:36 PM, Derek Buitenhuis wrote: +memcpy(buf, nal[0].payload, ctx-header_size); URG, I forgot to --amend before sending. Locally, it is: memcpy(ctx-header, nal[0].payload, ctx-header_size); - Derek I'd use nal-payload myself, though I'm not sure which, if any, would be preferred. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] avcodec/libx265: fill headers in extradata
On 23 Mar 2014, at 15:36, Derek Buitenhuis derek.buitenh...@gmail.com wrote: From: Michael Niedermayer michae...@gmx.at This allows muxing properly into Matroska and MP4. Signed-off-by: Michael Niedermayer michae...@gmx.at Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com --- libavcodec/libx265.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) AFAICT, neither your nor Luca's backport seem to free the context extradata. Most (if not all) encoders seem to do this. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] avcodec/libx265: fill headers in extradata
On 23 Mar 2014, at 18:29, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 3/23/2014 5:09 PM, Tim Walker wrote: AFAICT, neither your nor Luca's backport seem to free the context extradata. For some reason I was under the impression that it was done automatically. - Derek Looks like it, though an awful lot of encoders free it explicitly anyway. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Announce Release 10
On 23 Mar 2014, at 19:25, Anton Khirnov an...@khirnov.net wrote: On Sun, 23 Mar 2014 14:09:29 -0400, Reinhard Tartler siret...@tauware.de wrote: +a name=10final/ah3March 23, 2014/h3 +p +After several months spent finalizing, we are now pleased to announce +the release of Libav Eks. Libav 10 Looks good to me otherwise. For consistency with the release/9 announcement, should be: we are now pleased to announce the release of Libav 10 Eks. Alternatively, we could use: we are now pleased to announce the release of Libav 10 (codename Eks). …or something similar. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lagarith: Fix typo in printf format string
On 22 Mar 2014, at 18:36, Diego Biurrun di...@biurrun.de wrote: libavcodec/lagarith.c:671:16: warning: '#' flag used with ‘%u’ gnu_printf format [-Wformat] --- libavcodec/lagarith.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) LGTM. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] build: Add config option for CABAC code
On 22 Mar 2014, at 18:52, Diego Biurrun di...@biurrun.de wrote: This allows for more elegant dependency and object declarations. --- configure |5 +++-- libavcodec/Makefile |5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) LGTM. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vdpau: add av_vdpau_get_level()
On 20 Mar 2014, at 18:03, Rémi Denis-Courmont r...@remlab.net wrote:
+int av_vdpau_get_level(AVCodecContext *avctx, unsigned *levelp)
+{
+unsigned level = avctx-level;
+
+if (level == FF_LEVEL_UNKNOWN)
+return AVERROR(EINVAL);
FWIW, AVCodecContext.level is signed, and FF_LEVEL_UNKNOWN is negative (-99).
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] changelog: move libx265 to version next
On 21 Mar 2014, at 02:15, Vittorio Giovara vittorio.giov...@gmail.com wrote: --- It was agreed to remove libx265 from release/10, so update the Changelog accordingly. Vittorio Changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Changelog b/Changelog index 279c0d8..d0939a2 100644 --- a/Changelog +++ b/Changelog @@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest within each release, releases are sorted from youngest to oldest. version next: +- libx265 encoder - compand audio filter - shuffleplanes filter Isn't compand in release/10 already? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vdpau: add av_vdpau_get_level()
On 21 Mar 2014, at 11:46, Rémi Denis-Courmont r...@remlab.net wrote:
On Fri, 21 Mar 2014 10:53:45 +0100, Tim Walker tdskywal...@gmail.com
wrote:
On 20 Mar 2014, at 18:03, Rémi Denis-Courmont r...@remlab.net wrote:
+int av_vdpau_get_level(AVCodecContext *avctx, unsigned *levelp)
+{
+unsigned level = avctx-level;
+
+if (level == FF_LEVEL_UNKNOWN)
+return AVERROR(EINVAL);
FWIW, AVCodecContext.level is signed, and FF_LEVEL_UNKNOWN is negative
(-99).
The code still works, since the compiler will convert both the variable
and the constant to unsigned before the comparison. Do you want an explicit
cast?
VDPAU levels are unsigned, so the sign conversion has to be done
*somewhere*.
I guess this is as good a place to do it as anywhere else. But since you're
returning right away, maybe you could check avctx-level directly (and even
make the check more generic, i.e. make sure it's = 0).
This is mostly a nit though.
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/3] lavu: move all color-related enums to AVFrame
On 21 Mar 2014, at 16:57, wm4 nfx...@googlemail.com wrote: Inspired by FFmpeg changes and koda's patches. --- doc/APIchanges | 5 +++ libavcodec/avcodec.h | 67 -- libavutil/frame.c| 10 ++ libavutil/frame.h| 92 libavutil/version.h | 2 +- 5 files changed, 108 insertions(+), 68 deletions(-) Haven't reviewed the patch yet, but yeah, that's more like it, IMO. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] fixed miscellaneous coding standard violation
On 20 Mar 2014, at 08:03, Martin Storsjö mar...@martin.st wrote: On Wed, 19 Mar 2014, Tanja Batchelor wrote: --- libavformat/mpeg.c | 6 +++--- libavformat/srtp.c | 10 +- 2 files changed, 8 insertions(+), 8 deletions(-) This is part of the srtp test program and intentionally uses printf to write the output to stdout instead of stderr - please don't change it to av_log. // Martin Nice catch… still, perhaps this would warrant a comment. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/3] lavu: introduce AVPixformatron and move all color-related types from lavc
On 18 Mar 2014, at 09:22, Vittorio Giovara vittorio.giov...@gmail.com wrote: --- This is the AVPixformatron I thought for future embedding in AVFrame. I used this struct in AVCodec too, but maybe a smaller struct could be used instead? Vittorio doc/APIchanges | 3 +++ libavcodec/avcodec.h | 68 +--- libavutil/Makefile | 1 + libavutil/version.h | 2 +- 4 files changed, 6 insertions(+), 68 deletions(-) And here I thought AVPixformatron was colloquial. Pardon my ignorance, but what's it supposed to mean? :P Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] lavc: er: remove unused variable size
On 18 Mar 2014, at 12:38, Janne Grunau janne-li...@jannau.net wrote: The code using it was remove in d66e305bd1b. --- libavcodec/error_resilience.c | 1 - 1 file changed, 1 deletion(-) Looks like I beat Diego to it: remove_d ;-) Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 069/132] dsputil: Refactor duplicated CALL_2X_PIXELS / PIXELS16 macros
On 15 Mar 2014, at 12:17, Anton Khirnov an...@khirnov.net wrote: On Fri, 14 Mar 2014 05:42:24 -0700, Diego Biurrun di...@biurrun.de wrote: --- #if HAVE_YASM -#define HPELDSP_AVG_PIXELS16(CPUEXT)\ -PIXELS16(static, put_no_rnd, ff_, _x2, CPUEXT) \ -PIXELS16(static, put,ff_, _y2, CPUEXT) \ -PIXELS16(static, put_no_rnd, ff_, _y2, CPUEXT) \ -PIXELS16(static, avg,ff_, , CPUEXT) \ -PIXELS16(static, avg,ff_, _x2, CPUEXT) \ -PIXELS16(static, avg,ff_, _y2, CPUEXT) \ -PIXELS16(static, avg,ff_, _xy2, CPUEXT) +#define HPELDSP_AVG_PIXELS16(CPUEXT) \ +CALL_2X_PIXELS(put_no_rnd_pixels16_x2 ## CPUEXT, \ + ff_put_no_rnd_pixels8_x2 ## CPUEXT, 8) \ +CALL_2X_PIXELS(put_pixels16_y2 ## CPUEXT, \ + ff_put_pixels8_y2 ## CPUEXT, 8)\ +CALL_2X_PIXELS(put_no_rnd_pixels16_y2 ## CPUEXT, \ + ff_put_no_rnd_pixels8_y2 ## CPUEXT, 8) \ +CALL_2X_PIXELS(avg_pixels16 ## CPUEXT,\ + ff_avg_pixels8 ## CPUEXT, 8) \ +CALL_2X_PIXELS(avg_pixels16_x2 ## CPUEXT, \ + ff_avg_pixels8_x2 ## CPUEXT, 8)\ +CALL_2X_PIXELS(avg_pixels16_y2 ## CPUEXT, \ + ff_avg_pixels8_y2 ## CPUEXT, 8)\ +CALL_2X_PIXELS(avg_pixels16_xy2 ## CPUEXT,\ + ff_avg_pixels8_xy2 ## CPUEXT, 8) This is now much less readable Indeed. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 08/11] sgi: decode images with 4 channels at 8 and 16 bits
On 13 Mar 2014, at 16:27, Vittorio Giovara vittorio.giov...@gmail.com wrote: From: Carl Eugen Hoyos ceho...@ag.or.at --- Changelog | 1 + libavcodec/sgidec.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Changelog b/Changelog index 0f52fd0..4ff92cb 100644 --- a/Changelog +++ b/Changelog @@ -5,6 +5,7 @@ version next: - compand audio filter - shuffleplanes filter - OpenEXR image decoder +- support decoding 4 channel SGI images nit: 4-channel maybe? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] [RFC] configure: set 'cc' as default compiler
On 14 Mar 2014, at 01:51, Vittorio Giovara vittorio.giov...@gmail.com wrote: --- cc seems to work on osx and linux, it would allow skipping --cc=clang at configure on modern osx, but I'm not sure of the overall impact. Ideas? Vittorio Latest Xcode has gcc in /Applications/Xcode.app/Contents/Developer/usr/bin (if I am not mistaken, even when you don't install command-line tools), so I don't see that setting --cc is needed there either. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 09/11] sgi: encode images with 4 channel at 8 and 16 bits
On 13 Mar 2014, at 16:27, Vittorio Giovara vittorio.giov...@gmail.com wrote: --- Changelog | 2 +- libavcodec/sgienc.c | 54 ++--- 2 files changed, 48 insertions(+), 8 deletions(-) diff --git a/Changelog b/Changelog index 4ff92cb..9b607df 100644 --- a/Changelog +++ b/Changelog @@ -5,7 +5,7 @@ version next: - compand audio filter - shuffleplanes filter - OpenEXR image decoder -- support decoding 4 channel SGI images +- support encoding and decoding 4 channel SGI images same: nit: 4-channel maybe? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/3] codec_desc: add missing .long_name
On 14 Mar 2014, at 01:17, Vittorio Giovara vittorio.giov...@gmail.com wrote:
---
libavcodec/codec_desc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 3578a09..c94fe2b 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -908,12 +908,14 @@ static const AVCodecDescriptor codec_descriptors[] = {
.id= AV_CODEC_ID_V210X,
.type = AVMEDIA_TYPE_VIDEO,
.name = v210x,
+.long_name = NULL_IF_CONFIG_SMALL(Uncompressed 4:2:2 10-bit),
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
},
{
.id= AV_CODEC_ID_TMV,
.type = AVMEDIA_TYPE_VIDEO,
.name = tmv,
+.long_name = NULL_IF_CONFIG_SMALL(8088flex TMV),
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
},
{
@@ -1158,6 +1160,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
.id= AV_CODEC_ID_XBM,
.type = AVMEDIA_TYPE_VIDEO,
.name = xbm,
+.long_name = NULL_IF_CONFIG_SMALL(XBM (X BitMap) image),
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
},
{
@@ -1791,6 +1794,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
.id= AV_CODEC_ID_DVAUDIO,
.type = AVMEDIA_TYPE_AUDIO,
.name = dvaudio,
+.long_name = NULL_IF_CONFIG_SMALL(DVAUDIO),
Maybe DV audio?
If it's the audio portion of a DV stream, perhaps it qualifies as some form of
PCM, actually. Can someone clarify this please?
Rest probably OK.
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] [RFC] configure: set 'cc' as default compiler
On 14 Mar 2014, at 12:46, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Friday, March 14, 2014, Tim Walker tdskywal...@gmail.com wrote: On 14 Mar 2014, at 01:51, Vittorio Giovara vittorio.giov...@gmail.comjavascript:; wrote: --- cc seems to work on osx and linux, it would allow skipping --cc=clang at configure on modern osx, but I'm not sure of the overall impact. Ideas? Vittorio Latest Xcode has gcc in /Applications/Xcode.app/Contents/Developer/usr/bin (if I am not mistaken, even when you don't install command-line tools), so I don't see that setting --cc is needed there either. That gcc is *very* old, like 4.2.1 iirc. Moreover osx doesn't ship gdb any more, lldb only. So you cannot usually debug a gcc-produced executable, unless you reconfigure with --cc and re-compile which may be mildly annoying. No, it's just an alias for (or a rather a copy of, it looks like) clang. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [libav-commits] build: Use pkg-config for openjpeg
On 14 Mar 2014, at 13:08, Reinhard Tartler siret...@gmail.com wrote: I think it is even worse: In debian stable, and all released versions of ubuntu, there is no pkg-config file for libopenjpeg at all. I'm therefore inclined to revert to non-pkg-config detection for release/10. What do you think? Reinhard There were two follow-up patches from Luca, including one which does non-pkgconfig detection before doing pkg-config based detection. Not sure whether it got pushed or backported yet. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 5/9] ljpeg: fix double pixel format entry
On 12 Mar 2014, at 15:30, Vittorio Giovara vittorio.giov...@gmail.com wrote:
---
libavcodec/ljpegenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ljpegenc.c b/libavcodec/ljpegenc.c
index 7eb4675..7c1b3bc 100644
--- a/libavcodec/ljpegenc.c
+++ b/libavcodec/ljpegenc.c
@@ -329,6 +329,6 @@ AVCodec ff_ljpeg_encoder = {
AV_PIX_FMT_BGR24,
AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUV422P,
-AV_PIX_FMT_YUVJ444P,
+AV_PIX_FMT_YUV444P,
AV_PIX_FMT_NONE },
};
--
1.8.3.4 (Apple Git-47)
I fail to see the correlation between the patch and the commit message.
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 5/9] ljpeg: fix double pixel format entry
On 12 Mar 2014, at 16:27, Vittorio Giovara vittorio.giov...@gmail.com wrote:
On Wed, Mar 12, 2014 at 4:23 PM, Tim Walker tdskywal...@gmail.com wrote:
On 12 Mar 2014, at 15:30, Vittorio Giovara vittorio.giov...@gmail.com
wrote:
---
libavcodec/ljpegenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ljpegenc.c b/libavcodec/ljpegenc.c
index 7eb4675..7c1b3bc 100644
--- a/libavcodec/ljpegenc.c
+++ b/libavcodec/ljpegenc.c
@@ -329,6 +329,6 @@ AVCodec ff_ljpeg_encoder = {
AV_PIX_FMT_BGR24,
AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUV422P,
-AV_PIX_FMT_YUVJ444P,
+AV_PIX_FMT_YUV444P,
AV_PIX_FMT_NONE },
};
--
1.8.3.4 (Apple Git-47)
I fail to see the correlation between the patch and the commit message.
Amended to ‘fix duplicated pixel format entry’.
Vittorio
I would prefer something like: ljpeg: fix typo in pixel format list, since
this is what the patch does. Else make two patches, ljpeg: remove duplicate
pixel format entry and ljpeg: add missing pixel format entry.
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 00/12] isom/riff updates
On 10 Mar 2014, at 11:21, Diego Biurrun di...@biurrun.de wrote: On Sun, Mar 09, 2014 at 03:37:47PM +0100, Tim Walker wrote: On 09 Mar 2014, at 14:03, Diego Biurrun di...@biurrun.de wrote: On Sun, Mar 09, 2014 at 12:40:26PM +0100, Luca Barbato wrote: On 09/03/14 10:47, Anton Khirnov wrote: On Sun, 9 Mar 2014 08:14:14 +0100, Vittorio Giovara vittorio.giov...@gmail.com wrote: rawvideo: Support decoding YVYU FOURCC Other than this one, the rest of the set looks trivial enough to be ok +1 I'd squash them all together into one update. How about authorship? Entries in a table are not works of authorship. Diego OK. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] hevc: Use get_se_golomb_long
On 10 Mar 2014, at 11:01, Luca Barbato lu_z...@gentoo.org wrote: Do not use inline functions that refer to tables present in other libraries. --- libavformat/hevc.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) I used get_se_golomb because the spec. said those fields were se(v) and I was unsure whether get_ue_golomb/get_ue_golomb_long would read the correct number of bits (I really had no clue what I was doing). But it seems your get_se_golomb_long just uses get_ue_golomb_long - were's skipping these fields anyway, is there any difference in behavior or does it just make it obvious we're skipping signed golomb codes? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] lavf: use av_free instead of free
From: Michael Niedermayer michae...@gmx.at Signed-off-by: Michael Niedermayer michae...@gmx.at Signed-off-by: Tim Walker tdskywal...@gmail.com CC: libav-sta...@libav.org --- libavformat/hevc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/hevc.c b/libavformat/hevc.c index 2c1b4c4..69a23a4 100644 --- a/libavformat/hevc.c +++ b/libavformat/hevc.c @@ -1056,7 +1056,7 @@ int ff_hevc_annexb2mp4(AVIOContext *pb, const uint8_t *buf_in, } end: -free(start); +av_free(start); if (ps_count) *ps_count = num_ps; return ret; @@ -1109,7 +1109,7 @@ int ff_hevc_annexb2mp4_buf(const uint8_t *buf_in, uint8_t **buf_out, *size = avio_close_dyn_buf(pb, buf_out); end: -free(start); +av_free(start); if (ps_count) *ps_count = num_ps; return ret; -- 1.8.3.4 (Apple Git-47) ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] lavf: fix errors in documentation
From: Michael Niedermayer michae...@gmx.at Signed-off-by: Michael Niedermayer michae...@gmx.at Signed-off-by: Tim Walker tdskywal...@gmail.com --- libavformat/hevc.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/hevc.h b/libavformat/hevc.h index f394342..498cfb9 100644 --- a/libavformat/hevc.h +++ b/libavformat/hevc.h @@ -71,7 +71,7 @@ int ff_hevc_annexb2mp4(AVIOContext *pb, const uint8_t *buf_in, *or to discard them (non-zero) * @param ps_count address of the variable where the number of discarded *parameter set NAL units shall be written, may be NULL - * @return 0 in case of success, a negative value corresponding to an AVERROR + * @return =0 in case of success, a negative value corresponding to an AVERROR * code in case of failure */ int ff_hevc_annexb2mp4_buf(const uint8_t *buf_in, uint8_t **buf_out, @@ -89,7 +89,7 @@ int ff_hevc_annexb2mp4_buf(const uint8_t *buf_in, uint8_t **buf_out, * @param size size (in bytes) of the data buffer * @param ps_array_completeness whether all parameter sets are in the hvcC (1) *or there may be additional parameter sets in the bitstream (0) - * @return 0 in case of success, a negative value corresponding to an AVERROR + * @return =0 in case of success, a negative value corresponding to an AVERROR * code in case of failure */ int ff_isom_write_hvcc(AVIOContext *pb, const uint8_t *data, -- 1.8.3.4 (Apple Git-47) ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] hevc: Use get_se_golomb_long
On 10 Mar 2014, at 13:24, Luca Barbato lu_z...@gentoo.org wrote: On 10/03/14 12:43, Tim Walker wrote: On 10 Mar 2014, at 11:01, Luca Barbato lu_z...@gentoo.org wrote: Do not use inline functions that refer to tables present in other libraries. --- libavformat/hevc.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) I used get_se_golomb because the spec. said those fields were se(v) and I was unsure whether get_ue_golomb/get_ue_golomb_long would read the correct number of bits (I really had no clue what I was doing). se or ue are just the same encoding in the bitstream, you just use the first bit as sign. But it seems your get_se_golomb_long just uses get_ue_golomb_long - were's skipping these fields anyway, is there any difference in behavior or does it just make it obvious we're skipping signed golomb codes? mostly for completeness sake and prevent more cases in the future. lu Out of curiosity, what does get_se_golomb do which requires a table that we don't need in a get_se_golomb_long implementation? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf: fix errors in documentation
On 10 Mar 2014, at 13:22, Luca Barbato lu_z...@gentoo.org wrote: On 10/03/14 13:09, Tim Walker wrote: From: Michael Niedermayer michae...@gmx.at Signed-off-by: Michael Niedermayer michae...@gmx.at Signed-off-by: Tim Walker tdskywal...@gmail.com --- libavformat/hevc.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) What 0 means? It's a side-effect of using ff_avc_parse_nal_units. I need to make a better patch, please disregard this one. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] hevc: Use get_se_golomb_long
On 10 Mar 2014, at 13:30, Hendrik Leppkes h.lepp...@gmail.com wrote: On Mon, Mar 10, 2014 at 1:27 PM, Tim Walker tdskywal...@gmail.com wrote: On 10 Mar 2014, at 13:24, Luca Barbato lu_z...@gentoo.org wrote: On 10/03/14 12:43, Tim Walker wrote: On 10 Mar 2014, at 11:01, Luca Barbato lu_z...@gentoo.org wrote: Do not use inline functions that refer to tables present in other libraries. --- libavformat/hevc.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) I used get_se_golomb because the spec. said those fields were se(v) and I was unsure whether get_ue_golomb/get_ue_golomb_long would read the correct number of bits (I really had no clue what I was doing). se or ue are just the same encoding in the bitstream, you just use the first bit as sign. But it seems your get_se_golomb_long just uses get_ue_golomb_long - were's skipping these fields anyway, is there any difference in behavior or does it just make it obvious we're skipping signed golomb codes? mostly for completeness sake and prevent more cases in the future. lu Out of curiosity, what does get_se_golomb do which requires a table that we don't need in a get_se_golomb_long implementation? It doesn't require it, but since golomb parsing is often used in speed-critical code, the non-long functions are optimized for speed with help of tables (but limited in parsing length, hence the name long for those that are not). - Hendrik Thanks :-) Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: Use the right pkgconf file for openjpeg
On 10 Mar 2014, at 11:49, Luca Barbato lu_z...@gentoo.org wrote: The current release of version 1 uses libopenjpeg1. --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) LGTM. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] lavf: always use av_free
From: Michael Niedermayer michae...@gmx.at Signed-off-by: Michael Niedermayer michae...@gmx.at Signed-off-by: Tim Walker tdskywal...@gmail.com --- This supersedes the previous version of the patch. libavformat/hevc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/hevc.c b/libavformat/hevc.c index e3be20c..37b35b4 100644 --- a/libavformat/hevc.c +++ b/libavformat/hevc.c @@ -1056,7 +1056,7 @@ int ff_hevc_annexb2mp4(AVIOContext *pb, const uint8_t *buf_in, } end: -free(start); +av_free(start); if (ps_count) *ps_count = num_ps; return ret; -- 1.8.3.4 (Apple Git-47) ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] lavf: simplify ff_hevc_annexb2mp4_buf
Use ff_hevc_annexb2mp4 instead of duplicating
its functionality, and update the documentation
to match the new behavior.
---
Suggested by Janne on IRC.
libavformat/hevc.c | 43 +++
libavformat/hevc.h | 4 ++--
2 files changed, 5 insertions(+), 42 deletions(-)
diff --git a/libavformat/hevc.c b/libavformat/hevc.c
index dc45fbf..e3be20c 100644
--- a/libavformat/hevc.c
+++ b/libavformat/hevc.c
@@ -1066,52 +1066,15 @@ int ff_hevc_annexb2mp4_buf(const uint8_t *buf_in,
uint8_t **buf_out,
int *size, int filter_ps, int *ps_count)
{
AVIOContext *pb;
-int num_ps = 0, ret = 0;
-uint8_t *buf, *end, *start = NULL;
-
-if (!filter_ps) {
-ret = ff_avc_parse_nal_units_buf(buf_in, buf_out, size);
-goto end;
-}
+int ret;
ret = avio_open_dyn_buf(pb);
if (ret 0)
-goto end;
-
-ret = ff_avc_parse_nal_units_buf(buf_in, start, size);
-if (ret 0)
-goto end;
-
-buf = start;
-end = start + *size;
-
-while (end - buf 4) {
-uint32_t len = FFMIN(AV_RB32(buf), end - buf - 4);
-uint8_t type = (buf[4] 1) 0x3f;
-
-buf += 4;
-
-switch (type) {
-case NAL_VPS:
-case NAL_SPS:
-case NAL_PPS:
-num_ps++;
-break;
-default:
-avio_wb32(pb, len);
-avio_write(pb, buf, len);
-break;
-}
-
-buf += len;
-}
+return ret;
+ret = ff_hevc_annexb2mp4(pb, buf_in, *size, filter_ps, ps_count);
*size = avio_close_dyn_buf(pb, buf_out);
-end:
-free(start);
-if (ps_count)
-*ps_count = num_ps;
return ret;
}
diff --git a/libavformat/hevc.h b/libavformat/hevc.h
index f394342..03c43bd 100644
--- a/libavformat/hevc.h
+++ b/libavformat/hevc.h
@@ -71,8 +71,8 @@ int ff_hevc_annexb2mp4(AVIOContext *pb, const uint8_t *buf_in,
*or to discard them (non-zero)
* @param ps_count address of the variable where the number of discarded
*parameter set NAL units shall be written, may be NULL
- * @return 0 in case of success, a negative value corresponding to an AVERROR
- * code in case of failure
+ * @return the amount (in bytes) of data written in case of success, a negative
+ * value corresponding to an AVERROR code in case of failure
*/
int ff_hevc_annexb2mp4_buf(const uint8_t *buf_in, uint8_t **buf_out,
int *size, int filter_ps, int *ps_count);
--
1.8.3.4 (Apple Git-47)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avformat: more correct printf format specifiers
On 10 Mar 2014, at 15:37, Diego Biurrun di...@biurrun.de wrote: --- libavformat/apetag.c |6 -- libavformat/asfdec.c |8 +--- libavformat/avidec.c |4 ++-- libavformat/bink.c | 10 +++--- libavformat/cafdec.c |5 - libavformat/crcenc.c |4 +++- libavformat/dfa.c|7 +-- libavformat/dxa.c|5 - libavformat/electronicarts.c |8 +--- libavformat/framecrcenc.c|4 +++- libavformat/gxf.c|6 +- libavformat/hnm.c| 11 +++ libavformat/iff.c|4 +++- libavformat/lxfdec.c |9 ++--- libavformat/matroskadec.c|3 ++- libavformat/mov.c|7 --- libavformat/mvi.c|5 - libavformat/mxfdec.c | 13 - libavformat/omadec.c |8 +--- libavformat/rmdec.c |4 +++- libavformat/rpl.c|4 ++-- libavformat/smacker.c|8 ++-- libavformat/smjpegdec.c |8 +--- libavformat/spdifenc.c |8 +--- libavformat/wtv.c|6 -- libavformat/xmv.c|6 +++--- 26 files changed, 114 insertions(+), 57 deletions(-) I thought Michael used avformat and we used lavf? :P Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/5] lavc: restore copy_block{4, 16} functions
On 10 Mar 2014, at 18:00, Vittorio Giovara vittorio.giov...@gmail.com wrote: They were removed in 9e31729d692f1e721b7ed1a3a0f51b68c064d68f. --- libavcodec/copy_block.h | 22 ++ 1 file changed, 22 insertions(+) Removed accidentally or on purpose? If the latter, why do we need them now? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avformat: more correct printf format specifiers
On 11 Mar 2014, at 03:38, James Almer jamr...@gmail.com wrote:
On 10/03/14 11:37 AM, Diego Biurrun wrote:
---
libavformat/apetag.c |6 --
libavformat/asfdec.c |8 +---
libavformat/avidec.c |4 ++--
libavformat/bink.c | 10 +++---
libavformat/cafdec.c |5 -
libavformat/crcenc.c |4 +++-
libavformat/dfa.c|7 +--
libavformat/dxa.c|5 -
libavformat/electronicarts.c |8 +---
libavformat/framecrcenc.c|4 +++-
libavformat/gxf.c|6 +-
libavformat/hnm.c| 11 +++
libavformat/iff.c|4 +++-
libavformat/lxfdec.c |9 ++---
libavformat/matroskadec.c|3 ++-
libavformat/mov.c|7 ---
libavformat/mvi.c|5 -
libavformat/mxfdec.c | 13 -
libavformat/omadec.c |8 +---
libavformat/rmdec.c |4 +++-
libavformat/rpl.c|4 ++--
libavformat/smacker.c|8 ++--
libavformat/smjpegdec.c |8 +---
libavformat/spdifenc.c |8 +---
libavformat/wtv.c|6 --
libavformat/xmv.c|6 +++---
26 files changed, 114 insertions(+), 57 deletions(-)
[...]
@@ -539,14 +539,15 @@ static int mxf_read_partition_pack(void *arg,
AVIOContext *pb, int tag, int size
}
if (partition-kag_size = 0 || partition-kag_size (1 20)) {
-av_log(mxf-fc, AV_LOG_WARNING, invalid KAGSize %i - guessing ,
partition-kag_size);
+av_log(mxf-fc, AV_LOG_WARNING, invalid KAGSize %PRId32 -
guessing ,
+ partition-kag_size);
PRIi32? Ditto for any similar case.
Same result, but %d/%PRId32 are more commonly used than %i/%PRIi32
[...]
@@ -501,7 +503,7 @@ static void get_tag(AVFormatContext *s, AVIOContext *pb,
const char *key, int ty
return;
if (type == 0 length == 4) {
-snprintf(buf, buf_size, %PRIi32, avio_rl32(pb));
+snprintf(buf, buf_size, %u, avio_rl32(pb));
Isn't this doing the opposite of what the patch was meant to do?
No, avio_rl32 returns unsigned int, not uint32_t, so %u is the correct
specifier.
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 00/12] isom/riff updates
On 09 Mar 2014, at 14:03, Diego Biurrun di...@biurrun.de wrote: On Sun, Mar 09, 2014 at 12:40:26PM +0100, Luca Barbato wrote: On 09/03/14 10:47, Anton Khirnov wrote: On Sun, 9 Mar 2014 08:14:14 +0100, Vittorio Giovara vittorio.giov...@gmail.com wrote: rawvideo: Support decoding YVYU FOURCC Other than this one, the rest of the set looks trivial enough to be ok +1 I'd squash them all together into one update. Diego How about authorship? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mxfdec: Validate month/day before date formatting
On 09 Mar 2014, at 12:35, Martin Storsjö mar...@martin.st wrote: From: Hendrik Leppkes h.lepp...@gmail.com The MSVCRT version of strftime calls the invalid parameter handler if the struct values in struct tm are invalid. In case no invalid parameter handler is set for the process, the process is aborted. This fixes fate failures on MSVC builds since 570af382. --- libavformat/mxfdec.c | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c index 27f996f..1276391 100644 --- a/libavformat/mxfdec.c +++ b/libavformat/mxfdec.c @@ -1669,6 +1669,10 @@ static int mxf_timestamp_to_str(uint64_t timestamp, char **str) time.tm_min = (timestamp 16 0xFF); time.tm_sec = (timestamp 8 0xFF); +/* ensure month/day are valid */ +time.tm_mon = FFMAX(time.tm_mon, 0); +time.tm_mday = FFMAX(time.tm_mday, 1); Nit: align 0 and 1? Comment looks almost too obvious, maybe add a few words re: else it will abort and we don't want that? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/6] movenc: use 'hev1' tag for HEVC in MODE_MOV.
On 09 Mar 2014, at 16:26, Luca Barbato lu_z...@gentoo.org wrote: On 03/03/14 16:53, Tim Walker wrote: 'hvc1' requires that parameter set NAL units be present only in the samples entry, but not in the samples themselves, requiring that additional parameter sets, if present, be filtered out of the samples and placed in new, additional sample entries if they override or otherwise conflict with the parameter sets present in the first sample entry. We do not have any way of doing this at present, so the files we produce can only comply with the restrictions set for the 'hev1' sample entry name in ISO/IEC 14496-15. --- Note: unlike avplay, VLC does not support hev1 for some reason. We'll check with them later, patch looks fine. lu OK. BTW I could use some help in making the commit message more concise, if you have suggestions. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/6] movenc: write hvcC tag for HEVC.
On 09 Mar 2014, at 16:40, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Mon, Mar 3, 2014 at 4:53 PM, Tim Walker tdskywal...@gmail.com wrote: --- libavformat/Makefile |2 +- libavformat/hevc.c | 1076 ++ libavformat/hevc.h | 50 +++ libavformat/movenc.c | 13 + 4 files changed, 1140 insertions(+), 1 deletion(-) create mode 100644 libavformat/hevc.c create mode 100644 libavformat/hevc.h Ok, queueing with minor nits. Vittorio What nits? Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/6] movenc: enable Annex B to MP4 conversion for HEVC tracks.
On 09 Mar 2014, at 16:39, Luca Barbato lu_z...@gentoo.org wrote: On 03/03/14 16:53, Tim Walker wrote: --- Note: this includes a facility for filtering parameter set NALUs from the bitstream and knowing whether any NALUs were extracted (so that we can e.g. decide whether to generate a new MP4 sample entry with a new hvcC). It's unused as I'm not sure how the MP4 side of things would work. It is ok to keep it around I guess. We definitely should, we're going to need it eventually if we want to write 'hvc1' in a compliant way. I didn't write a patch for it as I don't know whether or how movenc can write multiple sample entries. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mxfdec: Validate parameters to strftime.
On 09 Mar 2014, at 21:47, Martin Storsjö mar...@martin.st wrote: The MSVCRT version of strftime calls the invalid parameter handler if the struct values in struct tm are invalid. In case no invalid parameter handler is set for the process, the process is aborted. This fixes fate failures on MSVC builds since 570af382. Based on a patch by Hendrik Leppkes. --- Added checking of the other struct values as well, and limiting the upper end of the values as well - tested each of them individually to find the actual limit. Luckily, it doesn't check to make sure the day of the month is within the actual number of days of that month during that year, limiting it to 1-31 seems to work regardless of the actual month. --- libavformat/mxfdec.c | 9 + 1 file changed, 9 insertions(+) OK. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] matroskadec: cosmetics: Fix attachement vs. attachment typo
On 07 Mar 2014, at 14:10, Luca Barbato lu_z...@gentoo.org wrote: On 07/03/14 13:55, Diego Biurrun wrote: --- This sounds like some French speaker came up with the struct name. I think so, thanks for polishing it a bit more. lu Nah, it would've been named piece_jointe. Or it was an overly-sentimental French speaker. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] g2meet: KR formatting cosmetics
On 07 Mar 2014, at 15:36, Diego Biurrun di...@biurrun.de wrote: On Fri, Mar 07, 2014 at 03:34:33PM +0100, Kostya Shishkov wrote: On Fri, Mar 07, 2014 at 03:31:12PM +0100, Diego Biurrun wrote: --- a/libavcodec/g2meet.c +++ b/libavcodec/g2meet.c @@ -320,10 +320,14 @@ static void kempf_restore_buf(const uint8_t *src, int len, -if (npal = 2) nb = 1; -else if (npal = 4) nb = 2; -else if (npal = 16) nb = 4; -else nb = 8; +if (npal = 2) +nb = 1; +else if (npal = 4) +nb = 2; +else if (npal = 16) +nb = 4; +else +nb = 8; I'd rather leave it as it - it was kinda tabular form that makes it easier to undertand IMO. I consider it just idiosyncratic formatting. If you prefer I'll leave it as-is. Patch OK with or without this hunk? Without. For short lines like this, I like this kind of formatting too. Otherwise, make it a switch :-) Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/5] hevc: Don't turn 32bit timebases into negative numbers
On 07 Mar 2014, at 18:49, Luca Barbato lu_z...@gentoo.org wrote:
On 07/03/14 17:47, Vittorio Giovara wrote:
From: Michael Niedermayer michae...@gmx.at
Fixes assertion failure
Found-by: Mateusz j00ru Jurczyk and Gynvael Coldwind
---
libavcodec/hevc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Which is the largest timebase by specification?
lu
Both {vui,vps}_num_units_in_tick and {vui,vps}_time_scale shall be greater
than zero, but are otherwise only limited by the fact that they're 32-bit
fields.
Tim
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] af_channelmap: fix ONE_STR mapping mode
On 05 Mar 2014, at 14:07, Anton Khirnov an...@khirnov.net wrote: get_channel() returns 0 on success CC:libav-sta...@libav.org --- Indeed, good catch --- libavfilter/af_channelmap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) LGTM. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] dxva2: bump maximum number of slieces for mpeg2
On 06 Mar 2014, at 16:27, Hendrik Leppkes h.lepp...@gmail.com wrote: On Thu, Mar 6, 2014 at 4:03 PM, Luca Barbato lu_z...@gentoo.org wrote: On 06/03/14 15:59, Felix Abecassis wrote: Without this patch, I have the following output with VLC using DXVA2 MPEG-2: http://imgur.com/HdMVAx9 With this patch, the problem seems to be solved. I'm simply suggesting a backport so I can't help you further with the ins and outs of this patch :) Ok. basically you need more slice to fill a whole frame properly. I need some information to put in the commit message. DXVA experts can chip in and/or propose a patch to make that context a little saner (discussion about breaking ABI are mooth). This is a private context, so not part of the ABI - so you are right, the discussion is pointless :P Other ideas are to dynamically alloc it as needed, but since there is no sane way to remember the number of slices from frame to frame right now, it would mean many many reallocs for every frame, just to potentially save a few bytes of memory - so it does not seem worth it. I've never hit a file with more then 1024 slices. - Hendrik Did you ever hit one with 1024 slices? That sounds excessive regardless of resolution, would love to see such a sample. Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] libx265: More API fixes
On 07 Mar 2014, at 01:16, Hendrik Leppkes h.lepp...@gmail.com wrote: On Fri, Mar 7, 2014 at 12:43 AM, Reinhard Tartler siret...@gmail.com wrote: On Thu, Mar 6, 2014 at 4:12 PM, Luca Barbato lu_z...@gentoo.org wrote: On 06/03/14 22:08, James Almer wrote: On 06/03/14 5:47 PM, Luca Barbato wrote: On 06/03/14 21:34, Reinhard Tartler wrote: Do we want this in release/10? Yes. The current stable version (x265 0.8) has X265_BUILD == 7. This change would make libav 10 only support the development branch, and most users and even distros usually prefer compiling using stable versions of every library. I'm not sure, given the current level of development at least in Gentoo I'd track it as it comes. So libx265 is an even worse API bumping nightmare than libx264? Its still very new and very much under development. What do you expect? :) +1 Just because they happen to have releases doesn't mean they have a mature codebase. I'd say, if we keep the wrapper in the release, we should check for a specific API (==). Doesn't really matter if the wrapper's API is ahead of what's in 0.8, there were like 2 weeks between 0.7 and 0.8, the next one can't be more than 3 months away. In any event, we shouldn't ship a release with support for X265_BUILD == 7, 10-bit encoding apparently only works properly with API 9 and later: https://bitbucket.org/multicoreware/x265/commits/eadec14 Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avfilter: Add missing emms_c when needed
On 05 Mar 2014, at 18:29, Hendrik Leppkes h.lepp...@gmail.com wrote: Is it very likely to get MMX code written these days, and not at least SSE/SSE2? Maybe put a notice in float_dsp to warn people. :p - Hendrik How much MMX do we still have? Port it to SSE* and drop support for it :P Tim ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
