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

[burek]

[00:11:16 CEST] <cone-883> ffmpeg 03Aaron Colwell 07master:b4189590a591: movenc: Add support for writing st3d and sv3d boxes.
[00:11:17 CEST] <cone-883> ffmpeg 03James Almer 07master:a715e5a276c0: avformat/movenc: restrict st3d and sv3d mov atoms to MODE_MP4
[00:11:18 CEST] <cone-883> ffmpeg 03James Almer 07master:86dee47e397f: avformat/movenc: allow st3d and sv3d mov atoms to be written in strict unofficial mode
[00:14:05 CEST] <cone-883> ffmpeg 03Michael Niedermayer 07master:bcd7153df382: ffprobe: Support adding av_log output to frames
[00:14:06 CEST] <cone-883> ffmpeg 03Dave Rice 07master:52d9442a557e: ffprobe.xsd: add frame log data
[00:14:07 CEST] <cone-883> ffmpeg 03Dave Rice 07master:3e0474ff3970: doc/ffprobe: add -show_log option
[00:16:36 CEST] <wm4> wow did this av_log patch really make it...
[00:16:53 CEST] <wm4> so wonderfully hacky and broken
[00:19:34 CEST] <jamrial> well, it's almost a year old and nobody said anything in almost four months aside from saste approving it...
[00:21:38 CEST] <iive> well, there is better solution, but it would make merges even bigger nightmare
[00:23:33 CEST] <jamrial> contained within ffprobe? because afaik avprobe merges are more often than not noops, so it wouldn't be an issue
[00:24:09 CEST] <ubitux> iive: ffprobe completely diverges from avprobe
[00:24:24 CEST] <ubitux> the only common point is which fields we decide to print
[00:24:25 CEST] <iive> i'm talking about error tracking in general
[00:25:13 CEST] <iive> if it's another av_log, then sorry for intrusion.
[00:26:07 CEST] <durandal_1707> so you have no idea about this patch?
[00:36:47 CEST] <nevcairiel> a better overall logging framework might be neat, but alas such things are complicated and very intrusive
[00:46:40 CEST] <PaoloP> jamrial: I added the files and did the commit. Should these operation appear in the irc channel? I see for example: "<cone-883> ffmpeg Michael Niedermayer master:bcd7153df382: ffprobe: Support adding av_log output to frames"   
[00:47:20 CEST] <jamrial> that has nothing to do with your git commands
[00:49:58 CEST] <PaoloP> what are them?
[00:53:03 CEST] <jamrial> a log of commits pushed to the main public repository
[03:20:16 CEST] <Shiz> '/w 32
[04:39:39 CEST] <cone-433> ffmpeg 03James Almer 07master:b613245c9715: ffprobe: free log buffer's parent_name during cleanup
[06:15:57 CEST] <cone-433> ffmpeg 03James Almer 07master:3fe7bb2bcf19: avcodec/extract_extradata_bsf: add missing break statement to extract_extradata_vc1
[06:24:56 CEST] <AaronL> Hi all, not sure if anyone is here right now, but I submitted a patch to the ffmpeg-devel e-mail list a couple of days ago
[06:25:28 CEST] <AaronL> Other than someone responding, indicating that he thought this had already been dealt with (it hadn't, and I responded as such), I haven't seen anything else
[06:25:47 CEST] <AaronL> do I need to get a small patch like this signed off on by someone else before pushing it to the repository?
[06:25:57 CEST] <AaronL> I've never contributed to ffmpeg in the past
[06:26:33 CEST] <AaronL> It's this one:  http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209129.html
[06:57:28 CEST] <Compn> AaronL : hello, just saying its late and i dont think anyone is online right now
[06:57:35 CEST] <Compn> but we do read this channel later, when we wake up :)
[06:58:32 CEST] <Compn> since your patch changes h264 decoding behavior, it will have to be extensively tested against all of our samples
[06:59:00 CEST] <Compn> AaronL: i understand you ran the fate tests, but those are only a handful of samples, while we have many TB of samples that we sometimes test against
[06:59:29 CEST] <Compn> AaronL : the usual turnaround time for patches is 2 weeks for a review
[06:59:37 CEST] <Compn> 2 weeks max...
[06:59:58 CEST] <Compn> you posted the patch 2 days ago... have patience :)
[07:00:08 CEST] <Compn> most of us here are volunteers and are not paid to do this work 
[07:02:33 CEST] <Compn> er, whoops i misread the patch re h264
[07:02:46 CEST] <Compn> was going by description not patch content :D
[07:02:56 CEST] <Compn> i think michaelni maintains ffmpeg.c 
[07:03:06 CEST] <Compn> AaronL : but yes , 2 weeks...
[07:04:15 CEST] <Compn> if you have other questions, please ask
[07:04:20 CEST] Action: Compn going sleepy town now
[07:04:32 CEST] <Compn> and feel free to stay here on irc.
[10:53:15 CEST] <cone-792> ffmpeg 03Steven Liu 07master:c0628919b8c5: avformat/flvdec: check FLVHeader PreviousTagSize0
[10:55:34 CEST] <ubitux> that cleanup_step thing is... original
[10:58:54 CEST] <ubitux> jkqxz: that AVHWDeviceType none change breaks ABI, doesn't it?
[10:58:58 CEST] <ubitux> shouldn't it be -1?
[10:59:23 CEST] <nevcairiel> he really wants it to be 0 so he can be lazy with explicit init
[10:59:36 CEST] <nevcairiel> and libav just major-bumped
[11:02:35 CEST] <wm4> yes Libav is in a phase where they can do arbitrary ABI changes
[11:02:49 CEST] <wm4> so if you can think of anything, now is the time (well, and again when FFmpeg does the same)
[11:08:32 CEST] <ubitux> ok
[11:12:58 CEST] <jkqxz> I wonder how many things would break if we made AV_PIX_FMT_NONE zero, because that would be a good change for everyone (except horrible existing code using YUV420P implicitly).
[11:13:26 CEST] <nevcairiel> Personally I think explicit init is always a good thing
[11:25:18 CEST] <wm4> I think implicit init to sane or invalid values is always a good thing
[11:25:31 CEST] <wm4> while init to some random but valid value (yuv420p) is pretty bad
[11:40:10 CEST] <cone-792> ffmpeg 03Clément BSsch 07master:c3706bc25574: doc/examples/filtering_*: switch to codecpar
[11:42:02 CEST] <cone-792> ffmpeg 03Matthieu Bouron 07master:7e3e0f87e6e9: doc/examples/muxing: re-indent block
[12:50:24 CEST] <mateo`> dear ubitux, would you kindly review my extract_mvs patch ?
[12:50:33 CEST] <ubitux> yes my love
[13:12:33 CEST] <mateo`> thanks :)
[14:32:53 CEST] <mateo`> transcoding.c is funny
[14:36:41 CEST] <durandal_1707> what could be cause of ratecontrol error, when qscale is too big?
[14:42:00 CEST] <atomnuker> durandal_1707: couldn't you scale back the qscale when sending it off to the rc system?
[14:43:54 CEST] <durandal_1707> how?
[14:45:02 CEST] <durandal_1707> this is dnxhr and it have some strange rc code
[14:49:19 CEST] <atomnuker> just set it before the weird stuff and restore it after
[15:01:15 CEST] <BtbN> Hm, I wonder what transcoding chip is on the 1080 Ti
[15:41:06 CEST] <ubitux> mmh
[15:41:21 CEST] <ubitux> how is ffmpeg able to read only specific streams?
[15:41:54 CEST] <ubitux> it seems it's able to not even get given packet for given streams
[15:42:13 CEST] <ubitux> which makes it much faster than a simple loop that filters out packet
[15:43:00 CEST] <ubitux> maybe a discard mechanism
[15:43:02 CEST] <ubitux> ?
[15:44:50 CEST] <BtbN> I'd guess it just discards any packets coming out of the demuxer that don't match the requested streams?
[15:45:15 CEST] <ubitux> omfg
[15:45:32 CEST] <ubitux> you can speeds it up by setting st->discard = AVDISCARD_ALL
[15:50:14 CEST] <ubitux> TIL...
[15:53:37 CEST] <nevcairiel> its good to learn things
[15:53:48 CEST] <ubitux> it really makes a difference, that's nice
[15:53:51 CEST] <bf_> Hey guys, any of you have some time for freelancing this afternoon? I need to pick someones brain for half an hour but it seems thilo and thomas are not available.
[15:55:44 CEST] <bf_> I'm trying to build a node.js RTMP server which is fed by OBS and spits out HLS or Dash, having problem to assemble the x264 frames coming through RTMP
[16:00:31 CEST] <RiCON> bf_: you could try looking through https://github.com/sergey-dryabzhinsky/nginx-rtmp-module
[16:01:23 CEST] <bf_> RiCON: thanks, I have already tried it out. Hit a lot of bugs unfortunately. discussing in #ffmpeg already
[16:02:47 CEST] <jamrial> ubitux: i sent a port of examples/transcoding to the ml months ago, but it didn't get reviewed and i moved to something else
[16:03:09 CEST] <mateo`> jamrial: :'(
[16:03:23 CEST] <jamrial> i guess it still works, but maybe you or matthieu want to look at it
[16:03:26 CEST] <jamrial> so we can push it
[16:03:27 CEST] <mateo`> jamrial: I will review it now
[16:04:31 CEST] <mateo`> jamrial: do you have the patch somewhere ?
[16:05:36 CEST] <jamrial> mateo`: one sec
[16:06:38 CEST] <jamrial> mateo`, ubitux: https://github.com/jamrial/FFmpeg/commits/examples
[16:08:27 CEST] <mateo`> thanks
[16:11:10 CEST] <PaoloP> Hello. Please have a look at the new API usage snippet I proposed. http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209256.html . I can provide other ones, which are useful for libav users,  if it is accepted (I have to re-organize all the code and it  requires much time)
[16:14:09 CEST] <PaoloP> I made many snippets during these last months, and they all separate all the tasks in a strict procedural way, so that the reader can easily understand the sequence   grabbing--> resampling ---> encoding ---> muxing ---> streaming
[16:29:30 CEST] <PaoloP> wm4: what's wrong in the cleanup_step variable?
[16:29:50 CEST] <wm4> it's fragile and hard to read
[16:30:14 CEST] <wm4> you could replace error handling with a call to abort() (it's an example after all), or do proper C style error handling
[16:30:33 CEST] <PaoloP> wm4: but in the other examples is even more fragile. I followed the style of the other examples and tried to improve it
[16:31:08 CEST] <PaoloP> I mean: all the other examples do use the cleanup label
[16:31:13 CEST] <PaoloP> with a goto jump
[16:32:45 CEST] <PaoloP> (they are really messy, though)
[16:33:14 CEST] <wm4> your approach is messier
[16:33:35 CEST] <wm4> if you need to add a new error case in-between, you need to edit and revisit all the other cases
[16:33:55 CEST] <wm4> and it's not easy to see at all which cleanup corresponds to which code
[16:34:40 CEST] <PaoloP> wm4: I don't agree it's messier. Look at transcode_aac.c . the error handling is partially done in the if statement and finalized in the cleanup block
[16:35:16 CEST] <PaoloP> you are right when you say that "[16:33] <wm4> if you need to add a new error case in-between, you need to edit and revisit all the other cases"
[16:35:29 CEST] <PaoloP> but it's not messier than the other examples
[16:35:41 CEST] <ubitux> it is
[16:35:48 CEST] <ubitux> but it's also inconsistent
[16:35:55 CEST] <ubitux> (with the rest of the codebase)
[16:36:25 CEST] <ubitux> please copy the style, we want consistency within the project
[16:36:39 CEST] <ubitux> s/but/and/
[16:37:00 CEST] <mateo`> jamrial: the patch looks good to me, nit: can you split the assignment from the if test (https://github.com/jamrial/FFmpeg/commit/6002f2d2a01656ad4290df7e3ae5b02225cd582f#diff-480ae57b68d1099ffbbb6bb01dcfb06dR181) ?
[16:37:13 CEST] <ubitux> PaoloP: typically in the same spirit you can drop the double line breaks
[16:37:44 CEST] <PaoloP> ubitux: which rules do I have to change?
[16:37:52 CEST] <jamrial> mateo`: sure
[16:38:00 CEST] <PaoloP> (in order to have consistency within the project)
[16:38:19 CEST] <ubitux> you don't change the rule, you follow it
[16:38:32 CEST] <ubitux> so you drop this cleanup step thing and have a common error path
[16:38:50 CEST] <PaoloP> ubitux: ok
[16:38:54 CEST] <ubitux> thanks
[16:39:17 CEST] <PaoloP> ubitux: and what else? it would be useful if you tell me a short list of things I should change
[16:39:36 CEST] <ubitux> the double line breaks
[16:39:44 CEST] <PaoloP> wm4: said to declare variables before statements. Is it necessary ?
[16:39:55 CEST] <ubitux> look at the rest of the code and compare
[16:40:01 CEST] <ubitux> yes it is
[16:40:10 CEST] <PaoloP> ok
[16:40:15 CEST] <ubitux> btw iirc you have tabs in the Makefile
[16:40:51 CEST] <ubitux> btw, you can use av_err2str() instead of that get_error_text
[16:40:58 CEST] <PaoloP> ubitux: ok again
[16:41:09 CEST] <PaoloP> (I copied get_error_text from another example)
[16:41:21 CEST] <wm4> ubitux: that's weird... it requires the examples to be in C99, which doesn't require decls-before-statements
[16:41:34 CEST] <PaoloP> wm4: I agree
[16:42:01 CEST] <ubitux> wm4: it's all about consistency...
[16:42:13 CEST] <ubitux> yeah that transcode_aac shouldn't be like that
[16:42:17 CEST] <mateo`> wm4: are you ok with the remuxing example patch (with the avformat_transfer_internal_stream_timing_info call removed) ?
[16:42:20 CEST] <ubitux> i think that's because libav doesn't have av_err2str
[16:42:28 CEST] <ubitux> and it comes from there
[16:42:35 CEST] <wm4> mateo`: yeah, I have no further comments I think
[16:43:05 CEST] <PaoloP> ubitux: IMHO, with the declaration after statements, the user can pick portions of the code and adapt them to his code in an easier way
[16:43:11 CEST] <ubitux> PaoloP: you don't need to cast malloc, it's not C++
[16:43:22 CEST] <mateo`> wm4: thanks for the review
[16:43:28 CEST] <mateo`> i'll push both patches (remuxing / extract_mvs) in a couple of minutes
[16:43:31 CEST] <ubitux> PaoloP: i know, but it's not the current convention we're following
[16:43:32 CEST] <PaoloP> ubitux: :-) yes again
[16:43:40 CEST] <PaoloP> ubitux: ok, I'll follow the rule
[16:44:07 CEST] <ubitux> you have to fix the coding style btw, like "if(" is missing a space
[16:44:25 CEST] <ubitux> but i don't want to explicit that style, look at the rest of the code and copy it
[16:44:48 CEST] <PaoloP> ubitux: just fixed
[16:44:50 CEST] <ubitux> i'll make a proper review on the ml at the next iteration
[16:45:30 CEST] <ubitux> PaoloP: squash your patches too
[16:45:58 CEST] <PaoloP> ubitux: <ubitux> PaoloP: squash your patches too <--- what does it mean?
[16:46:05 CEST] <ubitux> make one single patch
[16:46:13 CEST] <PaoloP> ubitux: yes, wm4 told me that
[16:46:29 CEST] <ubitux> sorry, missed it
[16:46:44 CEST] <PaoloP> ubitux: he told me that in pvt msg, it's not your fault
[16:48:17 CEST] <PaoloP> ubitux: the only thing I don't understand well is how to change the cleanup function. [16:38] <ubitux> so you drop this cleanup step thing and have a common error path ... which api example could I use as a model?
[16:48:44 CEST] <ubitux> btw, you'll have to update the configure to add the example here too (there are two ways of building examples; as standalone with the Makefile which uses the system libraries, and with `make examples` within the FFmpeg build system)
[16:48:53 CEST] <ubitux> you'll also have to update a .gitignore iirc
[16:49:04 CEST] <ubitux> PaoloP: look at other examples
[16:49:31 CEST] <ubitux> you generally just have a "end" label with a bunch of free
[16:49:41 CEST] <PaoloP> ubitux: do you mean that I have to keep the goto?
[16:49:47 CEST] <ubitux> yes, but only one
[16:50:18 CEST] <ubitux> look at doc/examples/filtering_audio.c for example
[16:50:22 CEST] <PaoloP> ok
[16:50:48 CEST] <ubitux> you don't need to use exit(), but the general flow should be the same
[16:51:14 CEST] <PaoloP> ok
[16:52:01 CEST] <PaoloP> ubitux: about the double line break, I don't understand that as well
[16:52:23 CEST] <PaoloP> do you mean \n\n in the code?
[16:52:27 CEST] <ubitux> yes
[16:52:31 CEST] <ubitux> actually \n\n\n
[16:53:09 CEST] <PaoloP> how do I have to replace it?
[16:53:09 CEST] <cone-792> ffmpeg 03Matthieu Bouron 07master:4a946aca7cf3: doc/examples/remuxing: switch to codecpar
[16:53:09 CEST] <cone-792> ffmpeg 03Matthieu Bouron 07master:64b553998567: doc/examples/extract_mvs: switch to codecpar
[16:53:18 CEST] <PaoloP> only one?
[16:53:26 CEST] <ubitux> no, many
[16:53:37 CEST] <ubitux> just keep one empty line between blocks
[16:53:47 CEST] <PaoloP> I mean: I have to replace each double/multi line with only one line?
[16:54:24 CEST] <PaoloP> I see, I used multi line in order to separate more clearly the blocks, but I'll follow the rule you said
[16:55:06 CEST] <ubitux> it's not the "the rule i said", it's how it's written in the rest of the codebase
[16:55:11 CEST] <ubitux> i'm not making them up as a whim
[16:56:26 CEST] <PaoloP> Also: I mead comments with "//" instead of "/*"  (I prefere the first one); I should replace them, right?
[16:56:36 CEST] <PaoloP> (s/mead/made)
[16:59:25 CEST] <ubitux> yeah, we usually use /* */ for the multiline ones 
[16:59:51 CEST] <ubitux> for single line ones i don't think that's important, i don't remember seeing a consistent convention on thjat
[17:03:40 CEST] <PaoloP> ubitux, wm4: ok, I'm changing all these things right now. If you have other suggestions, just tell them here and I'll follow them
[17:22:09 CEST] <ubitux> can i have reviews on the av_4cc2str() thing? i'll need to move on with the patchset
[17:22:22 CEST] <ubitux> it's a dependency for the pending djgpp patchset 
[17:23:37 CEST] <cone-792> ffmpeg 03Ronald S. Bultje 07master:5ba8c3a0ed0e: dirac: make initialization of arithmetic coder tables threadsafe.
[17:25:32 CEST] <ubitux> the whole thing is at https://github.com/ubitux/FFmpeg/compare/djgpp
[17:27:06 CEST] <wm4> ubitux: well there were multiple comments on 4cc2str? address them in some form, then push?
[17:27:32 CEST] <BBB> +1 that
[17:27:51 CEST] <cone-792> ffmpeg 03James Almer 07master:3b80f73b186d: doc/examples/transcoding: convert to codecpar
[17:28:02 CEST] <ubitux> wm4: i think i addressed all of them
[17:28:16 CEST] <mateo`> jamrial: thanks :)
[17:28:19 CEST] <BBB> is anyone interested in reviewing hevc: initialize no_rasl_output_flag in hevc_frame_start().? its fairly trivial and I believe it will remove some tsan warnigns for hevc
[17:29:16 CEST] <PaoloP> ubitux: wm4 and others, are the cleanup functions avcodec_close(), avcodec_free_context(), av_frame_free() etc. safe if I pass a null pointer to them ?
[17:29:32 CEST] <PaoloP> (So I can remove the "cleanup_step" variable
[17:29:36 CEST] <ubitux> jamrial: are you going to push these atomic commits? i'd like to see if that helps wrt the tsan fate instance
[17:29:38 CEST] <PaoloP> )
[17:29:48 CEST] <jamrial> ubitux: no, they are not correct as is
[17:29:50 CEST] <ubitux> PaoloP: most if not all are
[17:29:55 CEST] <ubitux> jamrial: ah? damn
[17:30:09 CEST] <PaoloP> ubitux: this should be added to the documentation!!!!!
[17:30:15 CEST] <ubitux> PaoloP: check the code
[17:30:21 CEST] <PaoloP> ubitux: ok
[17:30:30 CEST] <ubitux> send a patch for the doxy if not mentioned
[17:30:34 CEST] <PaoloP> ubitux: ok
[17:32:06 CEST] <jamrial> ubitux: only one was and i already pushed it. the rest use compare exchange and require more thought to them compared to the old implementation
[17:34:05 CEST] <ubitux> mmh
[17:34:07 CEST] <ubitux> ok
[17:42:31 CEST] <PaoloP> swr_free doesn't seem safe with a null pointer:   https://www.ffmpeg.org/doxygen/3.2/swresample_8c_source.html#l00140  (it calls av_freep() regardless of the NULL value). What to do? Is it necessary to patch it?
[17:43:39 CEST] <BtbN> good thing av_freep is safe to call with a NULL Value.
[17:43:46 CEST] <wm4> BtbN: nope
[17:44:02 CEST] <BtbN> what? I have seen that happen in quite a few places
[17:44:04 CEST] <wm4> the pointer you pass to it can be NULL
[17:44:11 CEST] <wm4> but av_freep(NULL) crashes I think
[17:44:24 CEST] <nevcairiel> av_freep(NULL) is not s afe, p = NULL; av_freep(&p) is safe
[17:44:45 CEST] <wm4> I wonder if that's intended
[17:44:59 CEST] <nevcairiel> the worse code in swr_free is that it dereferences ss right in the first line
[17:45:04 CEST] <BtbN> It should be easy to fix if that's really the case, and prevent a few possible accidents
[17:45:58 CEST] <nevcairiel> the way av_freep is commonly called, you wouldnt often run into this
[17:46:06 CEST] <nevcairiel> since its typical to call it like av_freep(&mypointer);
[17:46:43 CEST] <wm4> swr_free would better be named swr_freep (because that are its semantics)
[17:47:11 CEST] <PaoloP> so, what to do? is it better to patch it or to do if(ptr != NULL) swr_free() ?
[17:47:38 CEST] <BtbN> how would it even happen in normal usage for the ptr you pass to it to be NULL?
[17:47:44 CEST] <nevcairiel> since its essentially a freep mechanic, are you sure you are not using it wrong in the first place
[17:48:18 CEST] <PaoloP> BtbN: in the cleanup block of the code
[17:48:35 CEST] <BtbN> you usually do something like swr_free(&ptr);
[17:48:44 CEST] <BtbN> so there is normally no way for that to end up as NULL
[17:48:57 CEST] <nevcairiel> calling swr_free(&audio_convert_context);  will never error
[17:48:58 CEST] <PaoloP> BtbN: right
[17:49:30 CEST] <nevcairiel> since &var is never NULL
[17:49:36 CEST] <nevcairiel> var might be NULL, but thats ok
[17:51:38 CEST] <kkanungo17> where can I get the documentation for the native vorbis encoder and the AAC psychoacoustic system?
[17:52:07 CEST] <nevcairiel> internal components like that often dont have specific documentation - read the code
[17:52:14 CEST] <atomnuker> kkanungo17: sorry I didn't respond, been busy
[17:52:19 CEST] <atomnuker> there isn't any like nevcairiel said
[17:52:26 CEST] <atomnuker> you have to read the code
[17:53:07 CEST] <ubitux> i think found the race in libavfilter
[17:53:12 CEST] <kkanungo17> I've been busy too, so I delayed too, sorry
[18:16:32 CEST] <PaoloP> I have adts_container_buffer = av_malloc(adts_container_buffer_size) in the main() and  I put av_free(adts_container_buffer) in the "end:" cleanup block. How can I assure safety for that? should I check if adts_container_buffer is not null before calling av_free() ?
[18:18:02 CEST] <nevcairiel> av_free is NULL safe
[18:18:13 CEST] <PaoloP> thanks nevcairiel
[18:19:17 CEST] <nevcairiel> better would be using av_freep(&adts_...) though
[18:19:41 CEST] <PaoloP> nevcairiel: ok
[18:37:19 CEST] <PaoloP> Ok. I made all the modifications suggested by ubitux and wm4. Now I have to git add encode_raw_audio_file_to_aac.c and the Makefile. But how can I squash the two patches into one file?
[19:14:12 CEST] <jamrial> ubitux, BBB: https://bugs.kde.org/show_bug.cgi?id=378068#c1 the workaround mentioned here seems to work
[19:14:21 CEST] <BBB> cool
[19:14:30 CEST] <BBB> see? my code is never buggy[tm] :D
[19:17:05 CEST] <ubitux> jamrial: yeah i didn't update my instance yet
[19:17:10 CEST] <ubitux> i will add that option
[19:17:24 CEST] <ubitux> PaoloP: learn how to use git rebase (-i)
[19:23:47 CEST] <PaoloP> ubitux: I created the patch with "git diff HEAD~2 > mypatch.txt  (changed two files)  .    Here's the patch:   http://paste.ubuntu.com/24268946/    is it in the correct format? If so I send it to the ML
[19:24:21 CEST] <ubitux> no, we need a git formatted patch (with author, commit message and description, etc)
[19:24:30 CEST] <wm4> no, it makes it harder to apply
[19:24:38 CEST] <wm4> (which you probably don't want)
[19:24:59 CEST] <ubitux> https://help.github.com/articles/about-git-rebase/
[19:24:59 CEST] <wm4> so use git rebase or whatever to turn it into 1 commit, then use git format-patch to produce a proper patch
[19:25:08 CEST] <ubitux> git rebase -i HEAD~2
[19:25:17 CEST] <ubitux> then replace pick with fixup on the second one
[19:25:41 CEST] <ubitux> i'm not going to make a more advanced git tutorial, check on the net
[19:30:12 CEST] <ubitux> so, anyway, if we ignore the dirac, hevc, resize and lavfi race
[19:30:14 CEST] <ubitux> what's left?
[19:31:06 CEST] <atomnuker> BBB fixed the dirac race, didn't he
[19:31:15 CEST] <BBB> I hope so
[19:31:22 CEST] <BBB> at least that was the goal
[19:31:35 CEST] <ubitux> yeah, i mentioned the one that are supposed to be fixed in pending patches
[19:31:35 CEST] <BBB> did it work?
[19:31:41 CEST] <ubitux> is it pushed?
[19:31:44 CEST] <BBB> yes
[19:31:47 CEST] <BBB> only that one
[19:31:49 CEST] <ubitux> oh
[19:31:50 CEST] <BBB> the rest had no review so far
[19:32:02 CEST] <ubitux> i don't see dirac
[19:32:07 CEST] <ubitux> so i guess it's good :)
[19:32:10 CEST] <BBB> where?
[19:32:15 CEST] <ubitux> on tsan report
[19:32:20 CEST] <BBB> link?
[19:32:27 CEST] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170328161749&slot=x86_64-archlinux-gcc-tsan
[19:32:39 CEST] <ubitux> can i have a review on the lavfi one? should help reducing the noise
[19:32:40 CEST] <BBB> yup, indeed
[19:33:24 CEST] <wm4> I almost read that as "BBB fixed the horse race"
[19:34:22 CEST] <BBB> ubitux: I think it looks good but Im not that great with lavfi internal/core
[19:34:41 CEST] <ubitux> the threading is pretty much isolated in that file
[19:34:51 CEST] <BBB> ok
[19:34:59 CEST] <BBB> I have some ideas on how to fix the tsan reports on intra-only codecs
[19:35:13 CEST] <BBB> they are basically harmless, but they can be silenced by not syncing stuff for intra-only codecs
[19:35:29 CEST] <ubitux> the lavfi one is mostly harmless too
[19:36:00 CEST] <ubitux> actually, likely completely harmless as the concurrent write is never read 
[19:36:27 CEST] <BBB> :)
[19:37:01 CEST] <BBB> the remaining h264 ones are basically multi-slice header readers where we need to move to init stuff only in the first slice and check for identical data in next slices instead of rewrite already-copied values
[19:37:06 CEST] <BtbN> why is it written in the first place then?
[19:37:17 CEST] <BBB> BtbN: its things like width/height
[19:37:22 CEST] <BBB> BtbN: its pretty important to write them
[19:37:37 CEST] <BBB> imagine having AVFrame->width be unset ;)
[19:37:38 CEST] <BtbN> can't that just be limited to one thread, or just moved out of them?
[19:37:48 CEST] <BBB> its intraonly, why?
[19:37:53 CEST] <BBB> every thread can have a different value
[19:38:03 CEST] <BtbN> With slice threading?
[19:38:05 CEST] <BBB> imagine ffmpeg -f image2 -c:v mjpeg ~/Photos/*.jpg
[19:38:14 CEST] <BBB> no with frame threading
[19:38:34 CEST] <BBB> I dont see anything wrong with size changes
[19:38:41 CEST] <BBB> but theres no sense in syncing width/height between threads
[19:39:00 CEST] <BBB> and we dont want to wait spinning thread2 until thread1 has set width and height (which thread2 ignores anyway, because intraonly)
[19:39:15 CEST] <BBB> so syncing in those cases is useless and needs to be prevented
[19:39:15 CEST] <BtbN> the threads should be writing the different width/height fields in their own Frame anyway. The width/height in the codec context might be more complex
[19:39:18 CEST] <BBB> that silences the races
[19:39:38 CEST] <atomnuker> how about using atomic writes for that?
[19:39:42 CEST] <BBB> Im talking about syncing w/h *between* AVCodecContext in update_thread_context() in pthread_frame.c
[19:40:04 CEST] <BBB> atomics is more like a plastering issue
[19:40:11 CEST] <BBB> we shouldnt sync values that we ignore
[19:41:04 CEST] <BBB> dont worry about it, Ive got a pretty good idea on solving it without ugly hack
[19:41:17 CEST] <BBB> I just need some time to sit down and verify it does what I think it will dop
[19:41:19 CEST] <BBB> -p
[19:41:29 CEST] <BtbN> do they need to be written to at all? Or is preventing that ugly?
[19:41:54 CEST] <wm4> I suppose in theory, opening the decoder could set the video width/height in simple decoders
[19:42:09 CEST] <wm4> which would prevent us "syncing" them simply from AVFrame
[19:53:08 CEST] <PaoloP> wm4: is this ok? http://paste.ubuntu.com/24269103/
[19:55:35 CEST] <PaoloP> (I executed:   git add file1; git commit -m "comment1"; git add file2; git commit -m "comment2"; git rebase -i HEAD~2; git format-patch -1" )
[20:05:06 CEST] <BtbN> why didn't you add both files right away?
[20:05:44 CEST] <PaoloP> BtbN: what do you mean with "right away"? (forgive my poor english)
[20:05:53 CEST] <AaronL> Compn:  see that you are back now, perhaps you'll see this :-)
[20:06:04 CEST] <BBB> see pthread_frame: don't sync items between threads for intra-only codecs. for what I meant
[20:06:22 CEST] <BBB> I didnt test it at all, but my assumption is that it will fix tsan for most intra-only decoders
[20:06:26 CEST] <BtbN> well, if you did the git add before the second commit, you'd have just one commit right away, and wouldn't need to squash them into one using an interactive rebase.
[20:06:48 CEST] <AaronL> Compn:  I had read 3 days for small patches--the overall amount of changes in the patch I submitted are small, although it does represent a change in the behavior, so maybe it is considered a large patch
[20:07:25 CEST] <PaoloP> BtbN: I see. I'll do that in the future. But is the current patch in the correct fmt?
[20:08:06 CEST] <ubitux> BBB: as soon as you apply your threading patches i'll apply mine a trigger a new tsan run
[20:08:07 CEST] <AaronL> Compn:  It is not specific to H.264 and is actually quite general.  But, I think you noticed that when you took a look at it.
[20:08:17 CEST] <BBB> ubitux: -eneedsreview ;)
[20:08:57 CEST] <ubitux> can you run make fate THREADS=3 or sth on your patch just in case? :p
[20:20:38 CEST] <ericdc> Hi guys I have a question. To get a 800x480 resolution at 30 FPS with H264 what kind of ARM chip would be the minimum requirement? Also is libavcodec designed to use extensions like DSP and NEON on ARM?
[20:28:46 CEST] <BBB> ubitux: seems to work for png :)
[20:28:55 CEST] <BBB> but something is broken w/ vp9, checking
[20:34:32 CEST] <kkanungo17> ericdc: wouldn't any cortex a8 and up be able to do that?
[20:36:07 CEST] <ericdc> kkanungo17: perhaps but what about older devices?
[20:37:07 CEST] <kkanungo17> would have to look into it
[20:45:14 CEST] <tmm1> is it possible to tell if a h264 bitstream is interlaced by looking only at the SPS?
[20:55:10 CEST] <AaronL> tmm1:  May be possible--you could review https://cardinalpeak.com/blog/the-h-264-sequence-parameter-set/ and see what the tool reports
[20:55:29 CEST] <AaronL> and compare between an H.264 bitstream that is progressive and one that is interlaced
[20:55:40 CEST] <AaronL> using the same encoder to produce both
[20:57:21 CEST] <tmm1> funny, that's exactly what i'm doing
[20:57:26 CEST] <atomnuker> BBB: isn't "av_codec_get_codec_descriptor(src)->props & AV_CODEC_PROP_INTRA_ONLY)" returns !0 for intra only
[20:57:43 CEST] <atomnuker> so it'll sync for intra-only codecs only or if for_user is 1
[20:57:51 CEST] <BBB> oh did I forget a !?
[20:57:52 CEST] <tmm1> previously i thought sps->frame_mbs_only_flag == 0 always meant progressive, but i found a sample where that's not true
[20:57:53 CEST] <BBB> maybe I did
[20:57:55 CEST] <BBB> sorry
[20:57:59 CEST] <BBB> like I said, totally untested :D
[20:58:16 CEST] <tmm1> err, ==1
[20:58:18 CEST] <BBB> atomnuker: lemmefix
[20:58:32 CEST] <BBB> atomnuker: but do you think the idea of the patch makes sense?
[20:59:38 CEST] <atomnuker> I'm not sure actually
[20:59:53 CEST] <atomnuker> what if the width and height change between each avctx?
[21:00:37 CEST] <atomnuker> what's usually the dst in this case?
[21:03:35 CEST] <BBB> atomnuker: the dst in case of skipping is the next threads avcodeccontext
[21:03:43 CEST] <BBB> if its the user or whaever, for_user=1 and we do sync
[21:03:48 CEST] <BBB> from_user is done in a different function
[21:04:04 CEST] <BBB> so the idea is to continue allowing synchronization between user and worker threads
[21:04:11 CEST] <BBB> but not between worker threads (for intraonly)
[21:11:56 CEST] <atomnuker> as long as the user's context has the same data as the thread which decoded the returned frame it should be fine
[21:12:02 CEST] <AaronL> tmm1:  you can see how MediaInfo figures it out
[21:12:34 CEST] <AaronL> source code is available for MediaInfo
[21:13:09 CEST] <BBB> atomnuker: yeah thats still guaranteed
[21:16:23 CEST] <atomnuker> then yeah it makes sense, each worker reads the width and height itself always so there's no need to sync it
[21:17:12 CEST] <atomnuker> (until some intra only codec appears which doesn't always send that data on every frame to save 8 bytes on a 1Mb packet :))
[21:17:36 CEST] <BBB> then its not intra-only
[21:17:46 CEST] <BBB> ;)
[21:17:50 CEST] <BBB> right?
[21:18:02 CEST] <BBB> if I seek to frame 2, I cant decode it without having decoded frame 1 first (at least these 8 bytes)
[21:18:37 CEST] <wm4> PaoloP: yes
[21:18:51 CEST] <PaoloP> wm4: thnks
[21:20:39 CEST] <PaoloP> when sending patches to the ML, is it better to attach them to the mail or paste it in the body of the msg ?
[21:21:12 CEST] <ubitux> git send-email
[21:21:28 CEST] <ubitux> (--in-reply-to)
[21:26:55 CEST] <PaoloP> "git send-email --to ffmpeg-devel at ffmpeg.org  mypatch.txt" is enough or I have to add some other fields/descriptions?
[21:34:06 CEST] <ubitux> PaoloP: git send-email -1 --to=ffmpeg-devel at ffmpeg.org --in-reply-to=647710073.8448733.1490656403410 at mail.yahoo.com
[21:38:21 CEST] <PaoloP> thnks ubitux
[21:48:36 CEST] <ubitux> should we start working on the bitstream merge?
[21:48:52 CEST] <ubitux> as merges come, we're going to reach it and it's going to block any further merges
[21:48:59 CEST] <ubitux> can we start considering it now?
[21:52:35 CEST] <atomnuker> we can't merge the reader itself, its slower
[21:53:28 CEST] <atomnuker> the API sucks donkeys
[21:54:43 CEST] <thebombzen> so I just made a 2-line patch to add HEVC and Opus support to the nut container (two line addition to nut.c)
[21:54:53 CEST] <thebombzen> and I did a few quick tests and it appears to work
[21:55:08 CEST] <thebombzen> so I'd like to submit this patch to the maintainers but I don't know how or if this will even be approved
[21:55:22 CEST] <thebombzen> can someone give me some tips?
[21:56:49 CEST] <jamrial> thebombzen: https://ffmpeg.org/developer.html#Contributing
[21:57:05 CEST] <jamrial> basically, send your patches to the ffmpeg-devel mailing list
[21:59:15 CEST] <thebombzen> this is just me being unfamiliar with git, but I've made a few patches to my local git repo, so I'm not sure the sha-1 sums will match up
[21:59:20 CEST] <thebombzen> is that a problem?
[21:59:49 CEST] <jamrial> they will not matter once you make a patch with git format-patch and send them, no
[22:00:06 CEST] <thebombzen> okay, cause this is the patch I would send: https://0x0.st/v1c.patch
[22:00:20 CEST] <thebombzen> it's just a 2-liner but I've never done this before and I'm a bit worried something might messup
[22:00:29 CEST] <Compn> thebombzen : so just ask michaelni to review it, i think he maintains nut
[22:00:43 CEST] <Compn> there might be a reason why it wasnt adde
[22:00:58 CEST] <thebombzen> well in this case my best guess is "never got around to it"
[22:01:18 CEST] <thebombzen> cause Nut supports all riff/avi tags, plus a few extras that were explicitly added (like vp9)
[22:01:18 CEST] <jamrial> thebombzen: yes, you can send that just fine
[22:01:27 CEST] <thebombzen> jamrial: alright thanks
[22:02:07 CEST] <thebombzen> I tested it a bit - I remuxed an hevc/opus from matroska to nut with ffmpeg -i input.mkv -c copy output.nut and I could play the file correctly in both ffplay and mpv  (linked against the same ffmpeg)
[22:02:12 CEST] <thebombzen> so I'd assume there'd be no real issues
[22:02:29 CEST] <jamrial> ubitux: afaik the api is the same so it should be a search and replace for get_bits.h functions into bitstream.h functions for those codecs libav doesn't have, so not a lot of work
[22:02:33 CEST] <jamrial> but what atomnuker said is true, it's apparently slower in some cases
[22:02:55 CEST] <ubitux> "in some cases"; which? what can we do about it?
[22:03:03 CEST] <ubitux> 32-bit? ARM?
[22:03:08 CEST] <ubitux> which decoder(s)?
[22:03:44 CEST] <jamrial> some audio codecs i think, don't recall which ones, and yeah, 32 bit
[22:04:12 CEST] <jamrial> BBB tried to get them to fix or consider the latter, but didn't succeed
[22:05:25 CEST] <atomnuker> just merge the API and find and replace everything with a script
[22:06:19 CEST] <atomnuker> don't bother changing the few codecs which do reading using the macros directly, they'll still work as long as its just an API change
[22:07:08 CEST] <BBB> jamrial: what did I do?
[22:07:18 CEST] <BBB> oh get_bits vs. bitstream?
[22:07:20 CEST] <atomnuker> down the road we could make the cache size dependent on architecture/#define for the few codecs that could benefit
[22:07:25 CEST] <BBB> yeah Im not getting into that trollwar
[22:07:43 CEST] <BBB> if they believe they know what theyre doing and dont want input from me, then thats totally their call
[22:07:52 CEST] <BBB> its their project
[22:08:03 CEST] <atomnuker> BBB: they ignored my small tiny request as well
[22:08:11 CEST] <atomnuker> make the bloody API consistem for encoding and decoding
[22:08:15 CEST] <atomnuker> but no, fuck encoding
[22:08:27 CEST] <BBB> I think its really just all politics
[22:08:34 CEST] <BBB> they dont want to do it because you asked for it
[22:08:42 CEST] <BBB> if luca had made the same suggestion, they would do it instantly
[22:08:58 CEST] <BBB> at this point I dont want to reason with it anymore, I try to be fair in my reviews but that means I cant help them anymore
[22:09:16 CEST] <BBB> sorry j-b
[22:09:31 CEST] <BBB> but Im not a politician, I just code
[22:10:04 CEST] <jamrial> the author of the reader was also kinda reluctant about changing anything
[22:10:35 CEST] <jamrial> like, considering all the suggestions would mean more work and delay committing their work
[22:10:54 CEST] <ubitux> no improvement came up after that?
[22:11:10 CEST] <durandal_1707> just commit api but keep old functionality
[22:11:44 CEST] <BBB> ubitux: its faster for some codecs on some archs, slower for other codecs on other archs
[22:11:46 CEST] <BBB> its fairly random
[22:12:04 CEST] <BBB> I think theres a system to it and it can be dissected into a signal, but .. like I said, nobody cares
[22:12:31 CEST] <durandal_1707> if its faster just add define to toggle it?
[22:12:59 CEST] <atomnuker> durandal_1707: like I said we can just make our bitstream reader size be dependend on a define for the few codecs that could benefit from a larger/smaller one
[22:13:15 CEST] <atomnuker> but any codec which hardcore depends on reading performance does reading on its own
[22:13:22 CEST] <atomnuker> see dirac_vlc and dnxhd decoder
[22:13:47 CEST] <BBB> mpeg* also
[22:14:16 CEST] <BBB> even if you do it manually, there might be utility to having a bigger cache
[22:17:57 CEST] <thebombzen> alright I sent the patch
[22:25:48 CEST] <cone-560> ffmpeg 03Marton Balint 07master:7cfa98fd9460: configure: use c++11 and fallback to c++0x for c++ files
[22:25:48 CEST] <cone-560> ffmpeg 03Marton Balint 07master:c395d230b128: avdevice/decklink_enc: convert to std::atomic
[22:25:48 CEST] <cone-560> ffmpeg 03Marton Balint 07master:77d2cb88741a: avdevice/decklink: deprecate @mode syntax in device name to specify mode
[22:40:22 CEST] <iive> i've said it before, ffmpeg used to have a bitstream reader that used same principle as their new one. It was slowe on 32 bit so Mans removed it.
[22:56:54 CEST] <uau> i tested the new bitstream reader with vorbis on x86 - it was measurably slower, but OTOH decoding was still so fast that a significant portion of CPU was spent outside the codec (memory copying for packet handling and audio format conversion)
[22:57:24 CEST] <uau> so unless you're going to do micro-optimizations to speed up such non-decoding parts, it doesn't matter much IMO
[22:58:16 CEST] <atomnuker> everything matters on mips
[22:58:47 CEST] <kierank> uau: in something like vorbis bitstream reading is tiny
[22:59:01 CEST] <kierank> it's huffyuv, prores, dirac where it really matters
[22:59:47 CEST] <thebombzen> uh, so the patch I sent to the ffmpeg-devel mailing list needs "moderator approval" because I'm not subbed to the list
[22:59:48 CEST] <thebombzen> how does that work
[23:00:10 CEST] <thebombzen> would subbing to the list automatically grant "approval"
[23:00:29 CEST] <thebombzen> should I just sub and resubmit
[23:00:30 CEST] <PaoloP> ubitux, wm4 (and other people of the ffmpeg team): done. please, give a feedback when you can, so I can provide other useful snippets (in the same style)
[23:00:50 CEST] <thebombzen> is wm4 even on the ffmpeg team
[23:01:09 CEST] <BBB> thebombzen: yes
[23:01:14 CEST] <BBB> thebombzen: and yes, just sub and re-send
[23:01:15 CEST] <PaoloP> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209296.html
[23:01:16 CEST] <thebombzen> oh okay
[23:06:18 CEST] <wm4> there's no "team", just people who participate in development
[23:07:02 CEST] <ubitux> there is a voting comittee though :)
[23:07:09 CEST] <wm4> thebombzen: yes, subscribe to the list and you won't have to wait
[23:07:13 CEST] <ubitux> (and people with write access)
[23:07:42 CEST] <wm4> PaoloP: I'll look tomorrow
[23:08:26 CEST] <thebombzen> I canceled the previous one just to be safe
[23:08:30 CEST] <thebombzen> and yea I subbed and resent it
[23:10:08 CEST] <PaoloP> ok wm4 thanks
[23:11:01 CEST] <thebombzen> I just thought wm4 was the lead dev of mpv and thus had a lot of stake in the FFmpeg project
[23:11:08 CEST] <thebombzen> but by "the team" I meant maintainers
[23:11:49 CEST] <kierank> BBB: i agree, i don't have an objection to the technical changes behind the patch, but they just changed naming for no good reason
[23:12:02 CEST] <BBB> kierank: NIH ;)
[23:12:25 CEST] <BBB> thebombzen: wm4 is one member of the team of developers over here :)
[23:12:53 CEST] <kierank> BBB: don't attribute to NIH that which is adequately explained by madness
[23:13:24 CEST] <BBB> madness implies active malice, Im not sure about that
[23:13:37 CEST] <BBB> Im not saying it isnt, Im just saying Im not sure about it
[23:14:12 CEST] <BBB> e.g. most of the vp9 changes ubitux merged from them (thanks!) were just changes. they didnt make it better, they didnt make it worse. they just changed it for the sake of changing it
[23:14:31 CEST] <BBB> (so we merge it to keep the diff small, which is an OK reason on our side)
[23:15:13 CEST] <PaoloP> wm4: please, consider that the code is only 273 lines long. The transcode_aac.c is about 800 lines. I could provide another snippet which is equal to the one I posted + a decode block, so that transcoding is done, but with a much shorter (and hopefully clearer) code than the existing one
[23:16:11 CEST] <ubitux> goddamnit how were they able to run that dosemu thing
[23:17:54 CEST] <PaoloP> my idea is always to separate the blocks in a strict sequential and procedural way (demux --> decode --> resample --> encode --> mux). It's the only way to let the user of the API understand all the steps.
[23:23:02 CEST] <BBB> ubitux: wanna review the vp9 changes on the ML so I can push them? or busy w/ merge and want me to find some other victim?
[23:23:27 CEST] <ubitux> did something change from last time you asked me on irc?
[23:23:33 CEST] <BBB> also if any poor soul wants to review h264/hevc/frame_thread changes, please do! :)
[23:23:40 CEST] <BBB> ubitux: no
[23:23:46 CEST] <BBB> but ML has no review yet
[23:24:07 CEST] <ubitux> i can reply there if you want to proof of review
[23:24:18 CEST] <ubitux> but i won't have anything additionnal to say i guess
[23:24:31 CEST] <ubitux> i can still have a second look though
[23:24:41 CEST] <BBB> up to you, if you dont have time I can find someone else
[23:24:55 CEST] <BBB> Im just poking around to reduce my number of local patches
[23:25:01 CEST] <BBB> so I can look at more/additional tsan errors
[23:25:09 CEST] <BBB> we may actually be able to get it semi-clean this time
[23:29:44 CEST] <ubitux> i suppose it passes make checkheaders?
[23:30:09 CEST] <BBB> I actually had issues with that in one of the VDA files
[23:30:21 CEST] <BBB> I can send a separate patch for that
[23:32:09 CEST] <ubitux> honestly it looks pretty fine to me
[23:32:25 CEST] <ubitux> btw, i haven't check, but i think all the tables not shared should be local to the c-files
[23:32:49 CEST] <ubitux> but you may disagree due to object sizes
[23:33:08 CEST] <ubitux> anyway, you have my "OKed by ubitux on IRC"
[23:33:27 CEST] <BBB> but yes otherwise it passes make checkheaders
[23:34:08 CEST] <BBB> I agree it may be worth spilling around some vp9data.c tables[]
[23:34:15 CEST] <BBB> but I think that can be done separately
[23:34:42 CEST] <ubitux> sure
[23:35:06 CEST] <ubitux> michaelni: wanna have a look to the lavfi race fix?
[23:35:26 CEST] <ubitux> i just realized you did something very similar in lavc/pthread_slice.c
[23:36:32 CEST] <ubitux> BBB: do you need that Picture define? oO
[23:36:58 CEST] <BBB> I dont know, I copied it from vda.h
[23:37:05 CEST] <BBB> I have no idea how stuff like this works
[23:37:16 CEST] <BBB> I think the vda dude should review it ;)
[23:39:24 CEST] <wm4> thebombzen: no I don't
[23:39:49 CEST] <wm4> BBB: I have another patch for pthread_frame.c on the ML that could use another pair of eyes (sent it on monday)
[23:39:58 CEST] <BBB> subject?
[23:40:28 CEST] <wm4> Subject: [PATCH] pthread_frame: minor simplification to error handling
[23:40:32 CEST] <wm4> probably boring
[23:42:27 CEST] <BBB> wm4: yeah that looks good
[23:44:09 CEST] <ubitux> wait
[23:44:19 CEST] <ubitux> it's already in the skipheaders
[23:46:14 CEST] <ubitux> btw, i'm going to push the lavfi race fix
[23:46:18 CEST] <BBB> ok
[23:46:27 CEST] <ubitux> if anyone has thread related patches to push, now is the time
[23:46:33 CEST] <ubitux> as i'm going to trigger that tsan instance manually
[23:46:38 CEST] <BBB> I can push mine if you want
[23:46:41 CEST] <BBB> but no review yet
[23:47:00 CEST] <BBB> (hevc/h264)
[23:47:05 CEST] <BBB> I guess theyre small so I can review
[23:47:07 CEST] <BBB> er...
[23:47:08 CEST] <BBB> push
[23:47:23 CEST] <BBB> let me rebase after you push and Ill push
[23:48:09 CEST] <cone-560> ffmpeg 03Clément BSsch 07master:473f0f75a16b: lavfi: fix race when func rets holder is NULL
[23:55:46 CEST] <BBB> ubitux: any idea why SKIPHEADERS-yes isnt working?
[23:56:00 CEST] <ubitux> a previous install of these files?
[23:56:03 CEST] <ubitux> when it wasn't there
[23:56:52 CEST] <BBB> is it because of this line in common.mak? ../common.mak:SKIPHEADERS += $(ARCH_HEADERS:%=$(ARCH)/%) $(SKIPHEADERS-)
[23:57:01 CEST] <BBB> shouldnt that last one be $(SKIPHEADERS-yes)?
[23:59:02 CEST] <BBB> oooooooo
[23:59:03 CEST] <BBB> I get it
[23:59:15 CEST] <BBB> SKIPHEADERS- skips stuff for libraries I dont have installed
[23:59:23 CEST] <BBB> I do have VDA installed, since Im on mac
[23:59:28 CEST] <BBB> so then its _not_ skipped
[23:59:39 CEST] <BBB> so I think it needs to be moved from skipheaders-$(CONFIG_..) to SKIPHEADERS
[00:00:00 CEST] --- Wed Mar 29 2017