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

[burek]

[00:40:54 CEST] <BtbN> All the remaining EOF fixes are bugfixes anyway, so can be easily backported to 4.0
[01:07:36 CEST] <durandal_1707> llvm-cov is nice!
[01:07:46 CEST] <JEEB> yup
[01:07:47 CEST] <wm4> what does it do
[01:08:00 CEST] <durandal_1707> the ffmpeg does not support 6 version at all?
[01:08:00 CEST] <JEEB> code coverage
[01:08:25 CEST] <durandal_1707> it use lcov crap
[01:09:00 CEST] <JEEB> wm4: https://llvm.org/docs/CommandGuide/llvm-cov.html
[01:09:11 CEST] <durandal_1707> need this to add for cflags and ldflags: -fprofile-instr-generate -fcoverage-mapping
[01:09:16 CEST] <JEEB> yup
[01:09:22 CEST] <JEEB> you compile and then just run your app
[01:09:36 CEST] <JEEB> it will save instrumentation data
[01:09:52 CEST] <JEEB> then llvm-cov gcov will convert that into human-readable stuff
[01:10:48 CEST] <JEEB> or actually the stuff that durandal_1707 just noted will probably already output what llvm-cov show can handle?
[01:10:52 CEST] <JEEB> and not gcov files
[01:11:56 CEST] <durandal_1707> it can also 'report' and 'show'
[01:12:14 CEST] <JEEB> yup
[01:12:22 CEST] <durandal_1707> just pipe to less, no need for html
[01:13:21 CEST] <wm4> so does it show how often each line of code got run?
[01:13:29 CEST] <wm4> or just whether it was
[01:13:29 CEST] <durandal_1707> yes
[01:14:34 CEST] <JEEB> I think it should be able to show counts as well?
[01:14:41 CEST] <JEEB> since the data should have that at least
[01:15:12 CEST] <wm4> sounds interesting
[01:15:36 CEST] <wm4> I don't remember why I hated the gnu version of this, but I do
[01:53:06 CEST] <jamrial> don't we have an lcov toolchain option in configure?
[01:53:25 CEST] <jamrial> if that llvm one isn't supported, we could add it
[01:54:23 CEST] <jamrial> yeah, we do. but the cflags it uses are not the same as the ones durandal_1707 mentioned
[02:52:30 CEST] <atomnuker> wm4: which pixfmt hwcontext patch of yours was jkqxz talking about
[02:52:59 CEST] <atomnuker> the one which apparently exposed mapping between native fmts and avpixfmts
[03:17:41 CEST] <cone-314> ffmpeg 03Stephan Holljes 07master:37175122824d: lavf/tcp.c: Free allocated client URLContext in case of error.
[03:17:42 CEST] <cone-314> ffmpeg 03Jacob Trimble 07master:f7221d8e670e: avformat/mov: Increase support for common encryption.
[03:54:08 CEST] <cone-314> ffmpeg 03James Almer 07master:b8629654c646: avdevice/iec61883: return reference counted packets
[03:54:09 CEST] <cone-314> ffmpeg 03James Almer 07master:5079e96bcc7a: avdevice/iec61883: free the private context at the end
[04:11:16 CEST] <cone-314> ffmpeg 03Marton Balint 07release/3.0:3c056989dc57: avdevice/iec61883: free packet on buffer allocation error
[04:11:17 CEST] <cone-314> ffmpeg 03James Almer 07release/3.0:b949fd7a6540: avdevice/iec61883: return reference counted packets
[04:11:18 CEST] <cone-314> ffmpeg 03James Almer 07release/3.0:29683c6ba1fc: avdevice/iec61883: free the private context at the end
[04:11:23 CEST] <cone-314> ffmpeg 03Marton Balint 07release/3.1:13deb0c1f6af: avdevice/iec61883: free packet on buffer allocation error
[04:11:24 CEST] <cone-314> ffmpeg 03James Almer 07release/3.1:86d6fca94be7: avdevice/iec61883: return reference counted packets
[04:11:25 CEST] <cone-314> ffmpeg 03James Almer 07release/3.1:ac1ddc6361f3: avdevice/iec61883: free the private context at the end
[04:11:30 CEST] <cone-314> ffmpeg 03Marton Balint 07release/3.2:1fd992af6045: avdevice/iec61883: free packet on buffer allocation error
[04:11:31 CEST] <cone-314> ffmpeg 03James Almer 07release/3.2:53803ef71c79: avdevice/iec61883: return reference counted packets
[04:11:32 CEST] <cone-314> ffmpeg 03James Almer 07release/3.2:27fc118d1c79: avdevice/iec61883: free the private context at the end
[04:11:35 CEST] <cone-314> ffmpeg 03James Almer 07release/3.3:bc07879bc5e4: avdevice/iec61883: return reference counted packets
[04:11:35 CEST] <cone-314> ffmpeg 03James Almer 07release/3.3:003be3e49ede: avdevice/iec61883: free the private context at the end
[04:11:39 CEST] <cone-314> ffmpeg 03James Almer 07release/3.4:4264723b0eba: avdevice/iec61883: return reference counted packets
[04:11:40 CEST] <cone-314> ffmpeg 03James Almer 07release/3.4:a877ab75eb8f: avdevice/iec61883: free the private context at the end
[04:11:44 CEST] <cone-314> ffmpeg 03James Almer 07release/4.0:d52676da3802: avdevice/iec61883: return reference counted packets
[04:11:45 CEST] <cone-314> ffmpeg 03James Almer 07release/4.0:d9e9e97e5f47: avdevice/iec61883: free the private context at the end
[09:57:44 CEST] <cone-102> ffmpeg 03Hendrik Leppkes 07master:638575cd0ba4: configure: fix clang-cl check in the MSVC section
[09:59:07 CEST] <cone-102> ffmpeg 03Hendrik Leppkes 07release/4.0:a73b464118a7: configure: fix clang-cl check in the MSVC section
[10:14:54 CEST] <wm4> atomnuker: hm I think that was a relatively trivial one that provided two generic entrypoints to convert between native and avpixfmt
[10:39:37 CEST] <JEEB> has anyone tested the webm mode in dashenc, ever? has it ever worked? :D
[10:39:48 CEST] <JEEB> it seems to have been crashing for a very long time
[10:40:15 CEST] <durandal_1707> crashing?
[10:40:22 CEST] <JEEB> yes, segfaults
[10:40:33 CEST] <JEEB> you can see my reply to the akamai person who wanted to silently switch just VP9 to MP4
[10:41:06 CEST] <JEEB> which, yes, will make the segfault go away
[10:41:15 CEST] <JEEB> (and it actually can be played in firefox, chromium and edge)
[10:41:24 CEST] <JEEB> (after the profile string addition, at least)
[10:41:44 CEST] <JEEB> but I would say that if nobody can remember when that stuff actually worked, maybe we should just remove the webm mode from dashenc.c
[10:42:24 CEST] <JEEB> (there's a separate WebM "dash" muxer which probably gets more attention?)
[10:44:53 CEST] <JEEB> (me explaining the crash: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228433.html ), (akamai dude saying that even with the crash fixed it still isn't playable http://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228479.html )
[10:46:15 CEST] <wm4> JEEB: daemon404 afaik
[10:46:34 CEST] <wm4> (he regretted it)
[10:48:56 CEST] <JEEB> yes
[10:49:04 CEST] <JEEB> I know he spotted a lot of issues with it
[10:49:12 CEST] <JEEB> but I think that was dashenc in general
[10:51:56 CEST] <robUx4> nevcairiel: ping
[10:52:05 CEST] <nevcairiel> robUx4: ?
[10:52:29 CEST] <robUx4> is there a way to avoid bursts of frames in DVXA when using multiple threads
[10:52:42 CEST] <nevcairiel> dont use multiple threads
[10:52:55 CEST] <robUx4> not an option for us :/
[10:53:05 CEST] <robUx4> otherwise my problem would be solved
[10:53:06 CEST] <nevcairiel> thats too bad, i don't concern myself with sub-optimal usecases
[10:53:19 CEST] <robUx4> but it's odd the way it seems to be working
[10:53:50 CEST] <wm4> "bursts"?
[10:54:13 CEST] <robUx4> each thread seem to feed a frame to the GPU at the same time (minus the mutex, so they go one after the other)
[10:54:18 CEST] <wm4> robUx4: also maybe ypou shouldnjust fix your code
[10:54:29 CEST] <robUx4> here's a capture of what's happening in the GPU https://drive.google.com/open?id=1Q_0ZamI_w8cBtzwHlSUh2uVClOpwd6kR
[10:54:39 CEST] <wm4> yeah sounds like that is correct
[10:54:56 CEST] <robUx4> wm4: it's a design issue
[10:55:04 CEST] <nevcairiel> so fix the design
[10:55:06 CEST] <wm4> it's how multithreaded mode works, and the hwaccel stuff serializes it
[10:55:26 CEST] <nevcairiel> we've been saying for years that mt+hwaccel is bad, plenty time to fix it
[10:55:51 CEST] <robUx4> that causes display issues because the GPU gets overloaded, even though it's only using 30% of its capacity
[10:56:04 CEST] <wm4> nice gpu...
[10:56:09 CEST] <nevcairiel> how would it get overloaded, it should just go slower
[10:56:13 CEST] <robUx4> it's the same with NVIDIA
[10:56:37 CEST] <robUx4> frames appear later than they should
[10:57:40 CEST] <wm4> unless you either 1. fix the vlc code to not use mt for hw, 2. make it possible to change the # of threads on demand in lavc, or 3. litter it with dumb sleep calls, you can't fix it
[10:57:42 CEST] <nevcairiel> are you using a recent version of ffmpeg? the way this is serialized was changed somewhat recently
[10:57:49 CEST] <wm4> I believe these are your options
[10:58:18 CEST] <robUx4> eaff5fcb7cde8d1614755269773d471d3a3d1bfc
[10:58:43 CEST] <nevcairiel> that should be in that
[10:59:04 CEST] <wm4> maybe 4. make mt mode behave more like single threaded mode in mt (sounds as bad as 3.)
[11:00:42 CEST] <wm4> #define AVERROR_HTTP_NOT_FOUND     FFERRTAG(0xF8,'4','0','4')
[11:00:45 CEST] <robUx4> when we start feeding libavcodec data we don't know if it's going to decode in HW or not
[11:00:51 CEST] <wm4> man, seriously....
[11:01:04 CEST] <robUx4> (and that varies between the libavcodec versions)
[11:01:13 CEST] <robUx4> so we se FF_THREAD_FRAME
[11:01:14 CEST] <wm4> also does 0xF8 make it unsigned
[11:01:25 CEST] <robUx4> *set
[11:01:27 CEST] <wm4> (after the averr "-")
[11:02:08 CEST] <robUx4> by the time avcodec tells us it can do d3d11va_vld it's too late, we can't change it, can we ?
[11:02:10 CEST] <wm4> robUx4: generally you'll know after feeding it 1 packet in single threaded mode
[11:02:48 CEST] <wm4> start with hw, if hw not possible recreate lavc with mt+sw
[11:02:52 CEST] <nevcairiel> i usually start in hwaccel-enabled mode (ie. single threaded), and if hwaccel isnt possible with that stream i just re-start everything in  mt software mode
[11:03:06 CEST] <robUx4> and we lose all the precious data that were fed before
[11:03:15 CEST] <nevcairiel> works pretty reliable for me
[11:03:15 CEST] <wm4> like what
[11:04:15 CEST] <robUx4> how much frames do I have to buffer before it outputs something ?
[11:04:30 CEST] <wm4> 1 to reach get_format
[11:04:30 CEST] <nevcairiel> you dont need to wait for output, just get_format
[11:04:45 CEST] <nevcairiel> and if the first frame is valid, it will get called
[11:04:51 CEST] <nevcairiel> (and if its invalid, nothing lost)
[11:05:14 CEST] <wm4> I even used to return an error in get_format on fallback, but that broke sometimes (shitty error code paths in lavc), so now I let it decode the packet
[11:05:23 CEST] <wm4> slightly annoying, but not much
[11:05:34 CEST] <robUx4> I see
[11:05:43 CEST] <robUx4> I'll give that a try
[11:05:45 CEST] <nevcairiel> now more interestingly, why does this mac build of avformat give me broken pgs packets when demuxing mkv (much smaller and generally invalid) but this windows build from the same revision works fine
[11:05:51 CEST] <wm4> strictly speaking I don't wait for a frame being decoded though
[11:06:24 CEST] <nevcairiel> I also let it decode the packet but set a flag in my own code to re-create stuff after avcodec API returns
[11:06:30 CEST] <nevcairiel> error paths are annoying
[11:08:49 CEST] <robUx4> BTW I just discovered that the GPU analyzer in VS17 can be used with other apps that the ones built with VS17
[11:08:52 CEST] <robUx4> very handy
[11:09:34 CEST] <durandal_1707> there is no way to skip frames with ffmpeg?
[11:09:36 CEST] <robUx4> you can see VSync, all the commands to the GPU
[11:09:50 CEST] <robUx4> how long they take
[11:51:36 CEST] <Chloe> durandal_1707: there's not a vf_drop filter?
[11:55:34 CEST] <durandal_1707> Chloe: i want to copy frames, not to transcode/filter them
[12:00:10 CEST] <wm4> nevcairiel: can't confirm that the eof bug was added to ffmpeg 3.4
[12:00:58 CEST] <wm4> haha damn even the avio example had to be fixed after the change
[12:55:50 CEST] <wm4> lol everyone is suddenly fine with public API breakages
[12:56:05 CEST] <nevcairiel> it was broken ages ago and already released that way once
[12:56:10 CEST] <nevcairiel> doing it again serves no purpose
[12:56:18 CEST] <nevcairiel> other then your crusade
[12:56:23 CEST] <wm4> no it wasn't released
[12:56:28 CEST] <nevcairiel> it is in 3.4
[12:56:35 CEST] <wm4> didn't see it there
[12:57:10 CEST] <wm4> also "crusade", what can I do, we're finding new bugs every month, since half a year ago
[12:57:15 CEST] <wm4> this change was obviously very broken
[12:57:26 CEST] <wm4> first thing it did was break a bunch of API users (including mpv)
[12:58:11 CEST] <wm4> and jesus michaelni's bullshit arguments
[12:58:17 CEST] <wm4> well whatever
[12:58:50 CEST] <wm4> not like I want to spend too much of my time fighting resisting bullshit
[12:59:38 CEST] <wm4> but one thing is clear: especially the TLS thing still don't handle EOF _and_ 0 sized reads correctly
[12:59:58 CEST] <nevcairiel> tcp doesnt do 0 sized reads anyway
[13:00:14 CEST] <durandal_1707> report bug(s) to carl's bug tracker?
[13:00:51 CEST] <wm4> I know, I fixed the avio tcp protocol myself (which was _also_ broken by the change)
[13:18:50 CEST] <wm4> how delicious, the change wasn't even noted in APIchanges
[13:19:29 CEST] <JEEB> nevcairiel: I think arch linux actually patched it into 3.4
[13:19:36 CEST] <JEEB> don't think it's in the official 3.4
[13:19:38 CEST] <JEEB> but I may be wrong
[13:20:02 CEST] <JEEB> that said, I am of the opinion that if we start reverting now we might get even more issues because of trying to find all the places
[13:22:48 CEST] <klaxa> aren't all the avio reads() on URLContexts? can't that just get an is_eof field instead of changing the return code?
[13:23:09 CEST] <klaxa> probably a dumb idea, but i'd like to know why
[13:24:23 CEST] <JEEB> yea, 858db4b01fa2b55ee55056c033054ca54ac9b0fd doesn't seem to be in release/3.4
[13:24:28 CEST] <nevcairiel> that wouldnt really fix anything tho, since you would still need to change interpretation
[13:25:26 CEST] <wm4> the current problem is that code inconsistently interprets 0 as EOF or as "normal read that just returned 0 bytes"
[13:25:35 CEST] <wm4> and that is both within ffmpeg, and API users
[13:25:38 CEST] <wm4> it's a big mess
[13:25:49 CEST] <wm4> I just looked into reverting iut, 
[13:25:54 CEST] <wm4> ...but that's also a big mess
[13:25:56 CEST] <JEEB> yes
[13:26:01 CEST] <wm4> basically it's fucked
[13:26:23 CEST] <JEEB> unfortunately either we eat our big mess and have bug reports, or try to revert and most likely get bug reports the other way
[13:26:47 CEST] <wm4> wouldn't have happened if the first EOF change would have been thoroughly reviewed (I'm sure nicolas would also interpret that as personal attack and lose it, but whatever)
[13:27:14 CEST] <JEEB> unfortunately, that train already rolled past
[13:27:32 CEST] <cone-102> ffmpeg 03Hendrik Leppkes 07master:5c6365af454f: avformat/tls_schannel: fix handling of EOF after avio changes
[13:27:59 CEST] <cone-102> ffmpeg 03Hendrik Leppkes 07release/4.0:0b6de235b98c: avformat/tls_schannel: fix handling of EOF after avio changes
[13:28:25 CEST] <JEEB> nevcairiel: great
[13:29:17 CEST] <nevcairiel> for some reason hls http_persistent still doesnt work with schannel though, but it seems to be isolated to twitch for some reason, so might as well be a remote problem
[13:30:29 CEST] <JEEB> yea
[13:32:20 CEST] <wm4> klaxa: actually we have an eof_reached flag too
[13:33:35 CEST] <klaxa> huh, indeed
[13:41:47 CEST] <nevcairiel> interesting, now i rebuild avformat for windows and i get the same broken pgs subtitles that i got on mac before
[13:41:49 CEST] <nevcairiel> wtf is going on
[13:42:30 CEST] <nevcairiel> oh i know
[13:42:42 CEST] <nevcairiel> they are zlib compressed but its missing zlib
[13:42:53 CEST] <nevcairiel> it should probably error out instead of giving them to me anyway
[13:44:02 CEST] <JEEB> yes
[13:44:08 CEST] <JEEB> missing dep is missing dep
[13:44:28 CEST] <nevcairiel> thats what i get for using --disable-autodetect and  not turning those back on :D
[13:47:54 CEST] <wm4> lol
[13:48:01 CEST] <wm4> that's what you get for extreme ifdeffery
[13:48:10 CEST] <wm4> "obscure" configurations just behave buggy
[13:50:05 CEST] <wm4> so where's the 4.0 release
[13:50:16 CEST] <durandal_1707> patience
[13:53:53 CEST] <nevcairiel> ultimately the bug was in my build script, a message would've probably just saved me 20 minutes of wondering
[13:54:23 CEST] <nevcairiel> or maybe there was a message and i just didnt p ay attention? i should check the logs
[13:54:47 CEST] <nevcairiel> "Unsupported encoding type" maybe? not very verbose of a message
[13:55:17 CEST] <nevcairiel> yeah thats it
[13:56:37 CEST] <cone-102> ffmpeg 03Matthieu Bouron 07master:67d0911f27e2: avcodec/mediacodecdec_common: make stride and slice-height non-mandatory fields
[14:17:13 CEST] <cone-102> ffmpeg 03Gyan Doshi 07master:424836505fba: doc/muxers: tee muxer - rearrange, add notes and general tidy-up
[14:26:18 CEST] <cone-102> ffmpeg 03Matthieu Bouron 07release/4.0:9b7111424797: avcodec/mediacodecdec_common: make stride and slice-height non-mandatory fields
[17:01:02 CEST] <cone-102> ffmpeg 03Vittorio Giovara 07master:fbfee6adea61: aac: Rework extradata parsing code
[18:56:22 CEST] <durandal_1707> michaelni: can i bush deblock filter with deblock as name, please?
[19:12:09 CEST] <nevcairiel> why would you not? do we have a filter with that name already?
[19:20:37 CEST] <michaelni> durandal_1707, you can, i just dont think its the ideal name as there are many deblock filters already (in the various postprocess filters for example)
[19:21:09 CEST] <michaelni> its as if we have 10 deinterlace filters and then add a deinterlace filter
[19:23:07 CEST] <durandal_1707> michaelni: there is only pp
[19:23:33 CEST] <durandal_1707> and it is gpl
[19:24:02 CEST] <michaelni> fspp, pp, pp7, spp, uspp at least
[19:24:13 CEST] <wm4> good names
[19:24:33 CEST] <nevcairiel> yeah i would no idea to even look at those when i'm looking for deblocking
[19:24:34 CEST] <nevcairiel> :D
[19:24:54 CEST] <michaelni> yes that is the problem
[19:25:06 CEST] <iive> they also do deringing and denoising
[19:25:09 CEST] <wm4> well if I see vf_deblock I'd sure think it does deblocking
[19:25:36 CEST] <michaelni> yes butyou still wont find the others
[19:25:40 CEST] <iive> what algorithm is using this new deblocker ?
[19:26:05 CEST] <durandal_1707> michaelni: no, thos are fancy post processer, ah, and snow :(
[19:26:13 CEST] <durandal_1707> iive: read ml
[19:26:30 CEST] <iive> durandal_1707, go to the forest then.
[19:27:49 CEST] <michaelni> i think if theres a "deblock" filter it should allow access to all deblock filters we have in the codebase or at least point to them. As people correctly noticed "deblock" is the one people will find
[19:28:51 CEST] <wm4> are you afraid it marginalizes your pp filters or what
[19:29:00 CEST] <wm4> there's also a vf_scale and nobody complains
[19:30:47 CEST] <iive> and somebody else his filter to be called THE deblock.
[19:30:56 CEST] <iive> and somebody else wants his filter to be called THE deblock.
[19:31:07 CEST] <iive> this cuts both ways.
[19:31:37 CEST] <wm4> why don't we name filters after generated GUIDs
[19:31:40 CEST] <wm4> no conflicts!
[19:31:52 CEST] <durandal_1707> dedumb-ification
[19:32:06 CEST] <iive> i'm asking for the algorithm, because it is kind of custom to use the algorithm in the filter name.
[19:32:30 CEST] <nevcairiel> not every algorithm has a popular name
[19:32:30 CEST] <iive> so, ai-deblock or something.
[19:32:49 CEST] <iive> nevcairiel, it doesn't have to be popular, it just has to be catchy ;)
[19:36:28 CEST] <iive> if it is original algorithm we can call it paul-deblock 
[19:37:15 CEST] <durandal_1707> it is modified: A Simple and Efficient Deblocking Algorithm for Low Bit-Rate Video Coding
[19:38:58 CEST] <durandal_1707> and i really do not like *pp* filters, and i compile ffmpeg with libpostproc disabled
[19:39:44 CEST] <iive> spp is great
[19:39:58 CEST] <wm4> "no"
[19:41:17 CEST] <durandal_1707> gpl is not great
[19:41:27 CEST] <durandal_1707> for most of our users
[19:41:31 CEST] <iive> durandal_1707, seda sound catchy
[19:42:42 CEST] <iive> GPL is the greatest.
[19:43:39 CEST] <atomnuker> durandal_1707 / michaelni: you can just call it loopfilter or vf_loop
[19:43:44 CEST] <atomnuker> loopfilter == deblock
[19:44:18 CEST] <nevcairiel> give it more obscure names that users will never understand, good idea
[19:44:44 CEST] <atomnuker> no, pretty much anyone who deals or has dealt with or knows how encoding works will know what a loopfilter is
[19:45:02 CEST] <atomnuker> then again, can't be worse than vf_transpose vs vf_rotate
[19:45:08 CEST] <iive> atomnuker, doesn't loopfilter include deringing too?
[19:45:16 CEST] <atomnuker> no
[19:45:27 CEST] <michaelni> a loopfiter is a filter that is excuted in the hybrid MC/prediction/difference coding loop. so it would generally be part of a codec
[19:50:08 CEST] <durandal_1707> iive: seda sounds bad
[19:50:52 CEST] <wm4> btw. do ffmpeg encoders or muxers support parameter changes? (for muxing it'd mean updating extradata midstream if needed/supported)
[19:51:26 CEST] <nevcairiel> some encoders support a limited set of changes (basically just libx264, and only a few properties can change)
[19:52:02 CEST] <wm4> I mean you also could just recreate the encoder, and keep muxing what you get back
[19:52:45 CEST] <atomnuker> michaelni: just like a deblocking filter
[19:53:13 CEST] <atomnuker> I don't mind vf_deblock though, I'd prefer that
[19:53:22 CEST] <durandal_1707> atomnuker: there is already vf_loop, and it does looping, like name says and no deblocking :/
[19:53:24 CEST] <nevcairiel> muxers is a bit tricky, if you consider h264 you could ensure on the encoding side that different parts get a diffeernt sps id and the muxer could then append both into the extradata block, but there is a lot of things that need to go right for that to be possible
[19:53:56 CEST] <iive> durandal_1707, i bet you would have liked it more, if it was your idea :P
[19:54:03 CEST] <nevcairiel> (but its also not supported, i dont think)
[19:55:10 CEST] <nevcairiel> of course ffmpeg-based tools wont mind if you just concat stuff as logn as in-band headers are available
[19:55:27 CEST] <iive> it's still better than asaedaflbrvc
[19:55:47 CEST] <wm4> I mean in theory mkv has elements for extradata update, dunno about mp4
[19:55:59 CEST] <wm4> but in-band would be easier anyway
[19:56:06 CEST] <nevcairiel> mp4 writes its header at the end, it can deal with such things
[19:56:25 CEST] <nevcairiel> not sure anyone supports the mkv extradata update elements
[19:56:27 CEST] <wm4> I never understood how it's supposed to work in mkv
[19:56:29 CEST] <nevcairiel> because they are just never used
[19:56:32 CEST] <wm4> heh
[19:56:47 CEST] <durandal_1707> iive: we need to compete with vs and avs and they have deblock filter
[19:57:05 CEST] <wm4> vs and avs also have proper scripting languages
[19:57:16 CEST] <wm4> relatively speaking, at least
[19:57:17 CEST] <nevcairiel> vs is just python, they cheat
[19:57:32 CEST] <wm4> how so
[19:57:38 CEST] <nevcairiel> using an existing language
[19:57:40 CEST] <nevcairiel> thats for beginners
[19:57:43 CEST] <wm4> because they don't NIH some broken shit like avs?
[19:57:45 CEST] <nevcairiel> real developers invent their own
[19:58:15 CEST] <wm4> well good thing ffmpeg has real devs then
[19:58:20 CEST] <nevcairiel> indeed
[19:58:25 CEST] <nevcairiel> only inventing our own things here
[19:58:35 CEST] <wm4> so we get really really long filter graphs for trivial things
[19:59:20 CEST] <nevcairiel> the filtergraph syntax gets insane when you process multiple streams at the same time
[19:59:43 CEST] <nevcairiel> but luckily i dont really care about filtering much
[19:59:53 CEST] <nevcairiel> only simple cases, and only API usage where I feed single streams
[20:00:39 CEST] <JEEB> also you really don't want to have different things in a single filter chain
[20:01:02 CEST] <JEEB> it leads to side effects because of one of the inputs changing and causing a re-init in the whole filter chain
[20:01:59 CEST] <durandal_1707> JEEB: what?
[20:02:59 CEST] <JEEB> durandal_1707: like that subtitle issue I had being caused by an audio reconfig
[20:03:12 CEST] <JEEB> ffmpeg.c just happened to have video and audio in the same filter chain
[20:03:29 CEST] <JEEB> because you can't make multiple filter chains with filter complex
[20:03:31 CEST] <JEEB> as far as I can see
[20:05:48 CEST] <jamrial> atomnuker: vf_loop will more likely than not make people think it's to loop video or such
[20:27:31 CEST] <Chloe> nevcairiel: we should just have a lua api or something for filter graphs
[20:28:12 CEST] <Chloe> I mean, you could probably just write an fffilter program which does this
[20:28:18 CEST] <atomnuker> yeah, definitely, durandal_1707 wrote something like that 2 years ago iirc
[20:28:54 CEST] <Chloe> simplify filtering for the end user as we'd stop inventing our own weird language
[20:42:25 CEST] <wm4> it's probably pretty hard to fit lavfi into a scripting language
[20:42:38 CEST] <wm4> VS for one was designed with scripting in mind from the very start
[20:42:52 CEST] <wm4> and avs probably too, if you can use the word "design"
[20:42:57 CEST] <nevcairiel> well of course, thats its entire point, a scriptable filter system
[20:43:46 CEST] <nevcairiel> lavfi "grew" and wasnt really designed as much
[20:43:48 CEST] <wm4> and lavfi has some sort of pseudo-scripting (simplistic expression evaluation) which does not make it easier
[20:44:47 CEST] <wm4> so it's not really clear how to use a scripting language to make it more powerful
[21:36:06 CEST] <BBB> imagine my shock when I just saw an email with env vars in the title
[21:39:59 CEST] <nevcairiel> same old deal, someone wants to control some application that doesnt implement some option
[21:40:24 CEST] <BBB> I know, its just shocking how they always end up at the same solution
[21:40:44 CEST] <BBB> I need a tweak, so I used a hammer and smacked it up
[21:41:25 CEST] <wm4> apparently it's about chromium
[21:41:34 CEST] <wm4> easier to get a hack into ffmpeg than making them fix their code?
[21:42:50 CEST] <BBB> I think they want to be able to use 50-year old ffmpeg versions from a system install on some linux distribution
[21:42:55 CEST] <nevcairiel> i'm sure the chrome people dont actually want anyone to change how their decoder works
[21:42:56 CEST] <BBB> and so they cant use any of our api
[21:42:57 CEST] <BBB> at all
[21:43:09 CEST] <nevcairiel> chrome ships ffmpeg
[21:43:21 CEST] <nevcairiel> its firefox that has to rely on all sorts of crappy system installed versions for some reason
[21:43:22 CEST] <BBB> chrome does
[21:43:29 CEST] <BBB> chromium wants to be able to use system versions, no?
[21:43:39 CEST] <nevcairiel> probably only because distributions are insane
[21:43:45 CEST] <BBB> of course
[21:43:54 CEST] <BBB> so heres a patch to add env var tracking to ffmpeg
[21:43:56 CEST] <BBB> :-p
[21:45:32 CEST] <wm4> nevcairiel: considering changing the decoder can make it crash (lol), probably
[21:45:52 CEST] <nevcairiel> even if it didnt, they are pretty peculiar about the workings of the decoder
[21:46:09 CEST] <nevcairiel> and honestly, i wouldnt want my app to suddenly behave differently based on some env vars
[21:46:23 CEST] <JEEB> yup
[21:46:30 CEST] <BBB> I can just see how support forums will go
[21:46:42 CEST] <BBB> add this line in your ~/bashrc: export FFMPEG_BLA_BLA=magic
[21:46:47 CEST] <BBB> it will fix all your issues"
[21:47:27 CEST] <nevcairiel> i dont compile any alternative decoders in my binaries i ship, but if i did, i might not want to suddenly have some hardware decoder in there when i expect the software one, users often dont know what they do
[21:53:17 CEST] <cone-535> ffmpeg 03Jacob Trimble 07master:606c5c7f3ad1: avformat/mov: Fix memory leak in encryption info.
[21:53:17 CEST] <cone-535> ffmpeg 03Jacob Trimble 07master:baf9c0bd99d9: avformat/mov: Remove old encryption info methods.
[21:53:17 CEST] <cone-535> ffmpeg 03Rahul Chaudhry 07master:b22db4f465c9: swresample/arm: remove unintentional relocation.
[21:56:40 CEST] <wm4> hm "curse of action", that's a typo
[22:03:15 CEST] <cone-535> ffmpeg 03Richard Shaffer 07master:c705476c4788: libavformat/http: Refactor and fix additional leaks in get_cookies.
[23:01:33 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07master:2324ef1ff32e: avcodec/cinepak: move some checks prior to frame allocation
[23:01:34 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07master:9033920bec9c: avcodec/cinepak: Skip empty frames
[23:01:35 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07master:9d5a4fcfbb51: avcodec/dfa: Check dimension against maximum
[23:01:36 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07master:942217b153a9: avcodec/dsicinvideo: Propagate errors from cin_decode_rle()
[23:01:37 CEST] <cone-535> ffmpeg 03Michael Niedermayer 07master:5549488bbf3a: avcodec/dsicinvideo: Fail if there is only a small fraction of the data available that comprises a full frame
[23:11:31 CEST] <kierank> ttw
[23:11:33 CEST] <kierank> bleh
[00:00:00 CEST] --- Fri Apr 20 2018