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

[burek]

[00:08:37 CEST] <cone-577> ffmpeg 03Paul B Mahol 07master:3c6f70152413: avcodec/proresdec_lgpl: pass return values instead of discarding them
[00:32:46 CEST] <exastiken_> looks like my issue was an incomplete install of ffmpeg...
[00:38:00 CEST] <exastiken_> what is 'MPEG decompression' in the context of ffmpeg?
[00:38:09 CEST] <exastiken_> encoding/decoding?
[00:40:32 CEST] <JEEB> decoding
[00:40:44 CEST] <JEEB> decompressing compressed (in some way) data into raw samples
[00:43:29 CEST] <exastiken_> i have a yuv file; isn't that raw data?
[00:52:07 CEST] <mkav> Why does the x86 timer output decicycles and the arm timer outputs UNITS? What is the difference? What is a decicycle? 
[00:52:53 CEST] <mkav> trying to benchmark some performance across platforms and I'm kinda confused 
[00:55:08 CEST] <jdarnley> A decicycle is 1/10th of a cycle as implied by the deci prefix.
[00:57:39 CEST] <jdarnley> IIRC the final division is done to give a value 10x what the average of the recorded cycles would bve.
[01:00:49 CEST] <BBB> exastiken_: yes, a yuv file is raw data, but you still need to apply metadata to make sense of the data
[01:00:57 CEST] <BBB> (metadata as in width, height pixel format, bit depth, etc.)
[01:01:10 CEST] <BBB> otherwise its just another word document
[01:02:45 CEST] <JEEB> not an excel sheet?
[01:03:15 CEST] <BBB> whatever you want ;)
[01:03:20 CEST] <JEEB> :D
[01:03:36 CEST] <JEEB> excel just sends shivers down more people's spines as far as I've heard ;)
[01:04:14 CEST] <klaxa> really? we talked about how you can actually use excel for useful stuff while latex exists
[01:04:34 CEST] <JEEB> :D
[01:05:27 CEST] <JEEB> lol, new monitors from Eizo incorporating "AI" to keep the image stable with HDR
[01:05:50 CEST] <atomnuker> do they compress the image?
[01:06:48 CEST] <JEEB> huh, it seems like they apply it to the warmth sensor
[01:07:05 CEST] <JEEB> to apply color difference against the natural difference you get as the monitor gets hot
[01:09:56 CEST] <mkav> jdarnley thanks for the help, that makes sense. So what is a UNIT then? From my tests a UNIT seems to be a little over a third of a decicycle
[01:10:50 CEST] <jdarnley> No idea.  I dont do arm.  Probably a best effort attempt to get a cycle measurement since it sucks so much.
[01:12:58 CEST] <mkav> haha okay. thanks
[01:12:59 CEST] <atomnuker> mkav: you can't really convert (deci)cycles to time as on modern cpus frequency can change on every cycle
[01:13:35 CEST] <atomnuker> I don't think arm has a universal instruction like rtsc so the most accurate way to measure time seems to be linux's perf
[01:14:50 CEST] <mkav> okay, that makes sense. thanks atomnuker
[01:23:14 CEST] <exastiken_> Is there HEVC decoding?
[01:27:27 CEST] <Chloe> exastiken_: why would there not be HEVC decoding
[01:30:13 CEST] <exastiken_> Chloe: I don't see x265-related code in the source for decode or x265
[01:30:59 CEST] <exastiken_> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx265.c
[01:31:03 CEST] <Chloe> exastiken_: `ls libavcodec/hevc*`
[01:31:18 CEST] <Chloe> x265 is an external encoder
[01:31:37 CEST] <exastiken_> yes
[01:32:29 CEST] <Chloe> decoding is native
[01:32:45 CEST] <exastiken_> okay
[02:36:38 CEST] <klaxa> ah, duh i get 1000 fps because i use AV_TIME_BASE
[02:36:43 CEST] <klaxa> man, time is hard
[05:23:53 CEST] <cone-077> ffmpeg 03Steven Liu 07master:223f3dff8cd8: avformat/hls: remove redundant code
[07:32:19 CEST] <SimAV> Hi, ffmpeg has heavy memory leaks when reading from a DV/firewire camera: https://pastebin.com/RQTt5WBK
[07:33:15 CEST] <SimAV> for a 30 seconds video over 100 MB of memory leak which is (very close to) the total amount of data being sent by the DV camera in this time
[07:35:10 CEST] <SimAV> this makes streaming from a firewire-source unfeasible; on the other hand, reading from a USB webcam "-f video4linux2 -i /dev/video0" does not leak memory (according to valgrind).
[07:39:47 CEST] <SimAV> This makes me wonder whether its a bug in ffmpeg or in one of the libraries used by ffmpeg for DV/firewire sources.
[07:40:20 CEST] <SimAV> Ah, is this actually the correct channel to ask these questions or should I rather ask in #ffmpeg?
[07:44:54 CEST] <kierank> SimAV: open a ticket on trac
[07:59:18 CEST] <SimAV> kierank, I'm trying to register, but "create account" does not bring me to a new page (firefox says: "Waiting for trac.ffmpeg.org")
[08:36:03 CEST] <SimAV> kierank, ok, just took minutes(!)... 
[08:56:53 CEST] <SimAV> I'm happy to help finding the origin of this memory leak, so if anyone in here has some hints...
[10:57:40 CEST] <cone-314> ffmpeg 03Matt Oliver 07master:6be690685a88: ffplay: Fix realloc_texture when input texture is NULL.
[11:10:00 CEST] <JEEB> ...
[11:10:28 CEST] <JEEB> hlsenc uses ff_http_do_new_request for *files*
[11:11:22 CEST] <BtbN> Well, why not? Probably the least amount of duplicate code
[11:28:11 CEST] <JEEB> BtbN: it does have an else case for normal AVIO though, so it gets "interesting"
[11:28:21 CEST] <JEEB> also I think I found some nice boogs in it
[11:28:43 CEST] <nevcairiel> all this http shit is in there because people want to publish stuff right through http to a remote server with ffmpeg
[11:28:47 CEST] <nevcairiel> its all sorts of crappy
[11:30:02 CEST] <JEEB> well I more or less am OK with that, it's just really weird when you output to a file and get that message which is coming from http
[11:30:14 CEST] <JEEB> even though the function seems to have an if/else thing there
[11:30:33 CEST] <JEEB> also ff_http_do_new_request seems to check if protocol is http or https and if not AVERROR EINVAL
[11:31:03 CEST] <JEEB> so it is a bit like "what is this; I don't even"
[12:34:59 CEST] <debianuser> About that "FFMPEG ALSA CPU usage" ticket... I've helped debugging a similar issue for someone, and we noticed some weird sleep times there, e.g. usleep(1000) was sleeping at least 20000-30000us. As a test we used a simple shell one-liner:   for i in `seq -w 100`; do time sleep .$i; done
[12:36:23 CEST] <debianuser> I thought ffmpeg sleeps while waiting for new data, and if sleep/usleep is not precise enough it may be waiting in a busy loop, thus causing 100% CPU usage. At least that was the idea.
[12:37:00 CEST] <debianuser> (arecord uses snd_pcm_wait, which internally uses poll()ing to wait for new data, that's why the issue wasn't happening for arecord.)
[12:40:17 CEST] <debianuser> I don't know ffmpeg code good enough so I didn't dug deeper, but maybe that'd provide a hint for someone else...
[12:52:12 CEST] <Chloe> nevcairiel: clang-cl detection is properly broken
[13:10:24 CEST] <nevcairiel> Chloe: yeah i dont know how to fix it either, if you pipe the output then the interactive shit goes away and it just dumps all the help, but the pipe eats the return value so the entire check falls apart, so... i'll just revert it tomorrow or so when noone responds
[13:11:39 CEST] <Chloe> nevcairiel: run it twice? >.<
[13:28:31 CEST] <atomnuker> durandal_1707: do you know of any way for clients to get af_replaygain info without sniffing the console output?
[13:29:47 CEST] <atomnuker> there's AV_FRAME_DATA_REPLAYGAIN but I think the sanest way to do it would be to delay the output of the filter by one frame
[13:30:04 CEST] <atomnuker> until the last frame is reached, and then add that side data to the last frame
[13:31:13 CEST] <atomnuker> will the AVFrame *in argument of filter_frame be null to flush like encoders?
[13:34:56 CEST] <durandal_1707> in is never NULL in filter_frame
[13:35:28 CEST] <atomnuker> dang
[13:35:32 CEST] <durandal_1707> sniffing console output is better than sniffing last frame metadata
[13:36:41 CEST] <atomnuker> we have quite a few of these filters with which you have to do that, I think it might be worth designing some callback for clients to get the data directly
[13:36:49 CEST] <durandal_1707> anway there should be way to manipulate format metadata and sidedata from lavfi
[13:37:37 CEST] <durandal_1707> atomnuker: feel free to add it to your long TODO list of stuff not finished yet
[13:37:42 CEST] <atomnuker> there is, you can change both
[13:37:55 CEST] <atomnuker> just not for a filter which needs the entire stream
[13:37:58 CEST] <Chloe> atomnuker: yes the new detect vfr needs this
[13:38:25 CEST] <atomnuker> durandal_1707: hey I did finish something, cyanrip is now feature complete (except for replaygain but oh well)
[13:38:37 CEST] <durandal_1707> Chloe: what?
[13:39:17 CEST] <durandal_1707> atomnuker: that is old replaygain algo, there is newer one...
[13:39:19 CEST] <Chloe> durandal_1707: it only prints at the end, no? I havent looked at the code in a while
[13:40:03 CEST] <durandal_1707> Chloe: and where would it set that info?
[13:41:16 CEST] <Chloe> No idea, I believe thats what atomnuker is saying
[13:41:33 CEST] <atomnuker> durandal_1707: there's a new replaygain algo?
[13:43:29 CEST] <durandal_1707> atomnuker: yes, but i think its mentioned on hydrogenaudio
[15:14:56 CEST] <nevcairiel> dont people just use ebu r128 with a 5db offset for replaygain
[15:38:24 CEST] <atomnuker> nevcairiel: btw were you referring to "Could not read complete segment" errors when demuxing hls yesterday?
[15:44:51 CEST] <atomnuker> oh, wait, this was fixed today in 03:23 utc
[16:01:57 CEST] <nevcairiel> that would just be a warning without consequences anyway
[16:02:51 CEST] <nevcairiel> seems like some issues were caused by the internal avio api change that nicolas pushed through without taking responsibility for making sure it works properly, so 6 months later or so shit still breaking
[16:03:36 CEST] <JEEB> because all protocols of a certain type should be able to receive 8 byte packets
[16:03:45 CEST] <JEEB> (IIRC the original patch only touched UDP by the guy)
[16:11:38 CEST] <jamrial> nevcairiel: what msvc breakage? the bcrypt stuff?
[16:11:43 CEST] <nevcairiel> no
[16:11:46 CEST] <nevcairiel> the clang-cl fix
[16:11:49 CEST] <nevcairiel> entirely breaks configure
[16:12:06 CEST] <nevcairiel> i'm just going to push a revert in a couple hours if noone speaks up
[16:12:14 CEST] <nevcairiel> i had no smart ideas how to fix it, but my shell foo is rusty
[16:13:20 CEST] <nevcairiel> (and technically i'm listed as a maintainer for MSVC build system, so even if that list is mostly bogus, the written rules give me that right :p)
[16:13:36 CEST] <JEEB> I'd just go with it, it's been a few hours already right?
[16:14:42 CEST] <jamrial> nevcairiel: 9fd11e5188? maybe just revert the second change, the msvc specific one, and leave the clang one as is
[16:14:59 CEST] <nevcairiel> the change is really only meaningful with both
[16:15:31 CEST] <jamrial> alright
[16:15:44 CEST] <nevcairiel> because its supposed to skip the first one and then enter the second one
[16:17:03 CEST] <nevcairiel> can you group && || conditions in shell?
[16:17:27 CEST] <nevcairiel> right now its doing A || B && C and still executing C if A is true
[16:17:29 CEST] <nevcairiel> which we dont want
[16:17:40 CEST] <nevcairiel> so we really want A || (B && C)
[16:17:43 CEST] <jamrial> with brackets, yeah
[16:17:51 CEST] <SimAV> nevcairiel, round brackets are correct
[16:17:59 CEST] <jamrial> look at the part with checks for external libraries
[16:18:06 CEST] <nevcairiel> guess that might work to solve it then
[16:18:10 CEST] <nevcairiel> let me test
[16:19:03 CEST] <nevcairiel> hm i also see examples with curly brackets
[16:25:20 CEST] <SimAV> nevcairiel, see points 3 and 4b of https://stackoverflow.com/a/2188223
[16:26:47 CEST] <nevcairiel> sounds like curlys are better for less overhead of a new subshell
[16:28:02 CEST] <SimAV> nevcairiel, I don't know at which place you are placing the brackets, but I think its rather about side effects than performance/overhead
[16:28:40 CEST] <nevcairiel> they seem to do the same thing though, and there is no sideeffect to be had
[16:29:08 CEST] <SimAV> nevcairiel, have a look at point 3: after the closing ), the working directory is the same as before the opening (
[16:31:11 CEST] <nevcairiel> yeah thats where subshells are useful, but this doesnt change any state or whatever, just want to properly group conditions
[16:31:28 CEST] <nevcairiel> so i'll j ust go with {}
[16:31:36 CEST] <SimAV> nevcairiel, curly braces have the maybe(? at least IMO) unexpected syntactical peculiarity, that you need a ; before the }
[16:32:04 CEST] <SimAV> at least it seems so when trying here in bash...
[16:32:15 CEST] <nevcairiel> its in an if condition, there was an odd semicolon there anyway, it just moved
[16:34:58 CEST] <nevcairiel> i sent a patch to the ML if someone wants to quickly cross-check it
[16:35:11 CEST] <SimAV> nevcairiel, is there a ML archive somewhere?
[16:35:28 CEST] <nevcairiel> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228417.html
[16:39:55 CEST] <SimAV> nevcairiel, looks good (at least from gnu bash point of view). I'm not sure whether there are shells, that always expect a ; before the then
[16:41:02 CEST] <SimAV> (the "odd" one (as you said) I would actually call absolutely common)
[16:41:55 CEST] <nevcairiel> as I understand it he braces make the semicolon unnecessary because it already clearly terminates the command
[16:43:08 CEST] <SimAV> nevcairiel, yes. I think it is ok.
[16:43:33 CEST] <SimAV> I'm just not 100% sure.
[16:50:33 CEST] <Thirumalai_K> from 9e2b4c7ecc3014310d01e918800f7f7f36596598, I am getting segfault 11 when trying to play a dash stream (http://yt-dash-mse-test.commondatastorage.googleapis.com/media/car-20120827-manifest.mpd)
[16:50:46 CEST] <Thirumalai_K> using ffplay
[16:59:56 CEST] <Thirumalai_K> logout
[17:08:10 CEST] <SimAV> I was finally able to pin the massive memory leak when reading from firewire (via libiec61883) down to the commit which introduced that regression (see https://trac.ffmpeg.org/ticket/7146#comment:2 ).
[17:08:33 CEST] <SimAV> Can anyone give me a hint how to proceed?
[17:09:04 CEST] <nevcairiel> the demuxer should probably be allocating reference counted buffers
[17:09:49 CEST] <nevcairiel> due to the nature of those device things actually needing hardware, they often go untested for long periods of time, unfortunately
[17:09:57 CEST] <SimAV> it seems as if 'somewhere' code still relies on deprecated (and since 3.0 not available) stuff
[17:10:52 CEST] <nevcairiel> iec61883_callback allocates the data right, so instead of making a plain malloc call, it should probably be using av_buffer* functions
[17:10:53 CEST] <SimAV> nevcairiel, I would like to help there, if I'm able to... I'm just not at all into ffmpeg
[17:11:07 CEST] <nevcairiel> and accordingly  pass that buffer around later w hen making the AVPacket
[17:12:59 CEST] <nevcairiel> the problem seems to be that it uses avpriv_dv_produce_packet for that, which is sort of locked in ABI
[17:14:03 CEST] <SimAV> nevcairiel, I'm still unable to find iec61883_callback or iec61883.c
[17:14:17 CEST] <nevcairiel> its in libavdevice/
[17:14:58 CEST] <jamrial> nevcairiel: we can technically still deal with that if we do it before 4.0 is tagged
[17:15:18 CEST] <jamrial> might be pushing it a bit, though
[17:16:18 CEST] <nevcairiel> the dv demuxer is like one of the last ones that dont produce refcounted pkts
[17:16:25 CEST] <SimAV> nevcairiel, ah, thanks. I was still on a commit close to the regression, there the file was not available...
[17:16:47 CEST] <nevcairiel> and the dv device uses the demuxer functions
[17:18:38 CEST] <jamrial> would making avpriv_dv_produce_packet() create a refcounted packet be enough? should be trivial, although it would result in data copy
[17:19:04 CEST] <nevcairiel> that would solve it if you also free the origin data in iec61883.c then
[17:19:09 CEST] <nevcairiel> but yeah copy
[17:19:21 CEST] <nevcairiel> can fix now optimize later i guess
[17:20:35 CEST] <SimAV> jamrial, yes, DV/HDV is less than 30 Mbit/s. I guess there are very few systems out there, which have a firewire port and can't handle this better than diverging ram usage
[17:23:05 CEST] <durandal_1707> kierank: send me only bounty related mails
[17:23:07 CEST] <jamrial> nevcairiel: if the data is allocated by iec61883.c and not used by anything but to make these packets, then av_packet_from_data() can be used to avoid copy
[17:23:43 CEST] <nevcairiel> jamrial: well except that it uses that dv function to make the pkt, not sure how much it needs from that or modifies the pointer or whatever, didnt study it in detail
[17:24:19 CEST] <jamrial> i mean making avpriv_dv_produce_packet() generate the packet that way. it would require all callers to behave the same, though
[17:24:48 CEST] <jamrial> would have been nicer if this was known earlier :/
[17:26:10 CEST] <SimAV> jamrial, I'm verry sorry. I found the diverging ram usage a year ago, but had no time (nor ideas how) to find the reason
[17:27:06 CEST] <SimAV> and as this was on gentoo linux back then, I wasn't even sure whether this is something related to ffmpeg or some borken tinkering at the rest of the system :/
[17:30:10 CEST] <jamrial> it's fine, just thinking out loud
[17:45:03 CEST] <SimAV> jamrial, nevcairiel, is the memleak unique to iec61883 or common to multiple parts of the code dealing with dv packets?
[17:45:26 CEST] <SimAV> or is this something i should (and could) test somehow?
[17:47:13 CEST] <nevcairiel> seems to be isolated to that part of the code
[17:49:56 CEST] <jamrial> mmh, looks like making avpriv_dv_produce_packet take ownership of the data passed to it while creating the packet is feasible
[17:50:10 CEST] <nevcairiel> not entirely
[17:50:14 CEST] <nevcairiel> the dv demuxer uses a static buffer
[17:53:30 CEST] <nevcairiel> and if changes in the calling code are required thats also an ABI change, so also awkward
[17:53:32 CEST] <jamrial> the RawDVContext one? should be easy to replace with an av_malloc'ed one
[17:54:03 CEST] <jamrial> well, we still haven't tagged 4.0, but yeah, might be pushing it a bit
[17:55:06 CEST] <SimAV> jamrial, personally speaking I would be already absolutely happy if I had a patch ;)
[18:16:23 CEST] <cone-314> ffmpeg 03Paul B Mahol 07master:396c01979567: avfilter/avf_avectorscope: disable mirroring
[18:39:46 CEST] <kierank> durandal_1707: ok
[18:43:04 CEST] <durandal_1707> who knows anything about vc1?
[18:43:49 CEST] <atomnuker> isn't it basically cut down h264?
[18:53:17 CEST] <jamrial> SimAV: can you try https://pastebin.com/xDn5k2Gr ?
[18:53:38 CEST] <jamrial> atomnuker: vc1 is wmv3
[18:54:56 CEST] <atomnuker> I remember reading some paper about converting h264 to vc1 without decoding, maybe I'm misremembering
[18:58:35 CEST] <SimAV> jamrial, yes, just a (few) minute(s)
[19:09:50 CEST] <durandal_1707> atomnuker: is main profile in vc1 supported?
[19:11:24 CEST] <atomnuker> I think so, the advanced profile is supported
[19:11:42 CEST] <SimAV> jamrial, definitely lost: 33,264 bytes in 10 blocks instead of definitely lost: 18,321,264 bytes in 137 blocks
[19:11:46 CEST] <SimAV> (for a 5 seconds video)
[19:12:30 CEST] <SimAV> jamrial, this heavily improves the situation
[19:13:03 CEST] <jamrial> yes, but shows that something else is leaking other than packet data
[19:13:16 CEST] <jamrial> can you post the backtrace for that leak?
[19:15:04 CEST] <atomnuker> durandal_1707: I think interlacing was broken with vc1, is that what you're looking to fix
[19:16:06 CEST] <kierank> Wow Carl
[19:16:11 CEST] <kierank> Fuck carl
[19:16:53 CEST] <durandal_1707> atomnuker: no, main profile, there is also simple, complex and advanced
[19:17:11 CEST] <wm4> haha
[19:17:19 CEST] <wm4> cute tantrum
[19:20:13 CEST] <SimAV> jamrial, I will...
[19:25:30 CEST] <SimAV> jamrial, would you like to post your patch in the bugtracker, too?
[19:29:17 CEST] <SimAV> jamrial, up to tag n2.9-dev only 72 bytes leaked (for 5 seconds of input data, didn't check whether this grows over time as it was sufficiently little for me)
[19:29:39 CEST] <SimAV> so the current situation is worse than before
[19:30:10 CEST] <SimAV> Ah, I will check whether the leak with your patch is linear in the duration of the input data
[19:30:21 CEST] <jamrial> i'll post a patch to the ml once i get one that fixes all leaks if possible
[19:37:28 CEST] <SimAV> jamrial, I uploaded the new valgrind outputs to the bugtracker
[19:38:00 CEST] <SimAV> but at the moment these are meaningless for a third reader as your current version of the patch is not there
[19:39:26 CEST] <SimAV> jamrial, some very good news: the remaining memory leak seems to be constant in time now (it doesn't matter whether i take 5 or 30s of input video data)
[19:39:40 CEST] <jamrial> you could have posted those to pastebin instead. you'll indeed confuse cehoyos (who replied to that ticket before)
[19:39:53 CEST] <SimAV> before, the leak was linear in time
[19:40:16 CEST] <nevcairiel> minimal init leaks, apparently
[19:40:17 CEST] <jamrial> but yeah, my patch fixes the leak in iec61883.c, so it can go in as is
[19:40:36 CEST] <jamrial> main leak, rather
[19:41:23 CEST] <jamrial> dv->dv_demux is not being freed on close
[19:41:27 CEST] <jamrial> that's the 32k leak
[19:43:26 CEST] <jamrial> the other two are insignificant, and from avc1394_* functions
[19:43:52 CEST] <jamrial> that's external. maybe also missing a call to some external uninit function?
[19:49:05 CEST] <SimAV> jamrial, have to leave now, but I'll be back in two hours or so
[19:49:55 CEST] <SimAV> if you have a new patch, please paste it in the bugtracker, then I'll try it when I'm back and paste the resulting valgrind output
[20:07:46 CEST] <nevcairiel> hm interesting find, disabling persistent http connections actually makes HLS work much smoother
[20:08:39 CEST] <nevcairiel> tmm1: any idea why http_persistent would make hls glitch out sometimes (ie. deliver data too slow), but disabling it is fine? Playing from twitch
[20:11:53 CEST] <JEEB> o_O
[20:11:56 CEST] <JEEB> wow
[20:12:36 CEST] <tmm1> hmm thats strange
[20:12:43 CEST] <tmm1> how about -http_multiple 0 -http_persistent 1
[20:12:56 CEST] <nevcairiel> i tried that first, didnt help
[20:13:38 CEST] <tmm1> hm, so then its a problem with http_multiple and not persistent?
[20:13:50 CEST] <tmm1> (if turning multiple off still works fine)
[20:14:26 CEST] <nevcairiel> multiple off and persistent on still shows the glitching, so not sure how you got that from that :)
[20:17:04 CEST] <tmm1> sorry i misunderstood, didn't help = still broken
[20:17:13 CEST] <tmm1> i haven't had my coffee yet
[20:17:31 CEST] <nevcairiel> multiple=1 persistent=0 also w orks fine
[20:17:36 CEST] <nevcairiel> buffer stays constantly filled
[20:17:54 CEST] <nevcairiel> when i turn persistent on, it goes almost empty all the time, and sometimes it goes empty and playback breaks
[20:18:14 CEST] <BtbN> nevcairiel, my first guess would be Twitch CDN stuff
[20:18:50 CEST] <BtbN> Don't they give every segment a new domain by having a random part in it anyway?
[20:19:20 CEST] <nevcairiel> domain seems pretty constant
[20:19:32 CEST] <nevcairiel> although it differs for the m3u8 and the segments
[20:19:56 CEST] <nevcairiel> every second request i get a message that the server closed the connection though
[20:20:08 CEST] <nevcairiel> i wonder if maybe keepalive just doesnt work properly with tls_schannel for reasons i dont understand
[20:20:34 CEST] <BtbN> well yeah, if they enforce closing the connection, maybe even send a Connection: close header, ffmpeg trying to re-use it would explain the issues
[20:20:38 CEST] <nevcairiel> so maybe its timing out on some pipelined requests
[20:20:43 CEST] <sfan5> mpv --stream-lavf-o="http_multiple=0,http_persistent=1" <twitch stream> should reproduce this, correct?
[20:20:46 CEST] <sfan5> because I'm not seeing it here
[20:21:45 CEST] <BtbN> I can also totally see Twitch having their own hacks http server with a hard timeout on connections, because their own implementations don't re-use connections
[20:22:22 CEST] <tmm1> does someone have a url i can try
[20:23:05 CEST] <nevcairiel> i just use https://pwn.sh/tools/getstream.html and paste some twitch page in there
[20:23:11 CEST] <tmm1> nevcairiel: its not even really pipelined, the first request completes and then it sends a new request on the same socket
[20:23:35 CEST] <BtbN> youtube-dl -g https://twitch.tv/rocketbeanstv
[20:23:50 CEST] <BtbN> gives something insane like https://video-weaver.fra02.hls.ttvnw.net/v1/playlist/CtICKmKhr7A5IsE7AOvKbdkL7flUku50JsSoP6s4GPeY-wxDcKu07itbAHaTwhS1yUVJnsdsAsD_0GBnPdqUw27nnq8gwLqzxRSjhne5jDODVPpMZSFwe9JecOlcKtJA_qs0OJ1FhV4Va2C0XnLPUoy95QQd_9XLr8fPLGPGsz6L-JooWcW-SRcQkWv78zUR9Jw4Li_6cBrN6Q-pLvA0PViOB5daTwW0iJjUxj9sF6QpcDXThS0WEBfkDP0Y-Z3hF7OCrfPAunPxVK33AHGM-BWJfQOHNNgwAdOIZuwQI_uuAkp5uUg6OIDQ3G9Srm4e1tCQX4V1dMhX3ovmJp6wEnKo0VBd3kjfF1Z4l4BCaa_4fnSYW-4
[20:23:50 CEST] <BtbN> 0zWFoUUEix9x6CF6VJOU51E5rn5AH90-4WLDSDn3UOsFzKfZyrlG-GZqvuLOd5swH53nh1lq5toaFd6jcoFoSEJuaF9U-pRtiJQLIBdF-czoaDPP7u7qJbr72ogZjgA.m3u8
[20:23:57 CEST] <nevcairiel> yeah those links are too long to paste
[20:24:14 CEST] <BtbN> I still wonder what the point of making them so damn long is
[20:25:00 CEST] <nevcairiel> it seems to be working for like 2 segments or so and then the connection dies
[20:25:13 CEST] <nevcairiel> no clue if thats possibly this tls implementation or just twitch not being happy
[20:25:14 CEST] <tmm1> no errors here on mac (tls_securetransport)
[20:25:21 CEST] <nevcairiel> unfortunately i cant easily exchange that
[20:25:58 CEST] <BtbN> it could also just be your local CDN endpoint taking a dump
[20:26:06 CEST] <tmm1> are you using http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228409.html
[20:26:17 CEST] <nevcairiel> yes, thats me
[20:26:22 CEST] <nevcairiel> without that it just breaks entirely
[20:27:33 CEST] <cone-314> ffmpeg 03Carl Eugen Hoyos 07master:9d6c1687642c: lavd/vfwcap: Pass pointers to int instead of long to av_parse_video_size().
[20:28:43 CEST] <cone-314> ffmpeg 03Carl Eugen Hoyos 07master:30270561608a: lavc/dxva2_internal: Cast the dxva2 and d3d11 decoders and cfgs to (void *).
[20:29:14 CEST] <nevcairiel> hm i might have found another spot where it needs eof changes
[20:30:11 CEST] <nevcairiel> lets see
[20:30:18 CEST] <JEEB> quite possibly
[20:31:27 CEST] <nevcairiel> hm nah didnt help
[20:31:34 CEST] <nevcairiel> but still  more correct to do that
[20:32:14 CEST] <tmm1> is it fine on non-twitch streams?
[20:32:21 CEST] <nevcairiel> dunno
[20:32:25 CEST] <nevcairiel> dont have any handy
[20:34:12 CEST] <tmm1> try https://bitdash-a.akamaihd.net/content/sintel/hls/video/4000kbit.m3u8
[20:36:01 CEST] <nevcairiel> that seems fine, minimal queue drops and no connection closed messages in the log
[20:37:01 CEST] <tmm1> hmm
[20:37:15 CEST] <nevcairiel> maybe it is twitch and i should just turn off persistent
[20:37:49 CEST] <tmm1> could be. if you were able to try another tls impl in a linux vm or something it would narrow down to twitch/cdn vs schannel
[20:38:42 CEST] <tmm1> the code should already be detecting Connection:close headers, so it seems its advertising http/1.1 but then closing connections for some reason
[20:39:10 CEST] <tmm1> tbh it does sound like a tls issue.. there were strange issues like last year when tls_securetransport had some bugs
[20:39:38 CEST] <tmm1> hls.c could also maybe detect N failures and turn off persistent automatically
[20:54:11 CEST] <nevcairiel> i'll just turn it off for now until i  have more time to investigate different s etups
[21:00:35 CEST] <JEEB> hah, just as I was contemplating on if I should write a thing on trac regarding how broken the webm mode in dashenc.c is (segfaults at init), akamai conveniently posts patches that try to hide the fact that the webm mode is broken by moving VP9 to MP4
[21:01:06 CEST] <JEEB> -25
[21:20:23 CEST] <wm4> holy fuck
[21:20:36 CEST] <wm4> dashdec.c just gets code committed that makes no sense and has obvious issues
[21:21:27 CEST] <nevcairiel> of course, its "maintainers" are this subgroup that just ok each others patches =p
[21:21:45 CEST] <durandal_1707> ban them
[21:21:47 CEST] <JEEB> chinaffmpeg and akamai, was it?
[21:22:10 CEST] <nevcairiel> akamai is mostly dashenc, not so much dec
[21:22:33 CEST] <nevcairiel> much of that is contract work though I imagine
[21:23:57 CEST] <jamrial> chinaffmpeg is hlsenc and dashdec, it seems
[21:23:59 CEST] <wm4> at least "ptr = av_malloc(); \n memcpy(ptr, ...);" should have been seen by anyone who actually looked at the damn patch
[21:24:21 CEST] <jamrial> Steven Liu is who introduced dashdec, for that matter
[21:24:22 CEST] <wm4> and the compiler warning which cehoyos tried to fix is also about code that makes no damn sense at all
[21:24:45 CEST] <wm4> well this particular code was pushed by steven lia and authored by... someone
[21:25:11 CEST] <nevcairiel> his reviews  seem to be mostly just waving stuff through
[21:25:17 CEST] <jamrial> yes, i mean he introduced the demuxer, so no wonder he pushed those patches
[21:25:39 CEST] <wm4> actually looking at the patches before pushing would be appreciated
[21:25:39 CEST] <jamrial> should have actually tested/properly reviewed them first, though, yes
[21:26:05 CEST] <durandal_1707> it depends on xml, it is code dump, run away and ignore it
[21:26:44 CEST] <jamrial> ah yes, dashdec is what finally got ffmpeg to link to libxml2 :p
[21:26:45 CEST] <nevcairiel> yeah i dont build with dashdec because of the xml crap
[21:26:55 CEST] <nevcairiel> dont want to carry around that dependency
[21:27:18 CEST] <wm4> could at least have used a slightly better xml lib
[21:27:47 CEST] <JEEB> also I wish people wouldn't just "how do I FATE test?" when I mention those meta demuxers or muxers should get FATE tests :<
[21:27:47 CEST] <wm4> also I thought the patch was blocked on av_xml
[21:28:35 CEST] <atomnuker> I thought xml2 was the best, is expat better?
[21:28:46 CEST] <nevcairiel> they are all some breed of crap
[21:28:56 CEST] <nevcairiel> libxml2 is pretty standard though
[21:28:59 CEST] <wm4> expat seems slightly saner, although using it probably also needs crazy code
[21:40:49 CEST] <durandal_1707> huh? why vc1 return P type frames that are also keyframes?
[21:44:04 CEST] <atomnuker> key_frame = 1 && frame_type == P?
[21:44:09 CEST] <durandal_1707> yes
[21:44:14 CEST] <atomnuker> is that out from the parser
[21:44:21 CEST] <atomnuker> I'd check the parser
[21:44:59 CEST] <nevcairiel> vc1 has pretty simple reference structure like mpeg2, every I frame is basically a random entry point
[21:45:46 CEST] <nevcairiel> in the decoder, key_frame is also set accordingly
[21:45:50 CEST] <nevcairiel> s->current_picture.f->key_frame = s->pict_type == AV_PICTURE_TYPE_I;
[21:47:10 CEST] <nevcairiel> (although vc1 also has those BI frames that are intra-coded but not references)
[22:33:54 CEST] <durandal_1707> this guy needs lobotomy
[22:35:25 CEST] <cone-314> ffmpeg 03Marton Balint 07master:768c0774d82c: avdevice/decklink_commmon: enhance error messages when iterator creation fails
[22:44:39 CEST] <wm4> there should be consequences for such behavior
[22:44:49 CEST] <wm4> what's next, are we starting a revert war on git
[22:47:53 CEST] <nevcairiel> apparently carl is incapable of understanding the difference between decoding and pixel format conversion
[22:53:50 CEST] <kierank> Carl is like that cinepak guy
[22:56:58 CEST] <wm4> also lol nicolas george only replying to me indirectly
[23:00:02 CEST] <SimAV> jamrial, thank you very much for the patches, I consider #7146 resolved. The remaining 72 bytes memory leak (independent of video duration) seems to have happened within living memory...
[23:00:31 CEST] <SimAV> and of course thanks to everyone else who helped here!
[23:07:27 CEST] <wm4> huh he suddenly decided to reply, all is well I guess
[23:29:59 CEST] <wm4> why am I even trying to discuss with him
[23:45:48 CEST] <wm4> and it ended as expected
[00:00:00 CEST] --- Thu Apr 19 2018