[03:13:12 CET] <cone-346> ffmpeg 03Michael Niedermayer 07master:08c220d26cff: avcodec/huffyuvdec: Check input buffer size [03:54:59 CET] <cone-346> ffmpeg 03sfan5 07master:e752da546463: dashdec: Support SegmentTimeline inside Period [11:44:44 CET] <cone-809> ffmpeg 03Muhammad Faiz 07master:5a2abf00f194: avcodec/codec_desc: sort codec_descriptors [11:53:37 CET] <cone-809> ffmpeg 03Muhammad Faiz 07master:81d6501be77b: checkasm/Makefile: add EXTRALIBS-swresample [13:14:23 CET] <Chloe> wm4, michaelni: Im looking to fix any issues with the new api itself tomorrow (not issues with it at the moment), apart from libcaca is there anywhere else you know of issues? [13:15:24 CET] <michaelni> Chloe, thanks, theres another thing related but its probably not correct to call it an issue in the patchset [13:15:58 CET] <Chloe> michaelni: what is it [13:16:37 CET] <michaelni> ossfuzz broke too as it used to grep for REGISTER or something. Thats a design issue on how the ffmpeg ossfuzz finds codec names [13:17:22 CET] <michaelni> for reference: https://github.com/google/oss-fuzz/issues/1146#issuecomment-364284953 [13:18:06 CET] <Chloe> michaelni: see the find_things macro in configure [13:18:25 CET] <Chloe> Function* [13:18:45 CET] <JEEB> yea, the fuzzer was expecting something which is no longer true [13:34:51 CET] <wm4> Chloe: can't think of anything [13:35:14 CET] <wm4> for cmdutils, take care not to trigger the sox thing again (there's something on the ML) [13:35:48 CET] <Chloe> wm4: libsoxr? [13:37:43 CET] <wm4> ah I confused it, it was about building without lavd [13:39:09 CET] <JEEB> yea [13:39:19 CET] <JEEB> just make it builds without lavd/lavf [13:39:22 CET] <JEEB> *make sure [13:39:28 CET] <JEEB> since that's IIRC what you were touching [13:40:02 CET] <wm4> also I bet people will always come back to the problem that lavf doesn't iterate lavd devices anymore [13:41:02 CET] <JEEB> that is actually correct, they are two separate libraries and the fact that -f used to pull in lavd stuff was derp to begin with (although for bw compatibility the -f option in ffmpeg.c can be made to still select stuff from lavd [13:41:59 CET] <wm4> yeah, but many things seem to rely on getting both [13:44:24 CET] <Chloe> wm4: it does build without lavd I just forgot an ifdef in my new cmdutils code [13:44:37 CET] <Chloe> The cmdutils patch broke the most things [13:44:45 CET] <JEEB> yea, just yunno - adding that to the series of tests :) [13:46:06 CET] <Chloe> So Ill fix caca and redo cmdutils patch tomorrow. Then we can see whats left [13:51:03 CET] <JEEB> sure [14:52:10 CET] <durandal_1707> michaelni: for how long will you have power to give ssh git access to anybody? [15:00:06 CET] <jamrial> durandal_1707: drop the trolling [15:05:55 CET] <Chloe> Is there a reason Nicolas and Carl arent on irc [15:06:42 CET] <durandal_1707> jamrial: stop bulying me [15:08:32 CET] <jamrial> Chloe: i guess they don't like it and prefer to keep all discussion on the ml [15:12:30 CET] <RiCON> iirc carl does read irc logs at least [15:22:36 CET] Action: gnafu waves at Carl. [16:45:15 CET] <Maxz> hi, is there a libavformat HLS maintainer here? [16:46:41 CET] <BBB> Chloe: some people dont like IRC, thats totally OK I think [16:47:48 CET] <wm4> Maxz: probably (not me btw.) [16:48:35 CET] <Chloe> BBB: shame its not ok to dislike email [16:48:51 CET] <wm4> let's switch to github! [16:49:15 CET] <BBB> didnt steven liu maintain hls? [16:49:22 CET] <BBB> IIRC he is on IRC [16:49:27 CET] <BBB> sometimes [16:50:01 CET] <wm4> Anssi is formally the maintainer and he's here, also tmm1 did a lot on it [16:50:15 CET] <wm4> but the point is if you have a question just ask it [16:52:30 CET] <Chloe> wm4: I know youre joking but github is at least easier to work with than email [16:58:24 CET] <kierank> git send email is useless [16:59:40 CET] <wm4> I use it all the time though [17:00:22 CET] <RiCON> easier to review than attached patches [17:01:04 CET] <durandal_1707> let's fork! [17:04:43 CET] <kierank> wm4: you run your own mail server or downgrade gmail security i assume [17:05:13 CET] <wm4> getting it to work with gmail was a pain but somehow it works for me now [17:05:39 CET] <wm4> maybe it's because I also access my mail via IMAP [17:12:58 CET] <kierank> why do i still get nvidia crap with --disable-everything [17:13:00 CET] <kierank> how do I fix this [17:19:10 CET] <RiCON> --disable-autodetect [17:20:06 CET] <relaxed> kierank: or "nvenc='no' ./configure ..." [17:21:23 CET] <kierank> RiCON: but I don't have an nvidia card [17:21:34 CET] <kierank> why is it "autodetecting" one if everything is disabled [17:22:51 CET] <RiCON> idunno, ask whoever made the policy on what should be "autodetected"/system libs [17:23:37 CET] <RiCON> maybe it'll stop being autodetected when nvidia headers move off the repo [17:23:49 CET] <wm4> autodetect never considers installed hardware only libs [17:24:02 CET] <wm4> and since cuda/nvenc/etc. has internal headers it's always autodetected [17:24:12 CET] <wm4> I wonder what happened to moving the headers out [17:34:32 CET] <jamrial> wm4: the repo is there, so it's a matter of updating configure [17:45:25 CET] <jamrial> if the headers are going to be updated as nvidia releases new nvenc/dec sdks, then to avoid compilation issues with stable ffmpeg branches the headers repo should have its own branch for each ffmpeg release [17:48:06 CET] <BtbN> wm4, jamrial: I have a working patch for mingw/linux/cygwin, but it doesn't work on msvc because pkg-config is weird there. And so far I haven't found time to fix that. Then it's good to go from my end. [17:50:41 CET] <wm4> can we just not care about MSVC and leave it to whoever it interested in it to send a patch [17:50:52 CET] <wm4> it's a pretty obscure and hard to test platform [17:51:17 CET] <BtbN> I won't push something that breaks the build on a platform that is perfectly supported right now. [17:51:54 CET] <BtbN> Or alternatively drops support entirely. [17:53:30 CET] <BtbN> jamrial, I will make branches on the header repo for each nvidia headers release [17:53:52 CET] <BtbN> so you have the option to build modern ffmpeg with older nvidia headers, to support legacy drivers. [17:54:11 CET] <BtbN> each breaking nvidia headers release [17:55:35 CET] <jamrial> so configure in release branches would then look for an specific version using pkg-config? like "ffnvcodec = 8" or however you write it [17:55:45 CET] <BtbN> yes [17:56:21 CET] <BtbN> <9 for sdk 8 [18:03:10 CET] <Maxz> well, I wrote a patch to avoid an HLS demuxer error. When it reaches the "max_reload" limit (added recently), libavformat/hls.c:read_data returns AVERROR_EOF. After that another component on ffmpeg libs keeps trying to get new content from the HLS manifest. The max_reload limit can be reached between 3 and 10 times before stop the consuming and close the outputs. After the first max_reload is reached, FFmpeg is not able to recover itself if there [18:03:23 CET] <Maxz> transcoding stop working [18:03:31 CET] <Maxz> streamcopy keeps working fine [18:04:39 CET] <Maxz> I don't know why transcoding (demuxing->encode) stops [18:05:03 CET] <Maxz> I wonder if someone here can help to explain it [18:05:28 CET] <Maxz> because I want good argumentation for the patch i wrote [21:42:42 CET] <feliwir> hey, how can i get the default pixelformat for an AvCodecContext? [21:43:03 CET] <feliwir> (before using any send_packet/receive_packet stuff) [21:44:11 CET] <JEEB> the default's only known after you get a decoded picture [21:44:16 CET] <JEEB> or well, not default but what it actually is [21:44:21 CET] <nevcairiel> whats a "default" anyway [21:44:27 CET] <JEEB> yea [21:44:37 CET] <JEEB> you get the pix_fmt that matches what's in the stuff [21:44:37 CET] <nevcairiel> if you're decoding, there is only one choice - the one the decoder gives you [21:44:46 CET] <JEEB> yup [21:44:51 CET] <nevcairiel> if you're encoding, the encoder typically has a list of supported formats [21:44:58 CET] <nevcairiel> not sure if any of those are more default then others [21:47:19 CET] <feliwir> well, when i am decoding vp6 then it will always be in yuv (didn't see any other yet) [21:47:42 CET] <feliwir> so it would be cool to get the format before doing any stuff [21:47:42 CET] <nevcairiel> yeah decoders dont let you choose, they decode to the native format of the bitstream [21:47:56 CET] <nevcairiel> but sometimes this format isnt known before you feed it packet data [21:55:56 CET] <feliwir> okay thanks [21:56:44 CET] <feliwir> i think i asked this before: how do i jump back to frame 0 with a codecCtx (also for files that don't support seeking. I pretty much want to return to start) [21:57:17 CET] <JEEB> you reset the decoder, and seek to byte position zero [21:57:19 CET] <JEEB> I would guess? [21:59:32 CET] <feliwir> JEEB, there is a reset function? [21:59:47 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [21:59:53 CET] <JEEB> this mentions it :P [22:02:25 CET] <feliwir> thanks :) [22:03:26 CET] <feliwir> can i pass null to avcodec_receive_frame to get the AVERROR_EOF [22:04:26 CET] <JEEB> no? the idea of flushing is when you want all the pictures currently in buffer in the decoder [22:04:38 CET] <JEEB> so you do it in send_packet/send_frame [22:04:58 CET] <JEEB> if you just want to stop and reset I think you might be able to do that without draining? [22:05:03 CET] <JEEB> not sure, though [22:05:49 CET] <feliwir> ye, that's what i wanted to do :D [22:19:16 CET] <cone-809> ffmpeg 03Aurelien Jacobs 07master:b7915f8a149a: aptx: simplify by pre-calculating factor_max [22:19:26 CET] <cone-809> ffmpeg 03Aurelien Jacobs 07master:fea8e119a2bc: aptx: factorize FFABS calculation [22:19:31 CET] <cone-809> ffmpeg 03Aurelien Jacobs 07master:96b217f5e878: aptx: do some clipping to match original codec in extreme cases [22:19:32 CET] <cone-809> ffmpeg 03Aurelien Jacobs 07master:6fd110a0940f: aptx: implement the aptX HD bluetooth codec [22:19:33 CET] <cone-809> ffmpeg 03Aurelien Jacobs 07master:d8258489c87e: aptx: add raw muxer and demuxer for aptX HD [22:19:34 CET] <cone-809> ffmpeg 03Aurelien Jacobs 07master:c69054fa24f5: aptx: indentation (cosmetics only) [22:29:21 CET] <atomnuker> I hope he's satisfied because I sure am not [22:30:38 CET] <atomnuker> I look forward to him trying to add 3 more codec IDs for each sbc profile and me naking the hell out of that crap [22:38:57 CET] <jamrial_> atomnuker: ? [22:39:12 CET] <jamrial_> oh, that aptx set [22:39:24 CET] <atomnuker> his earlier sbc patch had 1 codec id for each profile [22:39:30 CET] <atomnuker> so 3 in total [22:39:39 CET] <atomnuker> and they had little to no bitstream changes in between [22:40:23 CET] <atomnuker> I really hope they're identifiable bitstream-wise unlike aptx [22:42:54 CET] <atomnuker> they must be, they can't not be, because how is hardware going to determine what's what if all it gets is the raw bitstream [22:43:23 CET] <nevcairiel> but is it? no control headers? [22:45:22 CET] <jamrial_> that reply of yours was kinda unnecessarely passive-aggressive, atomnuker [22:47:33 CET] <jamrial_> you really need to chill. too many times you get angry and lash out at people for no reason whatsoever [22:47:55 CET] <jamrial_> and i have told you this before [22:48:14 CET] <jamrial_> and it's getting tiresome [22:49:34 CET] <atomnuker> how else am I going to express my dislike for the patch when he's one of those not on IRC and email is less than suitable for informal stuff like this? [22:50:13 CET] <jamrial_> definitely not how you did it, for starters [22:50:24 CET] <feliwir> is the duration in stream always the number of frames? Or does it depend on the codec? [22:50:41 CET] <JEEB> it depends on the container [22:50:51 CET] <jamrial_> especially considering that you ultimately agreed with the committed aproach given that there's no way to identify the bitstream as you said [22:50:51 CET] <JEEB> some files have non-constant durations [22:51:26 CET] <JEEB> feliwir: things with just a "frame rate" field are the exception, not the norm [22:52:01 CET] <jamrial_> you express dislike direcly, in a proper review, and absolutely never with a passive aggressive reply [22:52:13 CET] <wm4> durations are almost always either from a file header (unreliable), or calculated from bit rates (unreliable) [22:52:55 CET] <wm4> even things like mp4 (which has a "perfect" file header and index) could have inaccurate durations because the file was incorrectly cut off etc. [22:54:40 CET] <feliwir> JEEB, i guess there is no way to check which unit it is? [22:55:05 CET] <feliwir> because i can't find a reliable method to get the stream duration [22:56:21 CET] <jamrial_> so again, chill up. Have a drink and a good night sleep before you write a reply next time. the project doesn't need any more aggressiveness between and towards contributors [23:09:34 CET] <atomnuker> I'd need to finally move to chill out and function properly again, can't take this place/city/country anymore and moving is very difficult [23:10:40 CET] <wm4> Britain? [23:24:05 CET] <atomnuker> yep [23:26:03 CET] <Chloe> can confirm, Britain makes people sour. [23:35:22 CET] <cone-809> ffmpeg 03Mark Thompson 07master:10bcc41bb40b: examples: Don't call deprecated functions which don't do anything [23:40:15 CET] <atomnuker> sucks even more if you're an EU citizen [23:40:51 CET] <atomnuker> each time I have to go abroad I come back and something's worse [23:42:46 CET] <wm4> make your own brexit [23:43:03 CET] <atomnuker> and my passport's stopped working at the uk scanner gates (and is slightly bent because a hamfisted worker thought there was a gap between the glass and the paper) [23:46:53 CET] <rcombs> tmm1: ping [23:48:55 CET] <tmm1> rcombs: sorry haven't forgotten but i'm swamped at the moment [00:00:00 CET] --- Sat Feb 10 2018