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

[burek]

[00:00:17 CET] <atomnuker> apparently it can support 1 packet in -> multiple frames out, its used by some audio codecs iirc
[00:00:50 CET] <atomnuker> or you could support only the new decoding api which allows for that without hacks
[00:00:50 CET] <wm4> AV_CODEC_CAP_SUBFRAMES doesn't really do anything
[00:01:23 CET] <wm4> it's only used for a weak check that prints a warning (which michaelni bullied me into porting, and which he since ignored, even though it triggers for some real files)
[00:02:24 CET] <atomnuker> should be deprecated then
[00:05:04 CET] <durandal_170> daddesio: if frame doesnt begin in new byte each time,  there its nothing you can do to support seeking
[00:05:29 CET] <michaelni> wm4, "which michaelni bullied" <-- patch review is not bullying (if that is what this refers to) Please dont randomly throw insults around
[00:05:33 CET] <daddesio> ^ without a reframer... :P
[00:05:51 CET] <daddesio> I forgot if it does, let me check.
[00:06:31 CET] <durandal_170> im being bullied on ml all the time
[00:07:42 CET] <daddesio> durandal_170: Within one SCDl packet, MicroTalk frames don't have to begin on a new byte. Across SCDl packets though, the bitstream reader is reset.
[00:07:50 CET] <daddesio> So seeking is possible, in theory.
[00:08:19 CET] <durandal_170> daddesio: yes, writing bit streamer filter would do it
[00:09:59 CET] <cone-639> ffmpeg 03Michael Niedermayer 07master:5e03eea673a9: avcodec/vp9: mark frame as finished on decode_tiles() failure
[00:10:00 CET] <cone-639> ffmpeg 03Steven Robertson 07master:2d131fc31bcd: avformat/movenc: Add support for more colorspaces
[00:11:18 CET] <jamrial> StevenLi_: the patch to remove the duplicate reverse arrays didn't get approved
[00:13:51 CET] <StevenLi_> looks like libavcodec and libavdevice, i will apply the patch build a same reverse.c into libavformat, now just be used for hlsenc.
[00:22:50 CET] <wm4> michaelni: demanding pointless things, giving short dismissals without explanation (like obscure command lines and just saying they "fail", you do that all the time), making up claims and insisting they're absolute, are
[00:24:15 CET] <wm4> michaelni: oh, also quoting private communication without consent
[00:24:50 CET] <michaelni> wm4, stop slandering me
[00:26:33 CET] <jamrial> calm down, please
[00:28:01 CET] <wm4> michaelni: which of those do you claim to be slander
[00:38:51 CET] <michaelni> wm4, i do not know why you keep attacking me and why you try to involve me into these disucssions which are completely off topic. The statements you make are the way you present them slander. I, like everyone is trying to improve FFmpeg and to do that found bugs are reported, issues found in patches are pointed out and so on. I havnt even replied to many mails from you recently IIRC. Can you please just stop with these 
[00:38:51 CET] <michaelni> attacks, iam interrested to work on the code not to be accused and insulted randomly
[00:40:19 CET] <wm4> sure, if you stop yours
[00:40:23 CET] <iive> wm4: what are you talking about? what is the private communication that michael has quoted?
[00:41:22 CET] <wm4> iive: he posted a line in a mailing post I sent to him privately in IRC (he didn't even respond on IRC)
[00:41:34 CET] <wm4> all to make me look bad
[00:41:42 CET] <iive> wm4: where and when?
[00:41:52 CET] <iive> i still have no idea what you are talking about.
[00:41:54 CET] <michaelni> this is slander --> <wm4> all to make me look bad
[00:42:17 CET] <wm4> it's not slander to point out your misbehavior
[00:43:04 CET] <michaelni> i have not done anything with the intend to make you look bad, saying that i did is slander
[00:43:14 CET] <wm4> michaelni: your obnoxious behavior and rejecting patches on minor bullshit almost made me leave this project
[00:43:37 CET] <iive> wm4: i still wait for your answer
[00:43:53 CET] <nevcairiel> if its so minor, maybe you should just change it in review =p
[00:43:57 CET] <wm4> iive: I'm not your personal google
[00:44:21 CET] <wm4> nevcairiel: well, someone else did some garbage just to make michaelni happy about his bullshit argument
[00:44:23 CET] <iive> wm4: i cannot google your personal private communication
[00:45:16 CET] <wm4> michaelni: don't forget that your behavior already caused a major fork... did you ever reflect upon that?
[00:45:47 CET] <nevcairiel> there is plenty blame to go around for that, its not on one person
[00:46:50 CET] <wm4> not sure why you feel the need to defend him
[00:48:06 CET] <iive> wm4: where and when has michael quoted your private communication.
[00:49:05 CET] <wm4> mailing list, probably around october or so?
[00:49:18 CET] <iive> what's the topic?
[00:49:35 CET] <wm4> iive: do you have any pets?
[00:50:17 CET] <iive> you want to know my secret pass phrase?
[00:51:00 CET] <iive> anyway, the fact that you are bringing back 2 months old issue, even if true tells me what I want to know.
[00:51:45 CET] <wm4> I'm not bringing back a 2 months old issue, you are
[00:51:53 CET] <wm4> I only cited it as example of past michaelni misbehavior
[00:52:13 CET] <wm4> and yes I'm clearly sick of his behavior
[00:52:42 CET] <iive> don't worry, it is not michael's fault.
[00:53:19 CET] <wm4> yes it is
[00:53:27 CET] <wm4> it's my fault for being bothered by it, of course
[00:53:54 CET] <iive> you've changed a lot and not for the better. You are burning out, fast.
[00:54:32 CET] <wm4> are you now an internet psychologist?
[00:54:38 CET] <iive> yes
[00:55:00 CET] <wm4> ok, please go to some offtopic channel
[00:55:45 CET] <iive> first calm down.
[11:13:31 CET] <JEEB> lol I should just post a patch to remove this thing
[11:13:32 CET] <JEEB> src/libavcodec/hevc_cabac.c:37:21: warning: variable 'num_bins_in_se' is not needed and will not be emitted
[11:13:45 CET] <JEEB> it's a static const
[11:29:52 CET] <cone-460> ffmpeg 03Martin Vignali 07master:49dced9fd0c8: avfilter/x86/vf_interlace : avoid crash when data are unaligned
[11:29:53 CET] <cone-460> ffmpeg 03Martin Vignali 07master:3c6dc270355f: avfilter/x86/vf_interlace : avfilter/x86/vf_interlace : fix crash when using unaligned data in low_pass complex
[12:53:17 CET] <Chloe> Am I able to get the fate samples without rsync?
[12:53:38 CET] <JEEB> yes
[12:53:45 CET] <JEEB> http://fate-suite.ffmpeg.org/
[12:54:05 CET] <BtbN> rsync is the more efficient way though, if you don't want just one sample
[12:54:29 CET] <Chloe> I'm behind an oppressive proxy it seems
[12:54:50 CET] <Chloe> I have a bunch of them downloaded, but I just wanted to update 
[12:56:47 CET] <Chloe> Just gonna wget --recursive it, I think my samples are all really old anyway (probably enough has changed to warrant a full dl)
[12:57:43 CET] <JEEB> Chloe: rsync can do HTTP IIRC
[12:57:50 CET] <JEEB> oh wait no
[12:57:51 CET] <JEEB> welp
[12:59:08 CET] <Chloe> I had thought there was a way to do rsync over HTTP but I couldn't find it, hence me just asking
[12:59:44 CET] <jkqxz> rsync needs support from the server to work (calculating the rolling checksums).
[13:00:33 CET] <jkqxz> The samples do not change, they are only added to (so that test runs on old versions still work).  You probably have most of it already, even with a version from a while ago.
[13:03:11 CET] <Chloe> `wget -r -np -R "index.html*" -nH -c http://fate-suite.ffmpeg.org/` should do it then I guess
[14:12:20 CET] <jdarnley> Is anyone here familiar with the Intel Software Development Emulator and its error messages?
[14:14:25 CET] <Compn> no but feel free to paste error :)
[14:14:50 CET] <jdarnley> I tried to run checkasm but got these three lines
[14:14:52 CET] <jdarnley> SDE ERROR: header_cm == header_bv
[14:14:52 CET] <jdarnley> Trackers are NYI, therefore CM should be the same as BV
[14:14:52 CET] <jdarnley>  at (no-file):303 Function (no-func)
[14:16:14 CET] <Compn> the trackers are nyi only gets one result in google
[14:16:18 CET] <Compn> https://stackoverflow.com/questions/47420032/when-can-i-call-xsaves-and-xsaves64
[14:16:25 CET] <Compn> fun error message for sure.
[14:16:45 CET] <jdarnley> I would guess that NYI stands for "not yet implemented" -- Oh good
[14:17:10 CET] <Compn> why would it abbreviate in the error message haha
[14:17:28 CET] <Compn> The plumbus FNI and BV and CM is RD.
[14:17:29 CET] <jdarnley> Perhaps they think only their internal devs will see this one
[14:18:00 CET] <iive> jdarnley: i've used sde, but it's errors are completely alien :D
[14:18:49 CET] <jdarnley> You don't think I need at least AVX for it do you?
[14:19:02 CET] <iive> jdarnley: does it work with some other program.
[14:19:15 CET] <jdarnley> hm, I didn't try
[14:19:28 CET] <iive> jdarnley: no, I used it to emulate avx on sse, and it managed quite well.
[14:19:53 CET] <jdarnley> `./sde64 -- $(which true)` worked
[14:21:10 CET] <iive> are you trying to run avx512 code?
[14:21:17 CET] <jdarnley> Not yet
[14:21:30 CET] <jdarnley> But I did plan to
[14:22:52 CET] <iive> what version of sde are you running?
[14:23:00 CET] <jdarnley> Oh great.  The link in the readme for "usage questions" send me to a read-only archived forum
[14:23:07 CET] <jdarnley> The latest I think
[14:23:25 CET] <jdarnley> 8.12 it says
[14:24:43 CET] <jdarnley> Maybe I'll write be own little program just to test these few instructions.
[14:25:55 CET] <iive> yeh, good idea.
[14:26:23 CET] <iive> also, try specifying different cpu.
[14:26:55 CET] <iive> the last version i've used is 8.4.0, so if you suspect regression, try it out.
[14:27:25 CET] <jdarnley> noted, thanks
[14:37:03 CET] <jdarnley> ls
[14:37:50 CET] <jdarnley> great, 8.4 segfaults
[14:52:37 CET] <Gramner> jdarnley: sde can be quite buggy, try a bunch of different versions
[15:00:47 CET] <jdarnley> oh
[15:16:30 CET] <iive> it's possible that the segfault and the error are caused by same issue, just (not) handled.
[15:17:00 CET] <iive> jdarnley: btw, have you tried all options in --help , something might work.
[15:19:23 CET] <Chloe> atomnuker: https://0x0.st/sX_y.patch passes fate, may not be insane code
[15:21:54 CET] <cone-460> ffmpeg 03Karthick J 07master:deceb7d9aeb7: avformat/hlsenc: Call avio_flush during persistent http connections
[15:21:55 CET] <cone-460> ffmpeg 03Karthick J 07master:6ae18228cd89: avformat/hlsenc: Handle NULL input in IO open and close utility functions
[15:21:56 CET] <cone-460> ffmpeg 03Karthick J 07master:b2d27d912ba9: avformat/hlsenc: Extend persistent http connections to playlists
[15:22:03 CET] <Chloe> Will post to ML if you think there's nothing really obvious I've missed 
[15:31:10 CET] <atomnuker> oh wow, do post to the ml then
[15:31:53 CET] <JEEB> do we have a thing like the oracle FATE system which libav has?
[15:32:02 CET] <JEEB> so that patches can be tested on the FATE machines before landing
[15:36:03 CET] <BtbN> I could setup the github mirror to do that with pull requests.
[15:36:15 CET] <BtbN> But that would be horribly confusing, as we still won't accept PRs
[15:37:00 CET] <BtbN> and it would only test on x86_64 linux
[15:37:03 CET] <BtbN> and maybe osx
[15:37:52 CET] <nevcairiel> Chloe: our compat wrappers dont define _Atomic, and the cast may not be safe
[15:37:55 CET] <JEEB> yea, in this case mingw-w64 and MSVC would be the most likely things to break anyways
[15:38:38 CET] <BtbN> I mean, it could cross-compile to windows. But not run tests.
[15:39:11 CET] <BtbN> https://oracle.libav.org/ looks rather dead anyway?
[15:41:30 CET] <Chloe> nevcairiel: ok I'll look into that 
[15:41:57 CET] <Chloe> I've only tested on macOS so far
[15:45:58 CET] <JEEB> BtbN: yea but I think they push stuff to it manually anyways
[15:46:12 CET] <JEEB> while automated building of patches would be cool, I don't think that's going to happen
[15:46:37 CET] <atomnuker> they'd spam the ml
[15:46:49 CET] <JEEB> so at this point it would be nice to have a thing where someone could push patches manually at request
[15:46:56 CET] <JEEB> like this atomic change
[15:47:29 CET] <BtbN> and make it run on the whole fate infra?
[15:49:24 CET] <Chloe> running this patch on the whole fate infra before it's pushed would probably be a good odea
[15:52:05 CET] <BtbN> we'd need an ffmpeg-oracle.git somewhere for that as well. And someone to hook it up to the fate infra
[16:02:28 CET] <JEEB> yea
[16:03:06 CET] <JEEB> so for now getting manual requests on from MSVC and mingw-w64 FATE'rs
[16:03:19 CET] <JEEB> and then linux at the very least
[16:05:00 CET] <wbs> JEEB: BtbN: the thing with fate-oracle is that you need to duplicate all the setup in all the fate clients as well; libav's oracle doesn't contain all the same instances as in the regular fate, only the ones that have been set up
[16:05:18 CET] <wbs> so for cronjobs/runloops/whatever, you need to have it first run jobs from normal fate then run jobs from oracle, etc
[16:05:37 CET] <JEEB> yup
[16:05:49 CET] <wbs> for my arm tests (which take many hours to run), I've only added the most relevant setups to it
[16:16:23 CET] <atomnuker> there's no way to disable arbitrary hwaccels/bsfs, right?
[16:18:30 CET] <jkqxz> Yes?  --disable-hwaccel=foo --disable-bsf=bar
[16:21:30 CET] <atomnuker> oh, great, print_enabled_components handles disabled ones
[17:48:08 CET] <Chloe> atomnuker: oh, I had a question. At the end of my test you see I just empty the atomics test, how can I remove that file completely? (cant see where it's being compiled from)
[17:48:26 CET] <atomnuker> what do you mean?
[17:50:33 CET] <Chloe> I think I'm being silly. Are all the files in libavutil/tests just compiled based off their filenames?
[17:50:45 CET] <Chloe> I may have not reconfigured when I tried to remove libavutil/tests/atomic.c
[17:59:59 CET] <jdarnley> You might need to run `make distclean` to get rid of the .d files too
[18:00:28 CET] <jdarnley> but all things to build should be listed in a makefile, usually in the directory next to them.
[18:06:11 CET] <cone-460> ffmpeg 03Jun Zhao 07master:d228d52f1cc9: lavc/vp8: Support resolution changes in the VP8 decoder hwaccel
[18:06:12 CET] <cone-460> ffmpeg 03Mark Thompson 07master:07e1bd7e2d7b: doc/libav-merge: Remove VAAPI VP8 decode hwaccel merge note
[18:40:34 CET] <cone-460> ffmpeg 03James Almer 07master:5450972be4a7: doc/libav-merge: remove line about VP9 superframe parsing
[20:10:04 CET] <Chloe> wm4: any idea how you'd make this work on windows?
[20:14:00 CET] <wm4> either some macro magic (don't know if this is possible?), or extra typedefs for each stdatomic wrapper (including standard stdatomic) for the argument type
[20:16:20 CET] <jamrial> i thought anyway that casting wasn't an option
[20:18:37 CET] <wm4> and I assume MSVC doesn't do GNU extensions like typeof or ({ ... })
[20:19:43 CET] <Chloe> I mean _Atomic can just be macro'd out
[20:20:21 CET] <Chloe> then it'll throw a warning for void ** -> intptr_t* but I dont see why it wouldnt work?
[20:21:45 CET] <wm4> oh right, this is for cases where the type is a pointer
[20:22:01 CET] <wm4> so even though it's a strict aliasing violation it could work
[20:22:53 CET] <Chloe> there's only 4 instances of it using cas and it's always a pointer
[20:23:44 CET] <Chloe> Gonna try setup a windows compile env and test it out
[20:24:07 CET] <nevcairiel> if anything _Atomic should probably be volatile
[20:24:18 CET] <nevcairiel> not just empty
[20:24:28 CET] <nevcairiel> but its hard to test if its really thread safe then
[20:24:58 CET] <Chloe> I read that volitile is bad when using atomics
[20:25:40 CET] <Chloe> keep in mind, I don't actually know much (or anything) about this (threading), I just wrote something that works and passes tests
[20:25:45 CET] <Chloe> volatile*
[20:26:36 CET] <JEEB> ok, so if I have an audio format that has a WAV format that has no header and instead just gets the stuff from the WAV header, and then a packet format which contains a header in each packet noting the specifics - how do I deal with this if the decoder in lavc currently just expects the stuff to be in the AVCodecContext already? what is the usual way of switching these sorts of packaging types that you 
[20:26:42 CET] <JEEB> can flag from the demuxer?
[20:27:38 CET] <JEEB> because I need a if (thing) { // handle header }
[20:27:42 CET] <JEEB> in the decoder
[20:28:39 CET] <JEEB> and during init I need to know that I shouldn't complain even if various values aren't already set
[20:32:22 CET] <Chloe> nevcairiel: mingw is just gcc right? so if it works on linux with gcc it should just work when cross-compiled with mingw
[20:32:35 CET] <Chloe> i.e. MSVC would be the issue, not mingw
[20:33:59 CET] <Chloe> I can't get MSVC (I don't have enough storage space on my windows computer). That is a problem with testing it
[20:34:41 CET] <nevcairiel> yeah mingw is just gcc
[20:34:42 CET] <BtbN> setup a git repo and use appveyor
[21:09:19 CET] <BtbN> michaelni, do you have some unusual umask set or how does that happen? For me the permissions are fine.
[21:09:57 CET] <SortaCore> Chloe: I have MSVC on windoze if you need some testing done
[21:11:02 CET] <Chloe> SortaCore: my atomics patch on the mailing list, I want to know how much it breaks with MSVC
[21:11:46 CET] <SortaCore> I'm not on ML, I have the empty-inbox character trait >.<
[21:15:27 CET] <jkqxz> SortaCore:  <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171215/d22a2d77/attachment.ksh>
[21:15:30 CET] <michaelni> BtbN, iam not sure its unusual but it of course limits access to what is needed
[21:16:49 CET] <SortaCore> ok, newb, how do I apply it?
[21:18:58 CET] <jdarnley> wget, maybe dos2unix, git apply
[21:21:17 CET] <SortaCore> just git apply attachment.ksh?
[21:21:51 CET] <SortaCore> and no requirements on configure to test it?
[21:21:56 CET] <jkqxz> git am
[21:22:13 CET] <jkqxz> It's a whole git patch, not just a diff.
[21:23:37 CET] <BtbN> michaelni, https://gist.github.com/1cc793c0aedb1eb9a5905ec77ab14e5f does this one work better?
[21:24:09 CET] <SortaCore> patch format detection failed
[21:25:43 CET] <SortaCore> it's in unix format
[21:28:55 CET] <michaelni> BtbN, this fixes the permissions, yes
[21:29:32 CET] <BtbN> it seems a bit odd that install does not have an option to create the path on demand
[23:31:12 CET] <SortaCore_> would you get patch format detection failed if you had modified your working copy?
[23:31:34 CET] <JEEB> depends on if the file was related
[23:32:00 CET] <SortaCore> that is a counter-intuitive error then
[23:32:13 CET] <JEEB> oh wait no
[23:32:21 CET] <JEEB> that does mean that the patch lacks something or is incorrect
[23:32:42 CET] <JEEB> what most often happens is that when you copy-paste a patch you lack the last line or something
[23:32:43 CET] <SortaCore> and it wouldn't be incorrect if you modified the line it was trying to replace?
[23:32:55 CET] <SortaCore> e.g. the from line
[23:33:28 CET] <JEEB> if the editing didn't touch anything else (such as save with CRLF or whatever) then no
[23:33:40 CET] <JEEB> or if it didn't clean up the last \n
[23:34:48 CET] <SortaCore> hm, and by editing, I mean editing the source file itself, not the patch
[23:35:19 CET] <JEEB> ok
[23:35:33 CET] <JEEB> then the patch is derp'd
[23:35:48 CET] <JEEB> if it's on patchwork I just curl and push it straight into git am
[23:36:03 CET] <JEEB> curl "URL" | git am
[23:36:16 CET] <JEEB> curl outputs to standard output, git am takes stuff in
[23:36:56 CET] <JEEB> the "download mbox" url in patchwork, https://patchwork.ffmpeg.org/patch/6795/ for example
[23:36:58 CET] <SortaCore> oddly, that worked
[23:37:07 CET] <SortaCore> curl | am
[23:37:12 CET] <JEEB> yup
[23:37:18 CET] <JEEB> little change of anything poking it the wrong way
[23:37:31 CET] <JEEB> *chance
[23:37:45 CET] <SortaCore> weird, I had used wget and tried both dos and unix line endings
[23:38:07 CET] <SortaCore> Chloe: I've done your patch
[23:38:20 CET] <SortaCore> running my usual configure
[23:39:07 CET] <Chloe> SortaCore: right, does it compile?
[23:39:16 CET] <Chloe> I assume it wont find stdatomic
[23:44:05 CET] <SortaCore> still configuring :p
[23:54:06 CET] <SortaCore> why doesn't make use multiprocessor by default?
[23:56:50 CET] <iive> SortaCore: last time I checked it had an option to run all jobs in parallel, even if they are few thousands...
[23:57:56 CET] <wm4> configure doesn't use make
[23:58:05 CET] <wm4> so that wouldn't help
[23:58:56 CET] <iive> or an option to spawn jobs until the cpu is not maxed out
[00:00:00 CET] --- Sat Dec 16 2017