[00:31:16 CEST] <cone-653> ffmpeg 03James Almer 07master:ab3c04c45805: avformat/dtshddec: parse chunks stored after audio data [00:31:17 CEST] <cone-653> ffmpeg 03James Almer 07master:60c2e38dcbe4: avformat/dtshddec: implement AUPR_HDR chunk parsing [04:23:08 CEST] <cone-837> ffmpeg 03ZhouXiaoyong 07master:af3e944e7edd: avcodec/mips/h264dsp_mmi: Version 2 of the optimizations for loongson mmi [08:02:17 CEST] <taniey> hello, [08:02:27 CEST] <taniey> anybody here? [08:03:36 CEST] <taniey> sorry ,I send the message error [11:03:55 CEST] <cone-639> ffmpeg 03Paul B Mahol 07master:95b20ad7b20c: avcodec/iff: fix artifacts with uncompressed ham ANIMs [14:11:22 CEST] <cone-639> ffmpeg 03Hendrik Leppkes 07master:a9bb4cf87d1e: h2645_parse: support badly muxed mp4 streams [14:24:48 CEST] <cone-639> ffmpeg 03Anton Khirnov 07master:8d0cc8ca9767: h264_parser: switch to h2645_parse for NAL unescaping [14:24:49 CEST] <cone-639> ffmpeg 03Hendrik Leppkes 07master:15ad02321074: Merge commit '8d0cc8ca97678f4ca87948ebabcbaab5a4f4c1f6' [14:24:50 CEST] <nevcairiel> Daemon404: ^ [14:27:45 CEST] <Illya> I'm stumped trying to do SDL2, maybe someone could look at my patchset (1st patch wasnt by me). https://gist.github.com/anonymous/881f64f93903cd21859f08220ef41514#file-0003... The first & second patch work, but the third patch ends up in a "Undefined symbols for architecture x86_64: "_ff_sdl2_muxer", referenced from:..." [14:27:45 CEST] <Illya> error. I've make clean, configure, make, and it didn't change the output. I'm sure it's something obvious [14:33:05 CEST] <Shiz> Illya: you didn't add sdl2.c to the files to build... [14:34:10 CEST] <Shiz> you want to edit libavdevice/Makefile [14:34:15 CEST] <Shiz> to say OBJS-$(CONFIG_SDL_OUTDEV) += sdl.o sdl2.o [14:34:40 CEST] <Shiz> (or create a new CONFIG_SDL2_OUTDEV) [14:35:07 CEST] <Illya> Hmm, well it was there before. Wonder how it got lost. Probably my bad git skills [14:35:10 CEST] <Illya> Thanks [14:44:55 CEST] <Daemon404> nevcarriel awesomw [15:50:58 CEST] <cone-639> ffmpeg 03Anton Khirnov 07master:e9f884416c76: h264: move reading direct_spatial_mv_pred out of ff_set_ref_count() [15:50:59 CEST] <cone-639> ffmpeg 03Derek Buitenhuis 07master:7ab2c036b917: Merge commit 'e9f884416c76558098fc1f63825b293956e8483c' [16:04:14 CEST] <cone-639> ffmpeg 03Anton Khirnov 07master:56b17a33f231: h264: stop testing whether the reference count changes in ff_set_ref_count() [16:04:15 CEST] <cone-639> ffmpeg 03Derek Buitenhuis 07master:6b295bccbbf7: Merge commit '56b17a33f231859cbccbd741b4763617cb4ecf03' [16:16:57 CEST] <cone-639> ffmpeg 03Anton Khirnov 07master:a6e27f7add26: h264: factor out parsing the reference count into a separate file [16:16:58 CEST] <cone-639> ffmpeg 03Derek Buitenhuis 07master:278dcec28db8: Merge commit 'a6e27f7add2698fdd89911632b570c3d0c3f2aaa' [16:19:40 CEST] <cone-639> ffmpeg 03Anton Khirnov 07master:71d3305c2711: h264_parse: make sure the ref count is zeroed on all failure paths [16:19:41 CEST] <cone-639> ffmpeg 03Derek Buitenhuis 07master:d55568d22a5a: Merge commit '71d3305c2711d4f6ec8b92db09ff64cf4e19a58e' [17:17:25 CEST] <pfelt> greatest of mornings everyone! [17:19:39 CEST] <Illya> hi pfelt [18:14:43 CEST] <BBB> is ibm spamming our bugtracker? [18:15:00 CEST] <BBB> I really dont think thats appropriate, even if theyre doing bounties, they should probably do that somewhere outside our bugtracker? [18:15:12 CEST] <BBB> or am I too sensitive? [18:15:57 CEST] <nevcairiel> gotta make people for their obsolete architecture somehow [18:16:03 CEST] <nevcairiel> +care [18:16:50 CEST] <Daemon404> POWER? [18:16:59 CEST] <Daemon404> i mean [18:17:08 CEST] <Daemon404> who the hell uses ffmpeg on POWER [18:17:10 CEST] <Daemon404> and why would they [18:18:09 CEST] <ubitux> power8 is not obsolete [18:18:24 CEST] <ubitux> https://en.wikipedia.org/wiki/POWER8 [18:18:30 CEST] <Daemon404> [17:17] <@Daemon404> who the hell uses ffmpeg on POWER [18:18:30 CEST] <Daemon404> [17:17] <@Daemon404> and why would they [18:18:33 CEST] <Daemon404> still stands [18:18:54 CEST] <rcombs> <@Daemon404> who the hell uses& POWER [18:19:02 CEST] <rcombs> <@Daemon404> and why would they [18:19:02 CEST] <rcombs> ftfy [18:19:08 CEST] <ubitux> because ibm, pro, enterprise ... [18:19:36 CEST] <nevcairiel> ubitux: it is in my book [18:19:46 CEST] <nevcairiel> its their last grasp at keeping an obsolete tech going [18:20:34 CEST] <rcombs> "it's not obsolete! citation: they're still making them" [18:26:55 CEST] <BBB> hm.... [18:27:24 CEST] <BBB> I think ubitux is on to something [18:28:46 CEST] <Daemon404> as in milking enterprises for money? [18:29:43 CEST] <ubitux> i think power8 has more use cases than mips [18:29:55 CEST] <Daemon404> of course [18:29:58 CEST] <Daemon404> but nobody here writes mips [18:30:01 CEST] <Daemon404> they send it [18:30:54 CEST] <ubitux> sure, probably no one here is going to write ppc simd, just like no one interested will write mips simd [18:30:55 CEST] <jamrial> aren't some smartphones mips? [18:31:25 CEST] <Daemon404> not any that people use [18:31:31 CEST] <Daemon404> except maybe in china [18:31:34 CEST] <ubitux> you mean smartphones with no gsm nor screen and with a bunch of ethernet slots? [18:31:46 CEST] <Daemon404> lol [18:37:47 CEST] <nevcairiel> mips is mostly routers and the like, not sure about phones [18:38:16 CEST] <Mavrik> Haven't seen one. [18:38:34 CEST] <Mavrik> (Even though Android supports it, but those are mostly some wierd car head units.) [19:06:54 CEST] <BtbN> This PPC64 bounty doesn't seem too bad. But that's just a pointless amount of tickets. [19:20:03 CEST] <TD-Linux> talos secure workstation is trying to sell POWER8 as a desktop machine [19:20:22 CEST] <TD-Linux> unfortunately it's too expensive even for my tastes in weird computers [19:38:02 CEST] <wm4> how much is it, less than 10k? [19:42:47 CEST] <TD-Linux> 3.7k for motherboard + CPU [20:12:25 CEST] <Daemon404> the amount of issues opened abouy concating is nuts [20:12:32 CEST] <Daemon404> like people just dont get it :V [20:13:54 CEST] <wm4> it's almost like it'd be better to have real mechanisms to handle this kind of stuff [20:13:56 CEST] <wm4> instead of hacks [20:14:25 CEST] <nevcairiel> unfortunately the nature of the beast doesnt really offer any clear real mechanisms [20:14:47 CEST] <nevcairiel> most people want to concat with codec copy, but thats just crazy [20:16:01 CEST] <pfelt> grumble. is there any easy way to do a round to specific number? decklink is asking me to round the width to the nearest 48 boundary [20:16:30 CEST] <nevcairiel> we have FFALIGN, but that only works with powers of two [20:16:53 CEST] <nevcairiel> you could check the v210 code, it also deals with 48 alignment iirc [20:17:30 CEST] <Daemon404> if its just for calculating w/h, thats done so rarely id just use mod [20:17:34 CEST] Action: Daemon404 runs [20:18:21 CEST] <pfelt> heh. v210 is why i'm playing with this actually [20:18:44 CEST] <pfelt> i'm hacking the decklink code to run in v210 mode just to see if i can get performance out of this [20:19:19 CEST] <pfelt> i suppose for this i could just calculate it by hand&.. i know the width...... [20:20:49 CEST] <jkqxz> What's wrong with (x + 47) / 48 * 48? [20:23:48 CEST] <fritsch> it's not l33t enough [20:25:41 CEST] <Daemon404> thats still more leet than what id do: x - (x % 48) [20:28:44 CEST] <pfelt> maybe i'm doing this wrong&.. [20:28:56 CEST] <pfelt> currently i'm using -vcodec rawvideo [20:29:03 CEST] <pfelt> should i really be using -vcodec v210 ? [20:30:42 CEST] <nevcairiel> if its v210 it outputs, then sure [20:30:49 CEST] <Daemon404> v210 is codoec in ffmpeg [20:30:51 CEST] <Daemon404> not a pixel format [20:31:01 CEST] <pfelt> ah. so no [20:31:10 CEST] <pfelt> ok. sry for the noise. i'll refrain :D [20:31:25 CEST] <nevcairiel> Daemon404: yours reduces the width instead of padding it [20:32:15 CEST] <Daemon404> i suppose youd want to pad in this case [20:32:27 CEST] Action: Daemon404 was thinkinf of playback [23:49:54 CEST] <cone-387> ffmpeg 03Chris Cunningham 07master:2875745d354a: avformat/utils: Check negative bps before shifting in ff_get_pcm_codec_id() [00:00:00 CEST] --- Wed May 18 2016
participants (1)
-
burek