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

[burek]

[00:42] <Tim_G> BtbN: https://trac.ffmpeg.org/ticket/4207#comment:1
[00:44] <BtbN> Tim_G, yep, they released a new SDK and didn't bother keeping the api compatible..
[00:45] <Tim_G> BtbN: OK, just letting you know
[00:45] <BtbN> they could have just left that field in as a dummy
[00:45] <BtbN> but nope
[00:45] <BtbN> gonna break code
[00:46] <BtbN> and i think i need a new GPU. h265 hw encoding sounds too interesting.
[00:51] <jamrial> based on the quality of h264 hw encondes i remember seeing, you're probably better using software encoders
[00:51] <jamrial> unless you need real time encoding for streaming or something
[00:51] <Daemon404> in which case youll likely end up with something worse than x264 can produce anyway
[00:52] Action: Daemon404 has yet to see a competetive hevc encoder
[01:06] <kierank> merry christmas
[01:26] <cone-985> ffmpeg.git 03Michael Niedermayer 07master:b51cc701bc4a: avcodec/vc1_mc: use the same reference as luma does in ff_vc1_mc_4mv_chroma()
[02:56] <cone-985> ffmpeg.git 03Kieran Kunhya 07master:1515bfb3132d: vf_scale: Use correct chroma positions for YUV420P
[09:27] <j-b> 'lo
[09:28] <aetasx> you're supposed to be asleep.  santa's not gonna come if you're awake
[13:04] <cone-440> ffmpeg.git 03Michael Niedermayer 07master:68fa549230af: avformat/segment: Use av_freep() avoid leaving stale pointers in memory
[13:04] <cone-440> ffmpeg.git 03Michael Niedermayer 07master:443bd2715d42: avformat/wtvdec: Use av_freep() avoid leaving stale pointers in memory
[13:04] <cone-440> ffmpeg.git 03Michael Niedermayer 07master:7dce91368f85: avformat/smoothstreamingenc: Use av_freep() avoid leaving stale pointers in memory
[16:08] <cone-440> ffmpeg.git 03Timo Rothenpieler 07master:1efdb0a43f15: avcodec/nvenc: Remove special cases for cygwin
[18:00] <j-b> what's the use case of supporting older nvenc APIs?
[18:00] <Daemon404> there isn't one
[18:01] <j-b> Ok
[18:02] <j-b> So, adding defines for an old API that requires more cruft?
[18:02] <Daemon404> nvidia doesnt care or support it
[18:02] <Daemon404> why should we?
[18:03] <j-b> exactly my question
[18:34] <nevcairiel> One define for the latest and previous isn't too bad, just drop it when it needs another version related update
[18:35] <j-b> well, the previous requires this crazy license-dummy
[18:35] <j-b> else, I would understand
[18:36] <nevcairiel> Not like I really care, I'll get the latest anyway when I start using it in a couple month once I find the time
[18:36] <ubitux> damn, why am i greylisted
[18:38] <j-b> but I'd love to see the new header, though...
[18:38] <ubitux> (please no one ack the xcb-shm patch from carl, i sent a mail but i'm grey listed for $reason)
[18:39] <nevcairiel> Just grab the new SDK?
[18:39] <j-b> very limited connection here in holidays and I don't want to "agree"
[19:30] <cone-99> ffmpeg.git 03Michael Niedermayer 07master:0c0168a2104b: avformat/cache: support non continuous caching
[19:39] <michaelni> ubitux, i think because of: "IP addr in hostname: bre75-1-78-192-242-8.fbxo.proxad.net", but it seems the mail already came through so i assume this doesnt need any admin action?
[19:42] <ubitux> ah yeah, i changed my IP
[19:42] <ubitux> yeah i guess it should be ok
[19:47] <ubitux> michaelni: i'm still greylisted for every mail though
[19:48] <ubitux> maybe it still doesn't like something in my smtpd
[19:48] <ubitux> i thought i fixed the issue last time
[20:01] <nevcairiel> Many mail servers will gray list you when you send from such a generic non descript hostname directly
[20:01] <Daemon404> makes sense
[20:01] <Daemon404> botnets etc
[20:04] <ubitux> no i believe it's something else
[20:04] <wm4> <Daemon404> nvidia doesnt care or support it
[20:04] <wm4> <Daemon404> why should we?
[20:05] <wm4> this is about a project which has 3 encoders for a certain lossless codec...
[20:05] <Daemon404> 3?
[20:05] <Daemon404> i know one with 2,
[20:05] <Daemon404> which is 3
[20:06] <wm4> prores
[20:06] <Daemon404> thats not lossless
[20:06] <Daemon404> and i thought it was 2
[20:06] <wm4> maybe it is
[20:06] <Daemon404> kostya's and "elvis"'s
[20:06] <wm4> either way, substitute it with $SOMETHING_DUMB
[20:11] <kierank> Weird that my patch didn't break fate
[20:34] <kierank> most mailservers won't let you send mail using a residential ip as a mail server
[20:39] <Loriker> merry christmas !
[21:13] <compn> Daemon404 : why do you think prores is lossy ?
[21:13] <compn> broadcasters wouldnt use lossy
[21:13] <kierank> because it is lossy
[21:13] <kierank> lossless is far too slow to edit
[21:14] <compn> oh ok
[21:14] Action: compn has no idea
[21:18] <wm4> I think I was actually thinking about utvideo and the pointless wrapper for that broken lib
[21:19] <JEEBsv> that one qyot dude is kind of maintaining the lib
[21:19] <JEEBsv> which is kind of sadfunny
[21:19] <JEEBsv> he's the guy who is providing "optimized for pIII" builds of everything
[21:30] <Daemon404> he isnt maintaining it
[21:30] <Daemon404> he just has a random repo with a build system on top
[21:30] <Daemon404> upstream doesnt even support buildign as a unix lib
[21:33] <compn> the wonders of open source! 
[21:33] <compn> the system works!
[21:33] <JEEBsv> lol
[21:33] <compn> the anime philes apparently run the multimedia codec world though. i was hoping the broadcast pros would take over when prores hit
[21:34] <compn> but one scary warning about being non optimized in fcp.... :P
[21:34] <compn> the archive pros are happy with ffv1 it seems
[21:36] <kierank> Well not yet
[21:36] <kierank> More at FOSDEM...
[21:38] <compn> kierank : you talk to broadcast people, any chance you would write down their wishlist for ffmpeg ? 
[21:38] <compn> might influence our attentions
[21:51] <kierank> well in general ffmpeg is untrustworthy because you have to test everything between versions
[21:51] <kierank> that's why ffmbc moves at a snails pace
[21:51] <kierank> timestamps are important in broadcast
[22:11] <cone-99> ffmpeg.git 03Michael Niedermayer 07master:681559d3ffeb: avformat/cache: remember EOF point if hit and use it to handle SEEK_END
[22:11] <cone-99> ffmpeg.git 03Michael Niedermayer 07master:dedd3c89ae6a: avformat/cache: more informative error message
[22:11] <cone-99> ffmpeg.git 03Michael Niedermayer 07master:7018d3d3510e: avformat/cache: Use the correct io handle in seeking
[22:11] <cone-99> ffmpeg.git 03Michael Niedermayer 07master:8706910c4c05: avformat/cache: Support user specified read-ahead for non seekable media
[23:51] <cone-99> ffmpeg.git 03Clément BSsch 07master:2188df96cf49: avfilter/xbr: refactor alpha blending macros
[23:51] <cone-99> ffmpeg.git 03Clément BSsch 07master:006caf03d700: avfilter/xbr: remove unused mask
[23:51] <cone-99> ffmpeg.git 03Clément BSsch 07master:20cac72a4f6d: avfilter/xbr: move alpha blend assignment out of the macros
[23:51] <cone-99> ffmpeg.git 03Clément BSsch 07master:87984d2fe260: avfilter/xbr: refactor px calculation in FILT[234]
[23:51] <cone-99> ffmpeg.git 03Clément BSsch 07master:6e6b0a8eed40: avfilter/xbr: reindent after previous commit
[00:00] --- Fri Dec 26 2014