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

[burek]

[00:18:51 CET] <Daemon404> 42
[00:59:38 CET] <kierank> Daemon404: going to try and use vf_overlay from the api soon, looking forward to a whole lot of fun
[01:07:04 CET] <cone-623> ffmpeg 03Matthias Hunstock 07master:e9025573faf6: decklink: support all valid numbers of audio channels
[01:12:27 CET] <jya> BBB: how good is the ARM code for ffvp9 compare to the one in libvpx?
[01:13:03 CET] <jya> I remember hearing that libvpx has neon optimisations that ffvp9 didn't have, or something like htat
[01:21:31 CET] <cone-623> ffmpeg 03Andreas Cadhalpun 07master:916da13d6dac: cfhd: fix off-by-one error in level check
[01:27:05 CET] <BBB> jya: right, afaik there is none
[01:27:19 CET] <BBB> jya: I know some people that could help you write neon simd, but Im probably not one of the
[01:27:21 CET] <BBB> +m
[01:27:41 CET] <jya> BBB: ok, so libvpx should be performing better on arm then no ?
[01:31:37 CET] <BBB> yes
[01:33:53 CET] <BBB> I dont think its hard to write the neon simd, so if arm has a high priority for you guys and you like the performance enhancement you likely get, you should absolutely consider writing the neon simd for ffvp9 *advertisement*
[01:42:41 CET] <jamrial> judging by x86 performance, i guess writing mc alone would put ffvp9 above libvpx :p
[01:52:19 CET] <jya> jamrial: are you volunteering ? :)
[02:09:39 CET] <jamrial> no, never wrote neon
[02:11:16 CET] <jamrial> simply saying that, based on what we saw with x86, ffvp9 on arm would probably only need mc to get ahead of libvpx
[02:11:27 CET] <jamrial> any further asm would make it much, much faster
[02:13:00 CET] <BBB> jya: wbs is pretty good at neon assembly, maybe you can convince him
[02:36:18 CET] <baptiste> thardin, agree with the comment about the MXF muxer, I changed it in ffmbc, I'll try to find the time to port the change
[02:38:40 CET] <Compn> a wild baptiste appears :)
[02:39:06 CET] <Compn> (its a pokemon reference, i'm not calling baptiste wild)
[02:39:19 CET] <baptiste> :)
[03:06:34 CET] <cone-623> ffmpeg 03Timothy Gu 07master:228eb6708bd7: sdl: Remove AVPicture usage
[03:06:34 CET] <cone-623> ffmpeg 03Timothy Gu 07master:13b8ba8c9d1f: xv: Remove AVPicture usage
[03:06:35 CET] <cone-623> ffmpeg 03Timothy Gu 07master:0ab25dac2f0b: cinepakenc: Stop using AVPicture
[03:16:28 CET] <Timothy_Gu> anybody who knows "grace.ryan"
[03:16:47 CET] <Timothy_Gu> his/her fate box is running outta space
[08:17:40 CET] <Timothy_Gu> michaelni: your openbsd box seems to be running out of space
[08:17:46 CET] <Timothy_Gu> http://fatebeta.ffmpeg.org/report/x86_64-openbsd4.8-gcc3.3/20160122092450
[08:51:34 CET] <thardin> baptiste: cool
[08:52:51 CET] <thardin> I need to set up an serverside filter for mxf on my mail account somehow. I sort all ffmpeg mail into its own folder because of the volume, so I tend to miss some of the mxf related emails (especially if not marked "mxf" in the subject)
[09:18:34 CET] <wm4> why do we still have x11grab?
[09:19:30 CET] <wm4> I thought xcbgrab is the new cool thing
[09:29:59 CET] <thardin> maybe not all systems have libxcb?
[09:30:36 CET] <wm4> doubtful
[09:31:07 CET] <flux> I doubt though xcbgrab would be any better than x11grab?
[09:31:24 CET] <flux> or would the pipelining increase throughput?-)
[09:31:41 CET] <wm4> I don't know, but that doesn't justify duplicated code
[09:35:19 CET] <flux> oh, I hadn't noticed it already exists :). I would probably say then just give the libx11-version the axe.
[09:37:32 CET] <flux> doesn't seem like the xcbgrab embraces the asynchronicity of xcb (if there's anything to embrace), but at least it's possible.
[09:40:32 CET] <cone-465> ffmpeg 03Paul B Mahol 07master:c1b23e158c92: avfilter/vf_nnedi: fix ISO C90 warnings
[12:27:34 CET] <wm4> raw dts appears to output incorrect timestamps
[12:28:10 CET] <wm4> it's like libavformat assumes half the sample rate to compute it (although the reported samplerate is correct)
[12:28:24 CET] <wm4> might be av_get_audio_frame_duration's fault, but this function is such a fucking mess
[12:29:58 CET] <wm4> hm, or is the parser computing it here
[12:32:00 CET] <nevcairiel> the parser computes a duration in samples
[12:32:10 CET] <nevcairiel> however, the parser doesnt know about extra samples for higher sample rates
[12:32:16 CET] <nevcairiel> so its duration is always based against the core
[12:32:56 CET] <wm4> hm
[12:33:38 CET] <nevcairiel> so was your raw dts actually 96 or 192khz?
[12:33:47 CET] <wm4> 96, 7.1
[12:34:10 CET] <nevcairiel> then the duration will probably be wrong
[12:34:33 CET] <nevcairiel> or well, use another timebase than you might expect
[12:35:03 CET] <wm4> so dca_parse_params returns 512, while the decoder output is 1024
[12:35:48 CET] <nevcairiel> could probably rescale the duration to the actual samplerate in dca_parse
[12:38:03 CET] <wm4> s->duration        = duration * (sample_rate / avctx->sample_rate);?
[12:38:09 CET] <wm4> could it just set the correct samplerate?
[12:38:24 CET] <nevcairiel> i would've said s->duration        = av_rescale(duration, avctx->sample_rate, sample_rate);
[12:38:26 CET] <nevcairiel> but yes
[12:38:38 CET] <nevcairiel> and feel free to make the parser parse all the dts extensions
[12:40:05 CET] <michaelni> Timothy_Gu, that run is from 12 days ago, theres 2 gb free space currently
[12:41:08 CET] <nevcairiel> wm4: i dont see where this duration field is actually read though
[12:41:28 CET] <wm4> patch sent
[12:41:48 CET] <wm4> nevcairiel: libavformat/utils.c should be using it
[12:41:52 CET] <wm4> "somewhere"
[12:42:03 CET] <wm4> in generally uses the frame duration for formats with no timestamps
[12:42:17 CET] <nevcairiel> wm4: that patch is wrong
[12:42:24 CET] <nevcairiel> its not the "actual samplerate"
[12:42:29 CET] <nevcairiel> the actual samplerate is what the decoder sets
[12:43:48 CET] <wm4> so this bug just compensates the other bug?
[12:44:02 CET] <wm4> where is the decoder involved in this?
[12:44:03 CET] <nevcairiel> why not do what you wanted to do first, scale to the actual sample rate
[12:44:33 CET] <wm4> you suggested that... scaling the duration seems strange to me
[12:46:46 CET] <nevcairiel> like I said, either you make the parser figure out the actual sample rate, or y ou just trust avctx->sample_rate
[12:47:06 CET] <nevcairiel> otherwise the decoder and parser will once again fight over the sample rate and cause weirdness
[12:48:52 CET] <nevcairiel> making the parser smarter would be a better solution, but alas thats also rather complicated
[12:50:34 CET] <wm4> yeah, that looks very annoying
[13:02:33 CET] <nevcairiel> did you test if the patch actually produces proper durations again?
[13:02:41 CET] <nevcairiel> i tend to screw up order of arguments in av_rescale
[13:04:37 CET] <wm4> nevcairiel: from what I can see, the patch works fine
[13:34:58 CET] <cone-465> ffmpeg 03Tobias Rapp 07master:ca71e6052e86: doc/demuxers: add some concat demuxer script examples
[14:20:43 CET] <Daemon404> :D
[14:29:25 CET] <wm4> D:
[14:29:35 CET] <wm4> we should rewrite lavc in Rust
[14:30:21 CET] <Daemon404> too unsafe, should be haskell
[14:31:19 CET] <iive> well, i've heard that java script is the best optimized language... 
[14:31:27 CET] <iive> maybe we should at least consider it...
[14:31:54 CET] <JEEB> Daemon404: not agda?
[14:32:00 CET] <Daemon404> ada you mean?
[14:32:46 CET] <JEEB> probably 8)
[14:54:41 CET] <Daemon404> :D
[16:00:28 CET] <Daemon404> what a mess the mjpeg and mpegec stuff is...
[16:00:36 CET] <Daemon404> why does mjpeg have ff_mpv_generic_options
[16:14:14 CET] <Daemon404> ah i see...
[16:19:58 CET] <cone-465> ffmpeg 03Schenk, Michael 07master:93f4b41208fb: avformat/http: add crypto to default whitlist to get encrypted HLS working  again
[16:19:59 CET] <cone-465> ffmpeg 03Michael Niedermayer 07master:edc34c937b70: avcodec/utils: Check the return code of av_image_fill_linesizes()
[16:49:58 CET] <nevcairiel> so far none of the dca tests failed on any fate box, I wonder when the more rare things like arm and aarch64 run the next ime
[16:53:01 CET] <Daemon404> my old pal snow shows up during merge...
[16:53:11 CET] Action: Daemon404 swears it uses the entirety of avctx
[16:53:35 CET] <nevcairiel> it does use a wide variety of crazy features, yes
[17:06:55 CET] <Daemon404> ugh it affects libutvideoenc.cpp
[17:07:02 CET] Action: Daemon404 doesnt want to fix that crap
[17:13:52 CET] <BBB> Daemon404: having fun with the old clunky code? :D
[17:14:51 CET] <Daemon404> BBB, libutvideo doesnt even exist anymore.
[17:15:00 CET] <BBB> so remove it?
[17:15:03 CET] <BBB> I mean
[17:15:04 CET] <BBB> ...
[17:15:08 CET] <Daemon404> sure. i can try again.
[17:15:11 CET] <BBB> why are we having this discussion :D
[17:15:20 CET] <Daemon404> people complain we lack some of its features (10 bit utvideo)
[17:15:26 CET] <Daemon404> and that you can still use the 3rd party fork of it
[17:15:27 CET] <BBB> IT DOES NOT EXIST ANYMORE
[17:15:27 CET] <Daemon404> to build
[17:15:35 CET] <BBB> oh ok so it does exist
[17:15:47 CET] <Daemon404> in the form of Some GUy maintaining a fork
[17:17:07 CET] <nevcairiel> Aren't we all just some guy  maintaining some code
[17:18:05 CET] <Daemon404> im not sure if it's maintained
[17:29:39 CET] <cone-465> ffmpeg 03Michael Niedermayer 07master:908d010b12fa: avfilter/af_sidechaincompress: Free out frame on error
[17:38:40 CET] <Daemon404> uh... so is it impossible to add avoptions to c++ based things?
[17:38:46 CET] <Daemon404> since it uses designated initializers on a union.
[17:39:02 CET] <Daemon404> on a static const var
[17:39:15 CET] <BtbN> it should be, just with a very ugly syntax
[17:39:43 CET] <Daemon404> how?
[17:40:15 CET] <Daemon404> i guess i could have a union of the same type, intiialzie it with that
[17:40:26 CET] <Daemon404> which is annoying.. because avoptions use ananonymous union.
[17:40:54 CET] <BtbN> iirc it involved implementing a struct that inherits from the main struct and then doing stuff in its constructor.
[17:41:16 CET] <Daemon404> hmm actually
[17:41:17 CET] <Daemon404> luckily
[17:41:24 CET] <Daemon404> the type i want is the unions first element
[17:41:29 CET] <Daemon404> so i can initialize it fine
[17:41:31 CET] <Daemon404> luck!
[17:42:37 CET] <BtbN> you can probably also do { 0, 0, 0, 0, 1234 } style, if it does the assignments from left to right
[17:48:42 CET] <BtbN> Great, libva added support for more VP9 profiles and 10bit, but didn't bother bumping the version number
[17:49:57 CET] <cone-465> ffmpeg 03Vittorio Giovara 07master:2862b63783b5: lavc: Move prediction_method to codec private options
[17:49:58 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:f3af379b5c18: Merge commit '2862b63783b5556f7f3fb2d097629bc6879f833a'
[17:50:05 CET] <Daemon404> bloody hell that was an ordeal
[17:54:02 CET] <cone-465> ffmpeg 03Vittorio Giovara 07master:5b6f42da98c2: lavc: Move me_penalty_compensation to codec private options
[17:54:03 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:43c0298208ad: Merge commit '5b6f42da98c26a8aee8d2c2edfcbd0633ad1c607'
[17:54:51 CET] <BBB> this fork business is such a mess
[17:54:55 CET] <cone-465> ffmpeg 03Vittorio Giovara 07master:0e9c4fe25407: lavc: Move pre_me to codec private options
[17:54:56 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:730d2aabacd6: Merge commit '0e9c4fe254073b209970df3e3cb84531bc388e99'
[17:55:01 CET] <Daemon404> THEYRE DONE
[17:55:10 CET] <atomnuker> Daemon404: what's the point of removing a field from avctx when a ton of things use it?
[17:55:23 CET] <Daemon404> atomnuker, they all use it for different things.
[17:55:29 CET] <Daemon404> very different things.
[17:55:38 CET] <atomnuker> ah, okay
[17:55:42 CET] <Daemon404> they just shoehorned them into the closest avcts field that fit
[17:55:50 CET] <Daemon404> pre-private-options
[17:56:09 CET] <Daemon404> BBB, the ordeal was mostly fixing snow 
[17:56:14 CET] <Daemon404> and mpeg*c
[17:56:15 CET] <nevcairiel> Daemon404: if you should reach "lavf: allow custom IO for all files" .. ffmpeg already has such a callback, duplicating it seems senseless
[17:56:28 CET] <Daemon404> ill check
[17:58:07 CET] <cone-465> ffmpeg 03Martin Storsjö 07master:87a814fdce52: libavcodec: Add missing AVClass pointers
[17:58:08 CET] <cone-465> ffmpeg 03Luca Barbato 07master:c0c4d7a0a556: configure: Correctly add openssl cflags and libs
[17:58:09 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:2880e6810c97: Merge commit '87a814fdce522d45aa31aa258cb5514d7e754bff'
[17:58:10 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:27acb64a5337: Merge commit 'c0c4d7a0a556ec66e3068d36a883e84d1efb0690'
[17:58:31 CET] <nevcairiel> BBB: like i said some weeks ago, at some point we should  discuss if we really want to continue doing this, or just cherry-pick actual improvements and just let them diverge
[17:58:56 CET] <nevcairiel> no linux distribution uses libav anymore, so downstreams will just follow us wherever we go
[17:59:24 CET] <cone-465> ffmpeg 03Anton Khirnov 07master:d336bfcf69fe: pixdesc: fix and extend doxy for av_pix_fmt_get_chroma_sub_sample()
[17:59:25 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:74f5cb0189d6: Merge commit 'd336bfcf69fee159e9dba5e5e486ddb1aba61aab'
[17:59:52 CET] <Daemon404> cherry picking is a hell of a lot harder than merging
[18:00:01 CET] <kierank> yeah
[18:00:04 CET] <Daemon404> for the current time, i prefer to merge
[18:00:30 CET] <nevcairiel> not really, git can apply the same conflict resolution, except you need to do a concious decision which to bring over
[18:00:34 CET] <BBB> nevcairiel: I have no opinion on merge vs cherrypick
[18:01:02 CET] <Daemon404> nevcairiel, it is when you let codebases drift significantly by skipping some e.g. refactoring
[18:01:20 CET] <BBB> nevcairiel: Im starting to become more negative over the prospect of this ever being an advantage to anyone, and if it isnt, and people follow us, maybe we should just let libav be
[18:01:21 CET] <Daemon404> i used to cherry pick to libav and it was not fun.
[18:01:36 CET] <Daemon404> BBB, merging is absolutely an advantage
[18:01:46 CET] <Daemon404> and i believe it's partly why ffmpeg 'won'
[18:01:46 CET] <BBB> to who
[18:01:49 CET] <Daemon404> users.
[18:01:59 CET] <BBB> I agree that it was an advantage in the past
[18:02:05 CET] <BBB> and I agree its why were doing better than libav
[18:02:07 CET] <nevcairiel> honestly in the last half year or so, there was nothing in there worth having
[18:02:19 CET] <BBB> Im not sure I agree that continuing this is beneficial for us (compared to doing nothing)
[18:02:27 CET] <Daemon404> says the person who doesnt merge anyway
[18:03:00 CET] <Daemon404> i think the stuff i just merged, for example, is useful.
[18:03:33 CET] <nevcairiel> the time it takes to merge these, you could probably re-do them =p
[18:04:00 CET] Action: Daemon404 notes these arguments are the exact same ones libav gave for not merging, and doign cherry picks
[18:04:06 CET] <Daemon404> look how well thst turned out
[18:04:08 CET] <Daemon404> oh wait.
[18:04:09 CET] <nevcairiel> they dont even do those
[18:04:15 CET] <nevcairiel> they just ignore us entirely
[18:04:20 CET] <wm4> merging is definitely why ffmpeg "won", because it implies it has everything libav does (even if that is not true)
[18:04:34 CET] <wm4> sanity for one often wasn't merged
[18:04:50 CET] <Daemon404> for the time being with myself merging
[18:04:55 CET] <Daemon404> the argument is moot
[18:04:59 CET] <Daemon404> you guys dont even have to do anything.
[18:06:32 CET] <nevcairiel> just wait until the next evil plan gets pushed to libav, and free your weekends :D
[18:07:32 CET] <BBB> Daemon404: so & Im thinking of the long-term mental health of contributors to this project, rather than whether my application will have libav+ffmpeg features next week
[18:07:50 CET] <BBB> becuase if you get burned out - and you will - 6 months from now, were all worse off
[18:08:19 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:7adcd4e841f3: x86inc: Make cpuflag() and notcpuflag() return 0 or 1
[18:08:20 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:f60f06d9894b: x86inc: Be more verbose in assertion failures
[18:08:21 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:715eb7ca24c9: x86inc: Improve FMA instruction handling
[18:08:22 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:91ed050f426b: x86inc: Preserve arguments when allocating stack space
[18:08:23 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:5ca8e195e51c: x86inc: Use more consistent indentation
[18:08:24 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:fd6ecac38eb3: x86inc: Simplify AUTO_REP_RET
[18:08:25 CET] <cone-465> ffmpeg 03Henrik Gramner 07master:002c47798da0: x86inc: Avoid creating unnecessary local labels
[18:08:26 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:9de85c544aaa: Merge commit '002c47798da0c43a053822c8041144798d49ed84'
[18:08:45 CET] <Daemon404> [17:07] <@BBB> becuase if you get burned out - and you will - 6 months from now, were all worse off <-- considering i average like 2 patches a year
[18:08:49 CET] <Daemon404> "worse off"
[18:12:03 CET] <BBB> maybe its a dutch expression
[18:12:03 CET] <BBB> sorry
[18:12:07 CET] <BBB> it means were all fucked
[18:12:54 CET] <cone-465> ffmpeg 03Geza Lore 07master:cc602061ee86: x86inc: Add debug symbols indicating sizes of compiled functions
[18:12:55 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:4736f8115be4: Merge commit 'cc602061ee860b041013397e27a036b85cd87b09'
[18:13:02 CET] <Daemon404> i dont see how
[18:14:17 CET] <cone-465> ffmpeg 03Anton Khirnov 07master:68395f8c9939: qsvenc: fix a typo
[18:14:18 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:06278265239f: Merge commit '68395f8c99393c281a08139d20a7a04398b2fd04'
[18:14:59 CET] <BBB> we lose 2 patches a year, we lose a positive voice in this irc channel, a reviewer on the mailinglist, heck even a community person working at some us company thats into video streaming
[18:15:07 CET] <BBB> no, I couldnt possibly see how any of these would be bad for us
[18:15:09 CET] <nevcairiel> Honestly the reason why I think merging should be re-considered is because the quality and substance of their changes has gone down greatly, their "review" process is a sham really
[18:15:13 CET] <BBB> o_O
[18:15:19 CET] <kierank> nevcairiel: yes that's kind of the problem
[18:15:35 CET] <Daemon404> that is true
[18:16:10 CET] <Daemon404> got to 'lavf: allow custom IO for all files'
[18:17:05 CET] <nevcairiel> for example, no-one is going to review every single of anton's next big refactoring pushes, so there is two choices, either I do it now on their ML, or I do it when I merge ... since I need to review every change anyway when merging since our code is different, I tend to do it then and fix it as appropriate =p
[18:17:15 CET] <nevcairiel> or replace "I" with whoever merges at that instance
[18:18:39 CET] <atomnuker> Daemon404: are you done with pushes for now? I have some stuff okay'd
[18:18:46 CET] <Daemon404> atomnuker, yes
[18:18:47 CET] <Daemon404> im thinking
[18:19:09 CET] <Daemon404> nevcairiel, thats a bad example to use
[18:19:21 CET] <Daemon404> because i think almost all of anton's changes are very useful
[18:19:28 CET] <Daemon404> and would be picked anywya
[18:19:41 CET] <kierank> yes TEP was what took libav* from a neckbeard project into the 21st century
[18:20:03 CET] <nevcairiel> like I said, free your weekends, because it requires every single demuxer and whatnot to be changed in one step
[18:20:21 CET] <Daemon404> nevcairiel, part of the problem is the way we merge
[18:20:25 CET] <Daemon404> it's One Guy Who Merges
[18:20:28 CET] <Daemon404> instead of a team effort.
[18:20:34 CET] <nevcairiel> the last TEP was a team effort
[18:20:37 CET] <nevcairiel> refcounting
[18:20:41 CET] <Daemon404> yes
[18:20:43 CET] <Daemon404> and only that.
[18:20:45 CET] <cone-465> ffmpeg 03Rostislav Pehlivanov 07master:3bbe7862ec81: diracdec: move the MAX_DWT_LEVELS macro to dirac.h
[18:20:46 CET] <cone-465> ffmpeg 03Rostislav Pehlivanov 07master:f02103036526: diradec: split tables away to a separate diractab file
[18:21:32 CET] <Daemon404> anyway
[18:21:36 CET] <Daemon404> on to something more relevant
[18:21:39 CET] <Daemon404> [17:16] <@Daemon404> got to 'lavf: allow custom IO for all files'
[18:21:48 CET] <Daemon404> you suggested i skip
[18:21:53 CET] <Daemon404> but that would be an API breakage
[18:22:20 CET] <nevcairiel> the alternative is providing two callbacks that do the same thing
[18:22:23 CET] <nevcairiel> thats worse
[18:22:23 CET] <nevcairiel> =p
[18:22:40 CET] <Daemon404> do they do exactly the same thing?
[18:22:52 CET] <nevcairiel> they get called when a new file is supposed to be opened
[18:23:08 CET] <Daemon404> doesnt answer me :P
[18:23:10 CET] <nevcairiel> not sure how widely ours is used, but its in the AVFormatContext
[18:23:45 CET] <nevcairiel> i think theirs is a bit more generic, ours is meant more as a filterign function
[18:23:53 CET] <nevcairiel> but still plenty overlap
[18:23:59 CET] <Daemon404> hmm.
[18:25:01 CET] <Daemon404> how have we handled such scenarios in the past
[18:25:17 CET] <nevcairiel> usually by duplication and deprecating our variant
[18:25:24 CET] <nevcairiel> no clue how old ours even is
[18:25:40 CET] <Daemon404> yeah, but if they do separate things
[18:25:44 CET] <Daemon404> then thats not possible
[18:30:54 CET] <Daemon404> not merging anymore today though
[18:46:29 CET] <Daemon404> rcombs, ^
[18:46:37 CET] <Daemon404> either the sidx index is wrong, or code is busted
[19:21:30 CET] <wm4> remind me, what is the theoretical maximum h264 can delay a frame? shouldn't it be 16 frames?
[19:21:39 CET] <kierank> yes
[19:22:17 CET] <wm4> ok
[19:23:25 CET] Action: Daemon404 allocs 16 4k cinema frames
[19:25:38 CET] <wm4> I guess I don't quite understand the relation between input packets and frame output logic, and what has_b_frames has to do with it
[19:26:51 CET] <nevcairiel> has_b_frames is a measure of amount of delay in this particular stream
[19:28:34 CET] <wm4> so if has_b_frames is 2, you need to feed the decoder 3 packets to get 1 frame, right
[19:28:53 CET] <iive> yes, the decoder could "store" 2 frames
[19:29:00 CET] <iive> before output anything.
[19:29:17 CET] <wm4> but in that scenario, how could it reorder a frame to output it much later than 2 or 3 frames?
[19:29:42 CET] <iive> let's say we have IBBBBB...BBBI
[19:29:59 CET] <iive> the B frame references the two I frames.
[19:30:23 CET] <iive> the decoder stream looks IIBBBBB...BBB
[19:31:06 CET] <BBB> iive: lies!
[19:31:06 CET] <nevcairiel> wm4: just because it stores only 2 frames doesnt mean that one of those couldnt be stored for a long time
[19:31:08 CET] <wm4> oh I see
[19:31:13 CET] <wm4> yeah
[19:31:31 CET] <wm4> but then, why would that be limited by 16?
[19:31:51 CET] <iive> max_b_frames ?
[19:32:19 CET] <BBB> 16 is the max number of refs
[19:32:31 CET] <BBB> not the max number of time units that refs can be stored
[19:33:00 CET] <nevcairiel> its also the max size of the DPB, but that is closely related to ref frames
[19:33:04 CET] <iive> wm4: the thing is, that it the above examples, it stores only the second I frame.
[19:33:12 CET] <BBB> DPB is basically n_refs + 1
[19:33:17 CET] <BBB> so I guess max_refs is then 15
[19:33:22 CET] <BBB> or something like that
[19:33:37 CET] <BBB> or in other words, cur_frame is a ref also
[19:33:43 CET] <iive> or rather, the future frame and the previous one.
[19:55:36 CET] <wm4> is max_dec_frame_buffering what I'm looking for?
[19:56:57 CET] <nevcairiel> no,  num_reorder_frames
[19:57:02 CET] <nevcairiel> one before that
[19:57:26 CET] <nevcairiel> but its only set in very few bitstreams
[20:02:53 CET] <wm4> what I'm looking for is the number of frames the output of a picture can be delayed maximally, and I don't see how num_reorder_frames could be that value
[20:03:16 CET] <RiCON> Daemon404: https://j.fsbn.eu/wxDK.txt
[20:03:24 CET] <nevcairiel> wm4: 16
[20:03:32 CET] <nevcairiel> but num_reorder_frames is that number
[20:03:36 CET] <nevcairiel> but its hardly reliable
[20:03:48 CET] <nevcairiel> bvecause its rarely available
[20:05:56 CET] <Daemon404> RiCON, i guess ill hunt down whatever fork of utvideo im supposed to use and try
[20:06:04 CET] <Daemon404> i would ask, of course: wtf do you use it for
[20:06:18 CET] <wm4> I'm trying to understand out why using has_b_frames packets for reordering PTS is enough to handle avi timestamps, but not enough after decoding
[20:06:44 CET] <RiCON> i don't, personally, but those don't seem like errors from utvideo
[20:06:57 CET] <Daemon404> theyre not
[20:07:05 CET] <Daemon404> but if you dont use it, why build it
[20:07:29 CET] <Daemon404> [19:05] <@Daemon404> RiCON, i guess ill hunt down whatever fork of utvideo im supposed to use and try <-- referring to the fact that upstream utvideo does nto actually build into libutvideo.
[20:07:58 CET] <RiCON> i help maintain a building script that includes libutvideo as feature
[20:08:08 CET] <RiCON> zeranoe has it too
[20:08:10 CET] <Daemon404> ... c++ cant do some_array[] = {1,2,3}?
[20:08:15 CET] <Daemon404> i need to have [3]?
[20:08:16 CET] <Daemon404> really?
[20:08:25 CET] <RiCON> i use https://github.com/qyot27/libutvideo.git
[20:08:35 CET] <Daemon404> RiCON, yes he just builds with everything possible
[20:08:40 CET] <Daemon404> 90% is useless
[20:08:59 CET] <RiCON> just give me a reason to not include it :)
[20:09:19 CET] <Daemon404> not one he'll accept
[20:09:24 CET] <Daemon404> im dling/fixing
[20:10:38 CET] <nevcairiel> Daemon404: such an array definition should be valid in c++
[20:12:34 CET] <Daemon404> ffconf.RAvjgsDs.c:(.text+0x0): multiple definition of `main'
[20:12:34 CET] <Daemon404> /home/daemon404/dev/f/u/lib/libutvideo.a(Coefficient.o):Coefficient.cpp:(.text.startup+0x0): first defined here
[20:12:41 CET] <Daemon404> yes this is a quality fork/library
[20:12:50 CET] <Daemon404> A+
[20:13:19 CET] <JEEB> lol
[20:13:31 CET] <Daemon404> it fails to configure because of that
[20:13:54 CET] <JEEB> because it defines main itself :V
[20:14:29 CET] <Daemon404> /* This file is NOT a part of "utv_core" module. */
[20:14:30 CET] <Daemon404> from that file
[20:14:35 CET] <Daemon404> so it shuldnt even be included
[20:14:38 CET] <Daemon404> quality fork, etc
[20:14:38 CET] <JEEB> :DDDD
[20:14:40 CET] <JEEB> yeah
[20:14:47 CET] <Daemon404> how did this ever work
[20:15:08 CET] <RiCON> btw, you're using HEAD and not master, right?
[20:15:19 CET] <JEEB> uhh
[20:15:23 CET] <JEEB> HEAD is a HEAD from some branch
[20:15:25 CET] <RiCON> HEAD as in 15.1.0
[20:15:26 CET] <JEEB> master is a branch
[20:15:27 CET] <JEEB> :V
[20:15:28 CET] <Daemon404> ...
[20:15:33 CET] <Daemon404> HEAD of master
[20:15:37 CET] <Daemon404> like 99% of people will use
[20:15:50 CET] <RiCON> yeah, that never worked
[20:15:54 CET] <Daemon404> A+
[20:15:57 CET] <RiCON> try with 15.1.0
[20:16:20 CET] <Daemon404> daemon404 at bbvm:~/dev/f/libutvideo$ git branch
[20:16:20 CET] <Daemon404> * 15.1.0
[20:16:21 CET] <Daemon404> well.
[20:16:22 CET] <Daemon404> i was.
[20:16:25 CET] <JEEB> :D
[20:16:33 CET] <RiCON> hm, wonder how zeranoe makes it work then
[20:16:44 CET] <Daemon404> he probably stashed a .a somewhere
[20:16:47 CET] <Daemon404> and manualyl fixed
[20:16:53 CET] <Daemon404> i did say this was crap
[20:17:05 CET] <RiCON> oh, he doesn't.
[20:17:11 CET] <RiCON> why did i think he included it
[20:17:42 CET] <JEEB> because he does the kitchen sink
[20:17:43 CET] <Daemon404> regardless, i guess ill fix ffmpeg's C++
[20:17:49 CET] <Daemon404> otherwise someone will harass me'
[20:18:01 CET] <Daemon404> even if NOTHING builds libutvideo in a way we can use
[20:21:42 CET] <RiCON> what does a working libutvideo have that native utvideo doesn't, again?
[20:22:03 CET] <nevcairiel> 10-bit
[20:22:32 CET] <Daemon404> yes
[20:27:57 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:0ea716f70b0f: libutvideo: Unbreak
[20:36:26 CET] <jamrial> Daemon404: you could make the AVCodec and AVClass use initializers while at it
[20:36:36 CET] <jamrial> that way you'd get rid of all the pointless NULL lines
[20:36:39 CET] <Daemon404> no. i cant
[20:36:41 CET] <Daemon404> it's C++.
[20:37:01 CET] <jamrial> ah
[20:37:49 CET] <J_Darnley> Isn't it such a great language.
[20:37:54 CET] <nevcairiel> its intentionally not supported because they dont like that style in C++, instead use constructors
[20:40:46 CET] <wm4> nevcairiel: but classes now support static intiializers, and there are initializer lists which look like the C thing except they are 1000% more complex
[20:46:07 CET] <llogan> kierank: why is grub stuff being held back on ffmpeg1?
[20:48:38 CET] <Daemon404> ...grub
[20:48:40 CET] <Daemon404> ?
[20:54:06 CET] <Compn> ffmpeg bootloader ?
[20:54:16 CET] <michaelni> i did put it on hold because kieran said grub updates break stuff
[20:54:24 CET] <michaelni> didnt want to find out if thats true ;)
[20:55:10 CET] <michaelni> break due to raid&grub&whatever IIRC
[20:55:18 CET] <llogan> ok. i never had it break anything, but i'm not at all interested in dealing with grub.
[20:55:55 CET] <J_Darnley> Oh I think I get it now.  "ffmpeg1" is some computer somewhere and the grub package is not being updated on it.
[20:57:14 CET] <Daemon404> ah.
[20:59:35 CET] <llogan> J_Darnley: you are correct. you win a washing machine...or what's in the box!
[20:59:50 CET] <wm4> take the box!
[20:59:51 CET] <J_Darnley> What's in the box!
[21:00:02 CET] <llogan> you win ffmpeg1! you are now the maintainer!
[21:00:14 CET] Action: J_Darnley cackles, evilly.
[21:00:40 CET] <llogan> cone-465 ffmpeg Lou Logan master:02948sif: MAINTAINERS: James Darnley is now server maintainer
[21:00:54 CET] <llogan> J_Darnley: ping
[21:01:00 CET] <llogan> grub is broken
[21:08:21 CET] <wm4> hm, the claws-mail databases is getting corrupted again
[21:10:04 CET] <llogan> wm4: what's the symptoms? I use claws and haven't had issues
[21:12:46 CET] <Compn> claws gets stupid after a couple thousand mails. i keep deleting old ones...
[21:13:11 CET] <wm4> llogan: when mails from one folder suddenly show up in the wrong one
[21:13:19 CET] <wm4> it's because its index is somehow corrupted
[21:16:27 CET] <llogan> i may have seen that once or twice, but it "fixes" itself after reopening folder. have 65k messages among 12 folders. (vast majority FFmpeg mailing lists)
[21:16:56 CET] <wm4> not sure how many I have, must be over 100k
[21:17:14 CET] <wm4> ffmpeg-devel alone is 47k
[23:03:38 CET] <RiCON> Daemon404: apparently there's patches to make 15.4.0 compile with linux
[23:03:47 CET] <RiCON> probably doesn't work with ffmpeg as is
[23:03:48 CET] <Daemon404> A+
[23:03:59 CET] <RiCON> trying now
[23:07:40 CET] <nevcairiel> Daemon404: you broke mjpegenc =p
[23:08:42 CET] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mjpegenc.c;h=b751d1402a9c889104b5ce412af2da0640dae583;hb=HEAD#l291 .. listing the same initializer twice causes the c99 converter to assert (priv_class)
[23:11:06 CET] <Daemon404> shit
[23:11:13 CET] <Daemon404> i didnt even get a warning about that
[23:11:18 CET] <Daemon404> git merge happily placed it in
[23:11:20 CET] <Daemon404> it seems.
[23:11:48 CET] <Daemon404> i even ran fate like 10 times
[23:11:50 CET] <nevcairiel> yeah sometimes it likes to do that, happened once before, which is why I remember what the problem was
[23:12:03 CET] <nevcairiel> and compilers generally dont complain if they both init to the same value
[23:12:05 CET] <Daemon404> gcc and clang are quite happy with it too
[23:12:10 CET] <Daemon404> not even a peep
[23:12:55 CET] <Daemon404> nevcairiel, care to push a fix?
[23:13:02 CET] <Daemon404> im not logged in on ym dev box
[23:13:04 CET] <Daemon404> and am lazy.
[23:13:15 CET] <nevcairiel> same, about to head to bed
[23:13:27 CET] <Daemon404> lol damn.
[23:14:58 CET] <cone-465> ffmpeg 03Derek Buitenhuis 07master:c4ef6c883bb6: mjpegenc: Remove duplicate initializer
[23:15:00 CET] <Daemon404> there
[23:17:51 CET] <jamrial> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/aes_ctr.c;h=234354374f38435a041bd8f66ca1774bd9072bc3;hb=HEAD#l82 shouldn't this be av_free(a)?
[23:18:54 CET] <Daemon404> looks like it...
[23:19:19 CET] <Daemon404> eh... whats with the untypedef'd and all caps struct
[23:19:37 CET] <Daemon404> oh it is typedef'd... just not in the func
[23:35:00 CET] <cone-465> ffmpeg 03James Almer 07master:0711c5bfb8b4: avutil/aes_crt: free AVAESCTR struct properly
[23:38:48 CET] <RiCON> Daemon404: looks like it'd need some updating to the code https://j.fsbn.eu/EvJH.txt https://www.diffchecker.com/upcpgqad
[23:39:46 CET] <Daemon404> utvideo has no api.
[23:39:49 CET] <Daemon404> it's not a library.
[23:40:17 CET] <Daemon404> it's an unwinnable game of chase
[23:41:00 CET] <RiCON> yeah, i don't care either
[23:41:20 CET] <Daemon404> even the fork im supposed to use is apparently not maintained or tested
[23:41:23 CET] <Daemon404> so uh... :V
[23:41:23 CET] <llogan> just get rid of it
[23:41:27 CET] <Daemon404> I WANT TO
[23:42:02 CET] <llogan> i know...i submitted a patch to do so
[23:42:10 CET] <Daemon404> so did i.
[23:42:16 CET] <Daemon404> ill send one tomorrow again
[23:42:33 CET] <Daemon404> now it's more broken than ever.
[23:43:45 CET] <llogan> refer to "[PATCH] libutvideo: remove libutvideo wrapper" if you want to see old discussion
[23:44:54 CET] <Daemon404> without lookinh, 5 bucks says stephen hutchenson was fighting for it almost solely
[23:45:28 CET] <Daemon404> (he maintains the fork that isnt maintained)
[23:45:31 CET] <RiCON> qyot?
[23:45:35 CET] <Daemon404> yes
[23:46:02 CET] <RiCON> the 15.1 branch still works, more or less, at least in mingw
[23:46:25 CET] <Daemon404> except for that whole 'main' thing.
[23:46:27 CET] <JEEB> also re 10bit
[23:46:28 CET] <JEEB> The wrappers also don't support the 10-bit variants of Ut Video's
[23:46:29 CET] <JEEB> 4:2:2 codec, but when I last checked, the native one didn't either.
[23:47:03 CET] <RiCON> unless he somehow picks up on updating the wrappers and the fork
[23:47:13 CET] <JEEB> ,,, and then mini adds support to 10bit!?
[23:47:35 CET] <JEEB> also qyot doesn't even fight for the wrapper
[23:47:39 CET] <Daemon404> o
[23:47:45 CET] <jamrial> hey, times they are a changin'
[23:47:46 CET] <jamrial> we got rid of quvi, aacplus and vo-aac
[23:47:50 CET] Action: Daemon404 sedates JEEB 
[23:47:51 CET] <jamrial> we can get rid of this one
[23:48:01 CET] <JEEB> From my perspective as the one taking the Ut Video release zips
[23:48:01 CET] <JEEB> and updating libutvideo itself, I don't particularly care whether the
[23:48:01 CET] <JEEB> lib wrapper is removed.  Not that I can provide any insight beyond
[23:48:02 CET] <JEEB> that, since I only make sure the lib still compiles.
[23:48:15 CET] Action: TD-Linux goes on doom9 and realizes people are still installing Ut Video
[23:48:36 CET] <JEEB> TD-Linux: it has things for all major multimedia frameworks
[23:48:39 CET] <JEEB> it just makes sense
[23:48:56 CET] <JEEB> it's a lossless format, pretty fast and with good VFW/QT/MF support
[23:48:59 CET] <llogan> i use it when i have to use Premiere 'n junk and need intermediates
[23:49:13 CET] <TD-Linux> QT hasn't had pluggable decoders in a long time
[23:49:24 CET] <Daemon404> no, the api has been deprecated
[23:49:26 CET] <JEEB> then I wonder what this module for it is then :P
[23:49:27 CET] <Daemon404> everyone still develops for it.
[23:49:30 CET] <Daemon404> because you have to.
[23:49:43 CET] <JEEB> and probably what Dae says :P
[23:49:48 CET] <TD-Linux> Daemon404, is there a way to install them system wide still?
[23:49:55 CET] <Daemon404> that, i am unsure of
[23:50:15 CET] <TD-Linux> or is it just an API that programs manually implement themselves now?
[23:50:23 CET] <JEEB> http://umezawa.dyndns.info/archive/utvideo/utvideo-15.4.0-macosx.zip
[23:50:26 CET] <JEEB> feel free to try?
[23:50:31 CET] <Daemon404> i wouldnt be surprised if major NLEs did
[23:50:37 CET] <JEEB> from http://umezawa.dyndns.info/wordpress/?p=5754#more-5754
[23:50:37 CET] <TD-Linux> IIRC someone had looked at this for XiphQt and determined it wasn't possible systemwide anymore at least
[23:50:55 CET] <JEEB> at least it seems to get used in NLEs
[23:50:59 CET] <JEEB> so it seems to work
[23:51:31 CET] <JEEB> also huh, umezawa seems to have an internal git repo now?
[23:51:39 CET] <RiCON> the patches http://git.pld-linux.org/?p=packages/utvideo.git;a=tree
[23:51:42 CET] <JEEB> since he notes that his zipballs are now done with git archive
[23:51:56 CET] <Daemon404> RiCON, oh good random packager patches
[23:51:59 CET] <Daemon404> my favourite
[23:52:07 CET] <Daemon404> to a fork with further patches
[23:52:24 CET] <Daemon404> ah no it uses the zip. but still.
[23:52:30 CET] <RiCON> and it's still your makefile
[23:52:48 CET] <Daemon404> i also wrote the .cpp files
[23:52:51 CET] <Daemon404> it haunts me to this day
[23:53:03 CET] <JEEB> oh nice
[23:53:05 CET] <JEEB> https://github.com/umezawatakeshi/utvideo
[23:53:08 CET] <JEEB> official github
[23:53:09 CET] <JEEB> :V
[23:53:29 CET] <Daemon404> wow real VCS
[23:53:32 CET] <Daemon404> no more zip drops
[23:53:53 CET] <RiCON> still sjis though
[23:54:01 CET] <JEEB> he still does them but I started looking at his stuff after I read the part "this zipball was made with git archive"
[23:54:21 CET] <JEEB> RiCON: windows still makes it very easy to create files with that
[23:54:28 CET] <JEEB> if you are on japanese locale
[23:55:09 CET] <JEEB> also I think the gplv2 being sjis is a historical thing
[23:55:18 CET] <JEEB> the japanese translation probably was encoded as such
[23:55:31 CET] <JEEB> because that way it would open in windows's text editors :P
[23:55:47 CET] <RiCON> doesn't notepad work with utf-8
[23:56:02 CET] <JEEB> only with stuff that *nix editors don't usually write
[23:56:27 CET] <JEEB> but yeah, japanese gplv2 file from 2002 :P
[23:56:31 CET] <JEEB> are you surprised it's in SJIS?
[23:58:29 CET] <TD-Linux> wow github correctly converts encoding, neat
[00:00:00 CET] --- Thu Feb  4 2016