[00:00:16 CET] <xintox_> i can send you the command i'm using if you want to reproduce it. but like i said the link and cookie expires. so its no use to post in a bug report [00:00:32 CET] <kierank> well this is open source, someone has to care then [00:00:40 CET] <kierank> or you can try and fix yourself [00:00:47 CET] <JEEB> if you scroll up the lines from kierank starting with 'nobody knows what a neulion key is' [00:00:55 CET] <JEEB> there is all that's required, more or less :P [00:01:14 CET] <xintox_> ok. i figured you guys would know what neulion is [00:01:32 CET] <xintox_> its a cdn provider for m3u8/hls streaming that uses an encryption key. [00:01:49 CET] <JEEB> *finally* you mentioned the actual thing you had issues with. [00:02:02 CET] <JEEB> ok, so you are having issues with the hls "demuxer" [00:02:09 CET] <xintox_> yeah [00:02:37 CET] <xintox_> from what i can tell ffmpeg isn't getting the updated cookie on the key file once it starts recording. [00:03:30 CET] <xintox_> perhaps there's an option i'm missing. but i don't know what it is. [00:04:10 CET] <JEEB> there seems to be some logic for cookies at least in the hls "demuxer" [00:04:18 CET] <xintox_> i saw that [00:04:40 CET] <xintox_> on the mailing list thread where it was submitted he said the cookies will pile up and still need to be fixed. [00:04:45 CET] <xintox_> that may be the isuee [00:04:57 CET] <xintox_> too long a cookie after 30-60 seconds and it crashes [00:05:14 CET] <xintox_> because he's just appending the cookie to the existing one [00:06:35 CET] <JEEB> "char *cookies; ///< holds HTTP cookie values set in either the initial response or as an AVOption to the HTTP protocol context" [00:06:43 CET] <JEEB> > initial response [00:06:55 CET] <JEEB> so if you get it later it might not get it [00:07:31 CET] <xintox_> it needs to re-apply the cookie on each key request....because neulion is chaning that every 10 seconds. [00:08:20 CET] <xintox_> i think it just grabs it on the intiial request...is that what you're seeing? [00:08:32 CET] <JEEB> no, that's what I'm reading off a random comment [00:08:42 CET] <JEEB> in the hls "demuxer" [00:08:59 CET] <xintox_> do u have a link to the line #? [00:09:37 CET] <JEEB> it does hit open_url for each segment and keys, though [00:10:01 CET] <JEEB> which does have av_dict_set(&opts, "cookies", c->cookies, 0); in it [00:10:10 CET] <xintox_> what about appending vs. overwriting? Someone mentioned that as a possible problem. [00:10:24 CET] <JEEB> "// update cookies on http response with setcookies" [00:10:51 CET] <xintox_> does it do cookies += newCookie or cookies = newCookie [00:11:16 CET] <xintox_> i don't know C so i'm not sure what the syntax would be. [00:11:19 CET] <JEEB> whatever update_options(&c->cookies, "cookies", u->priv_data); and av_dict_set(&opts, "cookies", c->cookies, 0); [00:11:22 CET] <JEEB> does [00:12:16 CET] <JEEB> oh, update_options was just on top of it [00:16:15 CET] <xintox_> what repo is that in? [00:16:24 CET] <xintox_> i don't see 'av_dict_set(&opts, "cookies", c->cookies, 0);' in FFMpeg repo [00:17:49 CET] <JEEB> the actual repo is on videolan.org, but mirrored on github and I'm going to link there due to the code browser looking better https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hls.c#L606 [01:00:40 CET] <xintox_> JEEB: thanks. how come i don't see that in the repo when i download it? [01:01:18 CET] <JEEB> no idea? make sure you're on the master branch? [01:01:23 CET] <xintox_> yup [01:01:24 CET] <xintox_> on master [01:02:40 CET] <xintox_> weird [01:02:42 CET] <xintox_> ack 'av_dict_set(&opts, "cookies", c->cookies, 0);' [01:02:44 CET] <xintox_> doesnt' find it [01:02:50 CET] <xintox_> i see its there [01:02:58 CET] <JEEB> git grep is your friend [01:07:26 CET] <xintox_> that works :) [01:08:07 CET] <xintox_> now i'm wondering. if this is only for the key request...because the request to the playlist has its own set of cookies that need to persist. [01:08:22 CET] <xintox_> afaik the playlist cookies don't change, only the key file cookies [02:11:36 CET] <Timothy_Gu> xintox_: FYI, ack uses regex by default so you need to escape the paren: ack 'av_dict_set\(&opts, "cookies", c->cookies, 0\);' [02:39:30 CET] <xintox_> Timothy_Gu: thanks! [02:44:57 CET] <cone-037> ffmpeg 03Michael Niedermayer 07master:80bfce35ccd1: swscale/x86/rgb2rgb_template: Do not crash on misaligend stride [08:50:42 CET] <zhuhc> I found that the ffmpeg H.265 decoder is not compatible with the iOS platform when the neon assembly code is enabled. When I run the decoder to decode one H.265 clip, it crashed. When I disable the neon assembly code, it worked fine. [09:01:59 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:a066ff89bcba: swscale/x86/rgb2rgb_template: Fallback to mmx in interleaveBytes() if the alignment is insufficient for SSE* [10:19:11 CET] <cone-777> ffmpeg 03Paul B Mahol 07master:04cc4d055079: avfilter/af_sofalizer: check av_fft_init return code [10:36:53 CET] <cone-777> ffmpeg 03Matthieu Bouron 07master:0c59d40ae06b: lavfi: use a video frame pool for each link of the filtergraph [10:36:54 CET] <cone-777> ffmpeg 03Matthieu Bouron 07master:ae1c750cb49f: lavc/utils: use AVPixFmtDescriptor to probe palette formats [10:47:16 CET] <cone-777> ffmpeg 03Anton Khirnov 07master:1f821750f0b8: hevcdsp: split the qpel functions by width instead of by the subpixel fraction [10:47:17 CET] <cone-777> ffmpeg 03Anton Khirnov 07master:818bfe7f0a3f: hevcdsp: split the epel functions by width [10:47:18 CET] <cone-777> ffmpeg 03Anton Khirnov 07master:688417399c69: hevcdsp: split the pred functions by width [10:47:19 CET] <cone-777> ffmpeg 03Anton Khirnov 07master:a853388d2fc5: hevc: change the stride of the MC buffer to be in bytes instead of elements [10:47:20 CET] <cone-777> ffmpeg 03Anton Khirnov 07master:0cef06df0739: checkasm: add HEVC MC tests [10:47:20 CET] <cone-777> ffmpeg 03Anton Khirnov 07master:e7078e842d93: hevcdsp: add x86 SIMD for MC [10:47:22 CET] <cone-777> ffmpeg 03Hendrik Leppkes 07master:9db8c2d7470a: Merge commit '1f821750f0b8d0c87cbf88a28ad699b92db5ec88' [10:47:23 CET] <cone-777> ffmpeg 03Hendrik Leppkes 07master:14a28298cb88: Merge commit '818bfe7f0a3ff243deb63c4b146de2563f38ffd4' [10:47:24 CET] <cone-777> ffmpeg 03Hendrik Leppkes 07master:6f0eb6229218: Merge commit '688417399c69aadd4c287bdb0dec82ef8799011c' [10:47:25 CET] <cone-777> ffmpeg 03Hendrik Leppkes 07master:d665d191a2ba: Merge commit 'a853388d2fc5be848cca839a9fdf39a97c2d7b0e' [10:47:26 CET] <cone-777> ffmpeg 03Hendrik Leppkes 07master:32105588fb23: Merge commit '0cef06df073934ca08d0357fcbbbcf2bc9b2a0cd' [10:47:27 CET] <cone-777> ffmpeg 03Hendrik Leppkes 07master:577e0132a2b5: Merge commit 'e7078e842d93436edba1f30af1f9869d3913f7fe' [11:22:54 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.0:f23efdd2401d: swscale/x86/rgb2rgb_template: Do not crash on misaligend stride [11:22:55 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.1:00c016a5f7d2: swscale/x86/rgb2rgb_template: Do not crash on misaligend stride [11:22:57 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.2:442e7c910a59: swscale/x86/rgb2rgb_template: Do not crash on misaligend stride [11:22:58 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.2:ef23c40d435b: swscale/x86/rgb2rgb_template: Fallback to mmx in interleaveBytes() if the alignment is insufficient for SSE* [11:23:00 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.3:633bf6246cfa: swscale/x86/rgb2rgb_template: Do not crash on misaligend stride [11:23:01 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.3:f8b25be7f751: swscale/x86/rgb2rgb_template: Fallback to mmx in interleaveBytes() if the alignment is insufficient for SSE* [11:23:02 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.4:bfebe3defed4: swscale/x86/rgb2rgb_template: Do not crash on misaligend stride [11:23:03 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.4:3440a9ba4f37: swscale/x86/rgb2rgb_template: Fallback to mmx in interleaveBytes() if the alignment is insufficient for SSE* [11:23:04 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.5:f8b83cfa1c85: swscale/x86/rgb2rgb_template: Do not crash on misaligend stride [11:23:05 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.5:dbc37977793b: swscale/x86/rgb2rgb_template: Fallback to mmx in interleaveBytes() if the alignment is insufficient for SSE* [11:23:06 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.6:45430c37531c: swscale/x86/rgb2rgb_template: Do not crash on misaligend stride [11:23:07 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.6:26e98f9ae54e: swscale/x86/rgb2rgb_template: Fallback to mmx in interleaveBytes() if the alignment is insufficient for SSE* [11:23:08 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.7:e7e4c65571d8: swscale/x86/rgb2rgb_template: Do not crash on misaligend stride [11:23:09 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.7:3ffc22443579: swscale/x86/rgb2rgb_template: Fallback to mmx in interleaveBytes() if the alignment is insufficient for SSE* [11:23:10 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.8:31aeb9653360: swscale/x86/rgb2rgb_template: Do not crash on misaligend stride [11:23:11 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.8:20a48eaaf18b: swscale/x86/rgb2rgb_template: Fallback to mmx in interleaveBytes() if the alignment is insufficient for SSE* [11:57:26 CET] <cone-777> ffmpeg 03Paul B Mahol 07master:c54632d3811d: avfilter/vf_stereo3d: add direct (faster) path: [13:59:02 CET] <durandal_1707> atomnuker: tried sofalizer? [14:20:33 CET] <atomnuker> durandal_1707: testing it now [14:22:14 CET] <atomnuker> any specific way I should give it a try? [14:22:33 CET] <atomnuker> I just got a bunch of SOFA files and feed them through the filter [14:22:55 CET] <atomnuker> (using headphones but can try speakers) [14:24:56 CET] <atomnuker> the headphone SOFA files don't seem to work ("Not a SimpleFreeFieldHRIR file") [14:35:59 CET] <durandal_1707> yea, only some sofa files works [14:38:39 CET] <durandal_1707> atomnuker: ARI database, hrtf b [15:36:33 CET] <cone-777> ffmpeg 03erankor 07master:23ac99dc17b0: libavutil: add aes-ctr support [15:36:34 CET] <cone-777> ffmpeg 03erankor 07master:4469e8ebb2f3: movenc: support cenc (common encryption) [15:38:21 CET] <j-b> Seriously. [15:38:50 CET] <j-b> The guy uses his full name+email on the mailing-list. How hard is that to check when pushing his patches? [15:40:29 CET] <kierank> lol kaltura [15:42:47 CET] <j-b> sorry, but here, the issue is the committer, not the author. [15:43:41 CET] <kierank> ofc [15:45:09 CET] <durandal_1707> so revert [15:45:23 CET] <j-b> Of course not, reverts are bad [15:46:18 CET] <j-b> but not caring about proper authorship is a bad idea. [15:46:29 CET] <durandal_1707> rebase it! [15:47:06 CET] <j-b> :D [15:47:49 CET] <j-b> you can do everything with rebases, IIRC [16:09:27 CET] <durandal_1707> PS4 based on FreeBSD? [16:11:03 CET] <BtbN> Yes, even the PS3 uses a BSD-Based OS [17:15:15 CET] <Daemon404> [14:46] <@j-b> but not caring about proper authorship is a bad idea. [17:15:15 CET] <Daemon404> [14:46] <@durandal_1707> rebase it! [17:15:27 CET] <Daemon404> ^ yes elvis is happy he has full authorship [17:15:29 CET] <Daemon404> anatoly too [17:16:24 CET] <TimNich> I wondered who would bring back Elvis... [18:37:00 CET] <durandal_1707> Compn: why ambisonic was never commited to mplayer? [18:37:40 CET] <Daemon404> nevcairiel, im i dense, or is this incorrect: http://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/185248.html [18:37:49 CET] <Daemon404> it looks like exactly what we were discussing to me [18:38:10 CET] <nevcairiel> aliasing shit is over my head anyway [18:59:21 CET] <rcombs> anyone ever seen the configure check for iconv check without `-liconv`, but then ffmpeg_g fail to build without the flag? [18:59:27 CET] <rcombs> (seeing this now on OSX) [19:02:11 CET] <Daemon404> os x / iconv always is weird... [19:02:17 CET] <Daemon404> usually due to system iconv vs ports iconv [19:18:08 CET] <cone-777> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:5a31f2318b8f: ffserver: allocate AVStream's internal too [19:18:09 CET] <cone-777> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:eb68c35670af: ffserver: be explicit on failed fork() msg [19:18:11 CET] <cone-777> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:1fa81430ca97: ffserver: use EXIT_FAILURE on failed child fork() [19:18:12 CET] <cone-777> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:dadb95142bd4: ffserver: free pathname before bailing out [19:18:13 CET] <cone-777> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:0bdf84b6b052: ffserver: explicitly use time_t for uptime calc [19:19:25 CET] <Daemon404> i didnt know J_Darnley and wm4 were related [19:20:55 CET] <Daemon404> ... 5a31f2318b8fed1f4711cb86eab6d9b679946878 makes my sad inside [19:20:58 CET] <Daemon404> me* [19:25:14 CET] <Daemon404> oh good it didnt even hit the ML [19:25:44 CET] <reynaldo> Daemon404: hey o/ [19:25:56 CET] <reynaldo> whats up with that one ? [19:26:10 CET] <Daemon404> uh [19:26:13 CET] <Daemon404> it's wrogn on many levels [19:26:18 CET] <Daemon404> it's half-assed at the very best [19:26:38 CET] <Daemon404> its doign a bunch of stuff with internal non-public fields instead of fixing it properly (to use new_stream) [19:26:51 CET] <Daemon404> it reads like "could be bothered to fix it properly' [19:27:11 CET] <reynaldo> it only adds a malloc and states theres a better solution to it [19:27:20 CET] <Daemon404> yes [19:27:23 CET] <Daemon404> it's a half assed fixed [19:27:27 CET] <Daemon404> [18:26] <@Daemon404> it reads like "could be bothered to fix it properly' <--- [19:27:27 CET] <reynaldo> and it is, but the code is a bit too intrincated there and its not trivial [19:27:46 CET] <reynaldo> so my intention is to get it fixed for the user that reported it and work on a proper and more involved fix as time allows [19:27:52 CET] <reynaldo> thats why I added the fix me [19:27:55 CET] <Daemon404> the latter rarely happens [19:27:58 CET] <Daemon404> we have fixmes from 2001. [19:28:04 CET] <reynaldo> this was a regresion actually, it used to work [19:28:04 CET] <Daemon404> it's bad practice. [19:28:19 CET] <reynaldo> Daemon404: if it serves of anything you can trust me on it [19:28:52 CET] <Daemon404> 'serves of anything'? [19:29:53 CET] <reynaldo> with you feeling sad that is [19:31:55 CET] <reynaldo> this got broken when AVStream.internal was introduced, seomeone pushed a related preemptive fix (on the same lines) back then (few weeks ago) but it wasn enough, the server was segfaulting, some user reported it, this is a fix [19:32:03 CET] <reynaldo> done in the same way the preemptive changes were done [19:32:13 CET] <reynaldo> the ones that werent enough to avoid this crashing [19:32:23 CET] <Daemon404> i guess i differ in opinion from most here [19:32:28 CET] <Daemon404> fix it right or dont do it at all [19:32:40 CET] <Daemon404> see the aforementioned fixmes dating back 14 years [19:32:57 CET] <reynaldo> I dont think mines are [19:33:09 CET] <reynaldo> but if you see some please ping me on it and I will see through it [19:33:42 CET] Action: Daemon404 writes a note ;) [19:33:46 CET] <reynaldo> ;) [19:34:04 CET] <Daemon404> ffserver is a great example of not dogfooding [19:34:16 CET] <Daemon404> (wrt public api) [19:34:28 CET] Action: Daemon404 still isnt sure why/who uses it [19:46:41 CET] <JEEB> recently it's been really popular on #ffmpeg and people notice that almost no-one can support you with it [19:46:52 CET] <JEEB> I've been pointing people towards ffmpeg itself as much as possible [20:17:29 CET] <Compn> durandal_1707 : commit it :) [20:17:34 CET] <Compn> just ask michaelni for svn write [20:28:45 CET] <durandal_1707> let mplayer RIP [20:32:18 CET] <kierank> +1 [20:53:54 CET] <J_Darnley> [Tue 19:19] <@Daemon404> i didnt know J_Darnley and wm4 were related <-- What do you mean? [20:58:32 CET] <cone-777> ffmpeg 03Paul B Mahol 07master:09d84e00bd88: avfilter/af_ladspa: unbreak Mch -> Nch plugins, where M < N [20:59:30 CET] <Daemon404> [18:19] -!- jlfhdvfjabsdfg is now known as J_Darnley [20:59:42 CET] <Daemon404> im referring to wm4's email address and trac name [20:59:46 CET] <J_Darnley> ah [22:32:29 CET] <ubitux> why is mmx prefered over mmxext? (libswscale/x86/yuv2rgb.c) [22:42:47 CET] <Compn> possibly faster, although i'm guessing. [22:45:06 CET] <cone-777> ffmpeg 03Andreas Cadhalpun 07master:ecf63b7cc24b: ffm: reject invalid codec_id and codec_type [22:45:12 CET] <ubitux> if mmx is faster, what would be the point of the presence of mmxext code, since every cpu supporting mmxext should be supporting mmx [22:49:53 CET] <Compn> its possible that when it was created, mmxext was faster [22:49:59 CET] <Compn> i mean, the cpu at the time... [22:50:06 CET] <Compn> but now cpus have changed [22:50:42 CET] <Compn> probably i should stfu and wait for michaelni to chime in [22:54:19 CET] <Compn> it would be interesting to benchmark functions across different cpu arch [22:56:04 CET] <nevcairiel> ubitux: how is mmx preferred? [22:56:34 CET] <nevcairiel> contrary to more typical dsp init functions, this one returns a function pointer, so whichever is earlier in the function prevails [22:56:52 CET] <ubitux> ah fuck i can't read [22:57:11 CET] <ubitux> yeah i had my the typical dsp init in mind [22:57:22 CET] <ubitux> expectations vs reality [22:57:24 CET] <ubitux> :( [22:57:27 CET] <ubitux> thx [23:40:14 CET] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libswscale/x86/yuv2rgb_templa... [23:40:26 CET] <ubitux> why is srcSliceY only honored for dst? [23:40:48 CET] <ubitux> shouldn't simply y start at srcSliceY and srcSliceY removed from line 55? [23:41:04 CET] <ubitux> (i suppose it works because the slices are always the full frame) [23:41:07 CET] <ubitux> michaelni ^ [23:47:16 CET] <ubitux> http://pastie.org/10634985 [23:47:18 CET] <ubitux> sth like this [23:47:55 CET] <michaelni> ubitux, if i dont miss somethng, then this is because sws_scales input is a slice and not a full frame, the output is a full frame [23:48:19 CET] <michaelni> the output cannot just be a slice for non trivial cases [23:48:27 CET] <ubitux> mmh [23:48:33 CET] <michaelni> because, with vertical scaling lines dot match up 1:1 [23:48:40 CET] <michaelni> unless its nearest neighbor [23:49:19 CET] <michaelni> also if fate doesnt test slices then some synthetic test would be a rather good idea [23:50:05 CET] <ubitux> in what case does slicing happens exactly? [23:50:12 CET] <ubitux> isn't the sole purpose for threading purpose? [23:53:14 CET] <ubitux> so you're saying it happens with vertical scaling [23:53:21 CET] <ubitux> i need a use case :p [00:00:00 CET] --- Wed Dec 16 2015