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

[burek]

[03:10:37 CEST] <cone-481> ffmpeg 03Michael Niedermayer 07master:46a60fe184cf: avformat: Fix ff_interleaved_peek()
[03:51:52 CEST] <cone-481> ffmpeg 03Jing Yu 07master:311a953c7608: avcodec/ppc: fix broken build when compiling libavcodec with LLVM on PPC backend
[04:01:37 CEST] <cone-481> ffmpeg 03Rick Kern 07master:8db203a9dd73: lavd/decklink: Fix compile issue on OS X
[04:56:29 CEST] <jamrial_> rcombs: could you apply patch 1 and 2 of your autobsf patchset to fix the memleak for the 3.1 release?
[04:57:02 CEST] <jamrial_> the rest can go in at a latter time, as they are or with changes
[04:57:12 CEST] <jamrial_> but the memleak should be fixed for the release
[04:59:53 CEST] <rcombs> I was just rebasing that set
[05:00:30 CEST] <Illya> ubitux: sorry, haven't gotten round to updating my patch. I will be able to do it the day after tomorrow. (life's been very busy)
[05:12:19 CEST] <jamrial_> rcombs: thanks
[05:18:48 CEST] <rcombs> ah, there was an MPEGTS muxer change so I need to tweak fate
[10:30:55 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:1e9b79b2dbc3: movenc: mark astronomical_body const string as static
[10:42:42 CEST] <ubitux> so we have a nvenc encoder
[10:42:55 CEST] <ubitux> but we also have a nvenc_h264 and nvenc_hevc encoder
[10:43:05 CEST] <ubitux> (which are btw inconsistent names)
[10:43:10 CEST] <ubitux> is this correct?
[10:43:51 CEST] <ubitux> oh nvenc is an alias for nvenc_h264, ok... great...
[10:44:10 CEST] <ubitux> can we please deprecate all of this and make it consistent?
[10:49:04 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:0d95d88fbd1a: lavc: revert the Makefile part of 330177b
[10:49:05 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:b45348130a60: Merge commit '0d95d88fbd1aeadafb8b0b1bfb880bf21b33132c'
[11:08:29 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:5e2203448ab4: configure: improve the help text for external libraries
[11:08:30 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:680ec710ec4b: Merge commit '5e2203448ab4cc8ea1d933b87f1b39b009201044'
[11:24:03 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:c0f4c7db9fea: configure: move the hardware accel libs' entries in the help text
[11:24:03 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:7bf52e12d4a1: Merge commit 'c0f4c7db9fea1c07d290a298b8db858b7ceed96d'
[11:32:32 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:85ce9636e42d: configure: move the hardware accel libs' entries in the configure output
[11:32:33 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:63ac806ccb75: Merge commit '85ce9636e42dbda06b7d0af76a528a64b113fb3a'
[11:45:27 CEST] <cone-423> ffmpeg 03Derek Buitenhuis 07master:d68fb1475856: mjpegdec: Properly fail on malloc failure
[11:45:28 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:2ab823d4a6ef: Merge commit 'd68fb1475856cf93199e2bc4eee3063902c35df7'
[11:46:42 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:65dc7ca4c8e7: Add release notes for 12.
[11:46:43 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:c7babd50de24: Merge commit '65dc7ca4c8e7e56362626a5d31e563e80108f104'
[11:56:20 CEST] <ubitux> mmh
[11:56:32 CEST] <ubitux> i can't push a merge containing several commits?
[11:56:39 CEST] <nevcairiel> sure can
[11:57:05 CEST] <ubitux> remote: -Deny-          ERROR: update contains a merge.
[11:57:09 CEST] <ubitux> maybe i missed something
[11:57:13 CEST] <nevcairiel> did you include the Merged-by line?
[11:57:15 CEST] <nevcairiel> thats required
[11:58:30 CEST] <ubitux> oh that's what i missed
[11:58:32 CEST] <ubitux> thanks
[11:59:19 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:e42b9bc8945f: nvenc: fix the rc option definitions
[11:59:20 CEST] <cone-423> ffmpeg 03Timo Rothenpieler 07master:795329dd4c5d: nvenc: Generate AUD NAL units for better compatiblity
[11:59:21 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:9427d92f40d4: nvenc: add support for lossless encoding
[11:59:22 CEST] <cone-423> ffmpeg 03Timo Rothenpieler 07master:a1e215ea0157: nvenc: Delay frame output to increase encoding speed
[11:59:23 CEST] <cone-423> ffmpeg 03Timo Rothenpieler 07master:cea1fb854c26: nvenc: Generate bufferingPeriod/pictureTiming SEI
[11:59:24 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:a1df7865039b: nvenc: only write the VUI signal type fields if they are set
[11:59:25 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:2156c4c30097: nvenc: write the VUI signal properties for HEVC
[11:59:26 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:f11ec8cee72f: nvenc: only support HW frames when CUDA is enabled
[11:59:27 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:6f58b4dc477e: nvenc: drop the hard dependency on CUDA
[11:59:28 CEST] <cone-423> ffmpeg 03Timo Rothenpieler 07master:09522a303db0: configure: Don't require nonfree for nvenc
[11:59:29 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:9375c9746010: nvenc: list the major contributors in the copyright header
[11:59:30 CEST] <cone-423> ffmpeg 03Philip Langdale 07master:10545f84b834: nvenc: De-compensate aspect ratio compensation of DVD-like content.
[11:59:31 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:3399a26d3f57: nvenc: allow setting the number of slices
[11:59:32 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:e13134c730bd: Merge commit '3399a26d3f57d462e839c0ee51223ae9aca20852'
[12:00:11 CEST] <ubitux> an extra check would be welcome, as well as fixing the nvenc aliases
[12:00:46 CEST] <ubitux> ok, anyone to continue the merge now?
[12:00:50 CEST] <ubitux> i'd like to take a pause
[12:01:08 CEST] <ubitux> next one is annoying though
[12:01:36 CEST] <ubitux> ETA: ~150 commits left to merge
[12:11:02 CEST] <nevcairiel> the next commit might not be mergeable since our ffmpeg wasnt migrated to codecpar yet
[12:11:12 CEST] <nevcairiel> which should probably happen at some point
[12:17:43 CEST] <ubitux> another commit we nooped?
[13:12:46 CEST] <nevcairiel> well it wasnt realistic to merge it since they diverge way too much, so it was decided that it should rather be re-implemented separately instead of somehow hacking that into the merge
[13:13:57 CEST] <ubitux> and it wasn't done :(
[13:28:05 CEST] <ubitux> i guess i should add it to the merge-libav.txt
[13:28:17 CEST] <ubitux> nevcairiel: anything else you know we need to add btw?
[13:35:51 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:11ee8a450499: ffmpeg: do not use deprecated AVSubtitleRect.pict
[13:42:02 CEST] <nevcairiel> ubitux: you can probably abstract that point and make it "all cli tools", but yeah
[13:42:57 CEST] <nevcairiel> dont think we skipped big things otherwise
[13:44:04 CEST] <ubitux> any reason we haven't updated the bitstream api usage too?
[13:44:13 CEST] <nevcairiel> noone did it
[13:44:14 CEST] <nevcairiel> :D
[13:44:45 CEST] <nevcairiel> bsf migration is probably easy though
[13:45:16 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:8ca78d0fefa0: lavf/utils: fix const warning at a find_decoder() call
[13:45:17 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:dfd0c0f981c5: lavc/neontest: fix constness in arm/aarch64 avcodec_open2() wrappers
[13:45:47 CEST] <ubitux> we probably want to do the bsf mig before codecpar
[13:46:00 CEST] <nevcairiel> should finally merge rcombs bsf patchset as well
[13:46:48 CEST] <ubitux> still not merged?
[13:46:54 CEST] <ubitux> rcombs please apply your patches :((
[13:47:14 CEST] <ubitux> pretty sure you have a local stack of srt and ass patches too :(
[13:51:38 CEST] <nevcairiel> he was talking about rebasing it yesterday
[14:34:48 CEST] <ubitux> http://sprunge.us/HFXF mmh.
[14:40:47 CEST] <cone-423> ffmpeg 03David Murmann 07master:0296b4b8d899: avformat/movenc: add option to use keys/mdta atoms for metadata
[14:55:42 CEST] Action: ubitux trying to figure out the purpose of avctx->subtitle_header
[14:55:56 CEST] <ubitux> why isn't it in extradata&
[15:01:22 CEST] <nevcairiel> if you dont know, noone will :D
[15:14:48 CEST] <ubitux> so it's the subtitle header in ass; and encoders uses the extradata to communicate to the muxer their own form of header/extradata
[15:15:24 CEST] <ubitux> (encoders receive data in ass, with the ass header in that subtitle_header)
[15:15:58 CEST] <ubitux> i suppose we don't have such problematic with audio or video because the raw forms don't have the need for headers
[15:16:43 CEST] <ubitux> so the $1M question
[15:16:51 CEST] <ubitux> should we add subtitle_header to codecpar?
[15:17:15 CEST] <nevcairiel> doesnt seem to be lacking or needed right now
[15:17:17 CEST] <nevcairiel> or is it?
[15:17:41 CEST] <ubitux> will be needed for users who wish to use the codecpar api
[15:17:52 CEST] <nevcairiel> what for?
[15:17:57 CEST] <nevcairiel> shouldnt the main extradata be plenty?
[15:18:11 CEST] <ubitux> it doesn't contain the ass header
[15:18:22 CEST] <ubitux> (maybe it should?)
[15:18:34 CEST] <nevcairiel> so either of those headers is useless
[15:18:39 CEST] <nevcairiel> and we shouldnt need two
[15:20:37 CEST] <ubitux> let's say you have a subtitle text encoder receiving decoded ASS data
[15:20:46 CEST] <nevcairiel> ie. when decoding, subtitle_header is even overwritten by avcodec_open2
[15:20:54 CEST] <ubitux> the ASS header currently lies into subtitle_header
[15:20:57 CEST] <nevcairiel> and then re-set by the decoder, i assume
[15:21:21 CEST] <ubitux> it's using it to interpret the dialogues (from decoded subtitles data)
[15:21:25 CEST] <ubitux> and encode it to its own markup
[15:21:36 CEST] <ubitux> now it also needs to write an extradata for the muxer
[15:21:53 CEST] <nevcairiel> but decoder->encoder communication is not governed by codecpar
[15:22:12 CEST] <ubitux> let's ignore codecpar for now
[15:22:23 CEST] <ubitux> my question is how do you communicate the ass header to the encoder
[15:22:31 CEST] <ubitux> and how it communicates its own header to the muxer
[15:23:43 CEST] <nevcairiel> so that makes subtitle_header an output for decoders, and an input to encoders, right?
[15:24:12 CEST] <nevcairiel> so those can agree about a header
[15:32:27 CEST] <ubitux> yes, iiuc, the subtitle_header is copied from decoder context to encoder context by the user
[15:32:52 CEST] <ubitux> then the encoder read it/interpret it, and outputs its own header in the encoder context extradata
[15:33:23 CEST] <ubitux> now if you put the decoded ass header in extradata instead of subtitle_header
[15:33:29 CEST] <ubitux> where is the encoder going to write its own header?
[15:33:37 CEST] <ubitux> read the extradata, free it, and reuse it?
[15:34:24 CEST] <nevcairiel> right, for that step you need the subtitle_header as a sort-of raw header
[15:35:43 CEST] <ubitux> so you think it would be better for the encoders to replace the extradata buffer instead of reading from subtitle_header and write to extradata?
[15:36:00 CEST] <nevcairiel> nah, encoders should output to extradata
[15:36:08 CEST] <nevcairiel> just like any other encoder
[15:36:19 CEST] <ubitux> yeah, that part doesn't change
[15:36:23 CEST] <ubitux> the question is from where it would read
[15:38:40 CEST] <ubitux> maybe we could have side data or something
[15:39:34 CEST] <ubitux> but if we decide to keep the subtitle_header, then we should offer a way for users to copy it from the decoder context to the encoder context
[15:39:55 CEST] <ubitux> and since they only have codecpar as interface for that purpose, it might become the holder
[15:40:16 CEST] <nevcairiel> but they dont
[15:40:22 CEST] <nevcairiel> decoder->encoder has no codecpar in between
[15:40:31 CEST] <nevcairiel> codecpar is only demuxer->decoder and encoder->muxer
[15:40:33 CEST] <nevcairiel> not in the middle
[15:40:37 CEST] <nevcairiel> there remains codec context
[15:41:10 CEST] <nevcairiel> or more specifically, there is no universal api to configure an encoder from a decoder
[15:41:18 CEST] <ubitux> ah, right
[15:41:21 CEST] <nevcairiel> it expects you to configure the encoder manually
[15:41:58 CEST] <ubitux> so i probably got lost somewhere
[16:37:38 CEST] <ubitux> errr i need dec_ctx->pkt_timebase = st->time_base;
[16:37:47 CEST] <ubitux> in order to decode properly with codecpar :(
[16:41:14 CEST] <nevcairiel> that was always required
[16:42:31 CEST] <ubitux> nevcairiel: i don't need it when decoding using the stream codec context
[16:42:55 CEST] <nevcairiel> well that has been discouraged for years now, even if it wasnt officially deprecated
[16:43:06 CEST] <ubitux> http://sprunge.us/UEIJ :(
[16:43:24 CEST] <ubitux> i wonder if i need to do something else
[16:43:31 CEST] <ubitux> so far it seems to work
[16:43:33 CEST] <nevcairiel> maybe you should find out why subtitles need pkt_timebase to absolutely be set and cant deal without it
[16:44:05 CEST] <nevcairiel> iirc video doesnt need it at all and audio only for sample skipping
[16:44:07 CEST] <ubitux> because the api sucks
[16:44:22 CEST] <ubitux> there is no way around it with the current state
[16:44:50 CEST] <ubitux> the decoded subtitles don't use the same time base as audio and video
[16:45:15 CEST] <ubitux> (they use AV_TIMEBASE, so they need to rescale and thus know the tb of the stream)
[16:45:30 CEST] <ubitux> ’ i need to write a new api for subz
[16:45:34 CEST] <ubitux> fuck my life
[16:46:21 CEST] <ubitux> but that's actually the last step before proper integration of subtitles
[16:46:40 CEST] <ubitux> (before they can be pushed savagely into lavfi)
[16:53:41 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:6bcb1e1aff2c: lavfi/subtitles: switch to codecpar
[16:54:58 CEST] <ubitux> i'm going to try to submit a draft for the new api asap
[16:55:39 CEST] <ubitux> nevcairiel: are you going to work on the merge this week end?
[16:57:43 CEST] <nevcairiel> i can probably do some later and tomorrow
[17:04:40 CEST] <ubitux> oh i can use avcodec_send_packet() and avcodec_receive_frame() for the new api
[17:05:04 CEST] <nevcairiel> of course
[17:06:09 CEST] <ubitux> that's actually perfect, just need to make a few tricks
[17:36:10 CEST] <ubitux> why do we have frame->pts and frame->best_effort_timestamp?
[17:36:53 CEST] <ubitux> in the decoding process, we have some code setting best_effort_timestamp to either pkt_pts or pkt_dts (based on reordering logic or whatever)
[17:37:05 CEST] <ubitux> but why not set frame->pts so user can just use that value?
[17:44:57 CEST] <durandal_1707> can I get comments about ylc?
[17:56:56 CEST] <nevcairiel> ubitux: there is a patch from libav in the queue i think to make it set frame->pts instead of pkt_pts
[17:57:07 CEST] <nevcairiel> (or in addition to)
[17:57:57 CEST] <ubitux> but what's the historic background of not using frame->pts in the first place, and also introducing best_effort_timestamp?
[18:13:03 CEST] <cone-423> ffmpeg 03Martin Vignali 07master:1e38791b7f8e: avcodec/exr: fix reading float channel when there is half and float channels in a file
[18:17:10 CEST] <durandal_1707> I will apply ylc soon, if I read no comments
[18:19:08 CEST] <jamrial> ubitux: shouldn't you call avcodec_free_context(&dec_ctx) after your vf_subtitles changes?
[18:19:46 CEST] <jamrial> i don't have libass here so i can't test with valgrind to confim
[18:28:59 CEST] <cone-423> ffmpeg 03Martin Vignali 07master:d96b8144c005: avcodec/exr: add missed hunks from previous exr commit
[18:53:30 CEST] <cone-423> ffmpeg 03Aman Gupta 07master:ee2a8f142b51: avcodec/omx: fix deprecation warning for ff_alloc_packet
[19:03:05 CEST] <BtbN> This will be an interesting release
[19:09:09 CEST] <durandal_1707> why?
[19:12:15 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:e73ccfd6ad10: lavfi/subtitles: fix memleak after 6bcb1e1a
[19:14:34 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:a887fbb582fe: lavfi/subtitles: remove unecessary checks
[19:14:48 CEST] <ubitux> jamrial_: you're right; fixed
[19:22:03 CEST] <BtbN> durandal_1707, a lot of hwaccel stuff was added, the RPi encoder, CUDA, VAAPI encoders/filters, ffmpeg_vaapi.c
[19:44:49 CEST] <durandal_1707> why nobody voted to ban Cehoyos?
[19:56:02 CEST] <jamrial_> durandal_1707: the four months part was arbitrary. the amount was not agreed in the meeting
[19:56:12 CEST] <jamrial_> it kinda rubbed people the wrong way
[19:56:52 CEST] <iive> durandal_1707: because 4 months are excessive and you didn't even try to explain why that ban is necessery
[19:56:57 CEST] <jamrial_> then michael enacted that arbitrary one day ban with an things got weird
[20:11:49 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:4cc896ea5f06: avformat/format: Fix registering a format more than once and related races
[20:50:31 CEST] <Compn> durandal_1707  : because no one cares ?
[20:50:38 CEST] <Compn> or they dont want to get involved
[20:50:44 CEST] <Compn> i think someone said as much in the thread
[20:51:19 CEST] <Compn> you got democratic vote anyways, so if you dont like results...
[20:52:31 CEST] <Compn> durandal_1707 : but i like you, so i hope you dont rage quit
[20:52:44 CEST] <ubitux> meanwhile no one to write release notes
[20:52:49 CEST] <Compn> not at all :D
[20:53:12 CEST] <ubitux> and we're going to release like an unwanted child
[20:53:36 CEST] <Compn> who said we need to write up release note message anyway?
[20:53:50 CEST] <Compn> for "yet another release"?
[20:54:47 CEST] <ubitux> "hey here are a thousands of cryptic lines of code after months of change, we worked a lot on it, but we were too lazy to spend half an hour making a summary, so figure out yourself"
[20:54:59 CEST] <ubitux> "also try to find what will break with your app after the upgrade ;)"
[20:55:10 CEST] <ubitux> seriously it's totally antiprofessionnal
[20:55:21 CEST] <ubitux> we passed for idiots again last time on HN
[20:56:59 CEST] <ubitux> https://news.ycombinator.com/item?id=11103066
[21:03:20 CEST] <jamrial_> ubitux: the changelog for this release seems clear enough about new features at least. but i agree some comments about new api like codecpar are probably needed
[21:05:44 CEST] <ubitux> see 65dc7ca4c8e7e56362626a5d31e563e80108f104 btw
[21:06:11 CEST] <ubitux> maybe we shouldn't release so often if we are not capable of doing them properly
[21:12:34 CEST] <jamrial_> we could cherry pick lines from those notes. unless it's considered bad practice...
[21:13:57 CEST] <Compn> ytgg
[21:14:00 CEST] <Compn> oops
[21:14:08 CEST] <Compn> yeah just copy what phronoix did
[21:14:17 CEST] <jamrial_> another option for future releases is to make people submitting new api to also add a few lines describing it to RELEASE_NOTES and not just a line to APIChanges
[21:14:37 CEST] <jamrial_> that way at the time of release it's a matter of polishing it a bit and adding an introductory paragraph
[21:15:37 CEST] <Compn> how many upvotes did that comment even get ?
[21:15:43 CEST] <Compn> "who reads release notes" 
[21:20:28 CEST] <Compn> 6 comments
[21:20:30 CEST] <Compn> way to worry
[21:28:02 CEST] <ubitux> Compn: guess how much i got by just taking 5 minutes to write my answer
[21:29:37 CEST] <Compn> we could probably just write some crap up instead of arguing :D
[21:31:29 CEST] <ubitux> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/2.5:/RELEASE_NOTES
[21:31:35 CEST] <ubitux> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/2.6:/RELEASE_NOTES
[21:31:44 CEST] <ubitux> and since then, full garbage
[21:36:26 CEST] <DSM_> our gitweb seems too old :P
[21:43:10 CEST] <jamrial_> ubitux: what i said above might work in the future. if anything to not end up with the same situation of having to write full notes from scratch with every release and nobody to do it
[21:43:42 CEST] <ubitux> fine with me
[21:55:57 CEST] <cone-423> ffmpeg 03Martin Storsjö 07master:a590d344e316: omx: Don't return > 0 from omx_encode_frame
[21:59:23 CEST] <Compn> sorry ubitux , i just get weird sometimes :\
[22:00:49 CEST] <Compn> i dont mean to argue. but i'm sorry i did
[22:31:12 CEST] <BtbN> ubitux, michaelni, https://github.com/BtbN/FFmpeg/commit/6d734b1aecac04032f170b96833a5d95be857471 any comments? Should it be pushed before the release?
[22:31:24 CEST] <BtbN> Also, do I need to bump lavc minor because of the new names?
[22:39:42 CEST] <nevcairiel> adding the new and future names early seems like a good idea
[22:40:41 CEST] <BtbN> hm?
[22:40:54 CEST] <BtbN> deprecating the existing ones without adding the new ones seems silly
[22:41:37 CEST] <nevcairiel> well of course
[22:41:52 CEST] <BtbN> Or do you mean, just adding the new ones for the 3.1 release, and deprecating the old ones after it?
[22:42:11 CEST] <nevcairiel> nah if the new ones show up the old ones should be deprecated, otherwise people would never find out
[22:42:38 CEST] <BtbN> Ok, so I'll just add the lavc version minor bump because of the new names
[22:43:03 CEST] <fritsch> may I ask (for kodi) when do you plan to release 3.1?
[22:43:09 CEST] <BtbN> today
[22:43:14 CEST] <fritsch> cause, we are currently making planes to go into beta soon
[22:43:20 CEST] <fritsch> and may bump prior to that
[22:43:54 CEST] <fritsch> okay - will investigate as fast as possible
[22:44:04 CEST] <fritsch> what feeling do you have about 3.1?
[22:44:15 CEST] <fritsch> rock solid? :-) maintainance release? feature release? bleeding edge?
[22:44:28 CEST] <michaelni> rcombs, about the patches ..., when can you push them ?
[22:45:08 CEST] <michaelni> also about release notes, can someone please write release notes, several people want release notes
[22:46:28 CEST] <michaelni> fritsch, planned today, of course it might slip and be tomorrow
[22:46:38 CEST] <fritsch> that's not a problem for us
[22:46:49 CEST] <fritsch> michaelni: what's your feeling about 3.1? all good so far?
[22:46:57 CEST] <fritsch> that's more important to us
[22:47:57 CEST] <michaelni> it seems working fine, there where a bunch of regressions that got fixed, fritsch you might want to ask carl, he tends to know every bug or so
[22:48:20 CEST] <fritsch> kodi will roughly have some months left until v17 will hit the streets, it's less than a year though - but I think going with 3.1 is a good idea
[22:48:36 CEST] <fritsch> especially considering that we are "stable" in n months first
[22:48:54 CEST] <fritsch> okay, will ask carl
[22:49:24 CEST] <fritsch> thx much
[22:51:35 CEST] <cone-423> ffmpeg 03Rodger Combs 07master:1df401505c6d: lavf/srtdec: fix probing files with negative first timestamps
[22:51:36 CEST] <cone-423> ffmpeg 03Rodger Combs 07master:150e5e13b1fa: lavf: deprecate av_apply_bitstream_filters
[22:51:37 CEST] <cone-423> ffmpeg 03Rodger Combs 07master:af7e2734b9c1: lavf: update auto-bsf to new BSF API
[22:51:50 CEST] <ubitux> BtbN: great! thanks a lot for doing this
[22:51:56 CEST] <rcombs> there memleak fixed
[22:52:16 CEST] <ubitux> rcombs: thx for srt; you could have fixed the indent though ;)
[22:52:23 CEST] <rcombs> oh dammit
[22:52:29 CEST] <ubitux> :D
[22:52:42 CEST] <ubitux> no worry :)
[22:52:50 CEST] <rcombs> I'll fix
[22:53:14 CEST] <cone-423> ffmpeg 03Rodger Combs 07master:6ee7adb881e4: lavf/srtdec: fix indent
[22:56:38 CEST] <BtbN> ubitux, am I right about this needing a lavc minor bump? It technically adds new encoders?
[22:57:43 CEST] <michaelni> BtbN, the lazy rule for minor / micro is, when in doubt bump, it does no real harm if t wasnt needed
[22:57:59 CEST] <nevcairiel> rcombs: was that the entire set now?
[23:01:13 CEST] <rcombs> nevcairiel: no, just the one people wanted for the release (since it fixes a memleak)
[23:01:24 CEST] <rcombs> nevcairiel: the later ones didn't apply cleanly and needed changes
[23:02:05 CEST] <rcombs> (resending now)
[23:08:35 CEST] <cone-423> ffmpeg 03Timo Rothenpieler 07master:888a5c794778: avcodec/nvenc: Bring encoder names in line with other encoders
[23:33:03 CEST] <jamrial_> rcombs: thanks for the bsf fix!
[23:36:21 CEST] <jamrial_> BtbN: yeah, new components are minor bump. micro is for small things like new or changed avoptions
[23:36:57 CEST] <BtbN> well, it's not realy a new component, but i guess the same rules apply
[23:37:27 CEST] <BtbN> Just another "alias" for the same encoders
[23:49:29 CEST] <cone-423> ffmpeg 03Jan Sebechlebsky 07master:d46a8e30dcac: avformat/tee: Support arbitrary number of slaves
[00:00:00 CEST] --- Sun Jun 26 2016