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

[burek]

[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_template.c;hb=HEAD#l54
[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