[FFmpeg-devel] avformat/mov: improve qt metadata reading and writing
Hi all, this has been brought up before, the MOV muxer/demuxer currently does not support all possible datatypes that are allowed in keys/mdta style metadata. This is specified here: https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/Metadata/Metadata.html#//apple_ref/doc/uid/TP4939-CH1-SW35 At the moment only data types 1 (UTF-8) and 23 (Float32) work. I have a patch that adds support for 21 and 22, as I have found those in actual files produced by ARRI cameras. I have a second patch that adds a flag to the muxer to output keys/mdta style metadata, to be able to keep the metadata while transcoding camera files. This patch tries to do something similar, but is mine is shorter (though not as complete) so hopefully easy to review: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178347.html (I actually found this only after writing my patches.) Patchset is in the next mails. till then, David. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/mov: add more datatypes in metadata handling
0001-avformat-mov-add-more-datatypes-in-metadata-handling.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/movenc: add option to use keys/mdta atoms for metadata
0002-avformat-movenc-add-option-to-use-keys-mdta-atoms-fo.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/proresenc_anatoliy: change quantization scaling to floating point to utilize vectorization
Quantization scaling seems to be a slight bottleneck,
this change allows the compiler to more easily vectorize
the loop. This improves total encoding performance in my
tests by about 10-20%.
Signed-off-by: David Murmann
---
libavcodec/proresenc_anatoliy.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavcodec/proresenc_anatoliy.c
b/libavcodec/proresenc_anatoliy.c
index 0516066163..8b296f6f1b 100644
--- a/libavcodec/proresenc_anatoliy.c
+++ b/libavcodec/proresenc_anatoliy.c
@@ -232,14 +232,18 @@ static const uint8_t lev_to_cb[10] = { 0x04, 0x0A,
0x05, 0x06, 0x04, 0x28,
static void encode_ac_coeffs(AVCodecContext *avctx, PutBitContext *pb,
int16_t *in, int blocks_per_slice, int *qmat)
{
+int16_t block[64];
int prev_run = 4;
int prev_level = 2;
int run = 0, level, code, i, j;
-for (i = 1; i < 64; i++) {
-int indp = progressive_scan[i];
-for (j = 0; j < blocks_per_slice; j++) {
-int val = QSCALE(qmat, indp, in[(j << 6) + indp]);
+for (j = 0; j < blocks_per_slice; j++) {
+for (i = 0; i < 64; i++) {
+block[i] = (float)in[(j << 6) + i] / (float)qmat[i];
+}
+
+for (i = 1; i < 64; i++) {
+int val = block[progressive_scan[i]];
if (val) {
encode_codeword(pb, run, run_to_cb[FFMIN(prev_run, 15)]);
-- 2.16.2
--
btf GmbH | Leyendeckerstr. 27, 50825 Köln | +49 (0) 221 82 00 87 10
Geschäftsführer: Philipp Käßbohrer & Matthias Murmann | HR Köln | HRB 74707
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/proresenc_anatoliy: change quantization scaling to floating point to utilize vectorization
On 2/27/2018 9:58 PM, Hendrik Leppkes wrote:
> On Tue, Feb 27, 2018 at 9:35 PM, David Murmann
wrote:
>> Quantization scaling seems to be a slight bottleneck,
>> this change allows the compiler to more easily vectorize
>> the loop. This improves total encoding performance in my
>> tests by about 10-20%.
>>
>> Signed-off-by: David Murmann
>> ---
>> libavcodec/proresenc_anatoliy.c | 12
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
[...]
>> +for (j = 0; j < blocks_per_slice; j++) {
>> +for (i = 0; i < 64; i++) {
>> +block[i] = (float)in[(j << 6) + i] / (float)qmat[i];
>> +}
>> +
>> +for (i = 1; i < 64; i++) {
>> +int val = block[progressive_scan[i]];
>> if (val) {
>> encode_codeword(pb, run, run_to_cb[FFMIN(prev_run,
15)]);
>
> Usually, using float is best avoided. Did you test re-factoring the
> loop structure without changing it to float?
Yes, the vector instructions don't have integer division, AFAIK, and the
compiler just generates a loop with idivs. This is quite a bit slower
than converting to float, dividing and converting back, if the compiler
uses vector instructions. In the general case this wouldn't be exact,
but since the input values are int16 they should losslessly fit into
float32. On platforms where this auto-vectorization fails this might
actually be quite a bit slower, but I have not seen that in my tests
(though I have only tested on x86_64).
--
David Murmann
da...@btf.de
Telefon +49 (0) 221 82008710
Fax +49 (0) 221 82008799
http://btf.de/
--
btf GmbH | Leyendeckerstr. 27, 50825 Köln | +49 (0) 221 82 00 87 10
Geschäftsführer: Philipp Käßbohrer & Matthias Murmann | HR Köln | HRB 74707
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
