[Ffmpeg-devel-irc] ffmpeg-devel.log.20150627

[burek]

[00:08:39 CEST] <cone-666> ffmpeg 03Luca Barbato 07master:92fdc80cab2a: nvenc: Fix NV12 input
[00:08:40 CEST] <cone-666> ffmpeg 03Michael Niedermayer 07master:1221b7df6817: Merge commit '92fdc80cab2acad9f171ba38a08aa89b392bdadd'
[00:38:16 CEST] <cehoyos> jamrial: icc defines _GCC_ depending on the gcc version on your system...
[00:38:44 CEST] <cehoyos> I would not expect that all icc versions support the builtin asm command: Is there a problem doing a configure check?
[00:39:11 CEST] <jamrial> i'm not adding any asm
[00:40:57 CEST] <jamrial> i'm adding the usage of a gcc builtin and putting it inside a __GNUC__ >= 5 guard
[00:43:51 CEST] <cehoyos> This guard triffers for icc.
[00:43:55 CEST] <jamrial> there are other builtins used in different headers, like this same one or attributes.h, that only check for __GNUC__
[00:43:59 CEST] <jamrial> i don't see how this one is any different
[00:44:53 CEST] <jamrial> if icc defines __GNUC__, shouldn't it support everything said define entails?
[00:44:59 CEST] <cehoyos> The difference - afaict - is that av_builtin_constant_p exists forever, no?
[00:45:22 CEST] <cehoyos> It doesn't, that's why some of the _GCC_ chacks also check for ICC
[00:46:13 CEST] <jamrial> av_builtin_constant_p if __GNUC__ is defined translates into __builtin_constant_p
[00:46:23 CEST] <jamrial> meaning icc uses it
[00:47:22 CEST] <cehoyos> What I meant was: The ifdef looks as if this builtin was already supported in gcc 2.95.3. And icc had ten years to also support it.
[00:47:46 CEST] <cehoyos> If your builtin is only supported in newest gcc, I find it very unlikely that it also works in older icc.
[00:47:56 CEST] <cehoyos> Why is a confiigure check a problem?
[00:48:15 CEST] <jamrial> the builtin has supported for several versions now
[00:48:22 CEST] <jamrial> and how gcc 2.95.3?
[00:48:38 CEST] <cehoyos> __builtin_constant_p does not check for the gcc version, only for gcc.
[00:48:46 CEST] <cehoyos> Meaning it is expected to work with gcc 2.95.3
[00:48:57 CEST] <cehoyos> (We had not supported anything older for a very, very long time)
[00:50:24 CEST] <iive> i don't think that there are any projects that do.
[00:51:07 CEST] <jamrial> sorry, but i fail to see how this is any different to other uses of AV_GCC_VERSION_AT_LEAST in the tree
[00:52:03 CEST] <cehoyos> Which uses do you mean?
[00:52:21 CEST] <cehoyos> __builtin_constant_p does not use AV_GCC_VERSION_AT_LEAST
[00:52:53 CEST] <jamrial> the ones you can find in many headers
[00:53:06 CEST] <jamrial> for bultins or otherwise
[00:53:18 CEST] <kierank> michaelni: are both fields guaranteed to be finished in decode_postinit in h264?
[00:53:42 CEST] <cehoyos> __builtin_ctz is also very old...
[00:54:03 CEST] <jamrial> and this one was not added yesterday
[00:55:03 CEST] <iive> jamrial: what is the minimum gcc that supports that builtin?
[00:55:33 CEST] <iive> also... can you still compiled ffmpeg on gcc 2.95.3?
[00:55:36 CEST] <cehoyos> I mean that it exists in gcc for a very long time giving Intel a very long time to also support it. This does not seem to be the case for your new builtin, or do I misunderstand?
[00:55:46 CEST] <cehoyos> iive: No, they broke it.
[00:56:08 CEST] <iive> they? the evil ones?
[00:56:11 CEST] <jamrial> not sure, but i know that 4.8 supports it
[00:56:18 CEST] <cehoyos> No, the thieves and liars.
[00:56:29 CEST] <iive> yes, the evil ones :)
[00:56:59 CEST] <cehoyos> (It is possible that Michael fixed it, he at least tried at one point.)
[00:58:02 CEST] <jamrial> again, how's any other AV_GCC_VERSION_AT_LEAST usage different than this one?
[00:58:18 CEST] <cehoyos> Which other usage?
[00:58:21 CEST] <jamrial> i see checks for gcc 4.6 with it that don't bother checking for icc
[00:58:33 CEST] <jamrial> tons, cehoyos. use grep
[00:58:34 CEST] <cehoyos> Don't you write in your patch that only 5.1 supports it? I don't understand?
[00:58:43 CEST] <cehoyos> Please tell me (only) one.
[00:58:55 CEST] <jamrial> AV_GCC_VERSION_AT_LEAST(4,6) in attributes.h
[00:59:03 CEST] <cehoyos> Which one?
[01:00:13 CEST] <cehoyos> I mean: Which define in attributes.h (there are many iirc)?
[01:00:45 CEST] <jamrial> i just said, the one that checks for 4.6
[01:00:53 CEST] <cehoyos> Which define is it?
[01:01:17 CEST] <iive> hum, av_const needs 2.6.x
[01:01:30 CEST] <cehoyos> This triggers a warning in icc because not all versions support it.
[01:01:39 CEST] <jamrial> AV_NOWARN_DEPRECATED, how hard is it to check the file?
[01:01:40 CEST] <cehoyos> We silence the warning in configure.
[01:01:53 CEST] <cehoyos> This also triggers a warning on compilation.
[01:02:09 CEST] <jamrial> and i wrote the patch to check for 5.1 not because older versions don't support it, but because the builtin was broken in older versions
[01:02:10 CEST] <cehoyos> When compiling with icc
[01:03:02 CEST] <jamrial> i'm completely lost in this discussion
[01:03:03 CEST] <cehoyos> Doesn't this support my point?
[01:03:36 CEST] <jamrial> i can't say because i don't understand what you're trying to say
[01:03:49 CEST] <iive> jamrial: so, constant_p is broken in all gcc before 5.1 ?
[01:04:28 CEST] <jamrial> when the second argument is a constant, yeah
[01:04:56 CEST] <jamrial> iive: wait no
[01:05:06 CEST] <cehoyos> jamrial: icc defines _GCC_ depending on your system compiler, not depending on the actual supported features.
[01:05:24 CEST] <cehoyos> If a gcc feature is new, it is unlikely (imo) that icc also supports it.
[01:05:29 CEST] <jamrial> constant_p is not broken
[01:05:37 CEST] <jamrial> the bzhi bultin is
[01:05:40 CEST] <cehoyos> If such a feature is just an attribute, it only triggers a warning and we don't care.
[01:05:48 CEST] <jamrial> it's not new
[01:05:52 CEST] <cehoyos> If the feature is a command, it may fail compilation.
[01:06:02 CEST] <jamrial> it's been available for several versions
[01:07:15 CEST] <cehoyos> The problem is that I only have some icc versions here to test (each takes 1G), how can I test if the intrinsic is defined?
[01:07:46 CEST] <iive> cehoyos: why icc cares what system gcc is installed? does it use it as front/back end?
[01:09:48 CEST] <cehoyos> iive: Sorry, I cannot answer, I am just remembering many issues I dealt with in the past.
[01:09:54 CEST] <cehoyos> No, it does not use it as backend.
[01:10:56 CEST] <iive> heh...
[01:12:19 CEST] <jamrial> the bzhi builtin i'm adding is available since 4.7
[01:12:40 CEST] <cehoyos> jamrial: Do I understand correctly that the intrinsic is only used if the compiler defines __BMI2__?
[01:12:43 CEST] <iive> jamrial: if you know that the builtin is broken, put a check and add comment that it is available, but broken of prior compilers
[01:12:50 CEST] <jamrial> iive: i did as much
[01:12:54 CEST] <cehoyos> Is __BMI2__ docuemented somewhere?
[01:13:18 CEST] <iive> what is the issue at hand then?
[01:13:32 CEST] <jamrial> iive: i really don't know
[01:13:40 CEST] <cehoyos> That icc cannot be detected with __GCC__ < xyz
[01:13:41 CEST] <jamrial> cehoyos: gcc's documentation, problably
[01:14:22 CEST] <michaelni> kierank, if i understand the question correctly, yes unless the stream is damaged/constructed like if it has only top fields
[01:14:39 CEST] <iive> cehoyos: icc uses same builtin syntax and defines gcc (depending on the system gcc).
[01:15:22 CEST] <cehoyos> https://software.intel.com/sites/landingpage/IntrinsicsGuide/
[01:15:32 CEST] <kierank> michaelni: basically closed captions are per field and so I need to decide where is the correct place to reset the caption buffer
[01:15:33 CEST] <jamrial> this is not an intrinsic, cehoyos
[01:15:34 CEST] <cehoyos> I do see BMI2 there
[01:15:41 CEST] <jamrial> also, just sent a new version that makes sure icc doesn't use this
[01:15:42 CEST] <cehoyos> What is it then?
[01:15:54 CEST] <jamrial> a gcc builtin
[01:15:59 CEST] <iive> so... it is possible for icc to define gcc version that is supposed to support builtin, that is not actually supported bu icc?
[01:16:31 CEST] <cehoyos> iive: That was the case in the past: All the attributes in attributes.h triggered warnings on icc because icc defines __GCC__
[01:17:37 CEST] <iive> how so? if icc doesn't support them, they are most likely fatal errors!?
[01:18:25 CEST] <iive> or does it just ignore them?
[01:19:28 CEST] <cehoyos> So if icc (either now or in the future) supports the builtin, we don't use it?
[01:19:44 CEST] <iive> maybe there should be AV_ICC_VERSION_AT_LEAST :)
[01:20:04 CEST] <jamrial> if anyone cares about icc by then, they are free to send a patch
[01:21:29 CEST] <iive> could the icc defining _gcc_be related to system headers mismatch?
[01:22:28 CEST] <cehoyos> jamrial: I try to test atm, but with gcc 4.9.1, I get "implicit declaration of function __builtin_ia32_bzhi_si"
[01:22:44 CEST] <cehoyos> when compiling adpcm.c
[01:23:10 CEST] <iive> anyway, i'm off
[01:23:13 CEST] <iive> have fun.
[01:23:19 CEST] <iive> and keep it simple :)
[01:28:39 CEST] <jamrial> cehoyos: with my patch applied as is?
[01:29:44 CEST] <jamrial> gcc 4.7 and newer all declare the builtin when you run gcc with -mbmi2 (or related -march values). otherwise you get that error
[01:29:56 CEST] <cehoyos> No, removing all checks to test if the builtin is used.
[01:30:00 CEST] <jamrial> that's why i guarded it with the __BMI2__ check
[01:30:09 CEST] <jamrial> well of course it will fail in that case
[01:30:12 CEST] <cehoyos> I didn't know about -mbmi2
[01:33:11 CEST] <cehoyos> icc -march=core-avx2 does not define __BMI2__ so I have no objections about the original patch.
[01:33:15 CEST] <jamrial> i still find it pretty absurd that icc arbitrarily defines __GNUC__ while not even providing all doing so entails
[01:33:43 CEST] <cehoyos> (And icc -mbmi2 does not work, march=core-avx2 is the suggested alternative in the icc manual)
[01:34:06 CEST] <cehoyos> Me too, there are many patches about this issue in the mailing list archive.
[01:35:01 CEST] <cehoyos> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/75876/match=icc
[01:36:15 CEST] <michaelni> kierank, iam not sure how exactly CC is stored (even less so in relation to MBAFF if its per field) but if its in SEIs then ff_h264_reset_sei() may be an option. It wont be called per field for MBAFF nor if the muxer packs2 fields per packet currently
[01:36:39 CEST] <michaelni> though
[01:36:49 CEST] <kierank> michaelni: there are CCs per picture
[01:37:15 CEST] <kierank> so 1 set in mbaff
[01:37:22 CEST] <kierank> and 1 per field in field codec pictures
[01:37:29 CEST] <kierank> the latter need to be merged somewhere
[01:44:43 CEST] <michaelni> decode_postinit() might work for the merge but not at the very top of the function, output_frame() could be used too (this one is at the output side reordering wise) there are many other possible places, dunno where is best
[03:58:28 CEST] <cone-718> ffmpeg 03George Boyle 07master:3f18cb97e5a7: fate/api-tests: Add directory and Makefile for API tests
[03:58:28 CEST] <cone-718> ffmpeg 03George Boyle 07master:7728d231a6cb: fate/api-tests: Move api-flac-test to API tests directory.
[04:08:09 CEST] <cone-718> ffmpeg 03Philip Langdale 07master:b69bea3ab8f8: avcodec: Add flag for experimental HWAccels and use it for VDPAU/HEVC
[11:30:52 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:aab4dbe534e2: avcodec/utils: Replace ENOTSUP by AVERROR_PATCHWELCOME
[11:33:40 CEST] <wm4> is there even anything that explicitly checks for AVERROR_PATCHWELCOME error codes
[11:56:05 CEST] <kierank> Hmmm I need field coded h264 samples
[11:56:11 CEST] <kierank> With captions
[12:06:09 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:8672c0a6436c: avcodec/jpeg2000dec: Limit poc end fields to whats available in jpeg2000_decode_packets()
[12:12:47 CEST] <Compnn> sounds pretty evil kierank
[12:27:28 CEST] <kierank> Yes very evil
[12:48:45 CEST] <cone-389> ffmpeg 03Derek Buitenhuis 07master:f4be604f1c4d: configure: Check for x265_api_get
[12:52:14 CEST] <cone-389> ffmpeg 03Derek Buitenhuis 07release/2.7:6ff54eb87bd0: configure: Check for x265_api_get
[15:37:20 CEST] <cone-389> ffmpeg 03Rodger Combs 07master:68f00fb40bb3: lavf/brstm: if the file lies about the last block's size, correct it
[15:37:21 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:5cccbc3b74b2: avcodec/jpeg2000dec: Check for mismatching per expected termination
[17:57:38 CEST] <cone-389> ffmpeg 03James Almer 07master:1e51e517be0a: avutil/x86/intmath: use bzhi gcc builtin in av_mod_uintp2()
[18:21:09 CEST] <cone-389> ffmpeg 03Derek Buitenhuis 07master:b56b12cd12f3: configure: Check for x265_api_get
[18:21:10 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:1edc87a665bf: Merge commit 'b56b12cd12f32bf11efff05632600a7619584b98'
[18:28:51 CEST] <cone-389> ffmpeg 03Niklesh 07master:cf9051deac49: movtextenc.c: Support for Bold, Italic and Underlined Styles
[18:54:04 CEST] <cone-389> ffmpeg 03Anton Khirnov 07master:e49e0f58e273: h264: make sure the slices do not overlap during slice threading
[18:54:05 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:f620315fa5b1: Merge commit 'e49e0f58e273237f83b4486f3536931ed1943d18'
[19:23:22 CEST] <cone-389> ffmpeg 03Andreas Cadhalpun 07master:6b9fdf7f4f07: nutdec: check maxpos in read_sm_data before returning success
[19:49:02 CEST] <cone-389> ffmpeg 03James Almer 07master:93e7b7fb3464: avutil/x86/intmath: add missing check for inline assembly
[20:15:30 CEST] <LigH> Hi.
[20:16:23 CEST] <LigH> Does FourCC tagging for AVI (e.g. "-vtag XVID") only work during conversions, but not during simple re-multiplexing (with "-vcodec copy")?
[20:25:41 CEST] <BBB> should be possible at least
[20:25:53 CEST] <BBB> what xact commandline? (this might belong on #ffmpeg, not #ffmpeg-devel)
[20:26:33 CEST] <LigH> No affirmative answers yet in #ffmpeg
[20:26:36 CEST] <LigH> "E:\Programme\MeGUI\tools\ffmpeg\ffmpeg.exe" -y -i "*.m4v" -vcodec copy -vtag XVID -r 25 "*.avi"
[20:26:47 CEST] <LigH> As used in MeGUI
[20:28:22 CEST] <BBB> Id file a bug on trac, it seems to me it should work
[20:29:52 CEST] <cone-389> ffmpeg 03Anton Khirnov 07master:b114f6d48a06: avconv: factor out flushing the filters
[20:29:54 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:a50b00822784: Merge commit 'b114f6d48a06a4dad6882bc83e07463905f004c4'
[20:30:22 CEST] <LigH> OK, will recommend that to Zathor and Kurtnoise
[20:30:47 CEST] <LigH> \o
[20:41:31 CEST] <cone-389> ffmpeg 03Anton Khirnov 07master:9a5e4fbec870: avconv: do not stop processing the input packet on decoding error
[20:41:32 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:a5f409bcc091: Merge commit '9a5e4fbec870c7d466b7a0aec92c70778efc96b5'
[20:54:00 CEST] <LigH> Hello again; reported https://trac.ffmpeg.org/ticket/4682
[20:54:11 CEST] <LigH> Aha.
[20:54:55 CEST] <LigH> I'll try to build a fresh ffmpeg now and test again.
[20:55:06 CEST] <LigH> But the one in MeGUI was not too old...
[21:11:36 CEST] <cone-389> ffmpeg 03Anton Khirnov 07master:6d4d3fee63c4: h264: make sure the current picture is not made a long ref multiple times
[21:11:37 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:77412f0ecd23: Merge commit '6d4d3fee63c46d921c4870feab79269af94e84e1'
[22:07:37 CEST] <wm4> kierank: so how do you use the closed captions crap? you somehow shuffle the side data coming out of the decoder to somewhere else?
[22:07:48 CEST] <kierank> I turn it into analogue pulses (lol)
[22:08:01 CEST] <kierank> and put them at the top of the frame
[22:08:17 CEST] <wm4> analogue? huh.
[22:08:20 CEST] <kierank> yup
[22:08:43 CEST] <kierank> http://nootropicdesign.com/projectlab/wp-content/uploads/2011/03/line21.jpg
[22:10:05 CEST] <wm4> as part of the broadcast signal?
[22:10:24 CEST] <kierank> yes
[22:10:26 CEST] <kierank> damn that patch is bugged
[22:16:03 CEST] <cone-389> ffmpeg 03Anton Khirnov 07master:5ec0bdf2c524: h264: do not update the context fields copied between threads after finish_setup()
[22:16:04 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:bd5c6a519e9b: Merge commit '5ec0bdf2c524224f30ba4786f47324970aed4aaa'
[22:52:55 CEST] <Compnn> lol line21 :D
[22:53:10 CEST] <Compnn> aka those dancing white lines on the top of the vhs signal
[22:58:15 CEST] <kierank> is there a preferred way to do overflow checks in ffmpeg?
[23:05:20 CEST] <wm4> as long as it's correct, who cares
[23:15:22 CEST] <Compnn> kierank : should we make a list of files that are "leading by example" ?
[23:15:30 CEST] <Compnn> of programming practices to follow ?
[23:17:04 CEST] <kierank> lol
[23:48:25 CEST] <wm4> kierank: I guess in general we just write "if(a+b>INT_MAX)", and then either add casts to a wider type (int64_t), or rearrange the expression in a way the overflow check itself can't overflow ("if(b>INT_MAX-a)")
[23:53:20 CEST] <cone-389> ffmpeg 03Michael Niedermayer 07master:9ea256814dc2: avcodec/h264_slice: assert that the first slice implies unfinished setup
[00:00:00 CEST] --- Sun Jun 28 2015