Re: [FFmpeg-devel] [PATCH] lavc/aacenc_quantization: use cbrt table
On 11.03.2016, at 03:48, Ganesh Ajjanagadde wrote:
> On Thu, Mar 10, 2016 at 3:12 AM, Reimar Döffinger
> wrote:
>> On 10.03.2016, at 00:49, Ganesh Ajjanagadde wrote:
>>
>>> There is no reason for computing cbrtf at runtime; we have a table for
>>> this.
>>>
>>> Cruft needed due to the build system, the people who still like using
>>> hardcoded tables and need for single cbrt_tab across the code.
>>
>> Could you please explain what exactly the problem is?
>> Why would you need cbrt_table.c for example? You can just conditionally
>> include it from cbrt_data.c for example.
>> Hardcoded tables are meant to only change when the initialization code is
>> run, not where the resulting data is located, i.e. it should only ever
>> replace a
>> int table[size];
>> by
>> const int table[size] = { data };
>> (though with the indirection of placing the second one in a header)
>
> The data can't go into a header; else one gets multiple copies, see
> above. Please not that I may still be missing something; this
> hardcoded ifdefry and build system is something I am not that familiar
> with.
You just include the header in the C file (and only that one) where you want
the data to be.
Obviously if you do not want multiple copies that will be some shared C file,
not the encoder or decoder code directly.
But the same applies to the non-hardcoded tables, they also need a shared file
or else you get two copies in the bss section.
I really don't see why the issue you describe should need anything other than
replacing a
int ff_something[size];
by
#if hardcodec
#include "something_table.h"
#else
ff_something[size];
#endif
hardcoding should _never_ ever require changing the code structure or the .c
files compiled in.
It should only consist of
1) generating a table header (can get a bit tricky admittedly, this should be
the most difficult step)
2) including that header instead of the code otherwise creating the
uninitialised table in .bss
3) disabling the code that initializes the table
Nothing magic beyond that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 06:43 AM, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats OK, I missed your "breaks fate" message, Michael. Then we'll have to regenerate those fate tests. Can you do it? I'm afraid of messing things up. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I'm regenerating them here. I hope I'm doing it right. If it doesn't work, I'll notify you. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section
Hi, 2016-03-10 19:57 GMT+01:00 Hendrik Leppkes : > This patch (the relocations part) broke debugging mingw-w64 ffmpeg > builds with gdb, you can't set breakpoints anymore when its applied. That issue prevented me to do anything interesting for ffmpeg since then, thinking it was a toolchain issue. I've lost considerable ffmpeg-time (and actual code) over it. > It should either be reverted or made dependent on > --enable/disable-debug (I would favor the first, honestly, since its a > rather ugly hack in itself). At the very least, that dependence is needed, yes. > Did the binutils/mingw guys ever comment anything useful on this issue? And does it still exist? And for which toolchain/binutils/mingw runtime/gdb version actually? There are like 3+ versions one can use (yours, msys2, tdm, msys1, ...) Thanks for looking into it, -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/lfg: switch to Ziggurat algorithm for normal random number generation
On 11.03.2016, at 05:16, Ganesh Ajjanagadde wrote: > Code taken from the Julia project, licensed under MIT: > https://github.com/JuliaLang/julia/blob/master/base/random.jl, in turn > derived from: "The Ziggurat Method for generating random variables" - > Marsaglia and Tsang. > > Paper and reference code: http://www.jstatsoft.org/v05/i08/. This is > well known to be the fastest method empirically for generating normal random > variables. Note that there are a large number of implementations with > various tunings, this was one of the simpler ones and also has a friendly > license. I absolutely can't see how this could be the fastest considering it uses the rather slow av_lfg_get twice, unless you only mean the part of getting floats in a certain distribution and not the actual randomness. I asked a long time ago for the decoder, but never got an answer why we use lfg and not a much faster lcg. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: build fix for P5600 along option --disable-msa
From: Shivraj Patil Signed-off-by: Shivraj Patil --- configure |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 1516b01..1b189328 100755 --- a/configure +++ b/configure @@ -5118,7 +5118,8 @@ elif enabled mips; then fi enabled mipsfpu && check_inline_asm_flags mipsfpu '"cvt.d.l $f0, $f2"' '-mhard-float' -enabled mipsfpu && enabled msa && check_inline_asm_flags msa '"addvi.b $w0, $w1, 1"' '-mfp64 -mmsa' && check_header msa.h || disable msa +enabled mipsfpu && (enabled mips32r5 || enabled mips32r6 || enabled mips64r6) && check_inline_asm_flags mipsfpu '"cvt.d.l $f0, $f1"' '-mfp64' +enabled mipsfpu && enabled msa && check_inline_asm_flags msa '"addvi.b $w0, $w1, 1"' '-mmsa' && check_header msa.h || disable msa enabled mipsdsp && check_inline_asm_flags mipsdsp '"addu.qb $t0, $t1, $t2"' '-mdsp' enabled mipsdspr2 && check_inline_asm_flags mipsdspr2 '"absq_s.qb $t0, $t1"' '-mdspr2' -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On Fri, Mar 11, 2016 at 5:10 AM, Mats Peterson wrote: > > Regarding the biClrUsed field, I'm setting it to 1 << > bits_per_coded_sample if palettized video, since setting it to 0 is > another case where it won't work with Windows Media Player and Microsoft > Video 1 in 8 bpp mode. > This is not "spec compliance" then, because the spec specifically says that when its 0, it should be assumed equal to 2^biBitCount, which is the same value you are explicitly writing now. Its a redundant value to work around the inability of some players, not spec compliance - the existing value is perfectly compliant. Please clarify as much in any potential commit message. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section
On Fri, Mar 11, 2016 at 8:57 AM, Christophe Gisquet wrote: > Hi, > > 2016-03-10 19:57 GMT+01:00 Hendrik Leppkes : >> This patch (the relocations part) broke debugging mingw-w64 ffmpeg >> builds with gdb, you can't set breakpoints anymore when its applied. > > That issue prevented me to do anything interesting for ffmpeg since > then, thinking it was a toolchain issue. I've lost considerable > ffmpeg-time (and actual code) over it. > >> It should either be reverted or made dependent on >> --enable/disable-debug (I would favor the first, honestly, since its a >> rather ugly hack in itself). > > At the very least, that dependence is needed, yes. > >> Did the binutils/mingw guys ever comment anything useful on this issue? > > And does it still exist? And for which toolchain/binutils/mingw > runtime/gdb version actually? There are like 3+ versions one can use > (yours, msys2, tdm, msys1, ...) > Any mingw-w64 build with a not-ancient binutils should probably be affected. I found several references to this on the mingw ML from 2013 (ignored since then), and reports on the binutils bugzilla from 2014 (no movement there either). Someone even posted a patch on the binutils bugzilla that added a new option to safely generate relocation information, but it was never applied. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
Hendrik Leppkes skrev: (11 mars 2016 09:18:43 CET) >On Fri, Mar 11, 2016 at 5:10 AM, Mats Peterson > wrote: >> >> Regarding the biClrUsed field, I'm setting it to 1 << >> bits_per_coded_sample if palettized video, since setting it to 0 is >> another case where it won't work with Windows Media Player and >Microsoft >> Video 1 in 8 bpp mode. >> > >This is not "spec compliance" then, because the spec specifically says >that when its 0, it should be assumed equal to 2^biBitCount, which is >the same value you are explicitly writing now. >Its a redundant value to work around the inability of some players, >not spec compliance - the existing value is perfectly compliant. >Please clarify as much in any potential commit message. > >- Hendrik >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I know all that, Hendrik, but the fact is Windows Media Player will not interpret 0 as 256 either for Microsoft Video 1 (CRAM) or RLE4/8. And the way I interpret the specs is that using 0 is only relevant to raw, uncompressed video. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
Mats Peterson skrev: (11 mars 2016 10:07:06 CET) >Hendrik Leppkes skrev: (11 mars 2016 09:18:43 >CET) >>On Fri, Mar 11, 2016 at 5:10 AM, Mats Peterson >> wrote: >>> >>> Regarding the biClrUsed field, I'm setting it to 1 << >>> bits_per_coded_sample if palettized video, since setting it to 0 is >>> another case where it won't work with Windows Media Player and >>Microsoft >>> Video 1 in 8 bpp mode. >>> >> >>This is not "spec compliance" then, because the spec specifically says >>that when its 0, it should be assumed equal to 2^biBitCount, which is >>the same value you are explicitly writing now. >>Its a redundant value to work around the inability of some players, >>not spec compliance - the existing value is perfectly compliant. >>Please clarify as much in any potential commit message. >> >>- Hendrik >>___ >>ffmpeg-devel mailing list >>ffmpeg-devel@ffmpeg.org >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >I know all that, Hendrik, but the fact is Windows Media Player will not >interpret 0 as 256 either for Microsoft Video 1 (CRAM) or RLE4/8. And >the way I interpret the specs is that using 0 is only relevant to raw, >uncompressed video. > >Mats >-- >Mats Peterson >http://matsp888.no-ip.org/~mats/ >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Or I should rather say Windows Media Player doesn't interpret 0 as 1 << bits per sample in those cases. -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 09:05 AM, Mats Peterson wrote: On 03/11/2016 06:43 AM, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats OK, I missed your "breaks fate" message, Michael. Then we'll have to regenerate those fate tests. Can you do it? I'm afraid of messing things up. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I'm regenerating them here. I hope I'm doing it right. If it doesn't work, I'll notify you. Mats It's better that you do this when you have the time, Michael. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/3] lavf: generalize md5enc to hashenc and clone the muxers
On Wed, Mar 02, 2016 at 15:17:58 +0100, Moritz Barsnick wrote: > As suggested in the thread regarding the proposed streammd5 muxer: > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/189694.html > this patchset converts the md5/framemd5 muxers into hash/hashenc muxers with > aliased muxers retaining the original names and default algorithms. Ping. This is just a rename to make the muxer more generic, maintaining full backward compatibility, and improving documentation. I could probably even merge the crc and crcenc muxers in a follow-up. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 10:07 AM, Mats Peterson wrote: Hendrik Leppkes skrev: (11 mars 2016 09:18:43 CET) On Fri, Mar 11, 2016 at 5:10 AM, Mats Peterson wrote: Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. This is not "spec compliance" then, because the spec specifically says that when its 0, it should be assumed equal to 2^biBitCount, which is the same value you are explicitly writing now. Its a redundant value to work around the inability of some players, not spec compliance - the existing value is perfectly compliant. Please clarify as much in any potential commit message. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I know all that, Hendrik, but the fact is Windows Media Player will not interpret 0 as 256 either for Microsoft Video 1 (CRAM) or RLE4/8. And the way I interpret the specs is that using 0 is only relevant to raw, uncompressed video. Mats Correction: Windows Media Player *does* interpret 0 as 1 << bits per sample, but using 0 will fail when there are 'xxpc' palette change chunks in the file, for some reason. We might as well use 1 << bits per sample in that field for palettized video to make it fool-proof. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 10:44 AM, Mats Peterson wrote: On 03/11/2016 10:07 AM, Mats Peterson wrote: Hendrik Leppkes skrev: (11 mars 2016 09:18:43 CET) On Fri, Mar 11, 2016 at 5:10 AM, Mats Peterson wrote: Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. This is not "spec compliance" then, because the spec specifically says that when its 0, it should be assumed equal to 2^biBitCount, which is the same value you are explicitly writing now. Its a redundant value to work around the inability of some players, not spec compliance - the existing value is perfectly compliant. Please clarify as much in any potential commit message. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I know all that, Hendrik, but the fact is Windows Media Player will not interpret 0 as 256 either for Microsoft Video 1 (CRAM) or RLE4/8. And the way I interpret the specs is that using 0 is only relevant to raw, uncompressed video. Mats Correction: Windows Media Player *does* interpret 0 as 1 << bits per sample, but using 0 will fail when there are 'xxpc' palette change chunks in the file, for some reason. We might as well use 1 << bits per sample in that field for palettized video to make it fool-proof. For reference, here are two short AVI clips with xxpc chunks, the first one with 256, the second one with 0 in biClrUsed. https://drive.google.com/open?id=0B3_pEBoLs0fab0ZDc21IREc4b0U https://drive.google.com/open?id=0B3_pEBoLs0faVmVITjJhSmlWU0E Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] sws/aarch64/yuv2rgb: use altmacro for the rgb combinations
From: Clément Bœsch
---
I just wanted to see if it was possible to do something less dumb than the
current code. I'm not sure I will push this patch (.altmacro is known to cause
issues and it's currently not used for aarch64), but that was just as an
exercise. It might be "inspiring" for the sws yuv2rgb ARM code that currently
needs some rework.
(Thanks Martin!)
---
libswscale/aarch64/yuv2rgb_neon.S | 45 +--
1 file changed, 20 insertions(+), 25 deletions(-)
diff --git a/libswscale/aarch64/yuv2rgb_neon.S
b/libswscale/aarch64/yuv2rgb_neon.S
index cae5384..a9ee8d5 100644
--- a/libswscale/aarch64/yuv2rgb_neon.S
+++ b/libswscale/aarch64/yuv2rgb_neon.S
@@ -123,14 +123,22 @@
add v23.8H, v27.8H, v23.8H // Y2
+ G2
add v24.8H, v26.8H, v24.8H // Y1
+ B1
add v25.8H, v27.8H, v25.8H // Y2
+ B2
-sqrshrun\r1, v20.8H, #1 //
clip_u8((Y1 + R1) >> 1)
-sqrshrun\r2, v21.8H, #1 //
clip_u8((Y2 + R1) >> 1)
-sqrshrun\g1, v22.8H, #1 //
clip_u8((Y1 + G1) >> 1)
-sqrshrun\g2, v23.8H, #1 //
clip_u8((Y2 + G1) >> 1)
-sqrshrun\b1, v24.8H, #1 //
clip_u8((Y1 + B1) >> 1)
-sqrshrun\b2, v25.8H, #1 //
clip_u8((Y2 + B1) >> 1)
-movi\a1, #255
-movi\a2, #255
+sqrshrunv\r1\().8B, v20.8H, #1 //
clip_u8((Y1 + R1) >> 1)
+sqrshrunv\r2\().8B, v21.8H, #1 //
clip_u8((Y2 + R1) >> 1)
+sqrshrunv\g1\().8B, v22.8H, #1 //
clip_u8((Y1 + G1) >> 1)
+sqrshrunv\g2\().8B, v23.8H, #1 //
clip_u8((Y2 + G1) >> 1)
+sqrshrunv\b1\().8B, v24.8H, #1 //
clip_u8((Y1 + B1) >> 1)
+sqrshrunv\b2\().8B, v25.8H, #1 //
clip_u8((Y2 + B1) >> 1)
+moviv\a1\().8B, #255
+moviv\a2\().8B, #255
+.endm
+
+.macro compute_rgba_ids ofmt fmt r g b a
+.ifc \ofmt, \fmt
+.altmacro
+compute_rgba %(\r+4),%(\g+4),%(\b+4),%(\a+4),
%(\r+16),%(\g+16),%(\b+16),%(\a+16)
+.noaltmacro
+.endif
.endm
.macro declare_func ifmt ofmt
@@ -164,23 +172,10 @@ function ff_\ifmt\()_to_\ofmt\()_neon, export=1
sub v27.8H, v27.8H, v3.8H //
Y2*(1<<3) - y_offset
sqdmulh v26.8H, v26.8H, v0.8H //
((Y1*(1<<3) - y_offset) * y_coeff) >> 15
sqdmulh v27.8H, v27.8H, v0.8H //
((Y2*(1<<3) - y_offset) * y_coeff) >> 15
-
-.ifc \ofmt,argb // 1 2 3 0
-compute_rgbav5.8B,v6.8B,v7.8B,v4.8B, v17.8B,v18.8B,v19.8B,v16.8B
-.endif
-
-.ifc \ofmt,rgba // 0 1 2 3
-compute_rgbav4.8B,v5.8B,v6.8B,v7.8B, v16.8B,v17.8B,v18.8B,v19.8B
-.endif
-
-.ifc \ofmt,abgr // 3 2 1 0
-compute_rgbav7.8B,v6.8B,v5.8B,v4.8B, v19.8B,v18.8B,v17.8B,v16.8B
-.endif
-
-.ifc \ofmt,bgra // 2 1 0 3
-compute_rgbav6.8B,v5.8B,v4.8B,v7.8B, v18.8B,v17.8B,v16.8B,v19.8B
-.endif
-
+compute_rgba_ids\ofmt, argb, 1, 2, 3, 0
+compute_rgba_ids\ofmt, rgba, 0, 1, 2, 3
+compute_rgba_ids\ofmt, abgr, 3, 2, 1, 0
+compute_rgba_ids\ofmt, bgra, 2, 1, 0, 3
st4 { v4.8B, v5.8B, v6.8B, v7.8B}, [x2], #32
st4 {v16.8B,v17.8B,v18.8B,v19.8B}, [x2], #32
subsw8, w8, #16 //
width -= 16
--
2.7.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tests/ref: Update files for the latest changes in lavf/riffenc
This patch should be used in conjunction with my latest three-part patch set. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From c5b2f45589fe532cc0a803a193e8d71b9ce6d5c9 Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Fri, 11 Mar 2016 12:12:42 +0100 Subject: [PATCH] tests/ref: Update files for the latest changes in lavf/riffenc --- tests/ref/fate/mpeg4-bsf-unpack-bframes|2 +- tests/ref/lavf-fate/avi_cram |4 ++-- tests/ref/vsynth/vsynth1-asv1 |2 +- tests/ref/vsynth/vsynth1-asv2 |2 +- tests/ref/vsynth/vsynth1-bpp1 |2 +- tests/ref/vsynth/vsynth1-ffv1 |2 +- tests/ref/vsynth/vsynth1-ffv1-v3-bgr0 |2 +- tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p |2 +- tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 |2 +- tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 |2 +- tests/ref/vsynth/vsynth1-ffvhuff |2 +- tests/ref/vsynth/vsynth1-ffvhuff420p12 |2 +- tests/ref/vsynth/vsynth1-ffvhuff422p10left |2 +- tests/ref/vsynth/vsynth1-ffvhuff444|2 +- tests/ref/vsynth/vsynth1-ffvhuff444p16 |2 +- tests/ref/vsynth/vsynth1-wmv2 |2 +- tests/ref/vsynth/vsynth1-zlib |2 +- tests/ref/vsynth/vsynth2-asv1 |2 +- tests/ref/vsynth/vsynth2-asv2 |2 +- tests/ref/vsynth/vsynth2-bpp1 |2 +- tests/ref/vsynth/vsynth2-ffv1 |2 +- tests/ref/vsynth/vsynth2-ffv1-v3-bgr0 |2 +- tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p |2 +- tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 |2 +- tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 |2 +- tests/ref/vsynth/vsynth2-ffvhuff |2 +- tests/ref/vsynth/vsynth2-ffvhuff420p12 |2 +- tests/ref/vsynth/vsynth2-ffvhuff422p10left |2 +- tests/ref/vsynth/vsynth2-ffvhuff444|2 +- tests/ref/vsynth/vsynth2-ffvhuff444p16 |2 +- tests/ref/vsynth/vsynth2-wmv2 |2 +- tests/ref/vsynth/vsynth2-zlib |2 +- tests/ref/vsynth/vsynth3-asv1 |2 +- tests/ref/vsynth/vsynth3-asv2 |2 +- tests/ref/vsynth/vsynth3-bpp1 |2 +- tests/ref/vsynth/vsynth3-ffv1 |2 +- tests/ref/vsynth/vsynth3-ffv1-v3-bgr0 |2 +- tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p |2 +- tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 |2 +- tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 |2 +- tests/ref/vsynth/vsynth3-ffvhuff |2 +- tests/ref/vsynth/vsynth3-ffvhuff420p12 |2 +- tests/ref/vsynth/vsynth3-ffvhuff422p10left |2 +- tests/ref/vsynth/vsynth3-ffvhuff444|2 +- tests/ref/vsynth/vsynth3-ffvhuff444p16 |2 +- tests/ref/vsynth/vsynth3-wmv2 |2 +- tests/ref/vsynth/vsynth3-zlib |2 +- tests/ref/vsynth/vsynth_lena-asv1 |2 +- tests/ref/vsynth/vsynth_lena-asv2 |2 +- tests/ref/vsynth/vsynth_lena-bpp1 |2 +- tests/ref/vsynth/vsynth_lena-ffv1 |2 +- tests/ref/vsynth/vsynth_lena-ffv1-v3-bgr0 |2 +- tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420p |2 +- tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv422p10 |2 +- tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv444p16 |2 +- tests/ref/vsynth/vsynth_lena-ffvhuff |2 +- tests/ref/vsynth/vsynth_lena-ffvhuff420p12 |2 +- tests/ref/vsynth/vsynth_lena-ffvhuff422p10left |2 +- tests/ref/vsynth/vsynth_lena-ffvhuff444|2 +- tests/ref/vsynth/vsynth_lena-ffvhuff444p16 |2 +- tests/ref/vsynth/vsynth_lena-wmv2 |2 +- tests/ref/vsynth/vsynth_lena-zlib |2 +- 62 files changed, 63 insertions(+), 63 deletions(-) diff --git a/tests/ref/fate/mpeg4-bsf-unpack-bframes b/tests/ref/fate/mpeg4-bsf-unpack-bframes index 21e58f6..718ca5e 100644 --- a/tests/ref/fate/mpeg4-bsf-unpack-bframes +++ b/tests/ref/fate/mpeg4-bsf-unpack-bframes @@ -1 +1 @@ -5db6b7b766c7a9fd5f42292d7467a36d +46386c4d2c3c63d17e03f92c2af60726 diff --git a/tests/ref/lavf-fate/avi_cram b/tests/ref/lavf-fate/avi_cram index 7864ab9..82882fb 100644 --- a/tests/ref/lavf-fate/avi_cram +++ b/tests/ref/lavf-fate/avi_cram @@ -1,3 +1,3 @@ -e202447ccd6660149c17070204d258a4 *./tests/data/lavf-fate/lavf.avi -928228 ./tests/data/lavf-fate/lavf.avi +6fc88702c23b895c305c5e1f51a0904e *./tests/data/lavf-fate/lavf.avi +928260 ./tests/data/lavf-fate/lavf.avi ./tests/data/lavf-fate/lavf.avi CRC=0xa4770de2 diff --git a/tests/ref/vsynth/vsynth1-asv1 b/tests/ref/vsynth/vsynth1-asv1 index 99ce220..d9966de 100644 --- a/tests/ref/vsynth/vsynth1-asv1 +++ b/tests/ref/vsynth/vsynth1-asv1 @@ -1,4 +1,4 @@ -8f1ab10246da351b6be88dd74319f76e *tests/data/fate/vs
Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real Time Video 2.1)codec
Hi, > > > Samples: https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE > > Mats This will be fixed when someone merges http://comments.gmane.org/gmane.comp.video.libav.scm/17960 Regards ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] IFF ANIM support
Hi, Could you post v3 of your patch? I want to test it with some files. Regards ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Vertical bands with RT21 (Intel Real Time Video 2.1)codec
On 03/11/2016 12:26 PM, Piotr Bandurski wrote: Hi, Samples: https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE Mats This will be fixed when someone merges http://comments.gmane.org/gmane.comp.video.libav.scm/17960 Regards ___ Oh, OK. I can still see vertical bands in Windows, so that codec is somewhat sub-par in itself. Thanks. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: > On 03/11/2016 05:10 AM, Mats Peterson wrote: > >Forget patch 2/3 and 3/3 from the old patch set. > > > > From the Microsoft documentation for BITMAPINFOHEADER at > >https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: > > > > > >"biSize: Specifies the number of bytes required by the structure. This > >value does not include the size of the color table or the size of the > >color masks, if they are appended to the end of structure." > > > >So, biSize is always 40. Also, Windows Media Player won't detect video > >encoded with Microsoft Video 1 in 8 bpp mode if this value is anything > >else than 40. I don't know about other codecs, they probably work. > >Anyway, we should stick with the specs, and not include the palette size > >in that field. > > > >Regarding the biClrUsed field, I'm setting it to 1 << > >bits_per_coded_sample if palettized video, since setting it to 0 is > >another case where it won't work with Windows Media Player and Microsoft > >Video 1 in 8 bpp mode. > > > >Mats > > > > > > > > Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that > *does* include the size of the Huffman tables in biSize. That's the > only exception as far as I know. is huffyuv really the exception ? and not raw rgb or palettes ? asv1 and asv2 do not have 40 there which codec with a non-palette global header puts 40 there ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 01:14 PM, Michael Niedermayer wrote: On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that *does* include the size of the Huffman tables in biSize. That's the only exception as far as I know. is huffyuv really the exception ? and not raw rgb or palettes ? asv1 and asv2 do not have 40 there which codec with a non-palette global header puts 40 there ? Don't know what you mean by "asv1 and asv2 do not have 40 there". Anyway, HuffYUV is the only codec I know of that has a specially designed BITMAPINFOHEADER that includes the Huffman tables in it. Hence, the larger value for biSize. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 01:16 PM, Mats Peterson wrote: On 03/11/2016 01:14 PM, Michael Niedermayer wrote: On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that *does* include the size of the Huffman tables in biSize. That's the only exception as far as I know. is huffyuv really the exception ? and not raw rgb or palettes ? asv1 and asv2 do not have 40 there which codec with a non-palette global header puts 40 there ? Do asv1 and asv2 use lavf/riffenc to write the BITMAPINFOHEADER as well? Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 01:17 PM, Mats Peterson wrote: On 03/11/2016 01:16 PM, Mats Peterson wrote: On 03/11/2016 01:14 PM, Michael Niedermayer wrote: On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that *does* include the size of the Huffman tables in biSize. That's the only exception as far as I know. is huffyuv really the exception ? and not raw rgb or palettes ? asv1 and asv2 do not have 40 there which codec with a non-palette global header puts 40 there ? Do asv1 and asv2 use lavf/riffenc to write the BITMAPINFOHEADER as well? Mats Sorry, I thought asv was a format. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 01:14 PM, Michael Niedermayer wrote: On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that *does* include the size of the Huffman tables in biSize. That's the only exception as far as I know. is huffyuv really the exception ? and not raw rgb or palettes ? asv1 and asv2 do not have 40 there which codec with a non-palette global header puts 40 there ? [...] biSize should only be the size of the very BITMAPINFOHEADER, not including the palette or extra data. HuffYUV has its own BITMAPINFOHEADER, once again. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 01:25 PM, Mats Peterson wrote: On 03/11/2016 01:14 PM, Michael Niedermayer wrote: On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that *does* include the size of the Huffman tables in biSize. That's the only exception as far as I know. is huffyuv really the exception ? and not raw rgb or palettes ? asv1 and asv2 do not have 40 there which codec with a non-palette global header puts 40 there ? [...] biSize should only be the size of the very BITMAPINFOHEADER, not including the palette or extra data. HuffYUV has its own BITMAPINFOHEADER, once again. Mats As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 won't even display in Windows Media Player if this value is anything else than 40. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 01:28 PM, Mats Peterson wrote: On 03/11/2016 01:25 PM, Mats Peterson wrote: On 03/11/2016 01:14 PM, Michael Niedermayer wrote: On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that *does* include the size of the Huffman tables in biSize. That's the only exception as far as I know. is huffyuv really the exception ? and not raw rgb or palettes ? asv1 and asv2 do not have 40 there which codec with a non-palette global header puts 40 there ? [...] biSize should only be the size of the very BITMAPINFOHEADER, not including the palette or extra data. HuffYUV has its own BITMAPINFOHEADER, once again. Mats As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 won't even display in Windows Media Player if this value is anything else than 40. Mats For the record, I submitted a patch for MKVToolnix regarding this issue in the past. It incorrectly included the palette size in biSize as well. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: > On 03/11/2016 01:25 PM, Mats Peterson wrote: > >On 03/11/2016 01:14 PM, Michael Niedermayer wrote: > >>On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: > >>>On 03/11/2016 05:10 AM, Mats Peterson wrote: > Forget patch 2/3 and 3/3 from the old patch set. > > From the Microsoft documentation for BITMAPINFOHEADER at > https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: > > > > "biSize: Specifies the number of bytes required by the structure. This > value does not include the size of the color table or the size of the > color masks, if they are appended to the end of structure." > > So, biSize is always 40. Also, Windows Media Player won't detect video > encoded with Microsoft Video 1 in 8 bpp mode if this value is anything > else than 40. I don't know about other codecs, they probably work. > Anyway, we should stick with the specs, and not include the palette > size > in that field. > > Regarding the biClrUsed field, I'm setting it to 1 << > bits_per_coded_sample if palettized video, since setting it to 0 is > another case where it won't work with Windows Media Player and > Microsoft > Video 1 in 8 bpp mode. > > Mats > > > > >>> > >>>Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that > >>>*does* include the size of the Huffman tables in biSize. That's the > >>>only exception as far as I know. > >> > >>is huffyuv really the exception ? and not raw rgb or palettes ? > >> > >>asv1 and asv2 do not have 40 there > >>which codec with a non-palette global header puts 40 there ? [...] > As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 > won't even display in Windows Media Player if this value is anything > else than 40. msv1 / RLE4/8 doesnt have a "Non palette global header" [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
Michael Niedermayer skrev: (11 mars 2016 13:49:32 CET) >On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: >> On 03/11/2016 01:25 PM, Mats Peterson wrote: >> >On 03/11/2016 01:14 PM, Michael Niedermayer wrote: >> >>On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: >> >>>On 03/11/2016 05:10 AM, Mats Peterson wrote: >> Forget patch 2/3 and 3/3 from the old patch set. >> >> From the Microsoft documentation for BITMAPINFOHEADER at >> >https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: >> >> >> >> "biSize: Specifies the number of bytes required by the structure. >This >> value does not include the size of the color table or the size of >the >> color masks, if they are appended to the end of structure." >> >> So, biSize is always 40. Also, Windows Media Player won't detect >video >> encoded with Microsoft Video 1 in 8 bpp mode if this value is >anything >> else than 40. I don't know about other codecs, they probably >work. >> Anyway, we should stick with the specs, and not include the >palette >> size >> in that field. >> >> Regarding the biClrUsed field, I'm setting it to 1 << >> bits_per_coded_sample if palettized video, since setting it to 0 >is >> another case where it won't work with Windows Media Player and >> Microsoft >> Video 1 in 8 bpp mode. >> >> Mats >> >> >> >> >>> >> >>>Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that >> >>>*does* include the size of the Huffman tables in biSize. That's >the >> >>>only exception as far as I know. >> >> >> >>is huffyuv really the exception ? and not raw rgb or palettes ? >> >> >> >>asv1 and asv2 do not have 40 there > >> >>which codec with a non-palette global header puts 40 there ? > >[...] > >> As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 >> won't even display in Windows Media Player if this value is anything >> else than 40. > >msv1 / RLE4/8 doesnt have a "Non palette global header" > > >[...] That's correct. Sorry. Anyway, the only case I know of is HuffYUV with its special variant of BITMAPINFOHEADER that includes the Huffman tables. Is there stated anywhere in the ASUS specs that the size of the extra data following the BITMAPINFOHEADER should be included in biSize? If not, it should be 40. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
Mats Peterson skrev: (11 mars 2016 13:55:20 CET) >Michael Niedermayer skrev: (11 mars 2016 >13:49:32 CET) >>On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: >>> On 03/11/2016 01:25 PM, Mats Peterson wrote: >>> >On 03/11/2016 01:14 PM, Michael Niedermayer wrote: >>> >>On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: >>> >>>On 03/11/2016 05:10 AM, Mats Peterson wrote: >>> Forget patch 2/3 and 3/3 from the old patch set. >>> >>> From the Microsoft documentation for BITMAPINFOHEADER at >>> >>https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: >>> >>> >>> >>> "biSize: Specifies the number of bytes required by the >structure. >>This >>> value does not include the size of the color table or the size >of >>the >>> color masks, if they are appended to the end of structure." >>> >>> So, biSize is always 40. Also, Windows Media Player won't detect >>video >>> encoded with Microsoft Video 1 in 8 bpp mode if this value is >>anything >>> else than 40. I don't know about other codecs, they probably >>work. >>> Anyway, we should stick with the specs, and not include the >>palette >>> size >>> in that field. >>> >>> Regarding the biClrUsed field, I'm setting it to 1 << >>> bits_per_coded_sample if palettized video, since setting it to 0 >>is >>> another case where it won't work with Windows Media Player and >>> Microsoft >>> Video 1 in 8 bpp mode. >>> >>> Mats >>> >>> >>> >>> >>> >>> >>>Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that >>> >>>*does* include the size of the Huffman tables in biSize. That's >>the >>> >>>only exception as far as I know. >>> >> >>> >>is huffyuv really the exception ? and not raw rgb or palettes ? >>> >> >>> >>asv1 and asv2 do not have 40 there >> >>> >>which codec with a non-palette global header puts 40 there ? >> >>[...] >> >>> As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 >>> won't even display in Windows Media Player if this value is anything >>> else than 40. >> >>msv1 / RLE4/8 doesnt have a "Non palette global header" >> >> >>[...] > >That's correct. Sorry. Anyway, the only case I know of is HuffYUV with >its special variant of BITMAPINFOHEADER that includes the Huffman >tables. Is there stated anywhere in the ASUS specs that the size of the >extra data following the BITMAPINFOHEADER should be included in biSize? >If not, it should be 40. > >Mats >-- >Mats Peterson >http://matsp888.no-ip.org/~mats/ >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Those asv1/asv2 files play just fine with a biSize of 40, at that. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
Mats Peterson skrev: (11 mars 2016 14:06:19 CET) >Mats Peterson skrev: (11 mars 2016 >13:55:20 CET) >>Michael Niedermayer skrev: (11 mars 2016 >>13:49:32 CET) >>>On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: On 03/11/2016 01:25 PM, Mats Peterson wrote: >On 03/11/2016 01:14 PM, Michael Niedermayer wrote: >>On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: >>>On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at >>>https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the >>structure. >>>This value does not include the size of the color table or the size >>of >>>the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't >detect >>>video encoded with Microsoft Video 1 in 8 bpp mode if this value is >>>anything else than 40. I don't know about other codecs, they probably >>>work. Anyway, we should stick with the specs, and not include the >>>palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to >0 >>>is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats >>> >>>Once, again, HuffYUV has its own variant of BITMAPINFOHEADER >that >>>*does* include the size of the Huffman tables in biSize. That's >>>the >>>only exception as far as I know. >> >>is huffyuv really the exception ? and not raw rgb or palettes ? >> >>asv1 and asv2 do not have 40 there >>> >>which codec with a non-palette global header puts 40 there ? >>> >>>[...] >>> As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 won't even display in Windows Media Player if this value is >anything else than 40. >>> >>>msv1 / RLE4/8 doesnt have a "Non palette global header" >>> >>> >>>[...] >> >>That's correct. Sorry. Anyway, the only case I know of is HuffYUV with >>its special variant of BITMAPINFOHEADER that includes the Huffman >>tables. Is there stated anywhere in the ASUS specs that the size of >the >>extra data following the BITMAPINFOHEADER should be included in >biSize? >>If not, it should be 40. >> >>Mats >>-- >>Mats Peterson >>http://matsp888.no-ip.org/~mats/ >>___ >>ffmpeg-devel mailing list >>ffmpeg-devel@ffmpeg.org >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >Those asv1/asv2 files play just fine with a biSize of 40, at that. > >Mats >-- >Mats Peterson >http://matsp888.no-ip.org/~mats/ >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Should we perhaps "tighten" the "specs" (I saw that you have written some documentation on asv1/asv2 in FFmpeg), and include those extra bytes in biSize? I suppose this is somewhat of a proprietary FFmpeg invention. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
Mats Peterson skrev: (11 mars 2016 14:12:56 CET) >Mats Peterson skrev: (11 mars 2016 >14:06:19 CET) >>Mats Peterson skrev: (11 mars 2016 >>13:55:20 CET) >>>Michael Niedermayer skrev: (11 mars 2016 >>>13:49:32 CET) On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: > On 03/11/2016 01:25 PM, Mats Peterson wrote: > >On 03/11/2016 01:14 PM, Michael Niedermayer wrote: > >>On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: > >>>On 03/11/2016 05:10 AM, Mats Peterson wrote: > Forget patch 2/3 and 3/3 from the old patch set. > > From the Microsoft documentation for BITMAPINFOHEADER at > https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: > > > > "biSize: Specifies the number of bytes required by the >>>structure. This > value does not include the size of the color table or the size >>>of the > color masks, if they are appended to the end of structure." > > So, biSize is always 40. Also, Windows Media Player won't >>detect video > encoded with Microsoft Video 1 in 8 bpp mode if this value is anything > else than 40. I don't know about other codecs, they probably work. > Anyway, we should stick with the specs, and not include the palette > size > in that field. > > Regarding the biClrUsed field, I'm setting it to 1 << > bits_per_coded_sample if palettized video, since setting it to >>0 is > another case where it won't work with Windows Media Player and > Microsoft > Video 1 in 8 bpp mode. > > Mats > > > > >>> > >>>Once, again, HuffYUV has its own variant of BITMAPINFOHEADER >>that > >>>*does* include the size of the Huffman tables in biSize. That's the > >>>only exception as far as I know. > >> > >>is huffyuv really the exception ? and not raw rgb or palettes ? > >> > >>asv1 and asv2 do not have 40 there > >>which codec with a non-palette global header puts 40 there ? [...] > As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 > won't even display in Windows Media Player if this value is >>anything > else than 40. msv1 / RLE4/8 doesnt have a "Non palette global header" [...] >>> >>>That's correct. Sorry. Anyway, the only case I know of is HuffYUV >with >>>its special variant of BITMAPINFOHEADER that includes the Huffman >>>tables. Is there stated anywhere in the ASUS specs that the size of >>the >>>extra data following the BITMAPINFOHEADER should be included in >>biSize? >>>If not, it should be 40. >>> >>>Mats >>>-- >>>Mats Peterson >>>http://matsp888.no-ip.org/~mats/ >>>___ >>>ffmpeg-devel mailing list >>>ffmpeg-devel@ffmpeg.org >>>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >>Those asv1/asv2 files play just fine with a biSize of 40, at that. >> >>Mats >>-- >>Mats Peterson >>http://matsp888.no-ip.org/~mats/ >>___ >>ffmpeg-devel mailing list >>ffmpeg-devel@ffmpeg.org >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >Should we perhaps "tighten" the "specs" (I saw that you have written >some documentation on asv1/asv2 in FFmpeg), and include those extra >bytes in biSize? I suppose this is somewhat of a proprietary FFmpeg >invention. > >Mats >-- >Mats Peterson >http://matsp888.no-ip.org/~mats/ >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel In my book it's totally unnecessary, though, since we already have the size of the global asv1/asv2 header by subtracting the size of the BITMAPINFOHEADER from the strf chunk size. And the files play fine with a biSize of 40. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/lfg: switch to Ziggurat algorithm for normal random number generation
On Thu, Mar 10, 2016 at 11:16:08PM -0500, Ganesh Ajjanagadde wrote:
> Code taken from the Julia project, licensed under MIT:
> https://github.com/JuliaLang/julia/blob/master/base/random.jl, in turn
> derived from: "The Ziggurat Method for generating random variables" -
> Marsaglia and Tsang.
>
> Paper and reference code: http://www.jstatsoft.org/v05/i08/. This is
> well known to be the fastest method empirically for generating normal random
> variables. Note that there are a large number of implementations with
> various tunings, this was one of the simpler ones and also has a friendly
> license.
>
> This results in ~ 3x speedup of random number generation:
> old:
> 15090 decicycles in av_bmg_get, 1 runs, 0 skips
> 13140 decicycles in av_bmg_get, 2 runs, 0 skips
> 10117 decicycles in av_bmg_get, 4 runs, 0 skips
> [...]
>2133 decicycles in av_bmg_get, 524268 runs, 20 skips=60.4x
>2134 decicycles in av_bmg_get, 1048531 runs, 45 skips=61.3x
>2135 decicycles in av_bmg_get, 2097061 runs, 91 skips=61.9x
>
> new:
>7950 decicycles in av_bmg_get, 1 runs, 0 skips
>6000 decicycles in av_bmg_get, 2 runs, 0 skips
>4432 decicycles in av_bmg_get, 4 runs, 0 skips
>[...]
> 755 decicycles in av_bmg_get, 524281 runs, 7 skips= 62x
> 754 decicycles in av_bmg_get, 1048563 runs, 13 skips=63.4x
> 754 decicycles in av_bmg_get, 2097125 runs, 27 skips=63.8x
>
> and accordingly a ~2% speedup in aac encoding (-march=native, Haswell, clang):
>
> old:
> ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac 5.29s user 0.01s system
> 99% cpu 5.303 total
> new:
> ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac 5.14s user 0.02s system
> 99% cpu 5.166 total
>
> Documentation is also changed accordingly.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavutil/lfg.c | 309
> ++--
> libavutil/lfg.h | 2 +-
> 2 files changed, 299 insertions(+), 12 deletions(-)
>
> diff --git a/libavutil/lfg.c b/libavutil/lfg.c
> index ffa2f1f..9507754 100644
> --- a/libavutil/lfg.c
> +++ b/libavutil/lfg.c
> @@ -44,19 +44,306 @@ av_cold void av_lfg_init(AVLFG *c, unsigned int seed)
> c->index = 0;
> }
>
> +/* Code adapted from the Julia project:
> +https://github.com/JuliaLang/julia/blob/master/base/random.jl.
> +This is licensed under MIT
> (https://github.com/JuliaLang/julia/blob/master/LICENSE.md)
> +Copyright (c) 2009-2016: Jeff Bezanson, Stefan Karpinski, Viral B. Shah,
> and other contributors:
> +
> +https://github.com/JuliaLang/julia/contributors
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> copy of this software and associated documentation files (the "Software"), to
> deal in the Software without restriction, including without limitation the
> rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> sell copies of the Software, and to permit persons to whom the Software is
> furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice shall be included
> in all copies or substantial portions of the Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
> OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> SOFTWARE.
> +*/
> +
> +/* The Ziggurat Method for generating random variables - Marsaglia and
> Tsang
> +Paper and reference code: http://www.jstatsoft.org/v05/i08/. */
> +/* Tables for normal distribution */
> +static const uint64_t ki[] = {
> +
> UINT64_C(0x0007799ec012f7b2),UINT64_C(0x),UINT64_C(0x0006045f4c7de363),UINT64_C(0x0006d1aa7d5ec0a5),
> +
> UINT64_C(0x000728fb3f60f777),UINT64_C(0x0007592af4e9fbc0),UINT64_C(0x000777a5c0bf655d),UINT64_C(0x00078ca3857d2256),
> +
> UINT64_C(0x00079bf6b0ffe58b),UINT64_C(0x0007a7a34ab092ad),UINT64_C(0x0007b0d2f20dd1cb),UINT64_C(0x0007b83d3aa9cb52),
> +
> UINT64_C(0x0007be597614224d),UINT64_C(0x0007c3788631abe9),UINT64_C(0x0007c7d32bc192ee),UINT64_C(0x0007cb9263a6e86d),
> +
> UINT64_C(0x0007ced483edfa84),UINT64_C(0x0007d1b07ac0fd39),UINT64_C(0x0007d437ef2da5fc),UINT64_C(0x0007d678b069aa6e),
> +
> UINT64_C(0x0007d87db38c5c87),UINT64_C(0x0007da4fc6a9ba62),UINT64_C(0x0007dbf611b37f3b),UINT64_C(0x0007dd7674d0f286),
> +
> UINT64_C(0x0007ded5ce8205f6),UINT64_C(0x0007e018307fb62b),UINT64_C(0x0007e141081bd124),UINT64_C(0x0007e2533d712de8),
> +
> UINT64_C(0x0007e3514bbd7718),UINT64_C(0x0007e43d54944b52),UINT64_C(0x0007e5192f25ef4
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote: > Mats Peterson skrev: (11 mars 2016 > 14:06:19 CET) > >Mats Peterson skrev: (11 mars 2016 > >13:55:20 CET) > >>Michael Niedermayer skrev: (11 mars 2016 > >>13:49:32 CET) > >>>On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: > On 03/11/2016 01:25 PM, Mats Peterson wrote: > >On 03/11/2016 01:14 PM, Michael Niedermayer wrote: > >>On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: > >>>On 03/11/2016 05:10 AM, Mats Peterson wrote: > Forget patch 2/3 and 3/3 from the old patch set. > > From the Microsoft documentation for BITMAPINFOHEADER at > > >>>https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: > > > > "biSize: Specifies the number of bytes required by the > >>structure. > >>>This > value does not include the size of the color table or the size > >>of > >>>the > color masks, if they are appended to the end of structure." > > So, biSize is always 40. Also, Windows Media Player won't > >detect > >>>video > encoded with Microsoft Video 1 in 8 bpp mode if this value is > >>>anything > else than 40. I don't know about other codecs, they probably > >>>work. > Anyway, we should stick with the specs, and not include the > >>>palette > size > in that field. > > Regarding the biClrUsed field, I'm setting it to 1 << > bits_per_coded_sample if palettized video, since setting it to > >0 > >>>is > another case where it won't work with Windows Media Player and > Microsoft > Video 1 in 8 bpp mode. > > Mats > > > > >>> > >>>Once, again, HuffYUV has its own variant of BITMAPINFOHEADER > >that > >>>*does* include the size of the Huffman tables in biSize. That's > >>>the > >>>only exception as far as I know. > >> > >>is huffyuv really the exception ? and not raw rgb or palettes ? > >> > >>asv1 and asv2 do not have 40 there > >>> > >>which codec with a non-palette global header puts 40 there ? > >>> > >>>[...] > >>> > As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 > won't even display in Windows Media Player if this value is > >anything > else than 40. > >>> > >>>msv1 / RLE4/8 doesnt have a "Non palette global header" > >>> > >>> > >>>[...] > >> > >>That's correct. Sorry. Anyway, the only case I know of is HuffYUV with > >>its special variant of BITMAPINFOHEADER that includes the Huffman > >>tables. Is there stated anywhere in the ASUS specs that the size of > >the > >>extra data following the BITMAPINFOHEADER should be included in > >biSize? > >>If not, it should be 40. > >> > >>Mats > >>-- > >>Mats Peterson > >>http://matsp888.no-ip.org/~mats/ > >>___ > >>ffmpeg-devel mailing list > >>ffmpeg-devel@ffmpeg.org > >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > >Those asv1/asv2 files play just fine with a biSize of 40, at that. > > > >Mats > >-- > >Mats Peterson > >http://matsp888.no-ip.org/~mats/ > >___ > >ffmpeg-devel mailing list > >ffmpeg-devel@ffmpeg.org > >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > Should we perhaps "tighten" the "specs" (I saw that you have written some > documentation on asv1/asv2 in FFmpeg), and include those extra bytes in > biSize? I suppose this is somewhat of a proprietary FFmpeg invention. we didnt invent ASUS video 1 and 2 nor huffyuv which codec with a non-palette global header puts 40 there ? the ms specs just says the color table & mask isnt part of biSize it doesnt say the global header isnt, or iam looking at the wrong text or location in the text/spec [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
Michael Niedermayer skrev: (11 mars 2016 15:05:49 CET) >On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote: >> Mats Peterson skrev: (11 mars 2016 >14:06:19 CET) >> >Mats Peterson skrev: (11 mars >2016 >> >13:55:20 CET) >> >>Michael Niedermayer skrev: (11 mars 2016 >> >>13:49:32 CET) >> >>>On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: >> On 03/11/2016 01:25 PM, Mats Peterson wrote: >> >On 03/11/2016 01:14 PM, Michael Niedermayer wrote: >> >>On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: >> >>>On 03/11/2016 05:10 AM, Mats Peterson wrote: >> Forget patch 2/3 and 3/3 from the old patch set. >> >> From the Microsoft documentation for BITMAPINFOHEADER at >> >> https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: >> >> >> >> "biSize: Specifies the number of bytes required by the >> >>structure. >> >>>This >> value does not include the size of the color table or the >size >> >>of >> >>>the >> color masks, if they are appended to the end of structure." >> >> So, biSize is always 40. Also, Windows Media Player won't >> >detect >> >>>video >> encoded with Microsoft Video 1 in 8 bpp mode if this value >is >> >>>anything >> else than 40. I don't know about other codecs, they probably >> >>>work. >> Anyway, we should stick with the specs, and not include the >> >>>palette >> size >> in that field. >> >> Regarding the biClrUsed field, I'm setting it to 1 << >> bits_per_coded_sample if palettized video, since setting it >to >> >0 >> >>>is >> another case where it won't work with Windows Media Player >and >> Microsoft >> Video 1 in 8 bpp mode. >> >> Mats >> >> >> >> >>> >> >>>Once, again, HuffYUV has its own variant of BITMAPINFOHEADER >> >that >> >>>*does* include the size of the Huffman tables in biSize. >That's >> >>>the >> >>>only exception as far as I know. >> >> >> >>is huffyuv really the exception ? and not raw rgb or palettes >? >> >> >> >>asv1 and asv2 do not have 40 there >> >>> >> >>which codec with a non-palette global header puts 40 there ? >> >>> >> >>>[...] >> >>> >> As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 >> won't even display in Windows Media Player if this value is >> >anything >> else than 40. >> >>> >> >>>msv1 / RLE4/8 doesnt have a "Non palette global header" >> >>> >> >>> >> >>>[...] >> >> >> >>That's correct. Sorry. Anyway, the only case I know of is HuffYUV >with >> >>its special variant of BITMAPINFOHEADER that includes the Huffman >> >>tables. Is there stated anywhere in the ASUS specs that the size of >> >the >> >>extra data following the BITMAPINFOHEADER should be included in >> >biSize? >> >>If not, it should be 40. >> >> >> >>Mats >> >>-- >> >>Mats Peterson >> >>http://matsp888.no-ip.org/~mats/ >> >>___ >> >>ffmpeg-devel mailing list >> >>ffmpeg-devel@ffmpeg.org >> >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > >> >Those asv1/asv2 files play just fine with a biSize of 40, at that. >> > >> >Mats >> >-- >> >Mats Peterson >> >http://matsp888.no-ip.org/~mats/ >> >___ >> >ffmpeg-devel mailing list >> >ffmpeg-devel@ffmpeg.org >> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> Should we perhaps "tighten" the "specs" (I saw that you have written >some documentation on asv1/asv2 in FFmpeg), and include those extra >bytes in biSize? I suppose this is somewhat of a proprietary FFmpeg >invention. > >we didnt invent ASUS video 1 and 2 nor huffyuv > >which codec with a non-palette global header puts 40 there ? > >the ms specs just says the color table & mask isnt part of biSize >it doesnt say the global header isnt, or iam looking at the wrong text >or location in the text/spec > >[...] Again, only one I know of is HuffYUV, and the specs define a custom BITMAPINFOHEADER that includes the Huffman tables. The "global data" in ASUS is only 8 bytes. Do they regard the BITMAPINFOHEADER as being part of this global data as well? And should we? A BITMAPINFOHEADER is a BITMAPINFOHEADER is a BITMAPINFOHEADER... Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 03:13 PM, Mats Peterson wrote: Michael Niedermayer skrev: (11 mars 2016 15:05:49 CET) On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote: Mats Peterson skrev: (11 mars 2016 14:06:19 CET) Mats Peterson skrev: (11 mars 2016 13:55:20 CET) Michael Niedermayer skrev: (11 mars 2016 13:49:32 CET) On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: On 03/11/2016 01:25 PM, Mats Peterson wrote: On 03/11/2016 01:14 PM, Michael Niedermayer wrote: On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that *does* include the size of the Huffman tables in biSize. That's the only exception as far as I know. is huffyuv really the exception ? and not raw rgb or palettes ? asv1 and asv2 do not have 40 there which codec with a non-palette global header puts 40 there ? [...] As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 won't even display in Windows Media Player if this value is anything else than 40. msv1 / RLE4/8 doesnt have a "Non palette global header" [...] That's correct. Sorry. Anyway, the only case I know of is HuffYUV with its special variant of BITMAPINFOHEADER that includes the Huffman tables. Is there stated anywhere in the ASUS specs that the size of the extra data following the BITMAPINFOHEADER should be included in biSize? If not, it should be 40. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Those asv1/asv2 files play just fine with a biSize of 40, at that. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Should we perhaps "tighten" the "specs" (I saw that you have written some documentation on asv1/asv2 in FFmpeg), and include those extra bytes in biSize? I suppose this is somewhat of a proprietary FFmpeg invention. we didnt invent ASUS video 1 and 2 nor huffyuv which codec with a non-palette global header puts 40 there ? the ms specs just says the color table & mask isnt part of biSize it doesnt say the global header isnt, or iam looking at the wrong text or location in the text/spec [...] Again, only one I know of is HuffYUV, and the specs define a custom BITMAPINFOHEADER that includes the Huffman tables. The "global data" in ASUS is only 8 bytes. Do they regard the BITMAPINFOHEADER as being part of this global data as well? And should we? A BITMAPINFOHEADER is a BITMAPINFOHEADER is a BITMAPINFOHEADER... Mats Do you have a sample file with asv1/asv2 *created by ASUS* where biSize isn't 40? Mts -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 03:21 PM, Mats Peterson wrote: On 03/11/2016 03:13 PM, Mats Peterson wrote: Michael Niedermayer skrev: (11 mars 2016 15:05:49 CET) On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote: Mats Peterson skrev: (11 mars 2016 14:06:19 CET) Mats Peterson skrev: (11 mars 2016 13:55:20 CET) Michael Niedermayer skrev: (11 mars 2016 13:49:32 CET) On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: On 03/11/2016 01:25 PM, Mats Peterson wrote: On 03/11/2016 01:14 PM, Michael Niedermayer wrote: On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that *does* include the size of the Huffman tables in biSize. That's the only exception as far as I know. is huffyuv really the exception ? and not raw rgb or palettes ? asv1 and asv2 do not have 40 there which codec with a non-palette global header puts 40 there ? [...] As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 won't even display in Windows Media Player if this value is anything else than 40. msv1 / RLE4/8 doesnt have a "Non palette global header" [...] That's correct. Sorry. Anyway, the only case I know of is HuffYUV with its special variant of BITMAPINFOHEADER that includes the Huffman tables. Is there stated anywhere in the ASUS specs that the size of the extra data following the BITMAPINFOHEADER should be included in biSize? If not, it should be 40. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Those asv1/asv2 files play just fine with a biSize of 40, at that. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Should we perhaps "tighten" the "specs" (I saw that you have written some documentation on asv1/asv2 in FFmpeg), and include those extra bytes in biSize? I suppose this is somewhat of a proprietary FFmpeg invention. we didnt invent ASUS video 1 and 2 nor huffyuv which codec with a non-palette global header puts 40 there ? the ms specs just says the color table & mask isnt part of biSize it doesnt say the global header isnt, or iam looking at the wrong text or location in the text/spec [...] Again, only one I know of is HuffYUV, and the specs define a custom BITMAPINFOHEADER that includes the Huffman tables. The "global data" in ASUS is only 8 bytes. Do they regard the BITMAPINFOHEADER as being part of this global data as well? And should we? A BITMAPINFOHEADER is a BITMAPINFOHEADER is a BITMAPINFOHEADER... Mats Do you have a sample file with asv1/asv2 *created by ASUS* where biSize isn't 40? Mts I got the asv1/asv2 samples from the MPlayer sample directory. Are they from ASUS? They all use a biSize of 48. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)
Hi, On Thu, Mar 10, 2016 at 9:23 PM, Ganesh Ajjanagadde wrote: > On Thu, Mar 10, 2016 at 8:56 AM, Ronald S. Bultje > wrote: > > Hi, > > > > On Thu, Mar 10, 2016 at 2:37 AM, Reimar Döffinger < > reimar.doeffin...@gmx.de> > > wrote: > > > >> On 10.03.2016, at 03:06, Ganesh Ajjanagadde wrote: > >> > >> > On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger > >> > wrote: > >> >> On 08.03.2016, at 04:48, Ganesh Ajjanagadde > wrote: > >> >> > >> >>> +nzl += expf(logf(s / ethresh) * nzslope); > >> >> > >> >> Shouldn't log2f/exp2f be faster? > >> >> log2f at least has CPU support on x86 AFAICT. > >> > > >> > I had tested this, and no, though it is still faster than powf. > >> > > >> > It still seems to rely on libm, note that we don't use -ffast-math and > >> > a look at > >> https://github.com/lattera/glibc/tree/master/sysdeps/x86_64/fpu > >> > as well seems to say no. Problem is, GNU people like to prioritize > >> > "correctly rounded" behavior over fast, reasonably accurate code, > >> > sometimes to ludicruous degrees. > >> > > >> > Personally, I don't know why we don't use -ffast-math, not many seem > >> > to care that heavily on strict IEEE semantics. Maybe it leads to too > >> > much variation across platforms? > >> > >> You lose some guarantees. In particular, the compiler will assume NaNs > do > >> not happen and you cannot predict which code path (after a comparison > for > >> example) they take. > >> But some code for either security or correctness reasons needs them to > be > >> handled a certain way. > >> I guess in theory you could try to make sure fisnan is used in all those > >> cases, but then you need to find them, and I think if you take > -ffast-math > >> description literally there is no guarantee that even fisnan continues > to > >> work... I am also not sure none of the code relies on order of > operations > >> to get the precision it needs. > >> So it is simply too dangerous. > >> Some more specific options might be possible to use though (but I think > >> even full -ffast-math gains you almost nothing? Does it even help > here?). > > Yes, sorry, I meant some specific things from -ffast-math. I checked > configure, most of the unambiguously clear ones are already being > turned on. As such, it seems ok. > > > > > > > One could also consider writing some customized assembly (calling the > > relevant instructions instead of C wrappers) in cases where it is > > speed-sensitive. It's sort of the inverse of what Ganesh is suggesting, I > > guess, maybe some more effort involved but it can't be that much. You > could > > even use av_always_inline functions and inline assembly to call the > > relevant instruction and otherwise keep things in C. That's identical to > > what -ffast-math does but turns on only when specifically calling the new > > API function name... > > So seems like everything wrt this patch is fine, right? Not really. Your patch still does two things, and I don't like the explicit exp(log(a)*b). What I'm thinking is that you should have a static inline function, let's call it fast_pow(a, b), which can internally (in the C version) be implemented as exp+log. Just as you found for pow, we might find that for exp/log, the system lib is not very optimized and we can do it faster ourselves by doing whatever -ffast-math is doing for these functions. Those would be more specifically optimized and that would be part of the fast_pow implementation. This way, the code in aacenc remains easy to follow and the optimization is accessible for other parts of ffmpeg also. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 03:27 PM, Mats Peterson wrote: On 03/11/2016 03:21 PM, Mats Peterson wrote: On 03/11/2016 03:13 PM, Mats Peterson wrote: Michael Niedermayer skrev: (11 mars 2016 15:05:49 CET) On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote: Mats Peterson skrev: (11 mars 2016 14:06:19 CET) Mats Peterson skrev: (11 mars 2016 13:55:20 CET) Michael Niedermayer skrev: (11 mars 2016 13:49:32 CET) On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: On 03/11/2016 01:25 PM, Mats Peterson wrote: On 03/11/2016 01:14 PM, Michael Niedermayer wrote: On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that *does* include the size of the Huffman tables in biSize. That's the only exception as far as I know. is huffyuv really the exception ? and not raw rgb or palettes ? asv1 and asv2 do not have 40 there which codec with a non-palette global header puts 40 there ? [...] As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 won't even display in Windows Media Player if this value is anything else than 40. msv1 / RLE4/8 doesnt have a "Non palette global header" [...] That's correct. Sorry. Anyway, the only case I know of is HuffYUV with its special variant of BITMAPINFOHEADER that includes the Huffman tables. Is there stated anywhere in the ASUS specs that the size of the extra data following the BITMAPINFOHEADER should be included in biSize? If not, it should be 40. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Those asv1/asv2 files play just fine with a biSize of 40, at that. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Should we perhaps "tighten" the "specs" (I saw that you have written some documentation on asv1/asv2 in FFmpeg), and include those extra bytes in biSize? I suppose this is somewhat of a proprietary FFmpeg invention. we didnt invent ASUS video 1 and 2 nor huffyuv which codec with a non-palette global header puts 40 there ? the ms specs just says the color table & mask isnt part of biSize it doesnt say the global header isnt, or iam looking at the wrong text or location in the text/spec [...] Again, only one I know of is HuffYUV, and the specs define a custom BITMAPINFOHEADER that includes the Huffman tables. The "global data" in ASUS is only 8 bytes. Do they regard the BITMAPINFOHEADER as being part of this global data as well? And should we? A BITMAPINFOHEADER is a BITMAPINFOHEADER is a BITMAPINFOHEADER... Mats Do you have a sample file with asv1/asv2 *created by ASUS* where biSize isn't 40? Mts I got the asv1/asv2 samples from the MPlayer sample directory. Are they from ASUS? They all use a biSize of 48. Mats Nope. Written with libavformat. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/file: Move av_tempfile() to avutil/file_open ff_tempfile()
On Wed, Mar 9, 2016 at 4:51 PM, Hendrik Leppkes wrote:
> On Wed, Mar 9, 2016 at 4:35 PM, Michael Niedermayer
> wrote:
>> On Wed, Mar 09, 2016 at 04:27:12PM +0100, Hendrik Leppkes wrote:
>>> On Wed, Mar 9, 2016 at 3:37 PM, Michael Niedermayer
>>> wrote:
>>> > document the issue with av_tempfile()
>>> >
>>> > Signed-off-by: Michael Niedermayer
>>> > ---
>>> > libavcodec/libxvid.h |2 --
>>> > libavutil/file.c | 48 ++--
>>> > libavutil/file.h |1 +
>>> > libavutil/file_open.c | 59
>>> > +
>>> > libavutil/internal.h | 14
>>> > 5 files changed, 76 insertions(+), 48 deletions(-)
>>> >
>>> > diff --git a/libavcodec/libxvid.h b/libavcodec/libxvid.h
>>> > index bffe07d..ef9a5a9 100644
>>> > --- a/libavcodec/libxvid.h
>>> > +++ b/libavcodec/libxvid.h
>>> > @@ -26,6 +26,4 @@
>>> > * common functions for use with the Xvid wrappers
>>> > */
>>> >
>>> > -int ff_tempfile(const char *prefix, char **filename);
>>> > -
>>> > #endif /* AVCODEC_LIBXVID_H */
>>> > diff --git a/libavutil/file.c b/libavutil/file.c
>>> > index 2a06be4..25381b1 100644
>>> > --- a/libavutil/file.c
>>> > +++ b/libavutil/file.c
>>> > @@ -137,52 +137,8 @@ void av_file_unmap(uint8_t *bufptr, size_t size)
>>> > #endif
>>> > }
>>> >
>>> > -int av_tempfile(const char *prefix, char **filename, int log_offset,
>>> > void *log_ctx)
>>> > -{
>>> > -FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset,
>>> > log_ctx };
>>> > -int fd = -1;
>>> > -#if !HAVE_MKSTEMP
>>> > -void *ptr= tempnam(NULL, prefix);
>>> > -if(!ptr)
>>> > -ptr= tempnam(".", prefix);
>>> > -*filename = av_strdup(ptr);
>>> > -#undef free
>>> > -free(ptr);
>>> > -#else
>>> > -size_t len = strlen(prefix) + 12; /* room for "/tmp/" and "XX\0"
>>> > */
>>> > -*filename = av_malloc(len);
>>> > -#endif
>>> > -/* -common section-*/
>>> > -if (!*filename) {
>>> > -av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot
>>> > allocate file name\n");
>>> > -return AVERROR(ENOMEM);
>>> > -}
>>> > -#if !HAVE_MKSTEMP
>>> > -# ifndef O_BINARY
>>> > -# define O_BINARY 0
>>> > -# endif
>>> > -# ifndef O_EXCL
>>> > -# define O_EXCL 0
>>> > -# endif
>>> > -fd = open(*filename, O_RDWR | O_BINARY | O_CREAT | O_EXCL, 0600);
>>> > -#else
>>> > -snprintf(*filename, len, "/tmp/%sXX", prefix);
>>> > -fd = mkstemp(*filename);
>>> > -#ifdef _WIN32
>>> > -if (fd < 0) {
>>> > -snprintf(*filename, len, "./%sXX", prefix);
>>> > -fd = mkstemp(*filename);
>>> > -}
>>> > -#endif
>>> > -#endif
>>> > -/* -common section-*/
>>> > -if (fd < 0) {
>>> > -int err = AVERROR(errno);
>>> > -av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot open
>>> > temporary file %s\n", *filename);
>>> > -av_freep(filename);
>>> > -return err;
>>> > -}
>>> > -return fd; /* success */
>>> > +int av_tempfile(const char *prefix, char **filename, int log_offset,
>>> > void *log_ctx) {
>>> > +return avpriv_tempfile(prefix, filename, log_offset, log_ctx);
>>> > }
>>> >
>>> > #ifdef TEST
>>> > diff --git a/libavutil/file.h b/libavutil/file.h
>>> > index e931be7..8666c7b 100644
>>> > --- a/libavutil/file.h
>>> > +++ b/libavutil/file.h
>>> > @@ -62,6 +62,7 @@ void av_file_unmap(uint8_t *bufptr, size_t size);
>>> > * @note On very old libcs it is necessary to set a secure umask before
>>> > * calling this, av_tempfile() can't call umask itself as it is
>>> > used in
>>> > * libraries and could interfere with the calling application.
>>> > + * @deprecated as fd numbers cannot be passed saftely between libs on
>>> > some platforms
>>> > */
>>> > int av_tempfile(const char *prefix, char **filename, int log_offset,
>>> > void *log_ctx);
>>> >
>>> > diff --git a/libavutil/file_open.c b/libavutil/file_open.c
>>> > index 9e76127..6e58cc1 100644
>>> > --- a/libavutil/file_open.c
>>> > +++ b/libavutil/file_open.c
>>> > @@ -92,6 +92,65 @@ int avpriv_open(const char *filename, int flags, ...)
>>> > return fd;
>>> > }
>>> >
>>> > +typedef struct FileLogContext {
>>> > +const AVClass *class;
>>> > +int log_offset;
>>> > +void *log_ctx;
>>> > +} FileLogContext;
>>> > +
>>> > +static const AVClass file_log_ctx_class = {
>>> > +"TEMPFILE", av_default_item_name, NULL, LIBAVUTIL_VERSION_INT,
>>> > +offsetof(FileLogContext, log_offset), offsetof(FileLogContext,
>>> > log_ctx)
>>> > +};
>>> > +
>>> > +int avpriv_tempfile(const char *prefix, char **filename, int log_offset,
>>> > void *log_ctx)
>>> > +{
>>> > +FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset,
>>> > log_ctx };
>>> > +int fd = -1;
>>> > +#if !HAVE_MKSTEMP
>>> > +void *ptr= tempnam(NULL, prefix);
>>> > +if(!ptr)
>>> > +ptr= tempnam(".", prefix);
>>> > +*file
[FFmpeg-devel] Filter with multiple inputs, specific format on second and third input?
I am writing a filter that takes a video file and remaps pixels based on
second and third input.
second and third input are pgm files, which should give me a list of
integers (gray16) that I can use in the filter.
However ffmpeg by default converts my pgm files to YUV.
Is there a way to prevent that?
Should I add something to the filter code to only accept gray16 encoded
files as second (xmap) and third (ymap) input, but keep arbitray video as
input1?
Command line:
# ffmpeg -i INPUT.avi -i feep.pgm -i feep.pgm -lavfi '[0][1][2]remap'
OUTPUT.avi
static int query_formats(AVFilterContext *ctx)
{
static const enum AVPixelFormat pix_fmts[] = {
AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P,
AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P,
AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVA420P,
AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,
AV_PIX_FMT_YUVJ411P, AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P,
AV_PIX_FMT_RGB24, AV_PIX_FMT_BGR24,
AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR, AV_PIX_FMT_RGBA, AV_PIX_FMT_BGRA,
AV_PIX_FMT_0RGB, AV_PIX_FMT_0BGR, AV_PIX_FMT_RGB0, AV_PIX_FMT_BGR0,
AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE
};
return ff_set_common_formats(ctx, ff_make_format_list(pix_fmts));
}
static const AVFilterPad remap_inputs[] = {
{
.name = "source",
.type = AVMEDIA_TYPE_VIDEO,
.filter_frame = filter_frame,
.config_props = config_input,
},
{
.name = "xmap",
.type = AVMEDIA_TYPE_VIDEO,
.filter_frame = filter_frame,
},
{
.name = "ymap",
.type = AVMEDIA_TYPE_VIDEO,
.filter_frame = filter_frame,
},
{ NULL }
};
static const AVFilterPad remap_outputs[] = {
{
.name = "default",
.type = AVMEDIA_TYPE_VIDEO,
.config_props = config_output,
.request_frame = request_frame,
},
{ NULL }
};
AVFilter ff_vf_remap = {
.name = "remap",
.description = NULL_IF_CONFIG_SMALL("remap pixels."),
.priv_size = sizeof(remapContext),
.uninit= uninit,
.query_formats = query_formats,
.inputs= remap_inputs,
.outputs = remap_outputs,
.priv_class= &remap_class,
.flags = AVFILTER_FLAG_SUPPORT_TIMELINE_INTERNAL,
};
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Filter with multiple inputs, specific format on second and third input?
Le duodi 22 ventôse, an CCXXIV, F.Sluiter a écrit :
> I am writing a filter that takes a video file and remaps pixels based on
> second and third input.
> second and third input are pgm files, which should give me a list of
> integers (gray16) that I can use in the filter.
> However ffmpeg by default converts my pgm files to YUV.
> Is there a way to prevent that?
>
> Should I add something to the filter code to only accept gray16 encoded
> files as second (xmap) and third (ymap) input, but keep arbitray video as
> input1?
Not add, change. See below.
>
> Command line:
> # ffmpeg -i INPUT.avi -i feep.pgm -i feep.pgm -lavfi '[0][1][2]remap'
> OUTPUT.avi
>
>
> static int query_formats(AVFilterContext *ctx)
> {
> static const enum AVPixelFormat pix_fmts[] = {
> AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P,
> AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P,
> AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVA420P,
> AV_PIX_FMT_YUV420P,
> AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,
> AV_PIX_FMT_YUVJ411P, AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P,
> AV_PIX_FMT_RGB24, AV_PIX_FMT_BGR24,
> AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR, AV_PIX_FMT_RGBA, AV_PIX_FMT_BGRA,
> AV_PIX_FMT_0RGB, AV_PIX_FMT_0BGR, AV_PIX_FMT_RGB0, AV_PIX_FMT_BGR0,
> AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
> AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE
> };
>
> return ff_set_common_formats(ctx, ff_make_format_list(pix_fmts));
By using ff_set_common_formats(), you set the formats for all inputs and the
output to a pointer to this list, the same copy in memory. That means (1)
your second and third inputs do not accept gray16, and (2) all three inputs
and the output must have the same format at the end.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Filter with multiple inputs, specific format on second and third input?
Thanks Nicolas, can you be a bit more specific on how I can change it to
get what I need?
Or is it not possible?
Floris
2016-03-11 16:33 GMT+01:00 Nicolas George :
> Le duodi 22 ventôse, an CCXXIV, F.Sluiter a écrit :
> > I am writing a filter that takes a video file and remaps pixels based on
> > second and third input.
> > second and third input are pgm files, which should give me a list of
> > integers (gray16) that I can use in the filter.
> > However ffmpeg by default converts my pgm files to YUV.
> > Is there a way to prevent that?
> >
> > Should I add something to the filter code to only accept gray16 encoded
> > files as second (xmap) and third (ymap) input, but keep arbitray video as
> > input1?
>
> Not add, change. See below.
>
> >
> > Command line:
> > # ffmpeg -i INPUT.avi -i feep.pgm -i feep.pgm -lavfi '[0][1][2]remap'
> > OUTPUT.avi
> >
> >
> > static int query_formats(AVFilterContext *ctx)
> > {
> > static const enum AVPixelFormat pix_fmts[] = {
> > AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P,
> > AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P,
> > AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVA420P,
> > AV_PIX_FMT_YUV420P,
> > AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,
> > AV_PIX_FMT_YUVJ411P, AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P,
> > AV_PIX_FMT_RGB24, AV_PIX_FMT_BGR24,
> > AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR, AV_PIX_FMT_RGBA,
> AV_PIX_FMT_BGRA,
> > AV_PIX_FMT_0RGB, AV_PIX_FMT_0BGR, AV_PIX_FMT_RGB0,
> AV_PIX_FMT_BGR0,
> > AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
> > AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE
> > };
> >
>
> > return ff_set_common_formats(ctx, ff_make_format_list(pix_fmts));
>
> By using ff_set_common_formats(), you set the formats for all inputs and
> the
> output to a pointer to this list, the same copy in memory. That means (1)
> your second and third inputs do not accept gray16, and (2) all three inputs
> and the output must have the same format at the end.
>
> Regards,
>
> --
> Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Regarding HuffYUV, I would say it breaks the specs by using its own BITMAPINFOHEADER larger than 40 bytes, but we can't do much about that now. For other codecs, anything after the BITMAPINFOHEADER, be it a palette or other data, should NOT be included in biSize, since that's what Microsoft tells us. They don't mention non-palette data, but that's almost implicit. Remember, biSize is "The number of bytes required by the structure." I'm quoting Microsoft. The structure is the BITMAPINFOHEADER, nothing else. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 06:04 PM, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Regarding HuffYUV, I would say it breaks the specs by using its own BITMAPINFOHEADER larger than 40 bytes, but we can't do much about that now. For other codecs, anything after the BITMAPINFOHEADER, be it a palette or other data, should NOT be included in biSize, since that's what Microsoft tells us. They don't mention non-palette data, but that's almost implicit. Remember, biSize is "The number of bytes required by the structure." I'm quoting Microsoft. The structure is the BITMAPINFOHEADER, nothing else. Mats To get the size of any "global non-palette header" or whatever, just subtract the size of the BITMAPINFOHEADER (40 bytes) from the size of the strf chunk. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 06:06 PM, Mats Peterson wrote: On 03/11/2016 06:04 PM, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Regarding HuffYUV, I would say it breaks the specs by using its own BITMAPINFOHEADER larger than 40 bytes, but we can't do much about that now. For other codecs, anything after the BITMAPINFOHEADER, be it a palette or other data, should NOT be included in biSize, since that's what Microsoft tells us. They don't mention non-palette data, but that's almost implicit. Remember, biSize is "The number of bytes required by the structure." I'm quoting Microsoft. The structure is the BITMAPINFOHEADER, nothing else. Mats To get the size of any "global non-palette header" or whatever, just subtract the size of the BITMAPINFOHEADER (40 bytes) from the size of the strf chunk. Mats Both HuffYUV, ffvhuff and asv1/asv2 work just fine on demuxing when using a biSize of 40, for the record. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] libavutil/aes_ctr.c
Need guidance on getting started to write tests for libavutil/aes_ctr.c. Thank you, Naga ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On Fri, Mar 11, 2016 at 03:31:55PM +0100, Mats Peterson wrote: > On 03/11/2016 03:27 PM, Mats Peterson wrote: > >On 03/11/2016 03:21 PM, Mats Peterson wrote: > >>On 03/11/2016 03:13 PM, Mats Peterson wrote: > >>>Michael Niedermayer skrev: (11 mars 2016 > >>>15:05:49 CET) > On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote: > >Mats Peterson skrev: (11 mars 2016 > 14:06:19 CET) > >>Mats Peterson skrev: (11 mars > 2016 > >>13:55:20 CET) > >>>Michael Niedermayer skrev: (11 mars 2016 > >>>13:49:32 CET) > On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: > >On 03/11/2016 01:25 PM, Mats Peterson wrote: > >>On 03/11/2016 01:14 PM, Michael Niedermayer wrote: > >>>On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: > On 03/11/2016 05:10 AM, Mats Peterson wrote: > >Forget patch 2/3 and 3/3 from the old patch set. > > > > From the Microsoft documentation for BITMAPINFOHEADER at > > > > > >>>https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: > >>> > >>> > > > > > > > >"biSize: Specifies the number of bytes required by the > >>>structure. > This > >value does not include the size of the color table or the > size > >>>of > the > >color masks, if they are appended to the end of structure." > > > >So, biSize is always 40. Also, Windows Media Player won't > >>detect > video > >encoded with Microsoft Video 1 in 8 bpp mode if this value > is > anything > >else than 40. I don't know about other codecs, they probably > work. > >Anyway, we should stick with the specs, and not include the > palette > >size > >in that field. > > > >Regarding the biClrUsed field, I'm setting it to 1 << > >bits_per_coded_sample if palettized video, since setting it > to > >>0 > is > >another case where it won't work with Windows Media Player > and > >Microsoft > >Video 1 in 8 bpp mode. > > > >Mats > > > > > > > > Once, again, HuffYUV has its own variant of BITMAPINFOHEADER > >>that > *does* include the size of the Huffman tables in biSize. > That's > the > only exception as far as I know. > >>> > >>>is huffyuv really the exception ? and not raw rgb or palettes > ? > >>> > >>>asv1 and asv2 do not have 40 there > > >>>which codec with a non-palette global header puts 40 there ? > > [...] > > >As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 > >won't even display in Windows Media Player if this value is > >>anything > >else than 40. > > msv1 / RLE4/8 doesnt have a "Non palette global header" > > > [...] > >>> > >>>That's correct. Sorry. Anyway, the only case I know of is HuffYUV > with > >>>its special variant of BITMAPINFOHEADER that includes the Huffman > >>>tables. Is there stated anywhere in the ASUS specs that the size of > >>the > >>>extra data following the BITMAPINFOHEADER should be included in > >>biSize? > >>>If not, it should be 40. > >>> > >>>Mats > >>>-- > >>>Mats Peterson > >>>http://matsp888.no-ip.org/~mats/ > >>>___ > >>>ffmpeg-devel mailing list > >>>ffmpeg-devel@ffmpeg.org > >>>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >>Those asv1/asv2 files play just fine with a biSize of 40, at that. > >> > >>Mats > >>-- > >>Mats Peterson > >>http://matsp888.no-ip.org/~mats/ > >>___ > >>ffmpeg-devel mailing list > >>ffmpeg-devel@ffmpeg.org > >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > >Should we perhaps "tighten" the "specs" (I saw that you have written > some documentation on asv1/asv2 in FFmpeg), and include those extra > bytes in biSize? I suppose this is somewhat of a proprietary FFmpeg > invention. > > we didnt invent ASUS video 1 and 2 nor huffyuv > > which codec with a non-palette global header puts 40 there ? > > the ms specs just says the color table & mask isnt part of biSize > it doesnt say the global header isnt, or iam looking at the wrong text > or location in the text/spec > > [...] > >>> > >>>Again, only one I know of is HuffYUV, and the specs define a custom > >>>BITMAPINFOHEADER that includes the Huffman tables. The "global data" >
Re: [FFmpeg-devel] Filter with multiple inputs, specific format on second and third input?
Dana 11. 3. 2016. 16:42 osoba "F.Sluiter" napisala je:
>
> Thanks Nicolas, can you be a bit more specific on how I can change it to
> get what I need?
> Or is it not possible?
Its possible, just set explicitly formats for second and third input.
See similar how its done for extractplanes.
> Floris
>
> 2016-03-11 16:33 GMT+01:00 Nicolas George :
>
> > Le duodi 22 ventôse, an CCXXIV, F.Sluiter a écrit :
> > > I am writing a filter that takes a video file and remaps pixels based
on
> > > second and third input.
> > > second and third input are pgm files, which should give me a list of
> > > integers (gray16) that I can use in the filter.
> > > However ffmpeg by default converts my pgm files to YUV.
> > > Is there a way to prevent that?
> > >
> > > Should I add something to the filter code to only accept gray16
encoded
> > > files as second (xmap) and third (ymap) input, but keep arbitray
video as
> > > input1?
> >
> > Not add, change. See below.
> >
> > >
> > > Command line:
> > > # ffmpeg -i INPUT.avi -i feep.pgm -i feep.pgm -lavfi
'[0][1][2]remap'
> > > OUTPUT.avi
> > >
> > >
> > > static int query_formats(AVFilterContext *ctx)
> > > {
> > > static const enum AVPixelFormat pix_fmts[] = {
> > > AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P,
> > > AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P,
> > > AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVA420P,
> > > AV_PIX_FMT_YUV420P,
> > > AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,
> > > AV_PIX_FMT_YUVJ411P, AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P,
> > > AV_PIX_FMT_RGB24, AV_PIX_FMT_BGR24,
> > > AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR, AV_PIX_FMT_RGBA,
> > AV_PIX_FMT_BGRA,
> > > AV_PIX_FMT_0RGB, AV_PIX_FMT_0BGR, AV_PIX_FMT_RGB0,
> > AV_PIX_FMT_BGR0,
> > > AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
> > > AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE
> > > };
> > >
> >
> > > return ff_set_common_formats(ctx, ff_make_format_list(pix_fmts));
> >
> > By using ff_set_common_formats(), you set the formats for all inputs and
> > the
> > output to a pointer to this list, the same copy in memory. That means
(1)
> > your second and third inputs do not accept gray16, and (2) all three
inputs
> > and the output must have the same format at the end.
> >
> > Regards,
> >
> > --
> > Nicolas George
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9_superframe: fix endianness of size markers.
--- libavcodec/vp9_superframe_bsf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c index f991a80..d4a61ee 100644 --- a/libavcodec/vp9_superframe_bsf.c +++ b/libavcodec/vp9_superframe_bsf.c @@ -82,13 +82,13 @@ static int merge_superframe(const struct CachedBuf *in, int n_in, wloop(mag, *ptr = in[n].size); break; case 1: -wloop(mag, AV_WB16(ptr, in[n].size)); +wloop(mag, AV_WL16(ptr, in[n].size)); break; case 2: -wloop(mag, AV_WB24(ptr, in[n].size)); +wloop(mag, AV_WL24(ptr, in[n].size)); break; case 3: -wloop(mag, AV_WB32(ptr, in[n].size)); +wloop(mag, AV_WL32(ptr, in[n].size)); break; } *ptr++ = marker; -- 2.1.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9_superframe: fix endianness of size markers.
On 3/11/2016 4:22 PM, Ronald S. Bultje wrote: > --- > libavcodec/vp9_superframe_bsf.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c > index f991a80..d4a61ee 100644 > --- a/libavcodec/vp9_superframe_bsf.c > +++ b/libavcodec/vp9_superframe_bsf.c > @@ -82,13 +82,13 @@ static int merge_superframe(const struct CachedBuf *in, > int n_in, > wloop(mag, *ptr = in[n].size); > break; > case 1: > -wloop(mag, AV_WB16(ptr, in[n].size)); > +wloop(mag, AV_WL16(ptr, in[n].size)); > break; > case 2: > -wloop(mag, AV_WB24(ptr, in[n].size)); > +wloop(mag, AV_WL24(ptr, in[n].size)); > break; > case 3: > -wloop(mag, AV_WB32(ptr, in[n].size)); > +wloop(mag, AV_WL32(ptr, in[n].size)); > break; > } > *ptr++ = marker; > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: fix a few signed integer left-shifts.
Fixes trac tickets 5127, 5129, 5130.
---
libavcodec/vp9.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 5d8ad12..5c6f176 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -743,7 +743,7 @@ static int decode_frame_header(AVCodecContext *ctx,
if (s->s.h.lf_delta.enabled) {
s->s.h.segmentation.feat[i].lflvl[0][0] =
s->s.h.segmentation.feat[i].lflvl[0][1] =
-av_clip_uintp2(lflvl + (s->s.h.lf_delta.ref[0] << sh), 6);
+av_clip_uintp2(lflvl + (s->s.h.lf_delta.ref[0] * (1 << sh)),
6);
for (j = 1; j < 4; j++) {
s->s.h.segmentation.feat[i].lflvl[j][0] =
av_clip_uintp2(lflvl + ((s->s.h.lf_delta.ref[j] +
@@ -2769,7 +2769,7 @@ static av_always_inline void
mc_chroma_unscaled(VP9Context *s, vp9_mc_func (*mc)
ptrdiff_t y, ptrdiff_t x,
const VP56mv *mv,
int bw, int bh, int w, int h,
int bytesperpixel)
{
-int mx = mv->x << !s->ss_h, my = mv->y << !s->ss_v, th;
+int mx = mv->x * (1 << !s->ss_h), my = mv->y * (1 << !s->ss_v), th;
y += my >> 4;
x += mx >> 4;
@@ -2849,8 +2849,8 @@ static av_always_inline void mc_luma_scaled(VP9Context
*s, vp9_scaled_mc_func sm
int th;
VP56mv mv;
-mv.x = av_clip(in_mv->x, -(x + pw - px + 4) << 3, (s->cols * 8 - x + px +
3) << 3);
-mv.y = av_clip(in_mv->y, -(y + ph - py + 4) << 3, (s->rows * 8 - y + py +
3) << 3);
+mv.x = av_clip(in_mv->x, -(x + pw - px + 4) * 8, (s->cols * 8 - x + px +
3) * 8);
+mv.y = av_clip(in_mv->y, -(y + ph - py + 4) * 8, (s->rows * 8 - y + py +
3) * 8);
// BUG libvpx seems to scale the two components separately. This introduces
// rounding errors but we have to reproduce them to be exactly compatible
// with the output from libvpx...
@@ -2907,19 +2907,19 @@ static av_always_inline void
mc_chroma_scaled(VP9Context *s, vp9_scaled_mc_func
if (s->ss_h) {
// BUG https://code.google.com/p/webm/issues/detail?id=820
-mv.x = av_clip(in_mv->x, -(x + pw - px + 4) << 4, (s->cols * 4 - x +
px + 3) << 4);
+mv.x = av_clip(in_mv->x, -(x + pw - px + 4) * 16, (s->cols * 4 - x +
px + 3) * 16);
mx = scale_mv(mv.x, 0) + (scale_mv(x * 16, 0) & ~15) + (scale_mv(x *
32, 0) & 15);
} else {
-mv.x = av_clip(in_mv->x, -(x + pw - px + 4) << 3, (s->cols * 8 - x +
px + 3) << 3);
-mx = scale_mv(mv.x << 1, 0) + scale_mv(x * 16, 0);
+mv.x = av_clip(in_mv->x, -(x + pw - px + 4) * 8, (s->cols * 8 - x + px
+ 3) * 8);
+mx = scale_mv(mv.x * 2, 0) + scale_mv(x * 16, 0);
}
if (s->ss_v) {
// BUG https://code.google.com/p/webm/issues/detail?id=820
-mv.y = av_clip(in_mv->y, -(y + ph - py + 4) << 4, (s->rows * 4 - y +
py + 3) << 4);
+mv.y = av_clip(in_mv->y, -(y + ph - py + 4) * 16, (s->rows * 4 - y +
py + 3) * 16);
my = scale_mv(mv.y, 1) + (scale_mv(y * 16, 1) & ~15) + (scale_mv(y *
32, 1) & 15);
} else {
-mv.y = av_clip(in_mv->y, -(y + ph - py + 4) << 3, (s->rows * 8 - y +
py + 3) << 3);
-my = scale_mv(mv.y << 1, 1) + scale_mv(y * 16, 1);
+mv.y = av_clip(in_mv->y, -(y + ph - py + 4) * 8, (s->rows * 8 - y + py
+ 3) * 8);
+my = scale_mv(mv.y * 2, 1) + scale_mv(y * 16, 1);
}
#undef scale_mv
y = my >> 4;
--
2.1.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9_superframe: fix endianness of size markers.
Hi, On Fri, Mar 11, 2016 at 2:33 PM, James Almer wrote: > On 3/11/2016 4:22 PM, Ronald S. Bultje wrote: > > --- > > libavcodec/vp9_superframe_bsf.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/libavcodec/vp9_superframe_bsf.c > b/libavcodec/vp9_superframe_bsf.c > > index f991a80..d4a61ee 100644 > > --- a/libavcodec/vp9_superframe_bsf.c > > +++ b/libavcodec/vp9_superframe_bsf.c > > @@ -82,13 +82,13 @@ static int merge_superframe(const struct CachedBuf > *in, int n_in, > > wloop(mag, *ptr = in[n].size); > > break; > > case 1: > > -wloop(mag, AV_WB16(ptr, in[n].size)); > > +wloop(mag, AV_WL16(ptr, in[n].size)); > > break; > > case 2: > > -wloop(mag, AV_WB24(ptr, in[n].size)); > > +wloop(mag, AV_WL24(ptr, in[n].size)); > > break; > > case 3: > > -wloop(mag, AV_WB32(ptr, in[n].size)); > > +wloop(mag, AV_WL32(ptr, in[n].size)); > > break; > > } > > *ptr++ = marker; > > > > LGTM Pushed. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/utils: Fix DTS for short H264 streams.
Fill DTS if all packets have been read in avformat_find_stream_info, and still
has_decode_delay_been_guessed returns false.
Signed-off-by: Sasi Inguva
---
libavformat/utils.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 5f48de1..f22309d 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -877,6 +877,7 @@ static int has_decode_delay_been_guessed(AVStream *st)
avpriv_h264_has_num_reorder_frames(st->codec) ==
st->codec->has_b_frames)
return 1;
#endif
+
if (st->codec->has_b_frames<3)
return st->nb_decoded_frames >= 7;
else if (st->codec->has_b_frames<4)
@@ -3165,6 +3166,7 @@ int avformat_find_stream_info(AVFormatContext *ic,
AVDictionary **options)
int64_t max_stream_analyze_duration;
int64_t max_subtitle_analyze_duration;
int64_t probesize = ic->probesize;
+int eof_reached = 0;
flush_codecs = probesize > 0;
@@ -3331,6 +,7 @@ int avformat_find_stream_info(AVFormatContext *ic,
AVDictionary **options)
if (ret < 0) {
/* EOF or error*/
+eof_reached = 1;
break;
}
@@ -3454,6 +3457,40 @@ int avformat_find_stream_info(AVFormatContext *ic,
AVDictionary **options)
count++;
}
+if (eof_reached && ic->internal->packet_buffer) {
+int stream_index;
+for (stream_index = 0; stream_index < ic->nb_streams; stream_index++) {
+AVPacketList *pktl = ic->internal->packet_buffer;
+int64_t pts_buffer[MAX_REORDER_DELAY+1];
+
+// EOF already reached while reading the stream above.
+// So continue with reoordering DTS with whatever delay we have.
+int codec_delay = st->codec->has_b_frames;
+
+st = ic->streams[stream_index];
+
+if (st->codec->codec_id != AV_CODEC_ID_H264 ||
+has_decode_delay_been_guessed(st)) {
+continue;
+}
+
+
+for (; pktl; pktl = get_next_pkt(ic, st, pktl)) {
+if (pktl->pkt.stream_index != stream_index)
+continue;
+
+if (pktl->pkt.pts != AV_NOPTS_VALUE && codec_delay <=
MAX_REORDER_DELAY) {
+int j;
+pts_buffer[0] = pktl->pkt.pts;
+for (j = 0; j < codec_delay && pts_buffer[j] >
pts_buffer[j + 1]; j++)
+ FFSWAP(int64_t, pts_buffer[j], pts_buffer[j + 1]);
+
+pktl->pkt.dts = select_from_pts_buffer(st, pts_buffer,
pktl->pkt.dts);
+}
+}
+}
+}
+
if (flush_codecs) {
AVPacket empty_pkt = { 0 };
int err = 0;
--
2.7.0.rc3.207.g0ac5344
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/utils: Fix DTS for short H264 streams.
With this patch it doesn't produce invalid DTS for the file you mentioned
tickets/1242/sample.mkv
./ffmpeg -i sample.mkv -c:v copy -an -t 1 -f framecrc -
On Fri, Mar 11, 2016 at 12:36 PM, Sasi Inguva wrote:
> Having another go at this. My goal is to fix DTS of H264 videos which are
> shorter than 7 frames and don't have B-frames. Currently ffmpeg will output
> DTS=N/A for such frames.
>
> On Fri, Mar 11, 2016 at 12:34 PM, Sasi Inguva wrote:
>
>> Fill DTS if all packets have been read in avformat_find_stream_info, and
>> still
>> has_decode_delay_been_guessed returns false.
>>
>> Signed-off-by: Sasi Inguva
>> ---
>> libavformat/utils.c | 37 +
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index 5f48de1..f22309d 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -877,6 +877,7 @@ static int has_decode_delay_been_guessed(AVStream *st)
>> avpriv_h264_has_num_reorder_frames(st->codec) ==
>> st->codec->has_b_frames)
>> return 1;
>> #endif
>> +
>> if (st->codec->has_b_frames<3)
>> return st->nb_decoded_frames >= 7;
>> else if (st->codec->has_b_frames<4)
>> @@ -3165,6 +3166,7 @@ int avformat_find_stream_info(AVFormatContext *ic,
>> AVDictionary **options)
>> int64_t max_stream_analyze_duration;
>> int64_t max_subtitle_analyze_duration;
>> int64_t probesize = ic->probesize;
>> +int eof_reached = 0;
>>
>> flush_codecs = probesize > 0;
>>
>> @@ -3331,6 +,7 @@ int avformat_find_stream_info(AVFormatContext *ic,
>> AVDictionary **options)
>>
>> if (ret < 0) {
>> /* EOF or error*/
>> +eof_reached = 1;
>> break;
>> }
>>
>> @@ -3454,6 +3457,40 @@ int avformat_find_stream_info(AVFormatContext *ic,
>> AVDictionary **options)
>> count++;
>> }
>>
>> +if (eof_reached && ic->internal->packet_buffer) {
>> +int stream_index;
>> +for (stream_index = 0; stream_index < ic->nb_streams;
>> stream_index++) {
>> +AVPacketList *pktl = ic->internal->packet_buffer;
>> +int64_t pts_buffer[MAX_REORDER_DELAY+1];
>> +
>> +// EOF already reached while reading the stream above.
>> +// So continue with reoordering DTS with whatever delay we
>> have.
>> +int codec_delay = st->codec->has_b_frames;
>> +
>> +st = ic->streams[stream_index];
>> +
>> +if (st->codec->codec_id != AV_CODEC_ID_H264 ||
>> +has_decode_delay_been_guessed(st)) {
>> +continue;
>> +}
>> +
>> +
>> +for (; pktl; pktl = get_next_pkt(ic, st, pktl)) {
>> +if (pktl->pkt.stream_index != stream_index)
>> +continue;
>> +
>> +if (pktl->pkt.pts != AV_NOPTS_VALUE && codec_delay <=
>> MAX_REORDER_DELAY) {
>> +int j;
>> +pts_buffer[0] = pktl->pkt.pts;
>> +for (j = 0; j < codec_delay && pts_buffer[j] >
>> pts_buffer[j + 1]; j++)
>> + FFSWAP(int64_t, pts_buffer[j], pts_buffer[j + 1]);
>> +
>> +pktl->pkt.dts = select_from_pts_buffer(st,
>> pts_buffer, pktl->pkt.dts);
>> +}
>> +}
>> +}
>> +}
>> +
>> if (flush_codecs) {
>> AVPacket empty_pkt = { 0 };
>> int err = 0;
>> --
>> 2.7.0.rc3.207.g0ac5344
>>
>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/utils: Fix DTS for short H264 streams.
Having another go at this. My goal is to fix DTS of H264 videos which are
shorter than 7 frames and don't have B-frames. Currently ffmpeg will output
DTS=N/A for such frames.
On Fri, Mar 11, 2016 at 12:34 PM, Sasi Inguva wrote:
> Fill DTS if all packets have been read in avformat_find_stream_info, and
> still
> has_decode_delay_been_guessed returns false.
>
> Signed-off-by: Sasi Inguva
> ---
> libavformat/utils.c | 37 +
> 1 file changed, 37 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 5f48de1..f22309d 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -877,6 +877,7 @@ static int has_decode_delay_been_guessed(AVStream *st)
> avpriv_h264_has_num_reorder_frames(st->codec) ==
> st->codec->has_b_frames)
> return 1;
> #endif
> +
> if (st->codec->has_b_frames<3)
> return st->nb_decoded_frames >= 7;
> else if (st->codec->has_b_frames<4)
> @@ -3165,6 +3166,7 @@ int avformat_find_stream_info(AVFormatContext *ic,
> AVDictionary **options)
> int64_t max_stream_analyze_duration;
> int64_t max_subtitle_analyze_duration;
> int64_t probesize = ic->probesize;
> +int eof_reached = 0;
>
> flush_codecs = probesize > 0;
>
> @@ -3331,6 +,7 @@ int avformat_find_stream_info(AVFormatContext *ic,
> AVDictionary **options)
>
> if (ret < 0) {
> /* EOF or error*/
> +eof_reached = 1;
> break;
> }
>
> @@ -3454,6 +3457,40 @@ int avformat_find_stream_info(AVFormatContext *ic,
> AVDictionary **options)
> count++;
> }
>
> +if (eof_reached && ic->internal->packet_buffer) {
> +int stream_index;
> +for (stream_index = 0; stream_index < ic->nb_streams;
> stream_index++) {
> +AVPacketList *pktl = ic->internal->packet_buffer;
> +int64_t pts_buffer[MAX_REORDER_DELAY+1];
> +
> +// EOF already reached while reading the stream above.
> +// So continue with reoordering DTS with whatever delay we
> have.
> +int codec_delay = st->codec->has_b_frames;
> +
> +st = ic->streams[stream_index];
> +
> +if (st->codec->codec_id != AV_CODEC_ID_H264 ||
> +has_decode_delay_been_guessed(st)) {
> +continue;
> +}
> +
> +
> +for (; pktl; pktl = get_next_pkt(ic, st, pktl)) {
> +if (pktl->pkt.stream_index != stream_index)
> +continue;
> +
> +if (pktl->pkt.pts != AV_NOPTS_VALUE && codec_delay <=
> MAX_REORDER_DELAY) {
> +int j;
> +pts_buffer[0] = pktl->pkt.pts;
> +for (j = 0; j < codec_delay && pts_buffer[j] >
> pts_buffer[j + 1]; j++)
> + FFSWAP(int64_t, pts_buffer[j], pts_buffer[j + 1]);
> +
> +pktl->pkt.dts = select_from_pts_buffer(st,
> pts_buffer, pktl->pkt.dts);
> +}
> +}
> +}
> +}
> +
> if (flush_codecs) {
> AVPacket empty_pkt = { 0 };
> int err = 0;
> --
> 2.7.0.rc3.207.g0ac5344
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/ffjni: remove use of private JniInvocation API to retreive the Java VM
From: Matthieu Bouron
Android N will prevent users from loading non-public APIs.
Users should only rely on the av_jni_set_java_vm function to set the
Java VM.
---
libavcodec/ffjni.c | 88 ++
1 file changed, 3 insertions(+), 85 deletions(-)
diff --git a/libavcodec/ffjni.c b/libavcodec/ffjni.c
index da13699..54f3122 100644
--- a/libavcodec/ffjni.c
+++ b/libavcodec/ffjni.c
@@ -35,80 +35,6 @@
static JavaVM *java_vm = NULL;
static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
-/**
- * Check if JniInvocation has been initialized. Only available on
- * Android >= 4.4.
- *
- * @param log_ctx context used for logging, can be NULL
- * @return 0 on success, < 0 otherwise
- */
-static int check_jni_invocation(void *log_ctx)
-{
-int ret = AVERROR_EXTERNAL;
-void *handle = NULL;
-void **jni_invocation = NULL;
-
-handle = dlopen(NULL, RTLD_LOCAL);
-if (!handle) {
-goto done;
-}
-
-jni_invocation = (void **)dlsym(handle,
"_ZN13JniInvocation15jni_invocation_E");
-if (!jni_invocation) {
-av_log(log_ctx, AV_LOG_ERROR, "Could not find
JniInvocation::jni_invocation_ symbol\n");
-goto done;
-}
-
-ret = !(jni_invocation != NULL && *jni_invocation != NULL);
-
-done:
-if (handle) {
-dlclose(handle);
-}
-
-return ret;
-}
-
-/**
- * Return created Java virtual machine using private JNI_GetCreatedJavaVMs
- * function from the specified library name.
- *
- * @param name library name used for symbol lookups, can be NULL
- * @param log_ctx context used for logging, can be NULL
- * @return the current Java virtual machine in use
- */
-static JavaVM *get_java_vm(const char *name, void *log_ctx)
-{
-JavaVM *vm = NULL;
-jsize nb_vm = 0;
-
-void *handle = NULL;
-jint (*get_created_java_vms) (JavaVM ** vmBuf, jsize bufLen, jsize *nVMs)
= NULL;
-
-handle = dlopen(name, RTLD_LOCAL);
-if (!handle) {
-return NULL;
-}
-
-get_created_java_vms = (jint (*)(JavaVM **, jsize, jsize *)) dlsym(handle,
"JNI_GetCreatedJavaVMs");
-if (!get_created_java_vms) {
-av_log(log_ctx, AV_LOG_ERROR, "Could not find JNI_GetCreatedJavaVMs
symbol in library '%s'\n", name);
-goto done;
-}
-
-if (get_created_java_vms(&vm, 1, &nb_vm) != JNI_OK) {
-av_log(log_ctx, AV_LOG_ERROR, "Could not get created Java virtual
machines\n");
-goto done;
-}
-
-done:
-if (handle) {
-dlclose(handle);
-}
-
-return vm;
-}
-
JNIEnv *ff_jni_attach_env(int *attached, void *log_ctx)
{
int ret = 0;
@@ -117,21 +43,13 @@ JNIEnv *ff_jni_attach_env(int *attached, void *log_ctx)
*attached = 0;
pthread_mutex_lock(&lock);
-if (java_vm == NULL && (java_vm = av_jni_get_java_vm(log_ctx)) == NULL) {
-
-av_log(log_ctx, AV_LOG_INFO, "Retrieving current Java virtual machine
using Android JniInvocation wrapper\n");
-if (check_jni_invocation(log_ctx) == 0) {
-if ((java_vm = get_java_vm(NULL, log_ctx)) != NULL ||
-(java_vm = get_java_vm("libdvm.so", log_ctx)) != NULL ||
-(java_vm = get_java_vm("libart.so", log_ctx)) != NULL) {
-av_log(log_ctx, AV_LOG_INFO, "Found Java virtual machine using
Android JniInvocation wrapper\n");
-}
-}
+if (java_vm == NULL) {
+java_vm = av_jni_get_java_vm(log_ctx);
}
pthread_mutex_unlock(&lock);
if (!java_vm) {
-av_log(log_ctx, AV_LOG_ERROR, "Could not retrieve a Java virtual
machine\n");
+av_log(log_ctx, AV_LOG_ERROR, "No Java virtual machine has been
registered\n");
return NULL;
}
--
2.7.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: fix a few signed integer left-shifts.
On 3/11/2016 4:41 PM, Ronald S. Bultje wrote: > Fixes trac tickets 5127, 5129, 5130. > --- > libavcodec/vp9.c | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/alsdec: fix max bits in ltp prefix code
The maximum number of bits int the prefix code for p(0) is 4. By setting it as 3, we were missing the last 0 bit. This fixes bug #4715 present on the trac. Signed-off-by: Umair Khan --- libavcodec/alsdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c index 0043512..1402b00 100644 --- a/libavcodec/alsdec.c +++ b/libavcodec/alsdec.c @@ -765,7 +765,7 @@ static int read_var_block_data(ALSDecContext *ctx, ALSBlockData *bd) bd->ltp_gain[0] = decode_rice(gb, 1) << 3; bd->ltp_gain[1] = decode_rice(gb, 2) << 3; -r = get_unary(gb, 0, 3); +r = get_unary(gb, 0, 4); c = get_bits(gb, 2); bd->ltp_gain[2] = ltp_gain_values[r][c]; -- 2.5.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: fix a few signed integer left-shifts.
On Fri, Mar 11, 2016 at 4:05 PM, James Almer wrote: > On 3/11/2016 4:41 PM, Ronald S. Bultje wrote: > > Fixes trac tickets 5127, 5129, 5130. > > --- > > libavcodec/vp9.c | 20 ++-- > > 1 file changed, 10 insertions(+), 10 deletions(-) > > LGTM Pushed, ty. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
On 03/11/2016 06:45 PM, Michael Niedermayer wrote: On Fri, Mar 11, 2016 at 03:31:55PM +0100, Mats Peterson wrote: On 03/11/2016 03:27 PM, Mats Peterson wrote: On 03/11/2016 03:21 PM, Mats Peterson wrote: On 03/11/2016 03:13 PM, Mats Peterson wrote: Michael Niedermayer skrev: (11 mars 2016 15:05:49 CET) On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote: Mats Peterson skrev: (11 mars 2016 14:06:19 CET) Mats Peterson skrev: (11 mars 2016 13:55:20 CET) Michael Niedermayer skrev: (11 mars 2016 13:49:32 CET) On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote: On 03/11/2016 01:25 PM, Mats Peterson wrote: On 03/11/2016 01:14 PM, Michael Niedermayer wrote: On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote: On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is always 40. Also, Windows Media Player won't detect video encoded with Microsoft Video 1 in 8 bpp mode if this value is anything else than 40. I don't know about other codecs, they probably work. Anyway, we should stick with the specs, and not include the palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 is another case where it won't work with Windows Media Player and Microsoft Video 1 in 8 bpp mode. Mats Once, again, HuffYUV has its own variant of BITMAPINFOHEADER that *does* include the size of the Huffman tables in biSize. That's the only exception as far as I know. is huffyuv really the exception ? and not raw rgb or palettes ? asv1 and asv2 do not have 40 there which codec with a non-palette global header puts 40 there ? [...] As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8 won't even display in Windows Media Player if this value is anything else than 40. msv1 / RLE4/8 doesnt have a "Non palette global header" [...] That's correct. Sorry. Anyway, the only case I know of is HuffYUV with its special variant of BITMAPINFOHEADER that includes the Huffman tables. Is there stated anywhere in the ASUS specs that the size of the extra data following the BITMAPINFOHEADER should be included in biSize? If not, it should be 40. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Those asv1/asv2 files play just fine with a biSize of 40, at that. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Should we perhaps "tighten" the "specs" (I saw that you have written some documentation on asv1/asv2 in FFmpeg), and include those extra bytes in biSize? I suppose this is somewhat of a proprietary FFmpeg invention. we didnt invent ASUS video 1 and 2 nor huffyuv which codec with a non-palette global header puts 40 there ? the ms specs just says the color table & mask isnt part of biSize it doesnt say the global header isnt, or iam looking at the wrong text or location in the text/spec [...] Again, only one I know of is HuffYUV, and the specs define a custom BITMAPINFOHEADER that includes the Huffman tables. The "global data" in ASUS is only 8 bytes. Do they regard the BITMAPINFOHEADER as being part of this global data as well? And should we? A BITMAPINFOHEADER is a BITMAPINFOHEADER is a BITMAPINFOHEADER... Mats Do you have a sample file with asv1/asv2 *created by ASUS* where biSize isn't 40? Mts I got the asv1/asv2 samples from the MPlayer sample directory. Are they >from ASUS? They all use a biSize of 48. Mats Nope. Written with libavformat. why do you think they are written by libavformat ? i see: "C:\PROGRAM FILES\ASUS\ASUS LIVE\ASUSLIVE.EXE -AVICAP32- ASUS Video Capture Driver, Version: 3.8.2.2" in asv2_320x240_3.avi Yes, you are right. I was looking at some other files. Sorry. So how do we proceed from here? Should we make an exception to the "40-byte rule" for HuffYUV, ffvhuff, asv1 and asv2 in the meantime? Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: fix max bits in ltp prefix code
Am 11.03.16 um 22:04 schrieb Umair Khan: > The maximum number of bits int the prefix code for > p(0) is 4. By setting it as 3, we were missing the > last 0 bit. > This fixes bug #4715 present on the trac. > > Signed-off-by: Umair Khan > --- > libavcodec/alsdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Ok. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance
Mats Peterson skrev: (11 mars 2016 22:26:43 CET) >On 03/11/2016 06:45 PM, Michael Niedermayer wrote: >> On Fri, Mar 11, 2016 at 03:31:55PM +0100, Mats Peterson wrote: >>> On 03/11/2016 03:27 PM, Mats Peterson wrote: On 03/11/2016 03:21 PM, Mats Peterson wrote: > On 03/11/2016 03:13 PM, Mats Peterson wrote: >> Michael Niedermayer skrev: (11 mars 2016 >> 15:05:49 CET) >>> On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote: Mats Peterson skrev: (11 >mars 2016 >>> 14:06:19 CET) > Mats Peterson skrev: (11 >mars >>> 2016 > 13:55:20 CET) >> Michael Niedermayer skrev: (11 mars >2016 >> 13:49:32 CET) >>> On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson >wrote: On 03/11/2016 01:25 PM, Mats Peterson wrote: > On 03/11/2016 01:14 PM, Michael Niedermayer wrote: >> On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson >wrote: >>> On 03/11/2016 05:10 AM, Mats Peterson wrote: Forget patch 2/3 and 3/3 from the old patch set. From the Microsoft documentation for BITMAPINFOHEADER >at >> >https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: >> >> "biSize: Specifies the number of bytes required by the >> structure. >>> This value does not include the size of the color table or >the >>> size >> of >>> the color masks, if they are appended to the end of >structure." So, biSize is always 40. Also, Windows Media Player >won't > detect >>> video encoded with Microsoft Video 1 in 8 bpp mode if this >value >>> is >>> anything else than 40. I don't know about other codecs, they >probably >>> work. Anyway, we should stick with the specs, and not include >the >>> palette size in that field. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since >setting it >>> to > 0 >>> is another case where it won't work with Windows Media >Player >>> and Microsoft Video 1 in 8 bpp mode. Mats >>> >>> Once, again, HuffYUV has its own variant of >BITMAPINFOHEADER > that >>> *does* include the size of the Huffman tables in biSize. >>> That's >>> the >>> only exception as far as I know. >> >> is huffyuv really the exception ? and not raw rgb or >palettes >>> ? >> >> asv1 and asv2 do not have 40 there >>> >> which codec with a non-palette global header puts 40 >there ? >>> >>> [...] >>> As I said before, Microsoft Video 1 in 8-bit mode and >RLE4/RLE8 won't even display in Windows Media Player if this value is > anything else than 40. >>> >>> msv1 / RLE4/8 doesnt have a "Non palette global header" >>> >>> >>> [...] >> >> That's correct. Sorry. Anyway, the only case I know of is >HuffYUV >>> with >> its special variant of BITMAPINFOHEADER that includes the >Huffman >> tables. Is there stated anywhere in the ASUS specs that the >size of > the >> extra data following the BITMAPINFOHEADER should be included >in > biSize? >> If not, it should be 40. >> >> Mats >> -- >> Mats Peterson >> http://matsp888.no-ip.org/~mats/ >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > Those asv1/asv2 files play just fine with a biSize of 40, at >that. > > Mats > -- > Mats Peterson > http://matsp888.no-ip.org/~mats/ > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Should we perhaps "tighten" the "specs" (I saw that you have >written >>> some documentation on asv1/asv2 in FFmpeg), and include those >extra >>> bytes in biSize? I suppose this is somewhat of a proprietary >FFmpeg >>> invention. >>> >>> we didnt invent ASUS video 1 and 2 nor huffyuv >>> >>> which codec with a non-palette global header puts 40 there ? >>>
Re: [FFmpeg-devel] [PATCH] lavf/utils: Fix DTS for short H264 streams.
For testing , a link to one such failing video
https://drive.google.com/file/d/0Bz6XfEJZ-9N3X0FSMWR6T3B3U28/view?usp=sharing
. Without this patch,
ffprobe -show_frames -print_format compact | grep media_type=video -
shows dts=N/A
On Fri, Mar 11, 2016 at 12:39 PM, Sasi Inguva wrote:
> With this patch it doesn't produce invalid DTS for the file you mentioned
> tickets/1242/sample.mkv
> ./ffmpeg -i sample.mkv -c:v copy -an -t 1 -f framecrc -
>
> On Fri, Mar 11, 2016 at 12:36 PM, Sasi Inguva wrote:
>
>> Having another go at this. My goal is to fix DTS of H264 videos which are
>> shorter than 7 frames and don't have B-frames. Currently ffmpeg will output
>> DTS=N/A for such frames.
>>
>> On Fri, Mar 11, 2016 at 12:34 PM, Sasi Inguva wrote:
>>
>>> Fill DTS if all packets have been read in avformat_find_stream_info, and
>>> still
>>> has_decode_delay_been_guessed returns false.
>>>
>>> Signed-off-by: Sasi Inguva
>>> ---
>>> libavformat/utils.c | 37 +
>>> 1 file changed, 37 insertions(+)
>>>
>>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>>> index 5f48de1..f22309d 100644
>>> --- a/libavformat/utils.c
>>> +++ b/libavformat/utils.c
>>> @@ -877,6 +877,7 @@ static int has_decode_delay_been_guessed(AVStream
>>> *st)
>>> avpriv_h264_has_num_reorder_frames(st->codec) ==
>>> st->codec->has_b_frames)
>>> return 1;
>>> #endif
>>> +
>>> if (st->codec->has_b_frames<3)
>>> return st->nb_decoded_frames >= 7;
>>> else if (st->codec->has_b_frames<4)
>>> @@ -3165,6 +3166,7 @@ int avformat_find_stream_info(AVFormatContext *ic,
>>> AVDictionary **options)
>>> int64_t max_stream_analyze_duration;
>>> int64_t max_subtitle_analyze_duration;
>>> int64_t probesize = ic->probesize;
>>> +int eof_reached = 0;
>>>
>>> flush_codecs = probesize > 0;
>>>
>>> @@ -3331,6 +,7 @@ int avformat_find_stream_info(AVFormatContext *ic,
>>> AVDictionary **options)
>>>
>>> if (ret < 0) {
>>> /* EOF or error*/
>>> +eof_reached = 1;
>>> break;
>>> }
>>>
>>> @@ -3454,6 +3457,40 @@ int avformat_find_stream_info(AVFormatContext
>>> *ic, AVDictionary **options)
>>> count++;
>>> }
>>>
>>> +if (eof_reached && ic->internal->packet_buffer) {
>>> +int stream_index;
>>> +for (stream_index = 0; stream_index < ic->nb_streams;
>>> stream_index++) {
>>> +AVPacketList *pktl = ic->internal->packet_buffer;
>>> +int64_t pts_buffer[MAX_REORDER_DELAY+1];
>>> +
>>> +// EOF already reached while reading the stream above.
>>> +// So continue with reoordering DTS with whatever delay we
>>> have.
>>> +int codec_delay = st->codec->has_b_frames;
>>> +
>>> +st = ic->streams[stream_index];
>>> +
>>> +if (st->codec->codec_id != AV_CODEC_ID_H264 ||
>>> +has_decode_delay_been_guessed(st)) {
>>> +continue;
>>> +}
>>> +
>>> +
>>> +for (; pktl; pktl = get_next_pkt(ic, st, pktl)) {
>>> +if (pktl->pkt.stream_index != stream_index)
>>> +continue;
>>> +
>>> +if (pktl->pkt.pts != AV_NOPTS_VALUE && codec_delay <=
>>> MAX_REORDER_DELAY) {
>>> +int j;
>>> +pts_buffer[0] = pktl->pkt.pts;
>>> +for (j = 0; j < codec_delay && pts_buffer[j] >
>>> pts_buffer[j + 1]; j++)
>>> + FFSWAP(int64_t, pts_buffer[j], pts_buffer[j + 1]);
>>> +
>>> +pktl->pkt.dts = select_from_pts_buffer(st,
>>> pts_buffer, pktl->pkt.dts);
>>> +}
>>> +}
>>> +}
>>> +}
>>> +
>>> if (flush_codecs) {
>>> AVPacket empty_pkt = { 0 };
>>> int err = 0;
>>> --
>>> 2.7.0.rc3.207.g0ac5344
>>>
>>>
>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: fix max bits in ltp prefix code
Thilo Borgmann mail.de> writes: > > libavcodec/alsdec.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Ok. Then please push, the days of the monkeys are long gone;-) Carl Eugen (Or explicitly ask for pushing if you are away.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/utils: Fix DTS for short H264 streams.
Sasi Inguva ffmpeg.org> writes:
> Fill DTS if all packets have been read in
> avformat_find_stream_info, and still
> has_decode_delay_been_guessed returns false.
Could you explain your use-case?
Are streams with less than seven frames frequent?
> return 1;
> #endif
> +
No unrelated changes please.
> if (ret < 0) {
> /* EOF or error*/
> +eof_reached = 1;
> break;
> }
Doesn't the comment indicate that you should
check if you really reached eof?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/utils: Fix DTS for short H264 streams.
We get significant uploads of short timelapse videos which are of very low
frame rate very short length videos, and contain 5-6 frames.
We also have lot of teams using very small test-files, so that they can
test their pipeline very fast.
Sorry for the unintended space insertion.
I couldn't figure out what return value maps to eof and what return value
maps to error , by reading the code of read_frame_internal . If you have an
idea, I can include the return value condition there.
Thanks
On Fri, Mar 11, 2016 at 1:52 PM, Carl Eugen Hoyos wrote:
> Sasi Inguva ffmpeg.org> writes:
>
> > Fill DTS if all packets have been read in
> > avformat_find_stream_info, and still
> > has_decode_delay_been_guessed returns false.
>
> Could you explain your use-case?
> Are streams with less than seven frames frequent?
>
> > return 1;
> > #endif
> > +
>
> No unrelated changes please.
>
> > if (ret < 0) {
> > /* EOF or error*/
> > +eof_reached = 1;
> > break;
> > }
>
> Doesn't the comment indicate that you should
> check if you really reached eof?
>
> Carl Eugen
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: build fix for P5600 along option --disable-msa
On Fri, Mar 11, 2016 at 01:46:42PM +0530, shivraj.pa...@imgtec.com wrote: > From: Shivraj Patil > > Signed-off-by: Shivraj Patil > --- > configure |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] old attachments within lists.mplayerhq.hu
Hi, I am trying to build linphone-android in cygwin. Thank you very much for the patch. Regards MO 2016-03-11 0:23 GMT+02:00 Carl Eugen Hoyos : > mehmet ozisik gmail.com> writes: > > > I was looking for a problem which was posted before which I > > have encountered while building ffmped for android in cygwin > > in windows environment. > > How can I reproduce the issue? > > http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/94091 > > Carl Eugen > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/utils: Fix DTS for short H264 streams.
On Fri, Mar 11, 2016 at 12:34:19PM -0800, Sasi Inguva wrote:
> Fill DTS if all packets have been read in avformat_find_stream_info, and still
> has_decode_delay_been_guessed returns false.
>
> Signed-off-by: Sasi Inguva
> ---
> libavformat/utils.c | 37 +
> 1 file changed, 37 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 5f48de1..f22309d 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -877,6 +877,7 @@ static int has_decode_delay_been_guessed(AVStream *st)
> avpriv_h264_has_num_reorder_frames(st->codec) ==
> st->codec->has_b_frames)
> return 1;
> #endif
> +
> if (st->codec->has_b_frames<3)
> return st->nb_decoded_frames >= 7;
> else if (st->codec->has_b_frames<4)
> @@ -3165,6 +3166,7 @@ int avformat_find_stream_info(AVFormatContext *ic,
> AVDictionary **options)
> int64_t max_stream_analyze_duration;
> int64_t max_subtitle_analyze_duration;
> int64_t probesize = ic->probesize;
> +int eof_reached = 0;
>
> flush_codecs = probesize > 0;
>
> @@ -3331,6 +,7 @@ int avformat_find_stream_info(AVFormatContext *ic,
> AVDictionary **options)
>
> if (ret < 0) {
> /* EOF or error*/
> +eof_reached = 1;
> break;
> }
>
> @@ -3454,6 +3457,40 @@ int avformat_find_stream_info(AVFormatContext *ic,
> AVDictionary **options)
> count++;
> }
>
> +if (eof_reached && ic->internal->packet_buffer) {
> +int stream_index;
> +for (stream_index = 0; stream_index < ic->nb_streams;
> stream_index++) {
> +AVPacketList *pktl = ic->internal->packet_buffer;
> +int64_t pts_buffer[MAX_REORDER_DELAY+1];
> +
> +// EOF already reached while reading the stream above.
> +// So continue with reoordering DTS with whatever delay we have.
> +int codec_delay = st->codec->has_b_frames;
> +
> +st = ic->streams[stream_index];
> +
> +if (st->codec->codec_id != AV_CODEC_ID_H264 ||
> +has_decode_delay_been_guessed(st)) {
> +continue;
> +}
has_decode_delay_been_guessed already contains the H264 check, theres
no need to duplicate it here
> +
> +
> +for (; pktl; pktl = get_next_pkt(ic, st, pktl)) {
> +if (pktl->pkt.stream_index != stream_index)
> +continue;
> +
> +if (pktl->pkt.pts != AV_NOPTS_VALUE && codec_delay <=
> MAX_REORDER_DELAY) {
> +int j;
> +pts_buffer[0] = pktl->pkt.pts;
> +for (j = 0; j < codec_delay && pts_buffer[j] >
> pts_buffer[j + 1]; j++)
> + FFSWAP(int64_t, pts_buffer[j], pts_buffer[j + 1]);
wrong indention
> +
> +pktl->pkt.dts = select_from_pts_buffer(st, pts_buffer,
> pktl->pkt.dts);
> +}
> +}
this loop occurs elsewhere too, please factor it into a function
and not duplicate it otherwise it certainly would become out of
sync if either is changed
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/utils: Fix DTS for short H264 streams.
On Fri, Mar 11, 2016 at 01:54:07PM -0800, Sasi Inguva wrote: > For testing , a link to one such failing video > https://drive.google.com/file/d/0Bz6XfEJZ-9N3X0FSMWR6T3B3U28/view?usp=sharing > . Without this patch, can we include this video in the fate samples for adding a fate test? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: fix max bits in ltp prefix code
On Fri, Mar 11, 2016 at 10:40:06PM +0100, Thilo Borgmann wrote: > Am 11.03.16 um 22:04 schrieb Umair Khan: > > The maximum number of bits int the prefix code for > > p(0) is 4. By setting it as 3, we were missing the > > last 0 bit. > > This fixes bug #4715 present on the trac. > > > > Signed-off-by: Umair Khan > > --- > > libavcodec/alsdec.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Ok. applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/file: Move av_tempfile() to avutil/file_open ff_tempfile()
On Fri, Mar 11, 2016 at 03:35:43PM +0100, Hendrik Leppkes wrote:
> On Wed, Mar 9, 2016 at 4:51 PM, Hendrik Leppkes wrote:
> > On Wed, Mar 9, 2016 at 4:35 PM, Michael Niedermayer
> > wrote:
> >> On Wed, Mar 09, 2016 at 04:27:12PM +0100, Hendrik Leppkes wrote:
> >>> On Wed, Mar 9, 2016 at 3:37 PM, Michael Niedermayer
> >>> wrote:
> >>> > document the issue with av_tempfile()
> >>> >
> >>> > Signed-off-by: Michael Niedermayer
> >>> > ---
> >>> > libavcodec/libxvid.h |2 --
> >>> > libavutil/file.c | 48 ++--
> >>> > libavutil/file.h |1 +
> >>> > libavutil/file_open.c | 59
> >>> > +
> >>> > libavutil/internal.h | 14
> >>> > 5 files changed, 76 insertions(+), 48 deletions(-)
> >>> >
> >>> > diff --git a/libavcodec/libxvid.h b/libavcodec/libxvid.h
> >>> > index bffe07d..ef9a5a9 100644
> >>> > --- a/libavcodec/libxvid.h
> >>> > +++ b/libavcodec/libxvid.h
> >>> > @@ -26,6 +26,4 @@
> >>> > * common functions for use with the Xvid wrappers
> >>> > */
> >>> >
> >>> > -int ff_tempfile(const char *prefix, char **filename);
> >>> > -
> >>> > #endif /* AVCODEC_LIBXVID_H */
> >>> > diff --git a/libavutil/file.c b/libavutil/file.c
> >>> > index 2a06be4..25381b1 100644
> >>> > --- a/libavutil/file.c
> >>> > +++ b/libavutil/file.c
> >>> > @@ -137,52 +137,8 @@ void av_file_unmap(uint8_t *bufptr, size_t size)
> >>> > #endif
> >>> > }
> >>> >
> >>> > -int av_tempfile(const char *prefix, char **filename, int log_offset,
> >>> > void *log_ctx)
> >>> > -{
> >>> > -FileLogContext file_log_ctx = { &file_log_ctx_class, log_offset,
> >>> > log_ctx };
> >>> > -int fd = -1;
> >>> > -#if !HAVE_MKSTEMP
> >>> > -void *ptr= tempnam(NULL, prefix);
> >>> > -if(!ptr)
> >>> > -ptr= tempnam(".", prefix);
> >>> > -*filename = av_strdup(ptr);
> >>> > -#undef free
> >>> > -free(ptr);
> >>> > -#else
> >>> > -size_t len = strlen(prefix) + 12; /* room for "/tmp/" and
> >>> > "XX\0" */
> >>> > -*filename = av_malloc(len);
> >>> > -#endif
> >>> > -/* -common section-*/
> >>> > -if (!*filename) {
> >>> > -av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot
> >>> > allocate file name\n");
> >>> > -return AVERROR(ENOMEM);
> >>> > -}
> >>> > -#if !HAVE_MKSTEMP
> >>> > -# ifndef O_BINARY
> >>> > -# define O_BINARY 0
> >>> > -# endif
> >>> > -# ifndef O_EXCL
> >>> > -# define O_EXCL 0
> >>> > -# endif
> >>> > -fd = open(*filename, O_RDWR | O_BINARY | O_CREAT | O_EXCL, 0600);
> >>> > -#else
> >>> > -snprintf(*filename, len, "/tmp/%sXX", prefix);
> >>> > -fd = mkstemp(*filename);
> >>> > -#ifdef _WIN32
> >>> > -if (fd < 0) {
> >>> > -snprintf(*filename, len, "./%sXX", prefix);
> >>> > -fd = mkstemp(*filename);
> >>> > -}
> >>> > -#endif
> >>> > -#endif
> >>> > -/* -common section-*/
> >>> > -if (fd < 0) {
> >>> > -int err = AVERROR(errno);
> >>> > -av_log(&file_log_ctx, AV_LOG_ERROR, "ff_tempfile: Cannot open
> >>> > temporary file %s\n", *filename);
> >>> > -av_freep(filename);
> >>> > -return err;
> >>> > -}
> >>> > -return fd; /* success */
> >>> > +int av_tempfile(const char *prefix, char **filename, int log_offset,
> >>> > void *log_ctx) {
> >>> > +return avpriv_tempfile(prefix, filename, log_offset, log_ctx);
> >>> > }
> >>> >
> >>> > #ifdef TEST
> >>> > diff --git a/libavutil/file.h b/libavutil/file.h
> >>> > index e931be7..8666c7b 100644
> >>> > --- a/libavutil/file.h
> >>> > +++ b/libavutil/file.h
> >>> > @@ -62,6 +62,7 @@ void av_file_unmap(uint8_t *bufptr, size_t size);
> >>> > * @note On very old libcs it is necessary to set a secure umask before
> >>> > * calling this, av_tempfile() can't call umask itself as it is
> >>> > used in
> >>> > * libraries and could interfere with the calling application.
> >>> > + * @deprecated as fd numbers cannot be passed saftely between libs on
> >>> > some platforms
> >>> > */
> >>> > int av_tempfile(const char *prefix, char **filename, int log_offset,
> >>> > void *log_ctx);
> >>> >
> >>> > diff --git a/libavutil/file_open.c b/libavutil/file_open.c
> >>> > index 9e76127..6e58cc1 100644
> >>> > --- a/libavutil/file_open.c
> >>> > +++ b/libavutil/file_open.c
> >>> > @@ -92,6 +92,65 @@ int avpriv_open(const char *filename, int flags, ...)
> >>> > return fd;
> >>> > }
> >>> >
> >>> > +typedef struct FileLogContext {
> >>> > +const AVClass *class;
> >>> > +int log_offset;
> >>> > +void *log_ctx;
> >>> > +} FileLogContext;
> >>> > +
> >>> > +static const AVClass file_log_ctx_class = {
> >>> > +"TEMPFILE", av_default_item_name, NULL, LIBAVUTIL_VERSION_INT,
> >>> > +offsetof(FileLogContext, log_offset), offsetof(FileLogContext,
> >>> > log_ctx)
> >>> > +};
> >>> > +
> >>> > +int avpriv_tempfile(const char *prefix, char
Re: [FFmpeg-devel] [PATCHv2 1/3] tests/gapless: add gapless aac tests
On Thu, 10 Mar 2016, Michael Niedermayer wrote: On Tue, Mar 08, 2016 at 09:29:51PM +0100, Marton Balint wrote: fails on mips concat-demuxer-extended-lavf-mxf TESTconcat-demuxer-extended-lavf-mxf_d10 --- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/gapless2-mov-aac 2016-03-10 12:56:10.375535413 +0100 +++ tests/data/fate/gapless2-mov-aac2016-03-10 13:28:51.819576737 +0100 @@ -1,11 +1,11 @@ source|[STREAM] source|index=0 -source|codec_name=pcm_s16le +source|codec_name=pcm_s16be source|start_pts=N/A source|duration_ts=529200 source|[/STREAM] source|[FORMAT] -source|format_name=s16le +source|format_name=s16be source|start_time=N/A source|duration=12.00 source|[/FORMAT] Damn, I'll just remove the names as well, and send a new series. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3 3/3] avformat/mov: read start_pad from edit list start time if codec is aac
Related to ticket #2324, #2325. Stream duration still need to be fixed... Signed-off-by: Marton Balint --- libavformat/mov.c | 3 +++ tests/ref/fate/gapless2-ipod-aac1 | 36 ++-- tests/ref/fate/gapless2-ipod-aac2 | 36 ++-- tests/ref/fate/gapless2-mov-aac | 36 ++-- 4 files changed, 57 insertions(+), 54 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 4f446ba..3fa8fcc 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2688,6 +2688,9 @@ static void mov_build_index(MOVContext *mov, AVStream *st) st->codec->has_b_frames = 1; } } + +if (!unsupported && st->codec->codec_id == AV_CODEC_ID_AAC && start_time > 0) +sc->start_pad = start_time; } /* only use old uncompressed audio chunk demuxing when stts specifies it */ diff --git a/tests/ref/fate/gapless2-ipod-aac1 b/tests/ref/fate/gapless2-ipod-aac1 index 2b25fd1..cd236b6 100644 --- a/tests/ref/fate/gapless2-ipod-aac1 +++ b/tests/ref/fate/gapless2-ipod-aac1 @@ -41,11 +41,11 @@ source|1261|frame|pkt_pts=1292288|pkt_dts=1292288|best_effort_timestamp=1292288| source|1262|frame|pkt_pts=1293312|pkt_dts=1293312|best_effort_timestamp=1293312|pkt_duration=1024|nb_samples=1024 target|[STREAM] target|index=0 -target|start_pts=-1024 +target|start_pts=0 target|duration_ts=1293248 target|[/STREAM] target|[FORMAT] -target|start_time=-0.023220 +target|start_time=0.00 target|duration=29.326000 target|[/FORMAT] target|1|packet|pts=-1024|dts=-1024|duration=1024 @@ -64,19 +64,19 @@ target|1260|packet|pts=1288192|dts=1288192|duration=1024 target|1261|packet|pts=1289216|dts=1289216|duration=1024 target|1262|packet|pts=1290240|dts=1290240|duration=1024 target|1263|packet|pts=1291264|dts=1291264|duration=1984 -target|1|frame|pkt_pts=-1024|pkt_dts=-1024|best_effort_timestamp=-1024|pkt_duration=1024|nb_samples=1024 -target|2|frame|pkt_pts=0|pkt_dts=0|best_effort_timestamp=0|pkt_duration=1024|nb_samples=1024 -target|3|frame|pkt_pts=1024|pkt_dts=1024|best_effort_timestamp=1024|pkt_duration=1024|nb_samples=1024 -target|4|frame|pkt_pts=2048|pkt_dts=2048|best_effort_timestamp=2048|pkt_duration=1024|nb_samples=1024 -target|5|frame|pkt_pts=3072|pkt_dts=3072|best_effort_timestamp=3072|pkt_duration=1024|nb_samples=1024 -target|6|frame|pkt_pts=4096|pkt_dts=4096|best_effort_timestamp=4096|pkt_duration=1024|nb_samples=1024 -target|7|frame|pkt_pts=5120|pkt_dts=5120|best_effort_timestamp=5120|pkt_duration=1024|nb_samples=1024 -target|8|frame|pkt_pts=6144|pkt_dts=6144|best_effort_timestamp=6144|pkt_duration=1024|nb_samples=1024 -target|1256|frame|pkt_pts=1284096|pkt_dts=1284096|best_effort_timestamp=1284096|pkt_duration=1024|nb_samples=1024 -target|1257|frame|pkt_pts=1285120|pkt_dts=1285120|best_effort_timestamp=1285120|pkt_duration=1024|nb_samples=1024 -target|1258|frame|pkt_pts=1286144|pkt_dts=1286144|best_effort_timestamp=1286144|pkt_duration=1024|nb_samples=1024 -target|1259|frame|pkt_pts=1287168|pkt_dts=1287168|best_effort_timestamp=1287168|pkt_duration=1024|nb_samples=1024 -target|1260|frame|pkt_pts=1288192|pkt_dts=1288192|best_effort_timestamp=1288192|pkt_duration=1024|nb_samples=1024 -target|1261|frame|pkt_pts=1289216|pkt_dts=1289216|best_effort_timestamp=1289216|pkt_duration=1024|nb_samples=1024 -target|1262|frame|pkt_pts=1290240|pkt_dts=1290240|best_effort_timestamp=1290240|pkt_duration=1024|nb_samples=1024 -target|1263|frame|pkt_pts=1291264|pkt_dts=1291264|best_effort_timestamp=1291264|pkt_duration=1984|nb_samples=1024 +target|1|frame|pkt_pts=0|pkt_dts=0|best_effort_timestamp=0|pkt_duration=1024|nb_samples=1024 +target|2|frame|pkt_pts=1024|pkt_dts=1024|best_effort_timestamp=1024|pkt_duration=1024|nb_samples=1024 +target|3|frame|pkt_pts=2048|pkt_dts=2048|best_effort_timestamp=2048|pkt_duration=1024|nb_samples=1024 +target|4|frame|pkt_pts=3072|pkt_dts=3072|best_effort_timestamp=3072|pkt_duration=1024|nb_samples=1024 +target|5|frame|pkt_pts=4096|pkt_dts=4096|best_effort_timestamp=4096|pkt_duration=1024|nb_samples=1024 +target|6|frame|pkt_pts=5120|pkt_dts=5120|best_effort_timestamp=5120|pkt_duration=1024|nb_samples=1024 +target|7|frame|pkt_pts=6144|pkt_dts=6144|best_effort_timestamp=6144|pkt_duration=1024|nb_samples=1024 +target|8|frame|pkt_pts=7168|pkt_dts=7168|best_effort_timestamp=7168|pkt_duration=1024|nb_samples=1024 +target|1255|frame|pkt_pts=1284096|pkt_dts=1284096|best_effort_timestamp=1284096|pkt_duration=1024|nb_samples=1024 +target|1256|frame|pkt_pts=1285120|pkt_dts=1285120|best_effort_timestamp=1285120|pkt_duration=1024|nb_samples=1024 +target|1257|frame|pkt_pts=1286144|pkt_dts=1286144|best_effort_timestamp=1286144|pkt_duration=1024|nb_samples=1024 +target|1258|frame|pkt_pts=1287168|pkt_dts=1287168|best_effort_timestamp=1287168|pkt_duration=1024|nb_samples=1024 +target|1259|frame|pkt_pts=1288192|pkt_dts=1288192|best_effort_timestamp=1288192|pkt_dura
[FFmpeg-devel] [PATCHv3 2/3] avformat/utils: increase detected start_time with skip_samples
Signed-off-by: Marton Balint
---
libavformat/utils.c | 10 --
tests/ref/fate/gapless2-ipod-aac1 | 72 +++
tests/ref/fate/gapless2-ipod-aac2 | 72 +++
3 files changed, 80 insertions(+), 74 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index e0aea87..ccb76d2 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -971,8 +971,11 @@ static void update_initial_timestamps(AVFormatContext *s,
int stream_index,
if (is_relative(pktl->pkt.dts))
pktl->pkt.dts += shift;
-if (st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts !=
AV_NOPTS_VALUE)
+if (st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts !=
AV_NOPTS_VALUE) {
st->start_time = pktl->pkt.pts;
+if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
st->codec->sample_rate)
+st->start_time += av_rescale_q(st->skip_samples,
(AVRational){1, st->codec->sample_rate}, st->time_base);
+}
if (pktl->pkt.pts != AV_NOPTS_VALUE && delay <= MAX_REORDER_DELAY &&
has_decode_delay_been_guessed(st)) {
pts_buffer[0] = pktl->pkt.pts;
@@ -983,8 +986,11 @@ static void update_initial_timestamps(AVFormatContext *s,
int stream_index,
}
}
-if (st->start_time == AV_NOPTS_VALUE)
+if (st->start_time == AV_NOPTS_VALUE) {
st->start_time = pts;
+if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO &&
st->codec->sample_rate)
+st->start_time += av_rescale_q(st->skip_samples, (AVRational){1,
st->codec->sample_rate}, st->time_base);
+}
}
static void update_initial_durations(AVFormatContext *s, AVStream *st,
diff --git a/tests/ref/fate/gapless2-ipod-aac1
b/tests/ref/fate/gapless2-ipod-aac1
index b0ff2f4..2b25fd1 100644
--- a/tests/ref/fate/gapless2-ipod-aac1
+++ b/tests/ref/fate/gapless2-ipod-aac1
@@ -1,10 +1,10 @@
source|[STREAM]
source|index=0
-source|start_pts=0
+source|start_pts=2112
source|duration_ts=1294336
source|[/STREAM]
source|[FORMAT]
-source|start_time=0.00
+source|start_time=0.047889
source|duration=29.350023
source|[/FORMAT]
source|1|packet|pts=0|dts=0|duration=1024
@@ -41,42 +41,42 @@
source|1261|frame|pkt_pts=1292288|pkt_dts=1292288|best_effort_timestamp=1292288|
source|1262|frame|pkt_pts=1293312|pkt_dts=1293312|best_effort_timestamp=1293312|pkt_duration=1024|nb_samples=1024
target|[STREAM]
target|index=0
-target|start_pts=1058
+target|start_pts=-1024
target|duration_ts=1293248
target|[/STREAM]
target|[FORMAT]
-target|start_time=0.023991
+target|start_time=-0.023220
target|duration=29.326000
target|[/FORMAT]
-target|1|packet|pts=1058|dts=1058|duration=1024
-target|2|packet|pts=2082|dts=2082|duration=1024
-target|3|packet|pts=3106|dts=3106|duration=1024
-target|4|packet|pts=4130|dts=4130|duration=1024
-target|5|packet|pts=5154|dts=5154|duration=1024
-target|6|packet|pts=6178|dts=6178|duration=1024
-target|7|packet|pts=7202|dts=7202|duration=1024
-target|8|packet|pts=8226|dts=8226|duration=1024
-target|1256|packet|pts=1286178|dts=1286178|duration=1024
-target|1257|packet|pts=1287202|dts=1287202|duration=1024
-target|1258|packet|pts=1288226|dts=1288226|duration=1024
-target|1259|packet|pts=1289250|dts=1289250|duration=1024
-target|1260|packet|pts=1290274|dts=1290274|duration=1024
-target|1261|packet|pts=1291298|dts=1291298|duration=1024
-target|1262|packet|pts=1292322|dts=1292322|duration=1024
-target|1263|packet|pts=1293346|dts=1293346|duration=-98
-target|1|frame|pkt_pts=1058|pkt_dts=1058|best_effort_timestamp=1058|pkt_duration=1024|nb_samples=1024
-target|2|frame|pkt_pts=2082|pkt_dts=2082|best_effort_timestamp=2082|pkt_duration=1024|nb_samples=1024
-target|3|frame|pkt_pts=3106|pkt_dts=3106|best_effort_timestamp=3106|pkt_duration=1024|nb_samples=1024
-target|4|frame|pkt_pts=4130|pkt_dts=4130|best_effort_timestamp=4130|pkt_duration=1024|nb_samples=1024
-target|5|frame|pkt_pts=5154|pkt_dts=5154|best_effort_timestamp=5154|pkt_duration=1024|nb_samples=1024
-target|6|frame|pkt_pts=6178|pkt_dts=6178|best_effort_timestamp=6178|pkt_duration=1024|nb_samples=1024
-target|7|frame|pkt_pts=7202|pkt_dts=7202|best_effort_timestamp=7202|pkt_duration=1024|nb_samples=1024
-target|8|frame|pkt_pts=8226|pkt_dts=8226|best_effort_timestamp=8226|pkt_duration=1024|nb_samples=1024
-target|1256|frame|pkt_pts=1286178|pkt_dts=1286178|best_effort_timestamp=1286178|pkt_duration=1024|nb_samples=1024
-target|1257|frame|pkt_pts=1287202|pkt_dts=1287202|best_effort_timestamp=1287202|pkt_duration=1024|nb_samples=1024
-target|1258|frame|pkt_pts=1288226|pkt_dts=1288226|best_effort_timestamp=1288226|pkt_duration=1024|nb_samples=1024
-target|1259|frame|pkt_pts=1289250|pkt_dts=1289250|best_effort_timestamp=1289250|pkt_duration=1024|nb_samples=1024
-target|1260|frame|pkt_pts=1290274|pkt_dts=1290274|best_effort_timestamp=1290274|pkt_duration=1024|nb_samples=1024
-target|1261|frame|pkt_pts=1291298|pkt_dts=1291298|be
[FFmpeg-devel] [PATCHv3 1/3] tests/gapless: add gapless aac tests
Signed-off-by: Marton Balint
---
tests/fate-run.sh | 30 ++
tests/fate/gapless.mak| 20 +-
tests/ref/fate/gapless2-ipod-aac1 | 82 +++
tests/ref/fate/gapless2-ipod-aac2 | 82 +++
tests/ref/fate/gapless2-mov-aac | 82 +++
5 files changed, 295 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/gapless2-ipod-aac1
create mode 100644 tests/ref/fate/gapless2-ipod-aac2
create mode 100644 tests/ref/fate/gapless2-mov-aac
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 16087cb..1063c0c 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -96,6 +96,21 @@ probeframes(){
run ffprobe${PROGSUF} -show_frames -v 0 "$@"
}
+probegaplessinfo(){
+filename=$1
+shift
+run ffprobe${PROGSUF} -bitexact -select_streams a -show_entries
format=start_time,duration:stream=index,start_pts,duration_ts -v 0 "$filename"
"$@"
+pktfile1="${filename}.pkts"
+framefile1="${filename}.frames"
+cleanfiles="$cleanfiles $pktfile1 $framefile1"
+run ffprobe${PROGSUF} -bitexact -select_streams a -of compact
-show_entries packet=pts,dts,duration -v 0 "$filename" "$@" | nl -w 1 -s '|' >
$pktfile1
+head -n 8 $pktfile1
+tail -n 8 $pktfile1
+run ffprobe${PROGSUF} -bitexact -select_streams a -of compact
-show_entries
frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples -v 0
"$filename" "$@" | nl -w 1 -s '|' > $framefile1
+head -n 8 $framefile1
+tail -n 8 $framefile1
+}
+
ffmpeg(){
dec_opts="-hwaccel $hwaccel -threads $threads -thread_type $thread_type"
ffmpeg_args="-nostdin -nostats -cpuflags $cpuflags"
@@ -249,6 +264,21 @@ gapless(){
do_md5sum $decfile3
}
+gapless2(){
+sample=$(target_path $1)
+format=$2
+codec=$3
+
+file1="${outdir}/${test}.out-1"
+cleanfiles="$cleanfiles $file1"
+
+# test source data
+probegaplessinfo "$sample" | sed 's/^/source|/'
+# test data after reencoding
+ffmpeg -i "$sample" -flags +bitexact -fflags +bitexact -map 0:a -c:a
$codec -f $format -y $file1
+probegaplessinfo "$file1" | sed 's/^/target|/'
+}
+
concat(){
template=$1
sample=$2
diff --git a/tests/fate/gapless.mak b/tests/fate/gapless.mak
index 2fb005f..8d819bd 100644
--- a/tests/fate/gapless.mak
+++ b/tests/fate/gapless.mak
@@ -3,5 +3,23 @@ fate-gapless-mp3: CMD = gapless
$(TARGET_SAMPLES)/gapless/gapless.mp3
FATE_GAPLESS = $(FATE_GAPLESS-yes)
+FATE_GAPLESS2_PROBE-$(call ENCDEC, AAC, MOV) += fate-gapless2-ipod-aac1
+fate-gapless2-ipod-aac1: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gapless2-ipod-aac1: CMD = gapless2
$(TARGET_SAMPLES)/cover_art/Owner-iTunes_9.0.3.15.m4a ipod aac
+
+FATE_GAPLESS2_PROBE-$(call ENCDEC, AAC, MOV) += fate-gapless2-ipod-aac2
+fate-gapless2-ipod-aac2: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gapless2-ipod-aac2: CMD = gapless2
$(TARGET_SAMPLES)/gapless/102400samples_qt-lc-aac.m4a ipod aac
+
+FATE_GAPLESS2_PROBE-$(call ENCDEC, AAC, MOV) += fate-gapless2-mov-aac
+fate-gapless2-mov-aac: $(AREF)
+fate-gapless2-mov-aac: ffprobe$(PROGSSUF)$(EXESUF)
+fate-gapless2-mov-aac: CMD = gapless2 $(AREF) mov aac
+
+FATE_GAPLESS2-$(CONFIG_FFPROBE) = $(FATE_GAPLESS2_PROBE-yes)
+FATE_GAPLESS2 = $(FATE_GAPLESS2-yes)
+
FATE_SAMPLES_AVCONV += $(FATE_GAPLESS)
-fate-gapless: $(FATE_GAPLESS)
+FATE_SAMPLES_AVCONV += $(FATE_GAPLESS2)
+
+fate-gapless: $(FATE_GAPLESS) $(FATE_GAPLESS2)
diff --git a/tests/ref/fate/gapless2-ipod-aac1
b/tests/ref/fate/gapless2-ipod-aac1
new file mode 100644
index 000..b0ff2f4
--- /dev/null
+++ b/tests/ref/fate/gapless2-ipod-aac1
@@ -0,0 +1,82 @@
+source|[STREAM]
+source|index=0
+source|start_pts=0
+source|duration_ts=1294336
+source|[/STREAM]
+source|[FORMAT]
+source|start_time=0.00
+source|duration=29.350023
+source|[/FORMAT]
+source|1|packet|pts=0|dts=0|duration=1024
+source|2|packet|pts=1024|dts=1024|duration=1024
+source|3|packet|pts=2048|dts=2048|duration=1024
+source|4|packet|pts=3072|dts=3072|duration=1024
+source|5|packet|pts=4096|dts=4096|duration=1024
+source|6|packet|pts=5120|dts=5120|duration=1024
+source|7|packet|pts=6144|dts=6144|duration=1024
+source|8|packet|pts=7168|dts=7168|duration=1024
+source|1257|packet|pts=1286144|dts=1286144|duration=1024
+source|1258|packet|pts=1287168|dts=1287168|duration=1024
+source|1259|packet|pts=1288192|dts=1288192|duration=1024
+source|1260|packet|pts=1289216|dts=1289216|duration=1024
+source|1261|packet|pts=1290240|dts=1290240|duration=1024
+source|1262|packet|pts=1291264|dts=1291264|duration=1024
+source|1263|packet|pts=1292288|dts=1292288|duration=1024
+source|1264|packet|pts=1293312|dts=1293312|duration=1024
+source|1|frame|pkt_pts=2112|pkt_dts=2112|best_effort_timestamp=2048|pkt_duration=960|nb_samples=960
+source|2|frame|pkt_pts=3072|pkt_dts=3072|best_effort_timestamp=3072|pkt_duration=1024|nb_samples=1024
+source|3|frame|pkt_pts=4096|pkt_dts=4096|best_effort_ti
Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section
On Thu, Mar 10, 2016 at 07:57:53PM +0100, Hendrik Leppkes wrote: > On Mon, Sep 21, 2015 at 6:41 AM, Alex Smith wrote: > > From: Alex Smith > > > > Binutils will always strip the relocation information from executable > > files even if it needs it (dynamicbase/ASLR). We can work around this > > by using the pic-executable flag combined with setting the correct entry > > point since apparently ld forgets what that should be. This problem > > affects both 32 and 64-bit mingw-w64. > > > > We can combine the nxcompat/dynamicbase check because they were added to > > binutils at the same time. > > > > Signed-off-by: Alex Smith > > > > Conflicts: > > configure > > --- > > configure | 13 +++-- > > 1 file changed, 11 insertions(+), 2 deletions(-) > > > > diff --git a/configure b/configure > > index d2a25bb..d6ab35a 100755 > > --- a/configure > > +++ b/configure > > @@ -4367,8 +4367,6 @@ case $target_os in > > LIBTARGET=arm-wince > > fi > > enabled shared && ! enabled small && check_cmd $windres --version > > && enable gnu_windres > > -check_ldflags -Wl,--nxcompat > > -check_ldflags -Wl,--dynamicbase > > enabled x86_32 && check_ldflags -Wl,--large-address-aware > > shlibdir_default="$bindir_default" > > SLIBPREF="" > > @@ -4392,6 +4390,17 @@ case $target_os in > > objformat="win32" > > ranlib=: > > enable dos_paths > > +check_ldflags -Wl,--nxcompat,--dynamicbase > > +# Lets work around some stupidity in binutils. > > +# ld will strip relocations from executables even though we need > > them > > +# for dynamicbase (ASLR). Using -pie does retain the reloc section > > +# however ld then forgets what the entry point should be (oops) so > > we > > +# have to manually (re)set it. > > +if enabled x86_32; then > > +add_ldexeflags -Wl,--pic-executable,-e,_mainCRTStartup > > +elif enabled x86_64; then > > +add_ldexeflags -Wl,--pic-executable,-e,mainCRTStartup > > +fi > > ;; > > win32|win64) > > disable symver > > This patch (the relocations part) broke debugging mingw-w64 ffmpeg > builds with gdb, you can't set breakpoints anymore when its applied. > It should either be reverted or made dependent on > --enable/disable-debug (I would favor the first, honestly, since its a > rather ugly hack in itself). as i was the one applying it IIRC, i should probably comment ... iam not against this being partially or fully revered/mode conditional if it causes more problems than it does good. > > Did the binutils/mingw guys ever comment anything useful on this issue? > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3 1/3] tests/gapless: add gapless aac tests
On Sat, Mar 12, 2016 at 02:49:10AM +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > tests/fate-run.sh | 30 ++ > tests/fate/gapless.mak| 20 +- > tests/ref/fate/gapless2-ipod-aac1 | 82 > +++ > tests/ref/fate/gapless2-ipod-aac2 | 82 > +++ > tests/ref/fate/gapless2-mov-aac | 82 > +++ > 5 files changed, 295 insertions(+), 1 deletion(-) > create mode 100644 tests/ref/fate/gapless2-ipod-aac1 > create mode 100644 tests/ref/fate/gapless2-ipod-aac2 > create mode 100644 tests/ref/fate/gapless2-mov-aac cant speak about portability of the tests, do we use nl/head/tail elsewhere ? otherwise this LGTM also tested on mips/arm qemu [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavf/riffenc: Improve spec compliance; Fix WMP playback of AVI with xxpc chunks
New patch set. Forget the old one. From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is 40 for palettized video as well. And Windows Media Player won't display any video when using Microsoft Video 1 in 8 bpp mode or RLE4/RLE8 if this value is set to anything else than 40. For non-palette extra data in huffyuv, ffvhuff, asv1 and asv2, the extra data will be included in biSize. There are possibly more codecs with special global headers, but we can fix that as they are discovered. Currently these are the only ones I know of. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 won't work with Windows Media Player and AVI files with xxpc (palette change) chunks for some reason. Mats >From a54f3d793990d10f1fd99645d85580bbdaf8e7c4 Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sat, 12 Mar 2016 07:03:51 +0100 Subject: [PATCH 1/2] lavf/riffenc: Improve spec compliance; Fix WMP playback of AVI with xxpc chunks --- libavformat/riffenc.c | 14 +++--- tests/ref/fate/mpeg4-bsf-unpack-bframes|2 +- tests/ref/lavf-fate/avi_cram |2 +- tests/ref/vsynth/vsynth1-bpp1 |2 +- tests/ref/vsynth/vsynth1-ffv1 |2 +- tests/ref/vsynth/vsynth1-ffv1-v3-bgr0 |2 +- tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p |2 +- tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 |2 +- tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 |2 +- tests/ref/vsynth/vsynth1-wmv2 |2 +- tests/ref/vsynth/vsynth1-zlib |2 +- tests/ref/vsynth/vsynth2-bpp1 |2 +- tests/ref/vsynth/vsynth2-ffv1 |2 +- tests/ref/vsynth/vsynth2-ffv1-v3-bgr0 |2 +- tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p |2 +- tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 |2 +- tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 |2 +- tests/ref/vsynth/vsynth2-wmv2 |2 +- tests/ref/vsynth/vsynth2-zlib |2 +- tests/ref/vsynth/vsynth3-bpp1 |2 +- tests/ref/vsynth/vsynth3-ffv1 |2 +- tests/ref/vsynth/vsynth3-ffv1-v3-bgr0 |2 +- tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p |2 +- tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 |2 +- tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 |2 +- tests/ref/vsynth/vsynth3-wmv2 |2 +- tests/ref/vsynth/vsynth3-zlib |2 +- tests/ref/vsynth/vsynth_lena-bpp1 |2 +- tests/ref/vsynth/vsynth_lena-ffv1 |2 +- tests/ref/vsynth/vsynth_lena-ffv1-v3-bgr0 |2 +- tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420|4 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420p |2 +- tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv422p10 |2 +- tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv444p16 |2 +- tests/ref/vsynth/vsynth_lena-wmv2 |2 +- tests/ref/vsynth/vsynth_lena-zlib |2 +- 36 files changed, 45 insertions(+), 41 deletions(-) delete mode 100644 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420 diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c index 195a58e..0851ff9 100644 --- a/libavformat/riffenc.c +++ b/libavformat/riffenc.c @@ -222,8 +222,13 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc, if (!enc->extradata_size && pal_avi) extradata_size = 4 * (1 << enc->bits_per_coded_sample); -/* size */ -avio_wl32(pb, 40 + (ignore_extradata ? 0 :extradata_size)); +/* Size (not including the size of the color table or color masks) */ +avio_wl32(pb, 40 + (!ignore_extradata && ( + enc->codec_id == AV_CODEC_ID_ASV1 || + enc->codec_id == AV_CODEC_ID_ASV2 || + enc->codec_id == AV_CODEC_ID_FFVHUFF || + enc->codec_id == AV_CODEC_ID_HUFFYUV + ) ? extradata_size : 0)); avio_wl32(pb, enc->width); //We always store RGB TopDown avio_wl32(pb, enc->codec_tag || keep_height ? enc->height : -enc->height); @@ -236,7 +241,10 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc, avio_wl32(pb, (enc->width * enc->height * (enc->bits_per_coded_sample ? enc->bits_per_coded_sample : 24)+7) / 8); avio_wl32(pb, 0); avio_wl32(pb, 0); -avio_wl32(pb, 0); +/* Number of color indices in the color table that are used. + * A value of 0 means 2^biBitCount indices, but this doesn't work + * with Windows Media Player and files containing xxpc chunks. */ +avio_wl32(pb, pal_avi ? 1 << enc->bits_per_co
[FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index
Here's an interesting one. Windows Media Player won't make any palette
changes without the xxpc chunks beeing indexed.
Fixing the logic for reading and seeking with xxpc chunks in the demuxer
is a future task. Now the muxing of video with xxpc chunks works
properly at least.
Try playing the resulting test.avi file from the command line below with
Windows Media Player, with and without this patch.
ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 50f6c1dd38f503e77d53e0e6cdbadfe511282126 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sat, 12 Mar 2016 07:00:33 +0100
Subject: [PATCH 2/2] lavf/avienc: Add xxpc entries to index
---
libavformat/avi.h|6 -
libavformat/avienc.c | 56 +-
tests/ref/lavf-fate/avi_cram |4 +--
3 files changed, 51 insertions(+), 15 deletions(-)
diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
#define AVI_MASTER_INDEX_SIZE 256
#define AVI_MAX_STREAM_COUNT100
+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES 0x0001
+
/* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME 0x0100
#endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b731bc2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
*/
typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[5];
+unsigned int flags;
+unsigned int pos;
+unsigned int len;
} AVIIentry;
#define AVI_INDEX_CLUSTER_SIZE 16384
-#define AVISF_VIDEO_PALCHANGES 0x0001
-
typedef struct AVIIndex {
int64_t indx_start;
int64_t audio_strm_offset;
@@ -612,9 +613,13 @@ static int avi_write_idx1(AVFormatContext *s)
}
if (!empty) {
avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)
+ffio_wfourcc(pb, ie->tag);
+else {
+avi_stream2fourcc(tag, stream_id,
s->streams[stream_id]->codec->codec_type);
-ffio_wfourcc(pb, tag);
+ffio_wfourcc(pb, tag);
+}
avio_wl32(pb, ie->flags);
avio_wl32(pb, ie->pos);
avio_wl32(pb, ie->len);
@@ -673,6 +678,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
return avi_write_packet_internal(s, pkt); /* Passthrough */
if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+AVIContext *avi = s->priv_data;
AVIStream *avist = s->streams[stream_index]->priv_data;
AVIOContext *pb = s->pb;
AVPacket *opkt = pkt;
@@ -709,6 +715,39 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
unsigned char tag[5];
avi_stream2fourcc(tag, stream_index, enc->codec_type);
tag[2] = 'p'; tag[3] = 'c';
+if (s->pb->seekable) {
+AVIIndex *idx;
+int cl, id;
+if (avist->strh_flags_offset) {
+int64_t cur_offset = avio_tell(pb);
+avio_seek(pb, avist->strh_flags_offset, SEEK_SET);
+avio_wl32(pb, AVISF_VIDEO_PALCHANGES);
+avio_seek(pb, cur_offset, SEEK_SET);
+avist->strh_flags_offset = 0;
+}
+idx = &avist->indexes;
+cl = idx->entry / AVI_INDEX_CLUSTER_SIZE;
+id = idx->entry % AVI_INDEX_CLUSTER_SIZE;
+if (idx->ents_allocated <= idx->entry) {
+idx->cluster = av_realloc_f(idx->cluster, sizeof(void*), cl+1);
+if (!idx->cluster) {
+idx->ents_allocated = 0;
+idx->entry = 0;
+return AVERROR(ENOMEM);
+}
+idx->cluster[cl] =
+av_malloc(AVI_INDEX_CLUSTER_SIZE * sizeof(AVIIentry));
+if (!idx->cluster[cl])
+return AVERROR(ENOMEM);
+idx->ents_allocated += AVI_INDEX_CLUSTER_SIZE;
+}
+strcpy(idx->cluster[cl][id].tag, tag);
+idx->cluster[cl][id].flags = AVIIF_NO_TIME;
+idx->cluster[cl][id].pos = avio_tell(pb) - avi->movi_list;
+idx->cluster[cl][id].len = pal_size * 4
Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index
On 03/12/2016 07:14 AM, Mats Peterson wrote: Here's an interesting one. Windows Media Player won't make any palette changes without the xxpc chunks beeing indexed. Fixing the logic for reading and seeking with xxpc chunks in the demuxer is a future task. Now the muxing of video with xxpc chunks works properly at least. Try playing the resulting test.avi file from the command line below with Windows Media Player, with and without this patch. ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi Mats TOON.AVI is the file below, not the one included in fate-samples, which is only the first 1 MB of the original one, and which lacks an index). https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/avienc: Add xxpc entries to index
On 03/12/2016 08:31 AM, Mats Peterson wrote: On 03/12/2016 07:14 AM, Mats Peterson wrote: Here's an interesting one. Windows Media Player won't make any palette changes without the xxpc chunks beeing indexed. Fixing the logic for reading and seeking with xxpc chunks in the demuxer is a future task. Now the muxing of video with xxpc chunks works properly at least. Try playing the resulting test.avi file from the command line below with Windows Media Player, with and without this patch. ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi Mats TOON.AVI is the file below, not the one included in fate-samples, which is only the first 1 MB of the original one, and which lacks an index). https://drive.google.com/open?id=0B3_pEBoLs0faaFY0ME92SDA1VEU Mats ___ Well, it doesn't matter, since it's the produced file that is relevant. Sorry. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
