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

[burek]

[00:20:46 CET] <kierank> TD-Linux: not really
[00:27:54 CET] <ubitux> damn that mats answering 6x its own mail
[00:28:41 CET] <nevcairiel> i was hoping that he would cut that out after he was called out on that being annoying, but i should've known better
[00:31:03 CET] <wm4> wth is libi264
[00:31:15 CET] <nevcairiel> just a random name that guy choose for his vaapi encoder
[00:31:47 CET] <nevcairiel> that patch is full of code problems as it is, not to mention that its apparently extremely messy to use vaapi
[00:34:05 CET] <Daemon404> ubitux, i wake up every day and go 'wow so man posts on ffmpeg-devel!', but it's mostly just 2 people replying
[00:34:06 CET] <J_Darnley> Why has linking become so slow on (my) windows?
[00:34:19 CET] <Daemon404> s/man/many/
[00:34:48 CET] <nevcairiel> linking has always been relatively slow, but no reason for it to get slower
[00:35:49 CET] <J_Darnley> Perhaps my drive needs defragging
[00:36:06 CET] <nevcairiel> i have all my code on SSDs these days, that helps certainly
[00:37:03 CET] <wm4> Daemon404: it's like most mails are about minor math refactorings and qt palette something
[00:37:18 CET] <Daemon404> wm4, and makign 1 call to log2 faster
[00:37:31 CET] <Daemon404> it's like im reliving post-fork diego mails
[00:38:30 CET] <J_Darnley> 34% fragmented accoriding to windows' own tool
[00:38:51 CET] <nevcairiel> how can someone really care that much about a hundred year old crappy quicktime animations
[00:39:58 CET] <J_Darnley> If ffmpeg is supposed to be the goto library for video decoding it is good that someone cares.
[00:40:21 CET] <nevcairiel> I would rather someone else cares
[00:40:34 CET] <wm4> hm, people stopped blowing up money outside, time to go to bed
[00:40:43 CET] <nevcairiel> its still noisy here
[00:41:02 CET] <J_Darnley> It sounded like good flak/artillery rounds here
[00:41:29 CET] <J_Darnley> pop-pop-pop at launch; boom-boom-boom a little later
[00:43:07 CET] <J_Darnley> OMG!  Inline assembly in that libi264 patch!
[00:43:23 CET] <wm4> wat
[00:43:41 CET] <TD-Linux> kierank, well it's not weird if they want to compete with CinemaDNG, but I thought they wanted to be an adobe intermediate
[00:43:45 CET] <nevcairiel> yeah i saw that too
[00:43:53 CET] <nevcairiel> weird memcpy optimization it looks like
[00:44:18 CET] <wm4> hm is this really new code, or copy&pasted from somewhere
[00:44:26 CET] <kierank> TD-Linux: there are cameras that record into cineform
[00:48:54 CET] <fritsch> https://github.com/dicroce/vakit/blob/master/source/vah264_encoder.cpp <- parts from here?
[00:49:37 CET] <fritsch> https://github.com/gbeauchesne/libva/blob/master/test/encode/avcenc.c <- wait, it's here
[00:49:59 CET] <llogan> i should auto "mark mail as read" from a certain two from addresses
[00:50:00 CET] <fritsch> funny
[00:50:41 CET] <nevcairiel> its ugly as fuck code in any case, intel surely doesnt want vaapi to be used for encoding
[00:50:54 CET] <wm4> aren't you supposed to use qsv?
[00:51:04 CET] Action: wm4 is confused about all this duplication
[00:51:05 CET] <fritsch> it seems it is based on the encoding example by the vaapi devs
[00:51:28 CET] <nevcairiel> wm4: intel sure isnt making it easy to use qsv on linux, you need a bunch of hacks and patch your kernel
[00:51:31 CET] <fritsch> if it was after intel: you should all use libyami
[00:51:32 CET] <fritsch> :-)
[00:52:15 CET] <wm4> so what's wrong with using libyami for encoding?
[00:53:22 CET] <kierank> 2016: year of the many ways to hardware encode
[00:53:35 CET] <nevcairiel> if only one of them didnt suck
[00:53:38 CET] <fritsch> wm4: libyami itself?
[00:53:39 CET] <fritsch> :-)
[00:53:53 CET] <fritsch> BtbN looked into it lately and nearly fell of his chair ...
[00:53:56 CET] <nevcairiel> at least nvenc seems to work rather painlessly
[00:54:02 CET] <nevcairiel> but all intel methods seem to suck
[00:54:05 CET] <fritsch> but yeah, as it uses vaapi stuff itself it can only be ugly
[00:55:30 CET] <wm4> kierank: well, on Linux there's at _least_ half a dozen ways to hardware _decode_ too
[00:55:44 CET] <wm4> because every vendors needs his own API
[00:56:27 CET] <nevcairiel> well of course, linux lacks a strong force to provide a central API
[00:57:32 CET] <fritsch> wm4: kodi has openmax, amlogic, mmal, vaapi, vdpau and I am sure I missed something
[00:57:40 CET] <fritsch> ah we had xvba once
[00:59:56 CET] <wm4> mediacodec maybe?
[01:00:28 CET] <wm4> there's also v4l (not sure if anyone even uses that?)
[01:00:39 CET] <nevcairiel> that can hardware decoder as well?
[01:00:54 CET] <nevcairiel> -r
[01:01:05 CET] <nevcairiel> must be hip to offer an API for that
[01:01:21 CET] <Daemon404> [23:44] <+wm4> hm is this really new code, or copy&pasted from somewhere <-- the sender and author are two different people from two different companies
[01:01:24 CET] <Daemon404> so maybe
[01:01:35 CET] <nevcairiel> yeah that was weird
[01:01:46 CET] <wm4> nevcairiel: AFAIK yes, it can encode and decode
[01:01:57 CET] <nevcairiel> which probably means we wont get much improvements on the patch =p
[01:03:06 CET] <fritsch> wm4: i forgot IMX
[01:03:21 CET] <fritsch> the code sent there is vaapi encoder demo code + ffmpeg adjustments
[01:03:23 CET] <fritsch> nothing else
[01:03:43 CET] <nevcairiel> Admittedly even on Windows there are vendor specific APIs, but they are generally just wrappers around DXVA2 and offer only very little advantage if any, and I only have them for legacy reasons
[01:03:59 CET] <fritsch> but you have DXVA
[01:04:13 CET] <fritsch> currently on android we enforce: mediacodec only
[01:04:28 CET] <fritsch> every vendor that contacts us: hey get back libstagefright is told: do it platform conform
[01:04:43 CET] <fritsch> there are at least three "vendor specific android api hacks" arround
[01:04:44 CET] <nevcairiel> doesnt android have openmax
[01:04:55 CET] <fritsch> no idea - no vendor for now had that
[01:05:00 CET] <fritsch> mediacodec is the way to go
[01:05:31 CET] <nevcairiel> All I know about stagefright is that the ffmpeg libstagefright decoder is terrible crap
[01:05:31 CET] <wm4> wasn't it that android had openmax, but for root only?
[01:05:54 CET] <nevcairiel> apparently stagefright abstracts OMX
[01:05:59 CET] <nevcairiel> and mediacodec on top of that
[01:06:01 CET] <nevcairiel> or something :D
[01:06:19 CET] <fritsch> stagefright on android also was terrible crap
[01:06:20 CET] <fritsch> :p
[01:06:47 CET] <fritsch> making a good wrapper for a shitty lib is great art
[01:06:55 CET] <fritsch> one could wrap libyami again :-)
[01:07:12 CET] <nevcairiel> well i've been told by its author that its even worse than that
[01:07:19 CET] <nevcairiel> and should've never been submitted
[01:07:28 CET] <nevcairiel> but someone found some old PoC branch and just send it :D
[01:08:22 CET] <atomnuker> doesn't stagefright actually depend on some ffmpeg stuff?
[01:09:02 CET] <nevcairiel> its all sorts of circular, it can abstract a software decoder as well if it wants to, which m ight be ffmpeg
[01:33:40 CET] <cone-396> ffmpeg 03Michael Niedermayer 07master:48985576b11a: avcodec/ffv1dec: Support AV_PIX_FMT_YA8
[01:33:41 CET] <cone-396> ffmpeg 03Michael Niedermayer 07master:3843e52cb415: avcodec/ffv1enc: Support AV_PIX_FMT_YA8
[01:56:15 CET] <Compn> lol @ k&r comments on kierank wip patch :D
[01:56:52 CET] <J_Darnley> (sorry, I had to)
[02:01:57 CET] <kierank> Meh 
[02:02:05 CET] <kierank> I'll fix it later
[02:07:28 CET] <J_Darnley> FUCKMINTTYANDITLOSINGTHEFUCKINGCURSOR
[02:37:09 CET] <J_Darnley> kierank: does avdev already have the fate samples somewhere?
[02:38:15 CET] <kierank> usr/share/fate possibly
[02:38:31 CET] <kierank> seems not
[02:41:08 CET] <J_Darnley> Shall I fetch them?
[02:41:25 CET] <J_Darnley> Should I fetch them?
[02:41:31 CET] <philipl> So, all we need is BtbN's yami encoder and we'll have three ways to use the same hardware to do the same thing?
[02:41:46 CET] <cone-396> ffmpeg 03Lou Logan 07master:b47111b6579f: doc/filters: add showwavespic colorize example
[02:50:38 CET] <kierank> J_Darnley: yes
[02:53:40 CET] <J_Darnley> I'll put them in my home directory and you can copy/move them if you want.
[03:01:51 CET] <kierank> ok
[03:07:03 CET] <J_Darnley> Why did I assume there was a matching scatter to the gather instruction?
[03:09:17 CET] <jamrial> because there is?
[03:11:15 CET] <J_Darnley> are you sure?  are you sure it isn't avx512?
[03:31:12 CET] <jamrial> mmh, you're right
[03:57:25 CET] <BtbN> philipl, unless libyami drasticaly improves, I'm not going to send it in for merging.
[03:57:29 CET] <BtbN> It's horrible
[04:05:56 CET] <J_Darnley> kierank: They're in /home/jdarnley/fate-samples/
[04:06:06 CET] <J_Darnley> and with that I'm going to bed.
[04:06:27 CET] <J_Darnley> Good night all and happy new year.
[05:16:40 CET] <kierank> lol at that mats guy
[05:34:40 CET] <atomnuker> I've always found it surprising how much of my jpeg files are yuv444p
[05:35:15 CET] <atomnuker> you'd think subsampling would be as popular as it is in video, but nope
[06:06:31 CET] <TD-Linux> people generally save images at much higher quality than video
[07:11:55 CET] <kierank> I think we should copy j-b and do "the week in ffmpeg"
[09:58:54 CET] <kierank> https://medium.com/@kierank_/reverse-engineering-the-gopro-cineform-codec-7411312bfe1c#.jxkmda8md
[10:09:39 CET] <durandal_1707> congratulation!
[14:58:13 CET] <michaelni> nevcairiel, about put_bits() & assert(), what do you suggest ?
[15:37:32 CET] <nevcairiel> michaelni: i just dont like the prospect of the application crashing due to some internal bug, especially as an API user where writing a file may only be a small function of the bigger program
[15:38:07 CET] <michaelni> hmm, so you would be fine with a av_log + av_assert2 ?
[15:39:14 CET] <michaelni> or you are against always checking as such ? (so that such bug would write out of array but there would be no 0.1% slowdown)
[15:40:28 CET] <nevcairiel> how do these bugs really happen? Someone fiddles with put_bits code and breaks something? Or invalid usage from an encoder?
[15:43:30 CET] <michaelni> the max buffer size estimation can be wrong or out of sync with the actual code or someone can do something stupid. One such issue was reported yesterday, i have no idea if thats the only one or there are more
[15:45:30 CET] <nevcairiel> adding an av_log to the failure case shouldn't add any extra slowdown, should it? the if clause should prevent that. I would prefer not crashing and logging instead, at the expensive of writing corrupted frames
[15:47:06 CET] <michaelni> ill benchmark and then post a new patch
[15:52:21 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:1f008f34d5b2: rmenc: do not use AVCodecContext.frame_size
[15:52:21 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:53448461a772: Merge commit '1f008f34d5b2b5f6217521747e7acfe3efc0e666'
[15:55:12 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:9f1eccb97bf8: ff_parse_specific_params: do not use AVCodecContext.frame_size
[15:55:13 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:29e6606e9b42: Merge commit '9f1eccb97bf8894cb18b14f642500686505ef186'
[16:00:01 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:6bf4c1d71199: r3d: do not create the audio stream until we know the sample rate
[16:00:02 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:f6728a3ea27b: Merge commit '6bf4c1d71199b92894f24db6386ed5070e590a16'
[16:03:09 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:cdc9ce098e8d: lavc: print the name of the codec, not its implementation, in avcodec_string
[16:03:10 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:5f2d12b82494: Merge commit 'cdc9ce098e8d101b43b8f68dd35ba7226f4a728c'
[16:21:30 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:2c6811397bdf: lavc: add profiles to AVCodecDescriptor
[16:21:31 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:5e8b05345243: Merge commit '2c6811397bdf13d43ca206e48d6d6da9c2cd47c6'
[16:27:02 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:e76064172098: lavc: add vp9 profiles to AVCodecDescriptor
[16:29:37 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:cea1eef25c33: lavc: get the profile name through the codec descriptor in avcodec_string()
[16:29:38 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:15c60c8af227: Merge commit 'cea1eef25c3310a68dd327eb74aae14ad3c2ddef'
[16:45:24 CET] <michaelni> nevcairiel: libavcodec/h264.c:2007:17: error: profiles undeclared here (not in a function)
[16:45:55 CET] <nevcairiel> silly vdpau decoders
[16:48:41 CET] <michaelni> nevcairiel, theres a 2nd one: libavcodec/vc1dec.c:1168:17: error: profiles undeclared here (not in a function)
[16:49:27 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:955aec3c7c7b: mpegaudiodecheader: check the header in avpriv_mpegaudio_decode_header
[16:49:28 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:1e96b151fa6e: Merge commit '955aec3c7c7be39b659197e1ec379a09f2b7c41c'
[16:49:29 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:42ff56e362e8: lavc: fix profile declarations for vdpau decoders
[16:58:07 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:72d658766e6c: mp3dec: replace avpriv_mpa_decode_header with avpriv_mpegaudio_decode_header
[16:58:08 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:a78d9abee0df: Merge commit '72d658766e6ccf198317dffd6499c5e288847a1c'
[16:59:34 CET] <michaelni> nevcairiel, ok if i push the revert now or should i wait or something else (dont want to break your current work)
[16:59:37 CET] <michaelni> ?
[16:59:50 CET] <BtbN> Will this i264 thing be another "never heard of again" thing, like the attempt to add libyami support?
[17:00:23 CET] <BtbN> In general it seems like the best approach, directly adding an encoder on top of libva, but this patch has a lot of issues, and I'm confused which library it actualy refers to
[17:01:16 CET] <nevcairiel> BtbN: the name is made up
[17:01:21 CET] <nevcairiel> its not a library
[17:01:43 CET] <nevcairiel> michaelni: let me finish the merge of the current commit
[17:01:50 CET] <michaelni> ok
[17:01:55 CET] <BtbN> oh, the hell, why? oO
[17:02:36 CET] <nevcairiel> who the f' knows
[17:02:42 CET] <nevcairiel> its just a vaapi encoder
[17:05:59 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:de9e199a0394: lavc: make avpriv_mpa_decode_header private on next bump
[17:06:01 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:92fe2adc1b2b: Merge commit 'de9e199a039473ebe4b1b87382e3064d0ea2cf02'
[17:06:01 CET] <nevcairiel> michaelni: ok
[17:07:09 CET] <cone-951> ffmpeg 03Michael Niedermayer 07master:0b1e94c50a6e: Revert "Merge commit '9f1eccb97bf8894cb18b14f642500686505ef186'"
[17:07:27 CET] <michaelni> nevcairiel, done, thx
[17:14:00 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:09ae7b81ea20: flvdec: do not create any streams in read_header()
[17:14:01 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:95daa9e09aec: Merge commit '09ae7b81ea2051eec2be9964296bd6ef492c6622'
[17:14:57 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:2d0432d918a7: vocdec: put the code not shared with other demuxers under appropriate ifdef
[17:14:58 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:5c06fc4bd88e: Merge commit '2d0432d918a71468419b7ac1e543ab3b399d3d37'
[17:21:25 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:9f0b6e6827e2: vocdec: do not create the stream in read_header()
[17:21:26 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:a240aefc7a25: Merge commit '9f0b6e6827e21e3477abe1199dc2728e30b8c061'
[17:22:17 CET] <cone-951> ffmpeg 03Martin Storsjö 07master:64f8c439fd66: rtmpproto: Include the full path as app when "slist=" is found
[17:22:18 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:99f2a5638892: Merge commit '64f8c439fd663fec4d57ac21af572d498fe21f7a'
[17:22:34 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:5bc223b15d06: r3d: fix an invalid read introduced in 6bf4c1d
[17:22:35 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:5236cf871818: Merge commit '5bc223b15d064e328ff90b0241fa1191f1d2786d'
[17:23:49 CET] <atomnuker> BBB: I've sent a third revision of my decoder to the ML, check it out during the weeked if you've got the time
[17:24:41 CET] <BBB> ok
[17:25:17 CET] <BBB> re: i264, didnt we have vaapi already?
[17:25:26 CET] <nevcairiel> not as an encoder
[17:25:33 CET] <nevcairiel> (for good reason, vaapis encoding api is terrible)
[17:26:02 CET] <nevcairiel> its as low level as you can get, you ahve to do *everything* manually, building the bitstream, re-ordering frames, what have you
[17:26:26 CET] <BBB> reordering frames?
[17:26:32 CET] <BBB> wait, like, what
[17:26:40 CET] <BBB> it returns frames in display order?
[17:26:48 CET] <BBB> confused
[17:36:09 CET] <BtbN> It does not re-order them for you, yes
[17:37:07 CET] <BtbN> iirc it also has nothing to collect the required reference frames. You have to keep the yourself and pass them along the frame you want to encode
[17:37:55 CET] <BtbN> And even though it generates _some_ of the h264 NAL bitstream itself, you have to pass large parts of it manualy to libva, so it can integrate it into the parts it generates internaly...
[17:38:33 CET] <BtbN> There's no clear concept behind it at all, it's just the easiest possible way the Intel Hardware-Devs could have exposed the hardware capabilities
[17:38:49 CET] <BtbN> Easiest on the Intel-Devs, of course. A horrible mess for everyone else
[17:39:49 CET] <BtbN> An I/P-Only encoder is easily made, if you don't mind copying the entire bitstream generation logic from somewhere, but B frames are realy messy
[17:46:25 CET] <durandal_1707> fine to push ahistogram?
[17:53:23 CET] <Compn> of course horrible mess. :(
[17:53:45 CET] Action: Compn always supports hacky patches.
[17:53:54 CET] <Compn> someone wants to come and make it pretty, go for it. until then, it works? :P
[17:55:58 CET] <Daemon404> [16:37] <@BtbN> iirc it also has nothing to collect the required reference frames. You have to keep the yourself and pass them along the frame you want to encode <-- wtf?
[17:57:04 CET] <nevcairiel> like i said, its as low level as you can get
[17:58:02 CET] <Daemon404> im also confused...
[17:58:07 CET] <Daemon404> why does intel have like 900 libraries
[17:58:12 CET] <Daemon404> do they all use the same underlying hardware?
[17:58:16 CET] <Daemon404> or is it all special
[17:58:31 CET] <nevcairiel> all the same hardware
[17:58:38 CET] <nevcairiel> intel is terrible at producing software
[17:58:52 CET] <BtbN> Intel basicaly has libva on linux, and MSF/QSV on windows
[17:59:03 CET] <Daemon404> well, i think libva was the one i looked at back in 2011 when i work at an intel subsidiary
[17:59:10 CET] <nevcairiel> .. and msdk on linux, and libyami, and...
[17:59:11 CET] <Daemon404> i seem to recall it was horrible
[17:59:11 CET] <BtbN> But they also ported QSV to Linux because people requested it. They made it by setting it up on top of libva
[17:59:15 CET] <Daemon404> and didnt even have ratecontrol?
[17:59:28 CET] <nevcairiel> except that qsv on linux  is terrible
[17:59:38 CET] <BtbN> Yes, needs a patched libva and kernel...
[17:59:41 CET] <nevcairiel> on windows its already subpar, but on linux you need to patch your kernel
[17:59:45 CET] <Daemon404> who are using these hardware encoders anyway?
[17:59:51 CET] <Daemon404> and why
[17:59:56 CET] <nevcairiel> plus intel doesnt even offer a linux dispatcher library
[18:00:09 CET] <nevcairiel> you have to do the libva management yourself due to that
[18:00:15 CET] <Daemon404> i thought there was libmfx
[18:00:27 CET] <nevcairiel> that lacks any awareness of linux
[18:00:35 CET] <Daemon404> i thought luca forked it
[18:00:35 CET] <JEEB> :D
[18:00:37 CET] <nevcairiel> on windows it handles the device for you
[18:00:43 CET] <nevcairiel> he did, he added the linux stuff
[18:00:55 CET] <nevcairiel> but of course all the lusers out there want to build with the official one!
[18:01:01 CET] <Daemon404> ;)
[18:01:05 CET] <JEEB> classic
[18:01:18 CET] <Daemon404> i still stand by my original question: who even uses this stuff and why
[18:01:18 CET] <BtbN> It's realy sad, Intel has realy good hardware for multimedia stuff.
[18:01:25 CET] <Daemon404> it's not even cost-effective for anything at scake
[18:01:25 CET] <BtbN> But they royaly messed up the software side.
[18:01:28 CET] <Daemon404> whatsoever
[18:01:36 CET] <Daemon404> i linux peeps probably dont capture while playing games
[18:01:39 CET] <Daemon404> (dont hurt me pls)
[18:01:50 CET] <nevcairiel> its a consumer product really, its not going to be at scale
[18:02:00 CET] <BtbN> But they buy horribly slow CPUs and expect them to transcode TV for them
[18:02:03 CET] <Compn> Daemon404 : h264 encoder/decoder on embedded devices
[18:02:03 CET] <wm4> isn't there vaapi based video capture in wayland (weston), but dunno
[18:02:16 CET] <Daemon404> Compn, thats not intel 
[18:02:35 CET] <Compn> all those intel atom netbooks ?
[18:02:53 CET] <Daemon404> i thought they stopped making those a long time ago
[18:03:02 CET] <JEEB> and thank goodness
[18:03:06 CET] <Compn> possibly china...
[18:03:15 CET] <Daemon404> china prefers MIPs im sure
[18:03:17 CET] <Daemon404> MIPS*
[18:03:20 CET] <wm4> http://cgit.freedesktop.org/wayland/weston/tree/src/vaapi-recorder.c
[18:03:22 CET] <JEEB> no, china is making intel-based tablets
[18:03:42 CET] <nevcairiel> the only usecase is all those people trying to stream video to their phones, or do fast offline transcodes for phones
[18:03:51 CET] <nevcairiel> they dont care about quality, they want it done fast
[18:03:52 CET] <Daemon404> wm4, NSFW tag your links man
[18:03:57 CET] <Daemon404> thats perverted
[18:04:06 CET] <wm4> I knew you'd like it
[18:04:13 CET] <JEEB> the teklast x98 et al
[18:04:38 CET] <JEEB> but yeah, I've seen those people who just want something fast and I'm not even sure if it's faster than x264 preset ultrafast
[18:04:43 CET] <Daemon404> nevcairiel, but really how many normal people do this?
[18:04:50 CET] <Daemon404> ive never even thought of streaming to my phone
[18:04:57 CET] <Daemon404> tablet maybe...
[18:05:01 CET] <Compn> Daemon404 : you dont want a 10.1 in netbook? :P http://www.amazon.com/Acer-AOD270-1375-Netbook-Processor-Espresso/dp/B007582KGM
[18:05:11 CET] <nevcairiel> i do it all the time, well strictly speaking to my tablet, but yeah
[18:05:15 CET] <Compn> you can use h264 encoder for webcam stuff
[18:05:21 CET] <nevcairiel> but then i use x264 for that :D
[18:05:43 CET] <Daemon404> nevcairiel, we solved this problem for my SO by vlc for iOS
[18:05:43 CET] <JEEB> yup
[18:05:47 CET] <Daemon404> <_<
[18:05:50 CET] <Daemon404> the lazy fix
[18:06:37 CET] <nevcairiel> this way i can pick a bitrate and even use it from remote if i want to, its kinda handy once you have it all in place
[18:06:51 CET] <Compn> intel using image macros? http://www.intel.com/content/dam/www/public/us/en/include/tablets-2/imgs/dot.jpg/_jcr_content/renditions/noscript.jpg
[18:07:08 CET] <Daemon404> Compn, intel is learning dank memes
[18:07:12 CET] <JEEB> lol
[18:09:58 CET] <Compn> i mean how else are you going to set up your cam show on your intel atom notebook if it doesnt have h264 encoding right to youtube ?
[18:10:06 CET] <atomnuker> speaking of hardware decoders, companies are making a fortune selling their FPGAs with their proprietary decoders
[18:11:01 CET] <Daemon404> Compn, i dont think people who do cam shows use youtube...
[18:11:02 CET] <atomnuker> some go as far as to design and optimize their codecs with FPGAs in mind
[18:11:36 CET] <Daemon404> most big codecs are designed with hw in mind
[18:11:41 CET] <Daemon404> it's practical
[18:11:53 CET] <Daemon404> not sure about suoer magic proprietary oens ive never heard of
[18:12:55 CET] <Compn> what proprietary codecs are we talking about here ?
[18:13:15 CET] <Compn> thought we had samples for most codecs...
[18:13:18 CET] <Daemon404> no idea
[18:13:29 CET] <atomnuker> <cough>SMPTE</cough>
[18:13:37 CET] <Compn> i cant read your boxes
[18:13:55 CET] <atomnuker> that's the point
[18:14:23 CET] <atomnuker> VC-5, VC-2, etc.
[18:14:37 CET] <Compn> those smpte things
[18:14:44 CET] <nevcairiel> I still find their entire concept weird
[18:14:44 CET] <Daemon404> Compn cant into unicode
[18:14:58 CET] <nevcairiel> you standardize something, and afterwards you have a useless standard that  doesnt help y ou for shit?
[18:15:03 CET] <nevcairiel> how does that work for anyone
[18:15:04 CET] <Daemon404> nevcairiel, it's a circle jerk. a way companies can say they use a 'standard' codec.
[18:15:37 CET] <Compn> some corporate requirement to have product "standardized" "accredited" etc
[18:15:37 CET] <Daemon404> it's not meant to have other implementations.
[18:16:07 CET] <JEEB> yup
[18:16:13 CET] <Compn> its not a logic-based concept. its truely bureaucratic.
[18:26:32 CET] <prelude2004c> good day everyone.. can anyone help with vdapu ?  I am still having an issue. Here goes... " Running a system with M4000 card "... ffmpeg with vdpau enabled.. i can decode mpeg2video just fine using the GPU but any source with h264 it will not use the card to decode and instead uses CPU's. Can anyone assist with this ? what could i be doing wrong ?
[18:40:46 CET] <cone-951> ffmpeg 03Clément BSsch 07master:77eeaa2c3dec: lavf/srtdec: rewrite parsing logic
[18:47:20 CET] <Daemon404> kierank, you intend to leave bayer out for now i assume?
[18:59:59 CET] <kierank> Daemon404: dunno, only got 2 samples
[19:01:01 CET] <Daemon404> maybe dave can help you
[19:07:57 CET] <kierank> I don't really know what the bayer stuff is meant to look like eithrt
[19:08:05 CET] <kierank> Or the pixel format
[19:08:28 CET] <Daemon404> bayer is not really a 'pixel format' iirc
[19:08:37 CET] <Daemon404> isn't it basically a sensor dump
[19:12:39 CET] <wm4> ubitux: awesome
[19:13:50 CET] <kierank> Yes but sensors are all different
[19:13:57 CET] <kierank> Bayer is not a single type iirc
[19:14:02 CET] <kierank> It's a principle
[19:14:19 CET] <Daemon404> yes i know
[19:14:27 CET] <Daemon404> i thought it might code something to helo
[19:14:40 CET] <Daemon404> or it could just be like raw, where you handle it manually in the editor
[19:14:57 CET] <kierank> It prilobably does code something to jelp
[19:15:03 CET] <kierank> But I dunno what they mean
[19:17:09 CET] <ubitux> don't we have bayer pixel formats?
[19:19:02 CET] <wm4> yes
[19:19:53 CET] <Daemon404> vc-5 is supposed to support bayer
[19:19:57 CET] <Daemon404> does the spec not list anything
[19:20:49 CET] <kierank> No the spec says input data is out of scope
[19:20:58 CET] <kierank> It's just daya
[19:21:01 CET] <kierank> Data
[19:21:22 CET] <Daemon404> lolwut
[19:21:32 CET] <Daemon404> is this a joke?
[19:23:29 CET] <kierank> Nope
[19:23:51 CET] <ubitux> wm4: i don't doubt a second that you will find me another completely mad file anytime soon
[19:24:09 CET] <ubitux> but from a demuxing PoV, that should be better
[19:25:31 CET] <wm4> lol
[19:25:32 CET] <ubitux> anyway, i think i'm going to try again to end the ass madness 
[19:25:44 CET] <wm4> srt is surprisingly insane I guess
[19:25:45 CET] <Daemon404> "ass madness"
[19:27:15 CET] <durandal_1707> fork me reviews
[19:28:00 CET] <ubitux> wm4: actually not that much, but easily abused and widespread
[19:28:22 CET] <ubitux> i think most of the problems come from the numbers
[19:28:32 CET] <ubitux> the "event number"
[19:29:25 CET] <Daemon404> ubitux, also it has no spec.
[19:29:35 CET] <Daemon404> it was just some format a guy made up for an ocr program
[19:29:40 CET] <ubitux> specs or not, people will violate them anyway
[19:29:44 CET] <ubitux> so it's not really a problem
[19:29:49 CET] <Daemon404> this is true
[19:29:59 CET] <Daemon404> people upload the wierdest vtt files to us
[19:30:06 CET] <ubitux> i mean, you think the guy editing a .srt really cares about the specs ?
[19:30:16 CET] <ubitux> like, with Word
[19:30:21 CET] <wm4> vtt is in real world use?
[19:30:29 CET] <Daemon404> wm4, all subtitles on vimeo are vtt
[19:30:35 CET] <Daemon404> we output a very limited subset
[19:30:35 CET] <wm4> D:
[19:30:42 CET] <Daemon404> its teh only way to do html5 subs.
[19:30:51 CET] <Daemon404> youtube probably does too
[19:31:00 CET] <nevcairiel> invent your own js powered subs!
[19:31:11 CET] <wm4> isn't vtt like srt, except you need a web browser to render them
[19:31:11 CET] <Daemon404> or use .ass in flash like crunchyroll
[19:31:27 CET] <Daemon404> wm4, our subset is equivalent to a subset of srt
[19:31:31 CET] <Daemon404> no fancy things
[19:31:56 CET] <ubitux> is "ass markup in srt" part of that subset?
[19:31:56 CET] <Daemon404> source: i own the backend subtitle stack; inherited it from someone else
[19:32:02 CET] <Daemon404> subtitles are pain
[19:32:11 CET] <Daemon404> ubitux, lolno
[19:35:37 CET] <ubitux> why don't we add a frame_duration callback in lavc?
[19:35:42 CET] <ubitux> for codecs
[19:36:28 CET] <wm4> what would that do?
[19:36:28 CET] <Daemon404> the notion is somewhat derpy to begin with
[19:36:38 CET] <Daemon404> e.g. what about codecs with variable frames
[19:37:05 CET] <durandal_1707> have flag
[19:37:31 CET] <ubitux> wm4: move the per-codec code from av_get_audio_frame_duration() inside the codecs themselves
[19:37:42 CET] <wm4> ah
[19:38:08 CET] <durandal_1707> adding callback? Propose it to #libav-devel?
[19:39:14 CET] <Daemon404> ubitux, i still dont know how that would work for variable frame lengths
[19:39:25 CET] <nevcairiel> it wouldnt, but that wont work today either
[19:39:59 CET] <nevcairiel> some containers require a fixed frame size, and they need to know this frame size before hand, hence this function
[19:40:47 CET] <ubitux> do we at least issue a warning if the frame size is not fixed?
[19:41:29 CET] <Daemon404> btw why is av_get_audio_frame_duration even public
[19:41:46 CET] <Daemon404> eh, i guess for people's own muxer's
[19:41:48 CET] <Daemon404> s/'s/s/
[19:41:52 CET] <ubitux> grep -A2 av_get_audio_frame_duration libavformat/nutenc.c
[19:41:54 CET] <ubitux> lol
[19:42:11 CET] <ubitux> not enough per case inside the function
[19:42:15 CET] <Daemon404> \o/
[19:42:38 CET] <durandal_1707> Only pcm and s302m are vfs
[19:43:14 CET] <Daemon404> for some reason i thought wavpack was
[19:43:20 CET] <Daemon404> it may just be large frames
[19:44:41 CET] <rcombs> ubitux: mild preference for that to be in the parser
[19:45:16 CET] <durandal_1707> technically it is possible for wavpack but not done for simplicity
[19:45:18 CET] <jamrial> atomnuker: look at ogg_validate_keyframe() in oggdec.c
[19:45:41 CET] <jamrial> see if you need to add a check like the ones for theora and vp8
[19:45:53 CET] <rcombs> as I believe it's sometimes used when not actually decoding (e.g. remux) so it shouldn't depend on the decoder to work
[19:47:41 CET] <durandal_1707> can someone test/review showspectrumpic?
[20:25:37 CET] <nevcairiel> Man submitting content to trac is slow
[20:31:07 CET] <BBB> I feel that all audio or video codecs are huge massive hacks
[20:31:15 CET] <BBB> and then the frameworks or codebases around them are just as bad
[20:31:22 CET] <BBB> and then ffmpeg is the king of bad-ass code
[20:31:48 CET] <BBB> (re: audio frame size stuff)
[20:31:49 CET] <wm4> bad bad-ass code or just bad-ass code?
[20:33:14 CET] <BBB> Im as-of-yet undecided
[20:34:26 CET] <Compn> you are saying that it is impossible to create pretty code if it has to touch dirty codecs and formats ?
[20:34:55 CET] <Daemon404> BBB, it's a natural consequence of writign a generic framework around a lot of specific-requiring things
[20:35:11 CET] <BBB> Compn: yes
[20:35:13 CET] <Compn> some of these things like avi and mov and rm have had years worth of hacks added. which means the hacks required to play back such files...
[20:35:19 CET] <Daemon404> and yet nobody would argue they want a separate lib for every format/codec, i think
[20:35:36 CET] <BBB> I wasnt arguing for something like that
[20:35:42 CET] <BBB> Im just lamenting that the code has to be ugly
[20:36:00 CET] <Compn> you just need to personally redefine your criteria for "ugly" 
[20:36:03 CET] <BBB> Im shedding tears for the world that was once imagined to be so beautiful, yet ended up as it deserved
[20:36:22 CET] <Daemon404> isnt that just called gaining perspective
[20:36:36 CET] <BBB> Im growing up mommy
[20:36:37 CET] <BBB> :D
[20:38:13 CET] <Mavrik> Pretty code either solves no useful problem or doesn't work :P
[20:41:22 CET] <wm4> ugly code will eventually kill you
[20:41:40 CET] <Daemon404> life eventually kills you
[21:16:00 CET] <cone-951> ffmpeg 03Ganesh Ajjanagadde 07master:9dba3f8f0983: lavfi/af_sofalizer: remove exp2 and replace clz by ff_clz
[21:19:41 CET] <atomnuker> "Message body is too big: 654645 bytes with a limit of 550 KB"
[21:20:40 CET] <atomnuker> and I thought 5.8k lines was around right for a small-ish decoder
[21:21:08 CET] <durandal_1707> learn to code in less lines, for once :-/
[21:23:24 CET] <Compn> 5.8k lines shouldnt take up 650k though
[21:25:33 CET] <atomnuker> durandal_1707: that's about as small as I could make it without resorting to hacks and making it ugly and slow
[21:26:27 CET] <atomnuker> if the code styling standards were less loose I could probably just shape it like Mario's sprite and make it fit in a single file
[21:27:07 CET] <durandal_1707> atomnuker: then just commit it, no need for review :/
[21:27:17 CET] <atomnuker> but only the IOCCC accept such code :/
[21:28:17 CET] <atomnuker> durandal_1707: it's a new decoder, it needs a review
[21:29:26 CET] <durandal_1707> let reviews modify once it is in master
[21:31:04 CET] <atomnuker> maybe I will once I'm convinced it won't blow up someone's computer
[21:31:11 CET] <cone-951> ffmpeg 03Michael Niedermayer 07master:dbfb2c1abfe8: avformat/mp3dec: Remove unused variable
[21:31:36 CET] <atomnuker> btw durandal_1707, is the showspectrumpic patch broken: "fatal: sha1 information is lacking or useless (libavfilter/avf_showspectrum.c)." ?
[21:32:02 CET] <atomnuker> oh wait, I didn't apply 1/2
[21:34:09 CET] <durandal_1707> be sure to use the latest version for 2nd patch 
[21:35:21 CET] <durandal_1707> maybe I should add option to specify duration so it doesn't use bunch of memory
[22:00:55 CET] <atomnuker> durandal_1707: showspectrumpic is perfect: https://0x0.st/oJc.jpg https://0x0.st/oJT.jpg https://0x0.st/oJA.jpg
[22:01:10 CET] <atomnuker> I definitely think color=intensity should be the default though
[22:05:51 CET] <durandal_1707> atomnuker: this is all log scaler?
[22:07:42 CET] <atomnuker> yes, that's with log
[22:07:51 CET] <atomnuker> (which I think should be the default as well)
[22:08:02 CET] <atomnuker> but then again I've stared at Spek graphs for too long
[22:08:34 CET] <atomnuker> those settings do look pretty though, prettier than sox or spek
[22:08:54 CET] Action: J_Darnley now wants to install r4
[23:23:22 CET] <jamrial> ubitux: all your fate clients are randomly failing fate-h264-conformance-capcmnl1_sand_e
[00:00:00 CET] --- Sat Jan  2 2016