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

[burek]

[00:11] <cone-707> ffmpeg.git 03Timothy Gu 07master:774239be7171: ffmpeg_opt: get_preset_file_2(): fix avio_open2() return  code check
[00:16] <llogan> c91488a may break docs
[00:18] <llogan> like ticket 2243
[00:20] <Daemon404> it actually fixes the breakage
[00:40] <ramiro> hi, I'm REing some microcontroller code and stumbled upon a function I believe tries to do 24-bit multiplication, but gives an error if the result is over 16-bit. the overflow check seems wrong to me, could anyone else take a look? http://pastebin.com/Vwz8e1Lk
[00:41] <Daemon404> PIC code?
[00:43] <ramiro> upd7810. old dot-matrix printer
[00:44] <Daemon404> 0 -> error i suppose
[00:46] <Daemon404> i see what it does, but im not sure what the question is
[00:46] <Skyler_> ramiro: 0x1ff * 0xff will overflow, but the if won't trigger overflow, I think
[00:46] <Skyler_> because overflow is predicated entirely on the contents of mh, but mh + ml can overflow when mh doesn't
[00:46] <ramiro> Skyler_: that's exactly what I was thinking =)
[00:47] <Skyler_> looks like a bug.
[00:47] <ramiro> maybe I can use the bug to make glitch art with the printer
[00:47] <Skyler_> I guess I'd say if(mh&0xff00 || (mh + (ml>>8))&0xff00) would be more correct or something
[01:59] <cone-707> ffmpeg.git 03Lukasz Marek 07master:314444000494: lavu/buffer: add release function
[08:40] <andrewrk> hi, trac is taking too long to send me an email verification so I am here
[08:40] <andrewrk> here is a fix to http://trac.ffmpeg.org/ticket/3383
[08:40] <andrewrk> http://patches.libav.org/patch/47615/
[08:41] <andrewrk> that's going into libav but they had me squash it so that it won't merge cleanly into ffmpeg
[09:15] <ubitux> andrewrk: thanks!
[09:15] <andrewrk> no problem
[09:15] <ubitux> andrewrk: do you mind sending a patch rebased on ffmpeg to ffmpeg-devel mailing list?
[09:16] <andrewrk> not a problem. do I need to be subscribed?
[09:16] <ubitux> no but if you don't you won't get any feedback (unless you track the archive), and you'll have to wait for moderation
[09:16] <andrewrk> ok
[09:21] <cone-170> ffmpeg.git 03Janne Grunau 07master:5ea14d48a82a: texi2pod: always declare the pod file as UTF-8 encoded
[09:21] <cone-170> ffmpeg.git 03Michael Niedermayer 07master:a8ad7e47fb59: Merge remote-tracking branch 'qatar/master'
[09:25] <Zeranoe> I think the way configure is checking for x265 is causing a configure error. Looks like there were two recent patches relating to it: http://git.videolan.org/?p=ffmpeg.git;a=history;f=configure My version is 0.7, and i am unable to configure with it
[09:26] <ubitux> Daemon404 ^
[09:27] <ubitux> Zeranoe: the header has X265_BUILD >= 7?
[09:28] <Zeranoe> ubitux: I'm testing now, but it should be
[09:30] <c10ud> ubitux, can I abuse your patience and knowledge with a quick question about sse and unrelated to ffmeg? if it's inappropriate just say no, no worries
[09:31] <ubitux> i'm definitely not a sse expert but feel free to ask here
[09:31] <c10ud> alright thanks, I figured where all the AV gurus are would be the better place :)))
[09:31] <c10ud> I am trying to learn a bit how to operate with gcc intrinsics and my test code is a simple conversion from 6bytes uyvyyy (yes, Canon's viewfinder data uses this format) to yuyv422. I am fiddling with sse but I can't get my head around how to properly access the 6bytes data :s 
[09:32] <Skyler_> I suggest lots of pshufb
[09:34] <Skyler_> also, wouldn't that be 4:2:0, not 4:2:2?
[09:34] <Skyler_> since there's 2 u/v bytes per 4 luma bytes
[09:35] <c10ud> hey, I am new in the field, I am just doing: uy1vy2y3y4 -> y1uy2v y3uy4v
[09:35] <c10ud> and the image is good
[09:35] <c10ud> at least, ffmpeg gets it with -f raw yuyv422 
[09:36] <ubitux> c10ud: read 8/16, do your shuffling, then palignr?
[09:37] <Skyler_> my standard strategy is shuffle -> punpcklqdq/punpckldq/shufps/similar to combine multiple groups of bytes
[09:38] <c10ud> btw- regarding this sse "issue" I dont get how to properly go to the next input bytes: e.g. I read 16 bytes, process 12 of them, then how to tell the pointer to increase only of 12 instead of 16? ofcourse (__m128i *)++ won't do the trick
[09:38] <Skyler_> your input pointer should be uint8_t*, not __m128i
[09:38] <Skyler_> and you should be doing unaligned loads
[09:38] <Skyler_> this is, unfortunately, the most convenient option when your inputs don't divide nicely into 16 bytes
[09:39] <c10ud> yea i thought of processing 48 bytes per iteration but, registers :)  
[09:39] <Skyler_> I suggest doing 24 per iteration if you have 3 bytes per pixel
[09:39] <Skyler_> so 2x 12
[09:39] <c10ud> I'll try again now with the  uint8_t* but _mm_load_si128 was crashing :x
[09:40] <Skyler_> is that the unaligned load intrinsic?
[09:40] <c10ud> should be aligned, I'll try loadu now
[09:40] <Skyler_> if you're increasing by 12, that's going to be unaligned
[09:41] <c10ud> fuck me, it works
[09:41] <c10ud> and I must say yesterday I tried loading unaligned etc. but I must have had some other error so I thought I was doing bad things
[09:41] <c10ud> :(
[09:42] <c10ud> thank you guys, sorry for the noise :) now I can finally play with conversion
[09:43] <Zeranoe> ubitux: The only X265_BUILD I'm finding is: '#define x265_encoder_open x265_encoder_glue2(x265_encoder_open_, X265_BUILD)'
[09:52] <Zeranoe> Interesting, it's actually in x265_config.h, mine says '#define X265_BUILD 5' but it was built from hg today so it's at least 7. x265.pc reports 'Version: 0.7' so at least that is correct. Perhaps that isn't the safest way to check for the API version?
[09:52] <relaxed> Zeranoe: be sure and run "hg pull" and "hg update" in x265's dir
[09:53] <Zeranoe> relaxed: Good call, used to git
[09:54] <relaxed> yes, I could stab them for not using it too.
[09:58] <Zeranoe> Working now, thanks
[10:38] <andrewrk> ubitux, submitted
[10:39] <andrewrk> ubitux, I subscribed to ffmpeg-devel but it still says awaiting moderator approval
[10:40] <ubitux> i guess you'll have to be trusted once
[10:40] Action: andrewrk rubs his hands together evilly
[10:40] Action: ubitux doesn't know the exact rules
[10:40] <ubitux> :)
[11:43] <ubitux> http://tech.slashdot.org/comments.pl?sid=4823359&cid=46316735 lol
[11:44] <av500> nice
[11:44] <J_Darnley> :)  The troll got two bites
[12:22] <ubitux> https://lists.libav.org/pipermail/libav-devel/2014-February/056409.html anyone to reason Diego?
[12:33] <plepere> my FFmpeg-devel thread(s) disappeared ?
[12:39] <pross-au> Some one is outta space.
[12:39] <ubitux> and here you go, just pushed
[12:44] <pross-au> 'The rule "no commits without review" ensures that another set of qualified eyes looks over code prior to commit. Adopting that policy for all developers - maintainers, committers or first time contributors - puts everybody on equal footing.'
[12:45] <ubitux> utopy gone wrong
[12:45] <plepere> well I'm all for reviewing my code, but I'd like to see feedback on it. :)
[12:46] <ubitux> we're not against review
[12:46] <ubitux> and guess what, we do some
[12:47] <plepere> :D
[12:48] <plepere> so my patch submission has to be re-done ?
[12:49] <BBB> I'm against cosmetic-only review
[12:49] <BBB> it's such an utter waste of brainpower
[12:49] <pross-au> its dick flapping what it is
[12:49] <BBB> something like that yes
[12:49] <iive> and don't forget to sort your variables in alphabetical order!
[12:50] <BBB> I believe functional review can truly improve the quality of a patch, and that's where two people working together (which is really what review is) make more than either one alone
[12:50] <ubitux> iive: and headers!
[12:50] <BBB> cosmetic changes should just be done by someone who likes doing that, and then just don't involve the original coder at all - whether he or the "reviewer" makes the cosmetic changes doesn't matter much
[12:51] <BBB> since it doesn't require intelligence or code understanding
[12:51] <BBB> it's just monkey-spacebar-pressing
[12:51] <BBB> (or sometimes, if you're lucky, enter)
[12:51] <nevcairiel> funny enough those monkeys frequently keep breaking code :D
[12:51] <ubitux> yeah actually i'd better have someone who knows how to write code before shuffling around spaces
[12:52] <BBB> I just updated from mac 10.6.8 to mac 10.9.1, and also Xcode 4.2 to 5.2
[12:52] <BBB> new software once in a while is quite nice
[12:54] <plepere> BBB : I'm changing my ASM fuctions to eliminate the width loop. 
[12:54] <pross-au> plepere: lots of empty 'if (EXERNAL_SSE2(flags) {}' blocks in your patch. are you expected these to come later?
[12:55] <plepere> we have a loop_filter in sse2
[12:56] <plepere> it's just not in this patch
[12:57] <plepere> BBB : the problem is that I've got a lot of unused pointers. is it ok ?
[13:10] <BBB> plepere: what do you mean?
[13:10] <BBB> don't tell me you're calling it as dsp->function[width](...)
[13:11] <BBB> plepere: you should use some incremental index that has lower resolution (typically you can derive that from block_width * n_partitioning_methods + partitioning_index
[13:11] <BBB> or something smaller than that
[13:11] <BBB> or make a lookup table that gives index from partitioning and block width
[13:11] <BBB> like in vp9, index is log2(block_width)
[13:12] <BBB> plepere: or do you mean something else?
[13:14] <plepere> BBB : I'm using width / 2
[13:16] <plepere> BBB : it's for a first version at least
[13:27] <smarter> plepere: I was planning to submit the loop filter to libav/ffmpeg
[13:28] <BBB> plepere: hm... well can you make it a lookup table?
[13:28] <smarter> I cleaned it up the other month, but got lazy while reviewing it
[13:28] <smarter> I'll try to do that soon
[13:28] <BBB> plepere: i.e. try to make a table that indexes all valid widths to an incremental index, and all others to MIN_INT or some other invalid integer (-1?)
[13:29] <BBB> smarter: it is assembly, not crazy intrinsics, right?
[13:29] <smarter> yes
[13:29] <smarter> it's asm :)
[13:29] <BBB> \o/
[13:30] <smarter> stseppo wrote it, and he's now doing arm assembly
[13:30] <BBB> plepere: so assuming that 2, 4, 6, 8, 12, 16, 24, 32, 48, 64 are valid widths, use static const uint8_t table[65] = { [2] = 0, [4] = 1, [6] = 2, [8] = 3, [12] = 4, [16] = 5, [24] = 6, [32] = 7, [48] = 8, [64] = 9 };
[13:31] <BBB> plepere: and then call the function table as dsp->function[table[width]](..)
[13:31] <BBB> it's one more dereference but at least it makes the table normal-size
[13:32] <BBB> maybe even make the sizes an enum so their name makes it clear what actual width they're associated with, but only if you care about that (I'm fine with straight numbers)
[13:34] <plepere> oh, you're smart, BBB.
[13:36] <plepere> thanks
[13:47] <cone-170> ffmpeg.git 03Peter Ross 07master:bef6b27f106f: avcodec/vp8dsp: use AV_ZERO64 to clear idct coefficient rows
[13:47] <ubitux> ah thanks for this ^
[13:47] <JEEB> all the HEVC talk reminds me that I was thinking if I should ask for extra info on the VUI time_scale thingy
[13:48] <JEEB> because currently it isn't AFAIK defined as either frame or field rate
[13:48] <JEEB> in AVC it was IIRC field rate
[13:48] <JEEB> HM seems to imply it's the frame rate
[13:48] <smarter> really?
[13:49] <JEEB> we had a quick look with muken 
[13:49] <JEEB> didn't seem to find any specifics
[13:49] <JEEB> which then led to https://github.com/l-smash/l-smash/commit/c7fc06c3cf02ca46b129244034cc643a9e03c9db
[13:49] <JEEB> "follow HM"
[13:50] <smarter> looks like you're right
[13:50] <smarter> so maybe the time_base in hevc.c should be changed
[13:51] <smarter> I don't know how it's interpreted
[13:51] <JEEB> I guess I should ask JCT-VC?
[13:51] <JEEB> it really should be specified methinks
[13:51] <smarter> probably
[13:51] <muken> time_scale / num_units_in_tick does not always represent framerate
[13:52] <JEEB> yes, but it should still be defined, no?
[13:52] <smarter> so how the hell does ffmpeg decide how to interpret the time_base? :p
[13:53] <muken> for instance, let say time_scale = 24, num_units_in_tick = 1, user might have specified fps=24, 12, 8, 6, and so on...
[13:54] <muken> time_scale / num_units_in_tick doesnt tell us what fps is intended
[13:55] <JEEB> yes, but unfortunately it's too often used as the frame rate >_>
[13:55] <muken> time_scale / num_units_in_tick just tell us about the resolution of steam timeline
[13:55] <muken> *stream
[13:56] <JEEB> yes
[13:58] <JEEB> For 
[13:58] <JEEB> example,  when  the  picture  rate  of  a  video  signal  is  25  Hz,  vui_time_scale  may  be  equal  to  27 000 000  and 
[13:58] <JEEB> vui_num_units_in_tick may be equal to 1 080 000, and consequently a clock tick may be equal to 0.04 seconds.
[13:58] <JEEB> I will guess since it's a "picture rate" it can be either field or frame rate, depending on the coding mode
[14:01] <JEEB> HM can encode interlaced pictures now, right?
[14:18] <cone-170> ffmpeg.git 03Hendrik Leppkes 07master:fa84231ee8f3: mpegvideo: fix overwriting hwaccel surface objects
[14:18] <cone-170> ffmpeg.git 03Hendrik Leppkes 07master:bc249bd6736f: mpegvideo: re-indent buffer clearing code
[15:54] <ubitux> JEEB: so, what's a bit stream, i'm not sure i understand ;)
[16:21] <Daemon404> Zeranoe, did you ever get it worked out?
[16:35] <ubitux> http://www.mplayerhq.hu/design4/news.html  over on the tux; is that the "cola" joke? :P
[16:35] <ubitux> hover*
[16:36] <Daemon404> ubitux, im more interested in that design
[16:36] <Daemon404> the best 1998 had to offer?
[16:36] <ubitux> design7 to jump in the future
[16:36] <Daemon404> 'future'
[16:37] <Daemon404> that designs been around for like 10 year
[16:37] <Daemon404> i swear
[16:37] <Daemon404> -s
[16:37] <ubitux> it was slightly ironic ;)
[16:37] <Daemon404> ;p
[16:38] <ubitux> but well, it has some little charm :)
[16:39] <ubitux> i actually like the style of that site
[16:40] <ubitux> design3 is nice too
[16:40] <ubitux> 5 as well
[16:40] <ubitux> there is quite some work on the logo
[16:41] <saste> hi
[16:42] <saste> i was off in the last two weeks
[16:42] <saste> did i miss something important (apart gsoc reject)?
[16:44] <ubitux> saste: aca working on getting ffmpeg back in debian, libvpx vs vp9 optim done, hevc optims incoming
[16:45] <ubitux> bayer
[16:45] <ubitux> various asm improvements by James Almer
[16:45] <ubitux> 2.2 release incoming to match libav10
[16:45] <ubitux> libx265 wrapper
[16:45] <ubitux> did i forget anything?
[16:48] <saste> ubitux: i don't know, thanks
[16:49] <JEEBsv> btw, was anyone working on E-AC3 stuff that's not supported yet?
[17:13] <nevcairiel> you mean the blu-ray eac3 tracks?
[17:13] <nevcairiel> i briefly looked into it, and iirc the decoder already has all the parts to decode it, it just needs to stitch everything together
[17:14] <JEEBsv> k
[17:19] <nevcairiel> in any case, i never found the time to do anything more with it
[18:03] <aca> Hi all, I changed the Debian FFmpeg bug to ITP and promptly Moritz replied... (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#430)
[18:17] Action: Daemon404 seems to have found a bug in the jpeg decoder \o/
[19:03] <ubitux> aca: so Moritz suggest to replace libav with ffmpeg, is that how i understand it? ;)
[19:03] <ubitux> it's funny that we have to fight for keeping both libav and add ffmpeg
[19:09] <cone-596> ffmpeg.git 03Diego Biurrun 07master:ed61f3ca8a06: parser: Remove commented-out cruft
[19:09] <cone-596> ffmpeg.git 03Michael Niedermayer 07master:030643641648: Merge commit 'ed61f3ca8a0664a697782253b354055136c5d303'
[19:11] <ubitux> aca: anyway, it looks like he's trying to gain time by playing the "ffmpeg vs libav" endless debate and the immobilism of debian to keep the current state as is
[19:12] <ubitux> aca: a ctte discussion should probably be opened asap if you don't want to waste time
[19:15] <aca> ubitux: I don't think the few days until FFmpeg will get into unstable will matter much, but I guess this will end before the TC anyway, so it can happen it as well now.
[19:16] <aca> ubitux: I guess I should ask the libav maintainers (pro forma) to consider transitioning to FFmpeg. When they reject, this can go straight to the TC as 'matter of overlapping jurisdiction'.
[19:18] <cone-596> ffmpeg.git 03Luca Barbato 07master:a1c699659d56: parser: K&R formatting cosmetics
[19:18] <cone-596> ffmpeg.git 03Michael Niedermayer 07master:72d580f819ed: Merge commit 'a1c699659d56b76c0bf399307f642c6fd6d28281'
[19:45] <llogan> andrewrk: i just approved your message. sorry about the wait.
[20:00] <cone-596> ffmpeg.git 03Andrew Kelley 07master:9e329185d701: avfilter/af_compand: fix invalid read
[20:03] <ubitux> andrewrk: thx ^ :)
[20:25] <iive> ubitux: aca: IMHO moritz words that he ends the discussion because he doesn't want to argue, basically means he doesn't want ffmpeg, but he doesn't have a single argument against it.
[20:26] Action: Daemon404 watches highschool drama
[20:30] <aca> iive: That's a reasonable interpretation.
[20:30] <aca> iive: But he obviously doesn't want to say so in the open.
[20:34] <iive> the level of politics in debian is scary.
[20:40] <cone-596> ffmpeg.git 03Anton Khirnov 07master:e7dfaf16a403: libavfilter: example audio filtering program
[20:40] <cone-596> ffmpeg.git 03Michael Niedermayer 07master:1f2bacc89722: Merge commit 'e7dfaf16a403972eb6aed5ce8f84c0085bd2fb5a'
[20:51] <wm4> so what can one do to throw oil into the drama fire?
[20:54] <ubitux> well, wait for it to start at least
[20:54] <ubitux> if we can package both ffmpeg and libav that would be for the best
[20:55] <Plorkyeran_> security team's vetoed that a few times
[20:55] <Plorkyeran_> both there and on debian-devel
[20:55] <iive> is that for all repos or just for stable?
[20:56] <Plorkyeran_> well everything has to eventually go to stable
[20:57] <Plorkyeran_> dual-packaging in testing would only to be to evaluate which one to use
[20:57] <Plorkyeran_> and not a long-term thing
[20:58] <iive> so, the decision could be taken after the evaluation. 
[21:01] <aca> iive: It would be possible to have FFmpeg in experimental and probably even unstable, but that wouldn't be of much use.
[21:01] <aca> iive: Then nobody could use FFmpeg to compile his programs, because they wouldn't make it into stable.
[21:02] <aca> On the other hand, evaluating both alternatives is possible in unstable as well as in testing.
[21:03] <aca> I would be interested in how many other package maintainers would prefer to use FFmpeg over libav. I think most upstreams use FFmpeg.
[21:05] <Daemon404> BBB, im sure youve seen http://www.prweb.com/releases/2014/02/prweb11612574.htm
[21:05] <wm4> what led to debian deciding to switch to libav anyway?
[21:05] <JEEB> siretart?
[21:05] <wm4> there must have been some formal decision with arguments
[21:06] <JEEB> Daemon404, LOL :D
[21:06] <wm4> I suppose a single maintainer can't just change everything
[21:06] <iive> wm4: no, siretart was in the fork team, so he switched without telling anybody.
[21:07] <Plorkyeran_> at the time there was no technological difference
[21:07] <Plorkyeran_> so I'm not sure what a discussion about which version to use would even consist of
[21:07] <Plorkyeran_> the choice was to let the maintainer switch to his preferred fork or find a new maintainer
[21:10] <aca> wm4: In Debian a package maintainer can to pretty much anything with the package he maintains.
[21:10] <wm4> even if half of everything depends on it?
[21:11] <aca> Well, if the change is sort of compatible, it's not easy to complain, without offering to maintain the other fork.
[21:11] <iive> well, technically, ffmpeg is trademarked and debian is breaking it, by using it for completely different project...
[21:12] <Plorkyeran_> they did eventually remove the ffmpeg compat package
[21:12] <llogan> how many years did that take?
[21:12] <iive> yes, but the debian package is still named ffmpeg, isn't it?
[21:13] <Plorkyeran_> no
[21:13] <aca> iive: The Debian source package is now called libav.
[21:13] <Plorkyeran_> only stable and oldstable have packages named ffmpeg
[21:14] <iive> do these packages contain ffmpeg or fork?
[21:14] <Plorkyeran_> oldstable is ffmpeg 0.5
[21:14] <Plorkyeran_> stable is libav 0.8
[21:16] <Plorkyeran_> and the ffmpeg package in stable does in fact install the program named ffmpeg
[21:16] <nevcairiel> thats the one that yells at you for using a deprecated function, isnt it :p
[21:20] <wm4> that was really a fuckup
[21:21] <nevcairiel> they dont see it like that :D
[21:21] <nevcairiel> anyway
[21:21] <nevcairiel> back to implementing icy
[21:23] <llogan> yes, it was a great side effect for them. convinced many users that FFmpeg is no longer developed since distinction between ffalse ffmpeg and FFmpeg project is not always known.
[21:26] <andrewrk> np ubitux. thanks llogan 
[21:28] <andrewrk> llogan, it's true. that was what I thought at first as well
[21:29] <andrewrk> I'm really unhappy about the whole situation. I wish everybody could get along :(
[21:31] <cone-596> ffmpeg.git 03Diego Biurrun 07master:4ec336484d63: parser: cosmetics: Drop some unnecessary parentheses
[21:31] <cone-596> ffmpeg.git 03Michael Niedermayer 07master:2673357048eb: Merge remote-tracking branch 'qatar/master'
[21:32] <aca> andrewrk: I also wish everybody could get along, but it seems this is not possible. :(
[21:33] <andrewrk> I console myself that this "competition" might motivate development
[21:33] <andrewrk> as long as everybody plays fair
[21:33] <wm4> haha
[21:34] <wm4> well, look at this way: if all ffmpeg and libav developers were in the same project, development wouldn't be possible because drama and bikeshedding would not allow any progress
[21:36] <andrewrk> I guess it makes sense - given any sufficiently large body of people there will be disagreements about the direction of the project
[21:41] <nevcairiel> wm4: you contributed the ICY support for the http protocol, right?
[21:41] <wm4> yes
[21:42] <nevcairiel> is the metadata block always string? i figured it would possibly be a binary ID3 block or something, but the code wouldn't support that
[21:42] <nevcairiel> i'm only getting headers, the packet option is always empty
[21:43] <wm4> at least I haven't seen anything like that yet
[21:43] <wm4> what's your test source?
[21:43] <nevcairiel> the avoption handles it like a string, so if it happens to start with a 0 byte, it would show up empty
[21:43] <nevcairiel> http://dradio-ogg-dlf-l.akacast.akamaistream.net/7/629/135496/v1/gnl.akacast.akamaistream.net/dradio_ogg_dlf_l
[21:44] <wm4> hm
[21:44] <nevcairiel> time to debug into the code that reads it
[21:45] <nevcairiel> too bad avoptions are really crappy at string handling
[21:45] <nevcairiel> AV_OPT_TYPE_BINARY is an evil hack :p
[21:45] <wm4> returning data via avoptions is an evil hack too
[21:45] <nevcairiel> i guess
[21:46] <wm4> I had some evil ideas like injection ID3 tags (so the demuxer could read them), but unfortunately this just can't work
[21:46] <wm4> this stream doesn't seem to send a Icy-MetaInt header
[21:48] <nevcairiel> hm looks like you're right, the icy headers i have are only of rather generic nature
[21:49] <nevcairiel> hm ok an mp3 stream i tried has data in a text format
[21:49] <nevcairiel> oh well, just going to build a parser for that then
[21:51] <nevcairiel> i need better string parsers, hate quoted strings w ith possible escapes in them :(
[21:52] <wm4> I'm not sure what convention icy "packets" follow
[21:53] <wm4> seems generally very unreliable
[21:55] <nevcairiel> maybe i should just hack together a rather dumb parser, in the long run it may turn out to be more reliable on inconsistent input
[21:55] <wm4> that's what I did
[21:56] <nevcairiel> too bad the protocol can't reach the demuxer to just inject it into the metadata
[21:56] <wm4> some streams have icy _and_ ogg metadata, but the stream you posted doesn't seem to have anything on song changes
[21:56] <wm4> yeah
[21:57] <nevcairiel> the same station also has a mp3 stream, it had proper icy packets
[21:57] <wm4> weird
[21:58] <nevcairiel> anyway something for tomorrow, shouldn't be too hard to parse the headers and the packet
[21:58] <nevcairiel> headers dont usually change, do they
[21:59] <nevcairiel> wonder if the http protocol ever reconnects
[21:59] <nevcairiel> probably not if it doesnt have to
[22:00] <wm4> not sure if http.c reconnects automatically if the connection is dropped
[22:55] <kierank> andrewrk: yes but it's a pita for users
[22:58] <andrewrk> agreed
[23:10] <andrewrk> so when I ported the compand filter to libav, they had me change it from double to float
[23:11] <andrewrk> I've heard arguments on both sides for one or the other
[23:11] <andrewrk> honestly I don't think it makes too much of a difference. but it would be nice if both projects agreed...
[23:12] <Compn> andrewrk : whichever is fastest on most hardware :p
[23:13] <andrewrk> hmm good point. that is objectively measurable
[23:40] <durandal_1707> you are making audiophiles unhappy
[23:41] <thardin> pacify them with some $500/m CAT5
[00:00] --- Wed Feb 26 2014