Hello,
Patch in attach add some bitexact conversion for grayf32
and unscaled conv for gray16 to grayf32.
Pass fate test for me (x86_64, macos 10.12)
001 : Add bit exact conv for float to uint16
002 : Add bit exact conv for float to uint8
003 : Add bit exact lut generation for 8b to float (alloc/
Updated patch in attach
001 and 002 : unchanged
003 : update from prev 003 : change in lut generation : move coeff calc
outside the loop, and avoid "i - min_loop" calc.
004 : update from prev 004 : change in lut generation : avoid "i -
min_loop" calc.
Martin
0002-swscale-unscale-add-bitexact-co
>
> does the LUT generation code produce different results on platforms ?
> if so i would suggest to try to use double and to add a small offset if
> needed
>
> a 8bit table has 256 entries, a 16bit table 65536
> a difference would occur if a source value from 64bit floats gets rounded
> differentl
> you can just use something like (possibly with more or less 0 or a
> magnitude
> related value)
> #define assert_stable_int(x) av_assert(llrintf(x+0.0001) ==
> llrintf(x-0.0001))
> #define assert_stable_float(x) av_assert((float)(x+0.0001) ==
> (float)(x-0.0001))
>
> and then plac
> also, have you tried adding a small constant to tmp ?
> i would expect that this or a similar operation would allow moving
> away from all "unstable" points without really changing the output in a
> relevant way.
>
>
Can't find an op, in mult mode, in order to not raise the assert
But if i use ad
Hello,
In current git, the qt faststart test doesn't pass for me (clang os 10.12),
maybe need to be fix before the release.
CCtools/qt-faststart.o
LDtools/qt-faststart
TESTmov-faststart-4gb-overflow
--- -2018-09-20 12:18:23.0 +0200
+++ tests/data/fate/mov-faststart-4gb-ove
Hello,
Following suggestion of Hendrik Leppkes
the patch in attach fix for me the test mov-faststart-4gb-overflow
(os 10.12)
Can be test with :
make fate-mov-faststart-4gb-overflow SAMPLES=fate-suite
Martin
0001-fate-mov-use-do_md5sum-for-mov-faststart-4gb-overflo.patch
Description: Binary da
Le ven. 21 sept. 2018 à 05:17, James Almer a écrit :
>
>
> Should be ok.
>
>
Pushed, Thanks
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello,
Resend previous patch (from July)
001 : use scantable in prores_data instead of a duplicate one.
Doesn't seems to make speed loss (tested with timer and with -benchmark)
002 :
use for the frame header, primaries, transfert, colorspace like in
proresenc_ks
avoid color shift on some softwar
>
> also there are 2 divisions in this that you can trivially eliminate
> /255 and /65535 (extra precission beyond IEEE float/double could change
> these)
>
> also the whole could be done with fewer floats and no extra complexity
> for example:
> int64_t tmp2 = 16843009LL * i;
> (float)((double)tmp
Hello,
Patch in attach port inline asm shuffle 2103 func (mmx/mmxext) to external
asm
and remove the inline asm version
Martin
0001-swscale-x86-rgb2rgb-port-shuffle2103-to-external-asm.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpe
>
> Keeping both MMX and MMXEXT seems a bit excessive. Ideally both would
> be replaced with something more modern, but I'd at least drop the MMX
> one.
>
This func already have SSSE3 version (AVX2 can be add easily, but doesn't
find a command line where the speed is interesting in AVX2 (on my
com
> > >
> > > Keeping both MMX and MMXEXT seems a bit excessive. Ideally both would
> > > be replaced with something more modern, but I'd at least drop the MMX
> > > one.
> > >
> >
> > This func already have SSSE3 version (AVX2 can be add easily, but doesn't
> > find a command line where the speed is
>
> porting code and removing code sounds like 2 seperate things,
> that should not be in the same patch
>
Split patch in attach
Martin
0002-swscale-x86-rgb2rgb-remove-inline-mmx-mmxext-version.patch
Description: Binary data
0001-swscale-x86-rgb2rgb-port-shuffle-2103-mmxext-to-exte.patch
Desc
Le mer. 10 oct. 2018 à 11:52, Marc-Antoine ARNAUD <
arnaud.marcanto...@gmail.com> a écrit :
> Great patches ;-)
> I have submit a patch too, regarding colospace in prores:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-October/235034.html
> You have also in your patch 2, the same purpose (take co
>
> the split should be
> the removal of the code that stays removed
> the porting of the remaining code
>
> I understand its easier to drop both and then add one but thats a ugly way
> to split the patch. The patch porting the code should show both the code
> thats removed as well as the added cod
Le mer. 10 oct. 2018 à 17:13, Marc-Antoine ARNAUD <
arnaud.marcanto...@gmail.com> a écrit :
> I have updated the patch with our discussion.
> It took information only from the codec context.
>
> Marc-Antoine
>
> Hello,
If i correctly understand (which is not sure :-) :
the colorspace for AVCodec
> thats eliminates my concern
>
> Pushed, thanks.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello,
Patch in attach add a video generator which output all gray value for the
given pix_fmt
Also add fate test for each target pix_fmt.
The goal is to have a generator for testing swscale unscaled conversion
later
The size of the output depend of the pix_fmt
gray8 output a 256x1 frame
gray9 l
>
> The 256x <=16 size is not very useful.
>
You mean, increase the height of the output frame ?
If yes :
Do you think it's better to duplicate each value, or duplicate the current
lines several times ?
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@
>
> Applied
>
>
Seems like fate-mxf-reel_name doesn't pass after your patchs
make fate-mxf-reel_name SAMPLES=fate-suite
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > You mean, increase the height of the output frame ?
> > If yes :
> > Do you think it's better to duplicate each value, or duplicate the
> current
> > lines several times ?
>
> Your pick.
>
New patch in attach,
for gray 8, 9, 10, duplicate lines ramp several times, to have 16 pix height
(probab
Hello,
Following Carl Eugen comment,
and this commit :
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b38d4874
Add name of the author of the inline mmxext version of shuffle2103 at the
top of the asm file
Martin
0001-swscale-x86-rgb2rgb.asm-add-Ivo-Van-Poorten-name-to-.patch
Description
Hello,
Patch in attach add YA16 le/be output for swscale
(only available as input before this patch)
Martin
0001-swscale-add-YA16-LE-BE-output.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailm
Le lun. 15 oct. 2018 à 11:24, Marc-Antoine ARNAUD <
arnaud.marcanto...@gmail.com> a écrit :
> Hi Martin,
>
> For my point of view, the AVFrame contains the colorspace for each frame,
> which can be different (maybe not volunteer..).
> The colorspace in AVCodecContext is the "pre-computed" colorspa
>
> should be ok if you tested each function (that is confirmed
> vissually that both alpha and luma channels look ok for all 3
> functions)
>
>
Yes i tested each func with various input
also checked the result of the scale filter test
Pushed, Thanks.
Martin
__
Pushed.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> See coverity bug report, avctx->profile is not checked for valid values i
> think.
>
> Hello,
Doesn't find where avctx->profile can have an invalid value
seems to be checked in prores_encode_init
if FF_PROFILE_UNKNOWN
use pix fmt YUV422P10 or YUV444P10 to select the profile
(can pix_fmt be a
Hello,
Patch in attach add a bsf filter to set color property of a prores frame
Can be used, to set all frames of prores file to the same value
(avoid color shift on some frame depending of the software used to decode
the file)
or fix the value, for file created with incorrect metadata.
Martin
Hello,
Patch in attach add to show_info filter
print of the color property (range, primaries, trc, space)
Martin
0003-avfilter-show_info-add-print-of-color-information.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
Hello,
Missing doc update, and changelog entry.
001 : Merge setfield and setrange to a new setparams filter
like both filter have near identical code, and merging it, can let a user
to set all property at the same time.
in setparams, the field mode option have been rename to field_mode
Current b
Hello,
>
> > Blocking this patch, no code should remove old filters.
> >
>
I suppose you talk about the proposal of removing setfield, setrange later ?
> > If you want more parameters to be changed write new filters instead.
> >
>
This is what the current patch do.
>
> Feel free to merge code
Le sam. 20 oct. 2018 à 18:18, Paul B Mahol a écrit :
> On 10/20/18, Martin Vignali wrote:
> > Hello,
> >
> >>
> >> > Blocking this patch, no code should remove old filters.
> >> >
> >>
> > I suppose you talk about the proposal of
Hello,
001 : add unscaled grayf32 bswap func
similar to packed_16bpc_bswap processing
002 : rename packed_16bpc_bswap func to bswap_16bpc
this func is used for planar and packed bswap16
Martin
0002-swscale-swscale_unscaled-rename-packed_16bpc_bswap.patch
Description: Binary data
0001-swscale
>
> >if avtc->profile < 0 or > 4, return an error.
>
> Should 5 not become ProRes XQ (ap4x) as in prores_ks?
>
> Yes, plan to add it later. Need some test before.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman
Hello,
Patch in attach add support for YUVA444P10 input and alpha 16b encoding
001 : Add frame header description for alpha value (use value close to the
official encoder)
002 : indent and add comment, about the header value (based on multimedia
wiki doc)
003 : Add support for Prores 444 with a
New patch in attach
001 : change unscaled test condition for float (only use isFloat(src) ||
isFloat(dst)).
002 : add grayf32 le <-> be
i disable float (in/out) in the latest part of the patch, because it's
currently doesn't work for floating data
(and replace bswap_32 for grayf32 swap, in unscale
>
> please align these vertically, it makes them easier to read
>
>
New patch in attach.
Also add changelog entry, and libavfilter version change
Martin
0005-avfilter-setparam-add-options-to-set-color-primaries.patch
Description: Binary data
0004-avfilter-setparams-merge-setfield-and-setrange-
> > New patch in attach.
> > Also add changelog entry, and libavfilter version change
>
> LGTM
>
>
Pushed, thanks.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> You forgot to update setparams filter long description.
>
>
Patch in attach fix description, and two mistakes (not setting color
primaries, trc, space to auto for setfield and setrange, and colorspace
option for setparams
Sorry.
Martin
0002-avfilter-setparams-update-filter-description.patch
Le dim. 21 oct. 2018 à 18:59, Reto Kromer a écrit :
> Martin Vignali wrote:
>
> >prores_ks take care about alpha data size, for yuv encoding (in
> >other word reduce quality of yuv data if there is alpha), but
> >it's seems that this is not the case of the offi
> > Patch in attach fix description, and two mistakes (not setting color
> > primaries, trc, space to auto for setfield and setrange, and colorspace
> > option for setparams
> > Sorry.
> >
> > Martin
> >
>
> LGTM
>
Pushed, thanks
Martin
___
ffmpeg-devel
>
> fails on mips qemu
>
>
Thanks for testing.
New patch in attach,
001 : unchanged
002 : limit frame entries for ffprobe part, in order to not have pix_fmt in
the output.
Martin
0001-avcodec-add-prores_metadata-bsf-for-set-the-color.patch
Description: Binary data
0002-fate-prores_metadata_bs
>
> rename and simplify are ok
>
> the other needs a more verbose commit message
>
>
New patch in attach
Changed the second patch.
I edited planarCopyWrapper to add bswap32, instead of disable this func for
float. Will probably help to support more float pix fmt in the future
Martin
0003-swscale
>
> Could you look into adding ProRes bitstream parsing support to the CBS
> framework? It would be ideal for a filter like this.
>
> Hello,
The only metadata, which seems to have an interest to be edited (color
property), is at the start of every prores frame, no need to go deeper to
edit these t
>
> lgtm
>
Pushed, thanks
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> patches LGTM
>
> thx
>
> Pushed, thanks
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
New patch in attach
001 : remove dead comment, add av_packet_make_writable
002 : change the test to use md5 and didn't use ffprobe. Also change color
property
I will try to add prores to cbs later. Any tips for this ?
Martin
0002-fate-prores_metadata_bsf-add-test-for-setting-color.patch
Descri
Thanks for the comments
New patch in attach
- Change the options, to only authorized few value in prores frame (based
on rdd36).
- Change option name to match setparams filter
- Include intreadwrite instead of bytestream
- Do not modify the property if set to -1
- Move av_packet_make_writable at
Rebase after prores profile patch
fix stride used by alpha reorganization
and pushed
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Le dim. 28 oct. 2018 à 12:59, Martin Vignali a
écrit :
> Thanks for the comments
>
> New patch in attach
>
> - Change the options, to only authorized few value in prores frame (based
> on rdd36).
> - Change option name to match setparams filter
> - Include intreadwri
Hello,
Patch in attach should fix the memleak report by coverity
CID 1439934
CID 1439935
Replace return ret, by goto fail.
Martin
0004-avfilter-af_headphone-fix-mem-leak.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg
Hello,
Patch in attach add new pix fmt YUVA444P12 and YUVA422P12
In order to add 12b decoding for prores
Martin
0001-avutil-add-YUVA444P12-and-YUVA422P12.patch
Description: Binary data
0002-swscale-add-support-for-YUVA444p12-and-YUVA422P12.patch
Description: Binary data
Hello,
Patch in attach fix make fate-source error in vf_blend
Untested
Martin
0003-vf_blend-use-av_clip_uintp2-instead-of-av_clip.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo
Hello,
Patch in attach fix make fate-source error for cuda_check files
Martin
0004-fate-source-add-cuda_check-file-to.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello,
Patchs in attach add 12b decoding for prores
Theses patch are based on patch by Kieran Kunhya
https://pastebin.com/mYNJkdMH
After theses patch by default Prores 422 are decode in 10b and 444 in 12b
I add a user option, to force 10b or 12b decoding
Need to be apply after patch "avutil - sw
>
> Are all 444(4?) Encodings 12-bit? Also is there a way to verify if your
> file should be decoded as 10 or 12-bit? Or does this code automate this
> detection?
>
>
The auto mode of the patch, only use codec_tag to switch between 10b and
12b, no other value.
I don't think, prores have metadata fo
Le dim. 18 nov. 2018 à 01:57, Carl Eugen Hoyos a
écrit :
> 2018-11-18 0:28 GMT+01:00, Martin Vignali :
>
> > 012 : Add 12b support for 444 by default,
>
> Is it slower?
> I believe that once 12 bit decoding is not slower, it should
> be the default for 422.
>
Yes 12b
> > +AV_PIX_FMT_YUVA422P12BE, ///< planar YUV 4:2:2,24bpp, (1 Cr & Cb
> sample per 2x1 Y samples), 12b alpha, big-endian
> > +AV_PIX_FMT_YUVA422P12LE, ///< planar YUV 4:2:2,24bpp, (1 Cr & Cb
> sample per 2x1 Y samples), 12b alpha, little-endian
> > +AV_PIX_FMT_YUVA444P12BE, ///< planar
Hello,
Patch in attach fix prores-metadata test
add bitexact mode, to avoid to write encoder in target mov
Martin
0001-fate-prores-metadata-make-output-bit-exact.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
Hello,
New patchs in attach (002 to 010 unchanged)
011 : Remove user option for setting decoding precision
Only enable 12b decoding if the codec tag is Prores or XQ
let 10b decoding for 422 codecs tag.
Martin
0006-avcodec-proresdec-put-unpack-alpha-func-in-prores-ct.patch
Description:
Hello,
Patch in attach add some improvments to prores aw encoder
012 : Add vendor option (code come from prores_ks encoder)
013 : Only write color properties, if defined in rdd36 (other values are
"converted" to unspecified)
014 : Add XQ encoding support
Martin
0012-avcodec-prores_aw-add-
> > +/* align height to 16, to avoid segfault */
> > +tframe.f->height = FFALIGN(avctx->height, 16);
> > +tframe.f->width = FFALIGN(avctx->width, 16);
> > +tframe.f->crop_bottom = tframe.f->height - avctx->height;
> > +
> > if ((ret = ff_thread_get_buffer(avctx, &tframe, 0)) <
> > +
> > +switch (pict->colorspace) {
> > +case AVCOL_SPC_BT709:
> > +case AVCOL_SPC_UNSPECIFIED:
> > +case AVCOL_SPC_SMPTE170M:
> > +case AVCOL_SPC_BT2020_NCL:
> > +colorspace = pict->colorspace;
> > +break;
> > +default:
> > +av_log(avctx, AV_LOG_D
>
> So I applied these patches and it appears that ffmpeg will encode XQ as
> 10-bit, but it will decode as 12-bit. Is this intentional? I worry that I
> might have applied the patches incorrectly. And is it possible to add
> 12-bit encoding?
>
>
Hello,
Seems like you applied patch "add 12b decod
> > (alpha 12b encoding is probably
> > easy to add)
>
> Are you sure alpha is 12 bit? As long as I remember, it is 16 bit.
>
>
Alpha is stored in 16b, but like the input pix fmt is 10b or (later) 12b
alpha, the alpha val is shift during encoding to obtain a 16b val.
The right way will be to add yu
Hello,
New patchs in attach
001 : add YUVA444P12 and YUVA422P12 to avcodec_dimensions2 (in order to
have height padding)
002 to 009 : unchanged
010 : mention ticket 7163 in commit msg (unchanged otherwise)
Martin
0002-avcodec-proresdsp-remove-unused-value.patch
Description: Binary data
0001-
Pushed, thanks.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello,
New patch in attach
001 : add ff_int_is_in_list func to libavcodec/utils.c
002 : add vendor option (unchanged)
003 : only write color properties if supported (use new ff_int_is_in_list
func)
004 : Add 444Xq (unchanged)
Martin
0003-avcodec-prores_aw-only-set-color-prim-trc-space.patch
De
Hello,
No strong opinion about the func name, so change to
ff_int_from_list_or_default
Change int array to const int (in func and in prores_aw)
Martin
0003-avcodec-prores_aw-only-set-color-prim-trc-space.patch
Description: Binary data
0001-avcodec-utils-add-ff_int_from_list_or_default-func.pa
> > >>
> > >> It appears to me that NewTek abused our willingness to add an optional
> > >> external nonfree library, I don't see many better options. See Ticket
> > >> #7589 and a blog post by a NewTek engineer confirming the issue.
> > >>
> > >> Patch untested.
> > >>
> > >> Please comment, Carl
There is a mix of several discussion in this thread, which need to be
discuss separately.
1 - Licence violation on a build.
2 - Opinion on Newtek behaviour
3 - Inclusion of non open source part
4 - Removal of libndi device
1 :
Doesn't really understand, how this licence violation can be fix in
mo
>
> LGTM
>
> thanks
>
> [...]
> --
> Michael
>
Pushed, thanks.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Le mar. 4 déc. 2018 à 16:12, Jean-Baptiste Kempf a écrit :
> Helllo,
>
> On Tue, 4 Dec 2018, at 15:00, Martin Vignali wrote:
> > 1 :
> > Removing features used by people which doesn't respect the licence,
> seems a
> > very bad thing.
>
> I disagree
Hello,
Patchs in attach add interlace encoding support to prores aw encoding
Use +ildct flag to switch between progressive and interlace encoding
Use AVFrame flag to switch between tff and bff frame organization.
If AVFrame->interlaced value is not set to 1, but +ildct is set (interlace
encoding
Hello,
>
> > Use +ildct flag to switch between progressive and interlace encoding
> >
> > Use AVFrame flag to switch between tff and bff frame organization.
> >
>
> Is this what you mean by altering the -setparams filter?
>
> In order to choose between top field first and bottom field first, i use
Hello,
Patch in attach, improve decoding speed of qtrle (also known as Mov
Animation)
Can't test on big endian. Test on big endian is welcome.
fate test cmd : make fate-qtrle SAMPLES=fate-suite/
32bpp :
Mainly raw : 33fps -> 40 fps
Mainly rle : 128fps -> 153 fps
24bpp:
Mainly raw : 20fps->39fps
Hello,
Patch in attach improve prores_aw encoding speed
A basic encoding test (prores to prores)
test file 1 : 137fps -> 140fps
test file 2 : 49fps-> 54 fps
001 : Pre calc codebook switchbits, rice order, exp order and first_exp,
avoid to calc it in encode_codeword func.
002 : small code reorgan
Hello,
Patch in attach add fate test for interlace and 444 encoding
All prores_aw encoding test can be test with :
make fate-vsynth3-prores;make fate-vsynth2-prores;make
fate-vsynth1-prores;make fate-vsynth_lena-prores SAMPLES=fate-suite/;make
fate-vsynth3-prores_int;make fate-vsynth2-prores_int
Pushed.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello,
Thanks for testing.
Can you send me the result file vsynth3-prores_int.mov, so i can try to
find why the result are not the same.
Only the two vsynth3 interlaced test fail ?
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ff
Hello,
thanks for testing and comments.
New patch in attach
001 : unchanged
002 : use ARGB for little and big endian, and change the commit msg
003 and 004 : mention test platform in commit msg
I can't compile anymore for x86_32, so can't test speed in X86_32.
Martin
0004-avcodec-qtrle-improve
> I know we forgot before but this definitely needs a micro version bump.
>
>
New patchs in attach
001, 003, 004 : unchanged
002 : add avcodec micro version bump
Martin
0001-fate-qtrle-change-32b-test-to-output-bgra-instead-of.patch
Description: Binary data
0003-avcodec-qtrle-32bpp-dec-copy-tw
Hello,
Thanks for the files
The problem appear for "unsafe" resolution (only vsynth3 have this).
Patchs in attach are supposed to fix this
001 : fix sub_image_with_fill for interlaced encoding
002 : new fate test, with update result for vsynth3 interlace test
Can be test with :
make fate-vsynth
Hello,
Patch in attach, change codeword bits writing
by replacing PutBitContext, and use instead uint64_t bit_buf
Also remove byte buffer length check
encode_codeword func have two version now
- one for dc coeff and run coeff (same as previous encode_codeword func)
- one for level coeff who also
>
> Shouldn’t there be a 64Bit PutBitContext instead so other encoders can
> also profit?
>
> Carl Eugen
>
I only use here a small part of putbitcontext, and in an "unsafe" mode (the
buffer of the prores aw encoder is big enough to not check it, and write 64
bits during the flush even if less can
> works here
>
>
Pushed, thanks.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello,
I don't have knowledge to mentor a project,
But two idea :
- Swscale improvement :
YAP8, YAP16 : useful to switch some decoder/encoder to planar
Float/half float pixel format support
- Open Exr Decoder :
Add DWA decoder
support 4:2:0 mode
Martin
_
Hello,
Few comments.
You can use VBROADCASTI128 macro instead of changing the size of the
constants
(VBROADCASTI128 load 128 bit when using XMM, and broadcast the 128bit to
the two lane when using YMM)
The %if ARCH_X86_64 part, seems strange.
seems to only be useful for AVX2, not for sse/avx.
N
Pushed. Thanks
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hello,
Test on big endian is welcome.
If it's works, it will avoid to add #if HAVE_BIG_ENDIAN in lot of place, to
separate the old code from the new.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg
Hello,
do i understand correctly that there is no check that prevents out of array
> writing ?
> not even an assert
> If thats the case, then i think this is unwise.
>
>
Thanks for testing.
For the buffer check, i can add a test (assert or error), before slice
plane encoding, in order to check if
> Not sure if this justifies not adding the new code to PutBitContext: it
> doesn't
> have to work for all situations, only for the encoder that initially uses
> it.
>
>
Like the current patch, works on big and little endian, i will try to
rewrite this patch using a start of a new PutbitContext64.
>
> These tests fail on all FATE boxes. http://fate.ffmpeg.org/
>
> Can you check that and fix it?
>
>
Seems to be related to memory poisoning (pass when disable) :
http://fate.ffmpeg.org/report.cgi?time=20190307033138&slot=x86_64-archlinux-gcc-valgrind-no-undef
Will take a look.
Martin
_
>
> I'm new to the list, so I would like to first thank you for the great work
> of ffmpeg.
>
> I would like to report a bug on bitstream version on encoded ProRes output.
> Currently, ffmpeg always encode with bitstream version 0 even for
> (with alpha channel). According to RDD36-2015:
>
> >
>> Can you check that and fix it?
>>
>>
>
Patch in attach fix for me vsynth3 interlace prores test :
make fate-vsynth3-prores_int;make fate-vsynth3-prores_444_int
Pass fate test for me (os x X86_64) with and without
--enable-memory-poisoning
Martin
0001-avcodec-proresenc_aw-fix-interlace-encodi
Pushed, thanks for testing.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
They have not responded to any communications:
> https://trac.ffmpeg.org/ticket/7589
>
>
I still do not understand the link between the ticket and the removal of
lib ndi.
Is it plan to remove all features used by people who doesn't respect the
licence ?
If this patch concerns the removal of a libr
Le dim. 10 mars 2019 à 17:03, Nicolas George a écrit :
> Maksym Veremeyenko (12019-03-10):
> > code you going to remove was not made by you nor NewTek company.
> >
> > if you have a problem with NewTek company - do a step to solve it - dont
> > ruin a code.
>
> Nobody is ruining any code. Just re
Le dim. 10 mars 2019 à 18:55, Nicolas George a écrit :
> Martin Vignali (12019-03-10):
> > Le dim. 10 mars 2019 à 17:03, Nicolas George a écrit :
> > > It's just ruining his effort to integrate this feature inside the
> project.
>
> Please do not attribute
1 - 100 of 578 matches
Mail list logo
