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

[burek]

[00:00:31 CET] <atomnuker> not sure if they know only one can be accepted, I assumed they do
[00:03:42 CET] <cehoyos> I believe it is appreciated if you make sure they know. (At least this is what I think makes sense.)
[00:05:27 CET] <atomnuker> just sent them a message
[00:06:58 CET] <cehoyos> Thank you!
[00:08:07 CET] <cehoyos> If you believe both could be suitable students, we could try to find alternative projects for one.
[00:55:49 CET] <kierank> qiubit: I like the way you exposed the exact issue that my GSoC project wants to solve
[00:56:14 CET] <kierank> We have no way of tracking fuzz regressions
[01:02:20 CET] <qiubit> kierank: thanks, and BTW I didn't do anything fancy. It turns out that if you give afl enough time, it will find something interesting. And who knows how much more can it find, if fuzzing will be done somewhat more intelligently... 
[01:05:28 CET] <wm4> lol
[01:05:37 CET] <wm4> why do these people want to use ffmpeg at all
[01:12:13 CET] <TD-Linux> wm4, because it's apple quality!!
[01:12:22 CET] <TD-Linux> (see imgix)
[01:28:01 CET] <durandal_1707> What's wrong with this afero guy?
[01:31:24 CET] <llogan> What's wrong with these top-posting guys?
[01:34:43 CET] <TD-Linux> what's wrong with these guys that use IRC as mailing list backchannel
[01:37:02 CET] <iive> something's wrong with the world today
[01:37:07 CET] <iive> i don't know what it is...
[02:30:11 CET] <Shiz> x/w 48
[04:07:07 CET] <cone-281> ffmpeg 03Petru Rares Sincraian 07master:68e5976543e9: Refactor libavutil/parseutils.c
[04:38:22 CET] <rcombs> how _about_ on iOS
[04:41:56 CET] <rcombs> Shiz: error: failed to read memory from 0x30.
[06:56:10 CET] <rcombs> https://trac.ffmpeg.org/ticket/5366 <-- is there actually any compelling reason to use AU filters over the built-in lavfi ones
[06:56:18 CET] <rcombs> like, are they actually higher-quality or faster or something
[06:56:50 CET] <rcombs> (the codecs actually present a significant perf difference)
[08:27:54 CET] <omerjerk> I'm working on my proposal for ALS encoder.
[08:28:13 CET] <omerjerk> I want to know how does the review process take place ?
[08:28:38 CET] <omerjerk> review process for adding the encoder in the official codebase.
[08:44:26 CET] <JEEB> omerjerk: you can ask very initial comments by linking your repo here, and when your patch is in a state in which you think you can post it for actual review, you post it on the ML
[09:18:46 CET] <linuxuser9000> Hi! I'm trying to properly configure my git clone of ffmpeg such that I can use most of the disabled-by-default encoders, is there a better way to do this than to just give the --encoder* option for every encoder?
[09:28:44 CET] <ethe> linuxuser9000: you probably want #ffmpeg
[10:53:18 CET] <JEEB> btw, did the work on the subtitles without end timestamps also affect picture-based subtitles?
[11:23:18 CET] <ubitux> JEEB: what work?
[11:23:26 CET] <ubitux> oh you mean the realtime in the cc decoder?"
[11:24:00 CET] <JEEB> yeah, that you actually get the subtitle packets even if no endtime was gotten
[11:24:41 CET] <ubitux> it's just a private option in that decoder, i don't remember what value was decided to be used
[11:24:58 CET] <ubitux> i don't remember if some other do that
[12:44:03 CET] <cone-493> ffmpeg 03Michael Niedermayer 07master:50d017a28171: avformat/mpegtsenc: Keep track of the program for each service
[12:44:04 CET] <cone-493> ffmpeg 03Michael Niedermayer 07master:26811fd9468d: avformat/mpegtsenc: Fix used service
[12:46:08 CET] <Razva> guys, any RHEL/CentOS repo with ffmpeg 3.0 available?
[12:47:01 CET] <JEEB> not a -devel related thing, please don't spam channels
[12:56:43 CET] <ubitux> http://sprunge.us/BMND i wonder if a prefetch could help
[13:48:24 CET] <nevcairiel> rcombs: AT patches have broken building on all iphone targets (ie. arm darwin)
[13:51:08 CET] <wm4> does iphone not have this API
[14:05:12 CET] <cone-493> ffmpeg 03Rostislav Pehlivanov 07master:72e13600079e: vc2enc: optimize and simplify quantization
[14:07:40 CET] <wm4> does fate not stop on the first error?
[14:15:30 CET] <ubitux> running with -jX or -k?
[14:16:27 CET] <wm4> either
[14:38:45 CET] <nevcairiel> sure stops for me
[14:38:48 CET] <nevcairiel> just dont run with -k or -i
[14:39:47 CET] <wm4> oh it's -k
[14:39:55 CET] <wm4> so much for mindlessly copying command line options
[14:59:23 CET] <ubitux> re: codecpar; are we going to introduce the codec time_base in it for subtitles?
[14:59:39 CET] <ubitux> that's one of the last "meta" issue, isn't it?
[15:12:58 CET] <Daemon404> ubitux, i would really like to avoid that since it's a public struct
[15:13:05 CET] <Daemon404> :/
[15:15:40 CET] <wm4> I don't see where the problem is, I had to set an explicit timebase on subtitle converters before
[15:15:52 CET] <wm4> while no other decoders required this
[15:18:03 CET] <wm4> does anyone know how ffmpeg.c drains filter frames on midstream format changes?
[15:20:16 CET] <Daemon404> wm4, its not a real fix though
[15:20:31 CET] <Daemon404> it's a shitty hack to passtimebase in a place its not supposed to be
[15:20:41 CET] <Daemon404> it's not a "codec parameter"
[15:20:52 CET] <Daemon404> (the real fix is avframe subtitles IMO)
[15:21:05 CET] <wm4> there are other things that use timebase and require it to have a specific value in decoders
[15:21:18 CET] <Daemon404> such as?
[15:22:01 CET] <Daemon404> (it's worth noting nobody has been able to provide a legitimate explanation of what a "codec timebase" is, except that it's convenient for passing info that may or may not be an actual timebase)
[15:22:13 CET] <Daemon404> (most of the shit i see in lavf uses it for e.g. bitstream *framerate*)
[15:22:28 CET] <wm4> ah maybe I'm wrong
[15:23:15 CET] <wm4> seems like the general requirement is that they're linear integers and that AV_NOPTS_VALUE is special
[15:23:58 CET] <wm4> there are still some weird reference to time_base in utils.c though
[15:24:19 CET] <Daemon404> weird is the key word here
[15:24:22 CET] <Daemon404> i doubt it is correct
[15:24:36 CET] <Daemon404> e.g. the use in the framr duration computations is insane
[15:24:50 CET] <Daemon404> because codec timebase is used interchangeably with framerate in lavf
[15:25:01 CET] <Daemon404> like 90% of the fate failures were that so far
[15:25:15 CET] <wm4> I only see this in the encoding path:
[15:25:16 CET] <wm4>                     avpkt->duration = ff_samples_to_time_base(avctx,
[15:25:16 CET] <wm4>                                                               frame->nb_samples);
[15:25:49 CET] <Daemon404> iaybe its not utils.c where teh func im thinking of is
[15:25:55 CET] <Daemon404> but same idea
[15:26:18 CET] <Daemon404> i havent found a use yet where it's seemed 'correct', in any case
[15:26:52 CET] <durandal_1707> just change fate
[15:27:17 CET] <Daemon404> durandal_1707, no the correct fix was mostly to access the correct, framerate, fields
[15:27:33 CET] <Daemon404> fate had a good refence for most.
[15:30:09 CET] <nevcairiel> changing fate is usually not the right answer, unless you can clearly proof that the old value was wrong and the new one is better (which happens)
[15:30:20 CET] <nevcairiel> ie. every single fate change has to be properly explained, or its a bug
[15:30:24 CET] <Daemon404> yes
[15:41:07 CET] <cone-493> ffmpeg 03Ico Doornekamp 07master:e3e6a2cff4af: avformat/rtpdec_jpeg: fix low contrast image on low quality setting
[15:50:33 CET] <Daemon404> huh.. daala uses the term 'golden frame' too
[15:50:39 CET] <JEEB> funky
[15:52:59 CET] <wm4> doesn't this AGPL guy make a convincing argument
[15:54:25 CET] <Daemon404> im not even reading that thread
[15:54:34 CET] <Daemon404> people who argue for AGPL arent even worth my time to read
[15:55:06 CET] <wm4> I mean his argument about openjpeg vs. internal decoder
[15:55:19 CET] <JEEB> did he actually find copied code?
[15:55:22 CET] <nevcairiel> why do we attract the obnoxious nutjobs lately
[15:55:44 CET] <Daemon404> ... lately?
[15:55:53 CET] <nevcairiel> dunno, seems to be getting worse
[15:55:54 CET] <Daemon404> this project is founded on that
[15:55:58 CET] <Daemon404> us included
[15:56:04 CET] <Daemon404> (you have to be nitjobs to enjoy working with multimedia)
[15:56:08 CET] <wm4> seems accurate
[15:56:09 CET] <Daemon404> nut*
[16:01:41 CET] <rcombs> nevcairiel: huh, I guess iOS just doesn't provide VBR
[16:05:09 CET] <durandal_1707> so no tep2, still?
[16:05:57 CET] <Daemon404> you are fere to help 
[16:05:59 CET] <Daemon404> free*
[16:06:10 CET] <Daemon404> i dont think much will get done on easter eekend
[16:06:13 CET] <Daemon404> since, well, it is easter.
[16:07:46 CET] <rcombs> should AVOptions not available on a given platform be removed or "stubbed"?
[16:13:02 CET] <Daemon404> rcombs, whats this related to?
[16:13:16 CET] <rcombs> Daemon404: http://fate.ffmpeg.org/log.cgi?time=20160324030457&log=compile&slot=arm64-darwin-clang-apple-6.0
[16:13:33 CET] <Daemon404> right. well API-wise, i dont think it matters if there is a stub or not.
[16:13:40 CET] <Daemon404> it's a key/value dict, so.
[16:14:23 CET] <rcombs> some things error if you pass unknown AVOpts, but I guess if you're passing an opt that doesn't exist you'll probably want to know about it
[16:14:34 CET] <Daemon404> what errors?
[16:14:44 CET] <Daemon404> maybe im not remembering correct, but i thought they were ignored
[16:15:44 CET] <Daemon404> if they errored on unknown option, then we'd have to bump API major a lot more
[16:17:01 CET] <rcombs> oh, I thought ffmpeg errored but I guess it just logs
[16:17:12 CET] <rcombs> (ffmpeg_opt)
[16:17:58 CET] <Daemon404> who would be running ffmpeg cli on ios
[16:19:00 CET] <wm4> Daemon404: multimedia professionals?
[16:19:29 CET] <Daemon404> technically, you legally cant
[16:19:43 CET] <Daemon404> e.g. certain fate clients which run ios use rooted phones
[16:19:52 CET] <Daemon404> with samba and exec scripts
[16:19:55 CET] <Daemon404> it's rather very complicated
[16:37:11 CET] <ubitux> Daemon404: i don't think it's wise to wait for the subtitles frame api for the merge
[16:37:22 CET] <ubitux> we have way too much delay now on libav commits already
[16:37:38 CET] <ubitux> we can just do the usual "fields below are private" in codecpar
[16:39:40 CET] <Daemon404> ubitux, ok
[16:40:28 CET] <ubitux> also, add a big fat warning saying that this time base should be exclusively used for decoded subtitles because of current API limitations
[16:41:18 CET] <rcombs> are there any subtitle codecs where 1/1000 isn't suitable?
[16:41:45 CET] <rcombs> (sure ASS is 1/100 but it doesn't hurt anything to store it as 1/1000 internally)
[16:44:08 CET] <wm4> hm, would that be compatible?
[17:08:59 CET] <Daemon404> ... sigh
[17:09:01 CET] <Daemon404> NIH zlib
[17:09:09 CET] <Daemon404> this may be one of the dumbest patchsets ever
[17:12:27 CET] <nevcairiel> its also super ugly
[17:12:36 CET] <Daemon404> yes
[17:13:24 CET] <wm4> I can get behind wanting to NIH zlib, but not this ifdef soup
[17:13:51 CET] <Daemon404> i cant get behind wanting to NIH zlib
[17:14:09 CET] <Daemon404> Windows on MSVC is more or less the only place you do not have an easily accessible zlib
[17:14:59 CET] <sfan5> mingw has zlib out-of-the-box?
[17:15:01 CET] <sfan5> did i miss something
[17:15:06 CET] <sfan5> i always had to build zlib seperately
[17:15:33 CET] <nevcairiel> then you used a bad mingw package, the most basic libraries should be coming with it
[17:15:33 CET] <Daemon404> sfan5, most chains do, or: ./configure && make
[17:15:48 CET] <Daemon404> and its still retarded to NIH it for that
[17:15:48 CET] <sfan5> "bad mingw package"
[17:15:52 CET] <sfan5> i built it myself
[17:15:54 CET] <sfan5> it was a PITA
[17:16:00 CET] <Daemon404> wut?
[17:16:10 CET] <nevcairiel> its just like manually building gcc on linux
[17:16:12 CET] <Daemon404> iirc its like one command
[17:16:14 CET] <wm4> use msys, do pacman -S zlib-whatever?
[17:16:20 CET] <Daemon404> make -fwin32/Makefile.mingw
[17:16:21 CET] <mabreedlove> wanted to say these new builds I've done have been doing a much better job at fully taxing my cpu, so much appreciated
[17:16:22 CET] <wm4> (the only hard part is finding the package name)
[17:16:23 CET] <nevcairiel> anyone who is sane would just get a package that suits their needs :D
[17:16:24 CET] <Daemon404> optionally with PREFIX
[17:16:32 CET] <sfan5> yeah no
[17:16:40 CET] <Daemon404> then youre doing it massively wrong
[17:16:41 CET] <sfan5> i did linux from scratch but with mingw
[17:16:44 CET] <wm4> anyway that's no real argument
[17:16:57 CET] <wm4> zlib is one of the most ubiquitous libs ever
[17:17:02 CET] <nevcairiel> there are plenty of pre-packaged mingw environments that include what most projects need
[17:17:08 CET] <nevcairiel> if you build your own, you are of course also responsible
[17:17:11 CET] <mabreedlove> sfan5: theres a project that builds ffmpeg and its libs native on windows if you want, just asks which libs you'd like
[17:17:22 CET] <nevcairiel> on that ground you might argue that we should include a compiler =p
[17:17:27 CET] <sfan5> nah i don't need ffmpeg built for windows
[17:17:47 CET] <sfan5> nevcairiel: why stop there? include a kernel!
[17:17:50 CET] <sfan5> :P
[17:18:13 CET] <Daemon404> libav* including libc or a kernel has been a running joke
[17:18:14 CET] <mabreedlove> micro or monolithic? :p
[17:18:16 CET] <Daemon404> but obvious reasons
[17:18:28 CET] <Daemon404> mabreedlove, in libav* fashion it will be monolithic, but claim to be micro
[17:18:35 CET] <mabreedlove> haha
[17:19:02 CET] <mabreedlove> you guys amuse me everytime I come in here
[17:20:24 CET] <nevcairiel> Daemon404: should just package miniz with ffmpeg to make reimar and his broken buildenv happy
[17:20:30 CET] <nevcairiel> its api compatible to libz and just a single c file!
[17:20:46 CET] <wm4> dump it into compat/ ?
[17:20:51 CET] <wm4> or what
[17:21:06 CET] <mabreedlove> have you guys tried slim-lto builds using --enable-lto on your buildchain?
[17:21:15 CET] <mabreedlove> our of curiosity
[17:21:18 CET] <nevcairiel> lto is rather broken
[17:21:39 CET] <mabreedlove> it works.  just not like....without spending a ton of time screwing with it
[17:21:48 CET] <RiCON> last time i tried if failed building, didn't try too much
[17:21:58 CET] <nevcairiel> it conflicts with some of our inline assembly
[17:22:09 CET] <mabreedlove> thats what Im referring to ;)
[17:22:27 CET] <wm4> nevcairiel: interesting
[17:22:39 CET] <mabreedlove> I built it awhile back for my own usage but required disabling avx/avx2, etc which I didnt have native support for
[17:23:00 CET] <mabreedlove> this was before gcc 5+ had better thin LTO support though
[17:23:09 CET] <RiCON> unless it considerably improved performance, i'm not very interested in marginal space savings
[17:23:32 CET] <mabreedlove> saves a fairly significant amount of space on a static build
[17:24:21 CET] <drv> everything old is new again
[17:24:23 CET] <mabreedlove> I haven't done proper benchmarks so I can't disagree with you in terms of performance though
[17:24:23 CET] <drv> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/46754
[17:25:33 CET] <mabreedlove> I have a feeling thin-lto build may fix the assembly errors, however
[17:41:37 CET] <Daemon404> mabreedlove, lto generally doesnt work for ffmpeg
[17:41:47 CET] <Daemon404> due to us relying on DCE to disable arch-specific stuff
[17:41:58 CET] <Daemon404> so LTOing on x86 will complain about missing ARM symbols
[17:42:04 CET] <Daemon404> at least, last time i tried.
[17:42:19 CET] <nevcairiel> why would lto not manage to figure this out
[17:42:30 CET] <nevcairiel> seems like a rather important optimization if you actually want to save binary space
[17:42:48 CET] <Daemon404> bevause it is broken
[17:42:53 CET] <nevcairiel> all i ever got from it was fail from inline asm
[17:42:54 CET] <mabreedlove> usually those problems were due to it using fat-lto-objects with references that couldn't be resolved when they were recompiled
[17:43:00 CET] <Daemon404> ive had this happen with LTO on 3 different compiles, nevcairiel 
[17:43:07 CET] <Daemon404> compilers*
[17:43:50 CET] <mabreedlove> I know what you're referring to, though.  I disabled lto on my last build since I couldn't hassle with it at the time.  I'm going to try it with thin LTO objects this time and will let you guys know if you like
[17:44:08 CET] <mabreedlove> but yes, it is a complete pain in general to get working properly
[17:47:44 CET] <mabreedlove> need to go through the new configure script and figure out what all of this stuff is useless for me
[17:51:30 CET] <mabreedlove> SDL is just for ffplay mainly, right?
[17:51:48 CET] <wm4> yes, but also libavdevice
[17:54:33 CET] <mabreedlove> not that many options on windows for it anyway.  can probably dump it without noticing
[17:54:46 CET] <mabreedlove> thanks
[19:09:00 CET] <Angus__> Hey guys
[19:09:25 CET] <Angus__> quick question with getting some stuff setup, 
[19:09:37 CET] <Angus__> this list here:
[19:09:38 CET] <Angus__> https://ffmpeg.org/doxygen/2.8/dir_c323f0049949ddd42f5d8cc7327305d9.html
[19:09:45 CET] <Angus__> and this list:
[19:09:45 CET] <Angus__> http://packages.ubuntu.com/xenial/amd64/libavformat-dev/filelist
[19:09:52 CET] <Angus__> are not quite the same thing
[19:10:10 CET] <Angus__> what am I doing wrong here
[19:10:21 CET] <Daemon404> the former is a list of all internal files.
[19:10:24 CET] <JEEB> ^this
[19:10:31 CET] <JEEB> those get built into the .so and .a
[19:10:36 CET] <Daemon404> https://ffmpeg.org/doxygen/2.8/
[19:10:39 CET] <JEEB> and then you have the public headers
[19:10:39 CET] <Daemon404> start exploring here.
[19:11:46 CET] <Angus__> ah, alright, I should be cloning the source if I need the files for development?
[19:13:22 CET] <JEEB> in-FFmpeg development, yes
[19:13:33 CET] <JEEB> using FFmpeg for your own thingy, you can use those public things
[19:14:20 CET] <Angus__> I'm trying to port a citrix plugin from 0.7/0.8 to 2.8
[19:17:04 CET] <JEEB> then you are something using the public APIs
[19:19:10 CET] <Angus__> has url.h in libavformat been moved out of the public APIs between 0.8 -> 2.8?
[19:19:19 CET] <Daemon404> url.h is not publci api
[19:19:23 CET] <Daemon404> it was wrong to use it in teh first place
[19:20:40 CET] <Angus__> citrix seems to have written their own "FFDecode.h/cpp" files :(
[19:20:54 CET] <wm4> so, what is this citrix thing?
[19:21:23 CET] <Angus__> https://www.citrix.com/downloads/citrix-receiver/receiver-for-linux-sdks/linux-platform-optimization-sdk.html
[19:22:14 CET] <wm4> another instance of <corporate>-sdk==bad time
[19:23:03 CET] <Daemon404> Angus__, you can probably replace it using avio_*
[19:23:06 CET] <Daemon404> i havent looked though
[19:23:12 CET] <Daemon404> also, what wm4 said
[19:24:05 CET] <Angus__> heh
[19:24:42 CET] <Angus__> this is the wrapper they made: typedef 	int ( _PAPI PFN_av_register_protocol )( URLProtocol *protocol );
[19:24:54 CET] <Daemon404> that's... odd
[19:25:04 CET] <JEEB> http://pastebin.com/7UaeED2Q
[19:25:13 CET] <JEEB> their AVC decoding thingamajig through avcodec et al
[19:25:28 CET] <Angus__> you found it.
[19:25:29 CET] <Daemon404> er what
[19:25:32 CET] <wm4> lol
[19:25:34 CET] <Daemon404> why are they registering a protocol
[19:25:36 CET] <Daemon404> for a bufr
[19:25:39 CET] <Daemon404> you can use avio callbacks
[19:25:41 CET] <Daemon404> to do exactly that
[19:25:59 CET] <wm4> I want to know why they dlopen everything
[19:26:46 CET] <Daemon404> also there is next to no error checking
[19:26:57 CET] <Daemon404> but eh. corporate code.
[19:27:30 CET] <JEEB> also they did their NAL unit parser or whatever
[19:27:53 CET] <wm4> I don't get it
[19:27:58 CET] <wm4> why are they using libavformat at all
[19:28:07 CET] <JEEB> or well, "parser" since it really doesn't do jack shit :D
[19:28:09 CET] <durandal_1707> what's status of our j2k decoder?
[19:28:35 CET] <nevcairiel> it kind of works on dcinema files, probably not all that well on any others
[19:29:02 CET] <Daemon404> it really doesnt fully.
[19:29:07 CET] <Daemon404> iirc it cant do full 4k
[19:29:13 CET] <Angus__> I have not a clue, I just started working on this thing a yesterday
[19:29:36 CET] <JEEB> anyways, if they have buffers you can just do custom AVIO
[19:29:51 CET] <JEEB> heck, I was able to make a wrapper for Windows IStreams and I'm dumb :P
[19:30:26 CET] <JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/src/istream_wrapper.c
[19:31:56 CET] <JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/src/matroska_thumbnailer.cpp#L116 and then I just used the thing :D
[19:34:08 CET] <Angus__> right now, I'm just trying to get this to compile, see what it does
[19:35:36 CET] <JEEB> well, good luck :P it doesn't do too much of anything, but it looks like a classic corporate dump
[19:35:50 CET] <Angus__> is there any reason why I shouldn't copy the devel headers to /usr/include/etcetc ?
[19:36:00 CET] <Daemon404> because its not piblic api
[19:36:13 CET] <Daemon404> you are using stuff that is not exposed nor intended to be used
[19:36:20 CET] <Daemon404> if it doesnt work, we wont support it
[19:36:40 CET] <JEEB> nothing there requires any of the private APIs as far as I can tell :P
[19:37:03 CET] <Daemon404> nope
[19:37:13 CET] <Daemon404> they use private apis to implement something the public api has had for many years
[19:37:21 CET] <Daemon404> it's clear no docs were read
[19:38:10 CET] <Angus__> lol
[19:44:30 CET] <cone-289> ffmpeg 03Petru Rares Sincraian 07master:f707042c931c: Added more tests to libavutil/parseutils.c
[19:44:30 CET] <cone-289> ffmpeg 03Michael Niedermayer 07master:54f43984e1e4: avutil/parseutils: mark args as static const
[20:20:06 CET] <jkqxz> Why would RTP JPEG clip away quality 100?  (Seeing it in that patch which went past a few hours ago.)  RFC 2435 allows 1-99 and says 100-127 are "reserved", but 100 is well-defined so deliberately decoding it incorrectly seems kindof pointless, unless there is some other constraint I've missed.
[20:23:58 CET] <Angus__> +JEEB, you posted this a bit ago:
[20:23:59 CET] <Angus__> http://pastebin.com/7UaeED2Q
[20:24:12 CET] <Angus__> do you have any idea what the BufferContext is in there?
[20:24:40 CET] <Daemon404> its their own struct.
[20:24:45 CET] <Daemon404> it's user data.
[20:25:45 CET] <Angus__> hmm
[20:33:22 CET] <Angus__> https://www.citrix.com/downloads/citrix-receiver/linux/receiver-for-linux-latest.html
[20:33:34 CET] <Angus__> oh ho ho, "FFmpeg Source Package"
[20:35:09 CET] <Angus__> "The FFmpeg library has been modified by Citrix Systems, Inc. The difference file between the initial FFmpeg source and the Citrix modified FFmpeg source is 'Citrix-FFmpeg-DIFF.txt'."
[20:36:17 CET] <JEEB> because of course
[20:37:22 CET] <Daemon404> where is said txt file?
[20:39:01 CET] <JEEB> https://www.citrix.com/downloads/citrix-receiver/linux/receiver-for-linux-latest.html#ctx-dl-eula
[20:39:05 CET] <Angus__> ^
[20:39:22 CET] <JEEB> blergh, not a straight url
[20:39:23 CET] <Angus__> "Additional components"
[20:39:27 CET] <JEEB> yeah
[20:39:40 CET] <Daemon404> this is technically noncompliat
[20:39:47 CET] <Daemon404> it violates the lgpl to force me to agree with a eula
[20:40:03 CET] <JEEB> yeah, seems to be a generic shithole they have :P
[20:40:24 CET] <Daemon404> dling at 32 kb/s
[20:40:26 CET] <Daemon404> nice
[20:40:59 CET] <JEEB> anyways, they seem to be using lavc purely for AVC/JPEG (?) sw decode if their crappy hw decoder doesn't work
[20:41:03 CET] <JEEB> so not much use I guess?
[20:41:16 CET] <JEEB> unless they implemented their hwdec in their fork of FFmpeg, which I doubt
[20:41:44 CET] <BtbN> the changes are minimal
[20:41:47 CET] <BtbN> and look broken
[20:41:54 CET] <Daemon404> BtbN, so like the rest of the code?
[20:42:00 CET] <BtbN> no idea what the hell they are doing there, except for the ripping out all crypto
[20:42:17 CET] <Daemon404> they cant legally export strong crypto probably
[20:42:19 CET] <Daemon404> because USA USA USA
[20:42:29 CET] <BtbN> Yeah, but there are other changes, which make no sense
[20:42:38 CET] <llogan> old ass source
[20:42:41 CET] <Daemon404> well their api-using code makes no sense either
[20:42:41 CET] <Daemon404> so.
[20:43:47 CET] <Angus__> you guys ever had to deal with legal team code reviews?
[20:43:54 CET] <Angus__> horrible. horrible stuff.
[20:44:12 CET] <JEEB> yeah, usually at the point where a dependency is added into some stack
[20:44:24 CET] <JEEB> what license the thing is under, etc
[20:45:19 CET] <Daemon404> unless you are a multimedia bigcorp, then you just violate all the licneses
[20:45:55 CET] <dinux5> Do the developers here use any IDE ? Is it recommended or no?
[20:46:07 CET] <Daemon404> you can use whatever editor or ide you want
[20:46:15 CET] <Daemon404> not sure why you wouldnt
[20:46:31 CET] <JEEB> if you can set up an IDE with the build system and you feel like an IDE brings anything to you then feel free
[20:46:37 CET] <JEEB> everyone likes their own thing here methinks
[20:47:44 CET] <dinux5> Which one specifically ? The eclipse one for C is not much developed.
[20:48:27 CET] <Daemon404> most of us probably use vim or emacs.
[20:48:36 CET] <JEEB> you're going to get N amounts of answers here which is why I'm just telling you to use whatever you like/want to use
[20:48:46 CET] <JEEB> if you can set the FFmpeg build system into your IDE, feel free
[20:48:59 CET] <JEEB> I did that once with Qt Creator and L-SMASH, but never for FFmpeg
[20:49:43 CET] <Angus__> I'm using eclipse here just for the editor
[20:50:17 CET] <dinux5> Alright. Thanks :)
[21:06:01 CET] <Angus__> Do you guys know if this still exists?
[21:06:01 CET] <Angus__> https://www.ffmpeg.org/doxygen/0.6/libavformat_2raw_8c-source.html
[21:07:23 CET] <Daemon404> uh... context?
[21:07:33 CET] <Daemon404> that file is internal to avformat
[21:08:00 CET] <JEEB> and as has been noted N times here already, none of what that AVC thing did required internal APIs
[21:08:38 CET] <Angus__> I'm trying to patch the citrix changes to a newer build of FFMpeg, 
[21:08:44 CET] <JEEB> ugh
[21:08:54 CET] <JEEB> seriously, are there *any* useful things?
[21:09:13 CET] <JEEB> as far as I could tell, it's a goddamn scenario of decoding AVC from a buffer
[21:09:29 CET] <JEEB> anything else it does with lavf/lavc?
[21:09:39 CET] <Angus__> I have no idea
[21:10:20 CET] <JEEB> as far as I could see that thing could be reimplemented just fine with whatever 16.04 comes with
[21:10:51 CET] <JEEB> the thing in its current state is FUBAR
[21:12:08 CET] <Angus__> I have no idea what it actually does, so porting it over to use the proper API isn't going to be trivial
[21:12:44 CET] <JEEB> hacking up random/bad changes from ancient FFmpeg to current FFmpeg blindly is not gonna be any better
[21:13:01 CET] <JEEB> + that thing used private APIs that's going to end up in tears as well
[21:13:38 CET] <JEEB> you might think it's simpler to go on blindly trying to make it compile, but that's not going to happen
[21:13:59 CET] <Angus__> you're probably right
[21:14:17 CET] <JEEB> map how much avcodec/avformat is used in that code dump
[21:14:29 CET] <JEEB> then you will see how much of a job it would be
[21:15:36 CET] <JEEB> and if you're doing this for a company, consider getting someone on board who can habla these things
[21:16:01 CET] <JEEB> unless you have the time to learn this yourself of course
[21:16:03 CET] <Angus__> I'll probably be giving citrix a call on tuesday
[21:16:27 CET] <JEEB> looking at that thing, citrix doesn't really habla FFmpeg
[21:16:30 CET] <Angus__> idea is 4 weeks to hack this thing, and VDPAU together
[21:16:32 CET] <JEEB> which is what I was meaning
[21:16:54 CET] <Angus__> we have someone in the company who knows VDPAU stuff pretty well
[21:17:21 CET] <Angus__> but no-one here is from Citrix
[21:18:58 CET] <JEEB> anyways, if that is all it does with FFmpeg (decodes AVC), then you could probably get this done in a week and then spend the rest on your VDPAU infra :P
[21:19:21 CET] <JEEB> there's a VDPAU hwaccel but you still have to handle a lot of stuff on your side since hwaccel != decoder
[21:19:28 CET] <Angus__> that's the idea
[21:19:58 CET] <JEEB> not sure how much citrix would help you with regards to the FFmpeg part due to how crudely it was made
[21:20:21 CET] <JEEB> but at least it doesn't seem like they are actually doing much at all with FFmpeg :P
[21:20:40 CET] <Angus__> I don't even know how much of this they remember, it's not exactly new
[21:41:46 CET] <Angus__> https://trac.ffmpeg.org/wiki/HWAccelIntro
[21:41:54 CET] <Angus__> hmm, looks like there is a VDPAU implementation
[21:42:02 CET] <Angus__> but apparently shouldn't be used?
[21:43:14 CET] <JEEB> there was something old, but that has been since removed, there is a newer vdpau hwaccel - that should be utilized
[21:44:03 CET] <JEEB> hwaccels are a way of integrating those into the avcodec infrastructure. you will have to do some plumbing on your side as well, though. this differentiates it from the the plain decoders/encoders
[21:44:58 CET] <JEEB> quite a few applications, including ffmpeg.c, use the VDPAU hwaccel, so you should have no shortage of examples of its usage
[21:45:08 CET] <Angus__> ah
[21:45:11 CET] <Angus__> https://ffmpeg.org/doxygen/2.8/group__VDPAU__Decoding.html
[21:45:17 CET] <Angus__> is this the deprecated module?
[21:45:39 CET] <JEEB> no
[21:45:48 CET] <JEEB> I'm pretty sure the old thing is long gone
[21:46:01 CET] <JEEB> since even mplayer should be using the new one for years
[21:46:19 CET] <JEEB> and it was the only reason to keep the old thing in FFmpeg for as long as it was kept
[21:47:16 CET] <Angus__> I see
[21:53:14 CET] <wm4> JEEB: it's not gone
[21:53:27 CET] <JEEB> oh
[21:53:29 CET] <JEEB> jesus christ
[21:53:33 CET] <wm4> Angus__: that looks like the new hwaccel stuff
[21:53:38 CET] <JEEB> yeah
[21:53:43 CET] <JEEB> esp. since it had the HEVC stuff
[21:53:45 CET] <wm4> Angus__: I'd stop trying to read the doxygen generated pages
[21:54:00 CET] <wm4> it's worse than the source code
[21:54:07 CET] <Angus__> :(
[21:54:14 CET] <Angus__> makes enough sense though
[21:54:28 CET] <wm4> I don't think any of the frequent devs use this
[21:54:47 CET] <rcombs> I do sometimes
[21:54:52 CET] <wm4> (the doxygen in the source can still be useful, but, well, you can just read it as part of the source)
[21:54:52 CET] <rcombs> just for searching/browsing
[21:55:03 CET] <rcombs> I end up in the source whenever I want any detail, though
[21:55:07 CET] <wm4> rcombs: I use my modern refactoring tools like grep
[21:56:04 CET] <Daemon404> wm4, i use the doxy
[21:56:08 CET] <Daemon404> but probably only me
[21:56:35 CET] <wm4> ok maybe it's not as uncommon... personally I feel like the doxy omits a lot of information
[21:56:37 CET] <Daemon404> i google func names and ffmpeg doxycomes up
[21:56:48 CET] <Daemon404> less effort than grep
[22:02:08 CET] <JEEB> I use the doxy sometimes as it pops up on google for specific public structs/vars
[22:11:35 CET] <Angus__> typedef		int ( _PAPI PFN_avcodec_decode_video ) (AVCodecContext *avctx, AVFrame *picture, int *got_picture_ptr, const uint8_t *buf, int buf_size );
[22:11:37 CET] <Angus__> strange...
[22:13:47 CET] <wm4> ancient api
[22:13:59 CET] <wm4> long gone
[22:14:17 CET] <Angus__> ahh. so that's why I can't find it
[22:14:46 CET] <Angus__> there's no direct replacements for it, is there?
[22:15:17 CET] <wm4> avcodec_decode_video2 is direct enough
[22:15:24 CET] <wm4> but you need to setup a avpacket
[22:15:57 CET] <Angus__> hmm
[22:18:34 CET] <JEEB> just look at the decoding example under docs in the git repo
[22:31:01 CET] <Angus__> https://ffmpeg.org/doxygen/0.6/avcodec_8h.html#812b0ba18511f3c8787294bce7b06372
[22:31:16 CET] <Angus__> my god, it was deprecated by 0.6
[22:33:14 CET] <JEEB> Angus__: you'd probably get much more out of looking at https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/demuxing_decoding.c for a bit
[22:33:46 CET] <JEEB> since the citrix thing essentially is reading and decoding AVC
[22:33:57 CET] <Angus__> what exactly does demuxing do?
[22:34:29 CET] <Angus__> as in, what are the inputs/outputs of the demuxing?
[22:34:35 CET] <wm4> Daemon404: oh, now I remember... I confused time_base with pkt_timebase
[22:34:52 CET] <JEEB> Angus__: takes input and reads it with a demuxer of choice into chunks you can throw into avcodec
[22:35:02 CET] <wm4> Angus__: it turns a file (byte stream) into a stream of AVPackets
[22:35:12 CET] <wm4> but why your citrix thing does that... who knows
[22:35:32 CET] <wm4> maybe to split it into individual h264 packets (but a parser could do this)
[22:35:59 CET] <JEEB> basically it most probably was doing what the h264 demuxer for raw AVC does?
[22:36:27 CET] <Angus__> hmmm
[22:36:38 CET] <Angus__> the Citrix thing streams video to decode
[22:37:21 CET] <JEEB> yes, so you would be making a custom avio thing for avformat that feeds it bytes from the buffer (mark it as non-seekable) and then have avformat read it as "h264"
[22:37:28 CET] <JEEB> then pass those avpackets into avcodec and voila
[22:37:32 CET] <JEEB> you get AVC decoding
[22:38:21 CET] <Daemon404> wm4, lulz.
[22:43:53 CET] <Angus__> what's the difference netweem modifying the code to use avcodec_decode_video2 and getting it to use avio?
[22:44:41 CET] <JEEB> either manually creating avpackets
[22:44:46 CET] <JEEB> or getting the framework do it for you
[22:45:19 CET] <dinux5> What does sample_buffer contain 
[22:45:20 CET] <JEEB> because you need AVPackets for the decoder, and demuxers output them
[22:45:49 CET] <dinux5> is it an array or just a memory location?
[22:48:14 CET] <JEEB> Angus__: this https://github.com/jeeb/matroska_thumbnails/blob/master/src/matroska_thumbnailer.cpp#L98 until line 235 is my babby's first with custom AVIO and avformat+avcodec video demuxing and decoding
[22:49:20 CET] <Angus__> mhmmm
[22:49:24 CET] <JEEB> I defined the custom seek and read functions, in your case seek wouldn't be needed
[22:50:18 CET] <JEEB> you could of course simplify it somewhat even, because you know exactly what you're receiving :P
[22:50:35 CET] <JEEB> you don't need to probe or pick "best" streams per se
[22:52:00 CET] <Angus__> yep, exactly
[22:52:53 CET] <JEEB> and the only reason for having avformat there would be to make sure that the data fed to avcodec matches what it expects
[22:53:23 CET] <JEEB> not sure if making custom AVPackets and setting parsing to full in the AVC decoder would suffice
[22:53:49 CET] <Angus__> let me figure out how this citrix thing is creating the context, and if it's easier to let it do it's thing, vs taking the bytestream and making it an avformat
[23:02:56 CET] <Angus__> I'm putting off the decision of keeping with the custom avcodec_decode_video2 vs avio for now
[23:03:26 CET] <Angus__> how does FFMpeg decide what decoder to use?
[23:05:23 CET] <Angus__> or would it be easier just to trace the program when it's being run?
[23:07:07 CET] <cone-399> ffmpeg 03Michael Niedermayer 07master:0cd9ff4e3aa2: avcodec/libutvideodec: copy frame so it has reference counters when refcounted_frames is set
[23:07:54 CET] <Daemon404> and so it lives on
[23:07:59 CET] <Daemon404> as the undead
[23:08:53 CET] <wm4> this is the first decoder ever that checks thgis field
[23:08:55 CET] <wm4> (lol)
[23:09:06 CET] <wm4> gotta go fast when using legacy API
[23:10:01 CET] <wm4> also this patch was for 30 mins on the ML and then pushed without any replies, what's the point of sending it to the ML?
[23:11:31 CET] <Daemon404> carl ok'd it privately according to the msg
[23:11:34 CET] <Angus__> anyway, im heading out of work for the night. Thanks for the help, appreciate it.
[23:11:40 CET] <Daemon404> i dont care, it's not my problem
[23:11:42 CET] <Daemon404> @ am4
[23:11:47 CET] <Daemon404> wm4*
[23:12:04 CET] <Daemon404> (that was unfortunate timing)
[23:13:06 CET] <wm4> I'm just amazed how this created yet another special case
[23:13:29 CET] <wm4> probably harmless, but still
[23:13:41 CET] <wm4> (also might encourage users to use legacy API)
[00:00:00 CET] --- Fri Mar 25 2016