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

[burek]

[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-avdevice-sdl2-re-add-threading-patch 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