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

Sat Feb 10 03:05:03 EET 2018

[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