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

[burek]

[00:03:21 CET] <cone-242> ffmpeg 03Paul B Mahol 07master:0d65a7d03304: avfilter/af_astats: clear all stats
[00:08:56 CET] <cone-242> ffmpeg 03Michael Niedermayer 07master:6bc20e84d84f: avfilter/drawutils: Fix ff_fill_rectangle() on big endian
[00:08:57 CET] <cone-242> ffmpeg 03Michael Niedermayer 07master:954f865c8ee2: avfilter/drawutils: fix gray and gbr formats on big endian
[00:24:51 CET] <Daemon404> [22:49] < TD-Linux> BBB, chrome decides that if it's MSE then it's bt 709 <-- i hope youre joking
[00:25:10 CET] <Daemon404> unless you mean non unflagged streams only
[00:26:10 CET] <TD-Linux> Daemon404, nonflagged only
[00:26:34 CET] <TD-Linux> the only part I'm miffed about is them not flagging YT tracks
[00:26:35 CET] <Daemon404> ok
[00:26:54 CET] <Daemon404> our (vimeo's) are all flagged properly, so it isnt my problem...\
[00:26:55 CET] Action: Daemon404 runs
[00:36:13 CET] <ethe> If I require cus' patch for one of mine, then I guess I have to convince him to submit it first, or can I do it on his behalf?
[00:37:01 CET] <ethe> I spoke to him about my patch, and he said the only think blocking his was that mine didn't exist yet.
[00:37:38 CET] <ethe> sorry for being such a pain. I'm still very new to contributing open source
[00:47:30 CET] <JEEB> ethe: if it's a useful patch you can throw it into review if you think it's ready for that. of course, asking if the guy think it's ready for that as well probably is a good idea as well.
[00:47:58 CET] <JEEB> tl;dr just get the authorship right
[00:48:45 CET] <ethe> JEEB: oh yeah, that's not a bad idea.
[02:09:18 CET] <Jung> hi, can any one tell me why ffmpeg use YUV420P as default decoding output and most hardware decoders use nv12?
[02:12:40 CET] <BBB> Jung: its just an implementation tidbit
[02:12:47 CET] <J_Darnley> because much was written before things started using nv12
[02:15:06 CET] <iive> nv12 have 2 planes, Y and U/V interleaved, afair
[02:16:07 CET] <iive> having then color planes interleaved is probably cache optimization, so you can process both blocks in parallel.
[02:17:05 CET] <iive> it actually makes more sense if hardware decoders are in hm12 format, that is like nv12 but in 8x8 tiles/blocks
[02:17:50 CET] <iive> i remember some experimental mpeg12 decoder that claimed dramatic speed boost by using that scheme on PC.
[02:20:34 CET] <J_Darnley> Can anyone else replicate a crash with this command: ./ffmpeg_g -f lavfi -i testsrc=s=720x576:d=1:r=25,format=yuv420p -vcodec vc2 -strict -1 -threads 1 -f null -
[02:20:52 CET] <J_Darnley> (on a clean master)
[02:22:12 CET] <Jung> thanks
[02:22:30 CET] <iive> Jung: don't forget, Y and UV are in different resolutions
[02:24:50 CET] <Jung> @iive: I have to do format conver every time when i get decoded data from hardware and store them into AVFrame
[02:25:04 CET] <iive> why?
[02:25:41 CET] <iive> avframe should be able to hold any type of color format.
[02:28:57 CET] <jamrial> J_Darnley: yes
[02:29:14 CET] <J_Darnley> thanks for the confirmation
[02:30:38 CET] <jamrial> seems to be a memset
[02:31:07 CET] <atomnuker> ah, it's that memset
[02:31:41 CET] <atomnuker> that memset zeroes out the padding
[02:33:17 CET] <atomnuker> I'll troubleshoot both crashes (this one + the vsynth one) tommorow or on friday
[02:34:18 CET] <atomnuker> J_Darnley: you can remove the memset without affecting anything as long as you keep the wavelet_depth set to 3 or lower
[02:34:38 CET] <Jung> @iive: how to change output format in ffmpeg?
[02:34:45 CET] <J_Darnley> okay, I'll note incase I can't find the problem
[02:35:46 CET] <Jung> @iive: change avctx->pix_fmt value and store data in related sequence?
[02:36:26 CET] <iive> Jung: let me ask you this way... how do you get the data that you are converting?
[02:36:46 CET] <iive> you do use swscale for conversion, don't you?
[02:37:00 CET] <Jung> yes
[02:38:33 CET] <cone-242> ffmpeg 03Neil Birkbeck 07master:ad17b9d2d47a: libavcodec:add packet level support for mastering metadata
[02:41:58 CET] <Jung> I have two way to covert. 1. through swscale; 2. write a simple coverting function.
[02:42:28 CET] <Jung> I find 2 is more efficient than 1
[02:43:24 CET] <iive> really?
[02:43:49 CET] <iive> we might summon michaelni to investigate ;)
[02:43:53 CET] <iive> sorry gtg.
[02:43:58 CET] <iive> n8 ppl
[02:44:23 CET] <Jung> yes, my coverting function is very simple without any optimization
[02:45:03 CET] <Jung> so, i think maybe there are some optimization options for configure?
[02:53:58 CET] <Timothy_Gu> Jung: what is your operation?
[02:54:26 CET] <Timothy_Gu> swscale should be fairly optimized, especially for simpler operations which have SIMD assembly 
[03:30:36 CET] <J_Darnley> atomnuker: I think the problem is when the height is not padded (p->dwt_height is equal to p->height), dwt_plane() uses all the available lines in the buffer
[03:30:42 CET] <J_Darnley> buf is left pointing to the end of the memory block
[03:31:17 CET] <J_Darnley> then some bad math results in writing to buf
[03:31:33 CET] <J_Darnley> basically I think you want this diff: http://pastebin.com/jjuYak1B
[05:52:45 CET] <cone-210> ffmpeg 03Matt Oliver 07master:7ecef5ed514e: avfilter/hwupload_cuda: Add missing semicolon.
[10:24:06 CET] <kierank> so I guess I have to concede defeat
[10:24:23 CET] <kierank> since nobody seems to have any interesting ideas for ffmpeg
[10:24:29 CET] <kierank> and so we trot out the same gsoc crap as next year
[10:24:33 CET] <kierank> last
[10:45:45 CET] <wm4> I guess we should maybe think less about "what is something useful we could make the students do" to "what is something fun and engaging (even if useless) the students could do"
[10:46:21 CET] <kierank> yes
[10:54:09 CET] <iive> if they are getting paid, it's better be useful.
[10:55:22 CET] <nevcairiel> iive: no, those projects are not meant to offer cheap labor for projects that noone else wants to do. students never pick those projects anyway, or if they do they dont get finished, so its not working in any case
[10:55:39 CET] <nevcairiel> the actual point is to atract new contributors with an incentive to start working, and ideally stick around after
[10:56:13 CET] <iive> you can do that, with your own money.
[10:57:43 CET] <nevcairiel> you have to realize that there are more project offers than students, so boring tedious projects that no developed wanted to do before is not something thats going to convince a student to work for you
[10:58:52 CET] <nevcairiel> its proof in itself that our gsoc page carries the same silly projects for years, simply because noone ever does them
[10:58:52 CET] <iive> look, a lot of developers are working in projects only for fun. That's fine.
[11:00:10 CET] <iive> money are motivator. if you don't use them for useful things, you are wasting them.
[11:00:37 CET] <nevcairiel> gaining a new contributor that sticks around afterwards is certainly a useful thing
[11:00:39 CET] <wm4> as nevcairiel said, it's about attracting talent
[11:00:57 CET] <nevcairiel> you wont do that with annoying tedious tasks
[11:00:59 CET] <iive> well, would that new contributor stick around for the boring parts?
[11:00:59 CET] <wm4> for open source, talent is more valueable than money
[11:01:54 CET] <nevcairiel> every project has its boring parts, but the first thing someone does should be interesting and engaging, or they wont engage to the project and leave
[11:02:10 CET] <ubitux> the only way to keep someone who is getting paid to continue working on the project is to give him fun things to do 
[11:02:11 CET] <nevcairiel> if an interesting project engages a new contributor, he is more likely to also do boring work afterwards
[11:02:18 CET] <ubitux> but most of the unpaid people already pick the fun things to do
[11:03:42 CET] <nevcairiel> projects shouldnt be useless of course, because once the student realizes that it also removes a lot of the motivation, but projects also shouldnt be the same old boring ones from 5 years ago because we can't think of any interesting ideas
[11:04:59 CET] <wm4> well, "useless"
[11:05:26 CET] <wm4> there are many things being done that don't have a high need, but might be useful for some people in some situations, like all those filters
[11:08:16 CET] <iive> well, i could agree that it is your personal fault for not been able to think of project(s) that are both useful and fun/engaging :P
[11:09:02 CET] <wm4> sure, and yours as well
[11:10:22 CET] <nevcairiel> maybe we just shouldnt participate for a year and try to come up with project ideas for 2017 now already, instead of rushing through that in 3 weeks again next winter =p
[11:10:23 CET] <iive> can't take a joke :|
[11:10:51 CET] <nevcairiel> its not a joke, its the truth, everyone here is to blame for not having any fun ideas =p
[11:11:14 CET] <iive> that's because there is no low hanging fruit anymore
[11:20:00 CET] <jkqxz> Better plant some more fruit trees, then.  Once your orchard has been around for a few years, there will tend not to be anything with the right scope without doing something different.
[11:26:39 CET] <iive> the problem is that we already cover the majority of the available assortments. Even some of the old and obscure ones (like video game decoders).
[11:31:24 CET] <ank_95_> Hello, I am new to this organisation. I was looking through the project ideas and found them interesting. Can Somebody tell whether this org will be participating in GSOC'16 or not ?
[11:33:59 CET] <nevcairiel> We have applied, but in the end google will decide if we take part
[11:35:47 CET] <ank_95_> Okay, Thanks!
[12:38:33 CET] <wm4> woah $15 bounty for demuxing hds
[12:46:52 CET] <nevcairiel> wm4: better get on it, it can fund about half a day of food to sustain you while you work
[13:04:16 CET] <Daemon404> lmao $15
[13:04:38 CET] <ubitux> looking for an arm/aarch64 instruct to do (a*b)>>16 where a and b are i16
[13:04:52 CET] <ubitux> would anyone knows that here?
[13:08:05 CET] <wbs> ubitux: for neon there's vqdmulh, but that's also doubling at the same time (for some reason that I'm not familiar with)
[13:08:39 CET] <ubitux> sqdmulh seems indeed to match the description
[13:08:42 CET] <ubitux> thx
[13:09:37 CET] <jkqxz> vmull (widening multiply) + vqshrn (right shift and narrow) would do it.
[13:11:44 CET] <ubitux> jkqxz: not enough space
[13:24:36 CET] <cone-142> ffmpeg 03Carl Eugen Hoyos 07master:03af008e21ca: doc/filters: Fix idet option name "rep_thres".
[13:33:05 CET] <cone-142> ffmpeg 03Carl Eugen Hoyos 07master:0f31d401c35c: lavc/mjpegdec: Fix decoding images with Adobe_CM tag.
[14:18:34 CET] <durandal_170> is ffmpeg work paid so cheap?
[14:19:15 CET] <nevcairiel> if you find the right company, they tend to pay you decent money
[14:19:20 CET] <J_Darnley> (if at all)
[14:21:56 CET] <J_Darnley> Well damn.  It doesn't crash any more but now I've got 300 lines of assembly to check for bugs
[14:39:31 CET] <J_Darnley> Is ffmpeg supposed to be able to decode vc2 that it made itself?
[14:39:52 CET] <ubitux> ethe: the dispatch.h check is not correct
[14:40:02 CET] <ubitux> it only check for the header but it doesn't link to the library
[14:40:12 CET] <ubitux> so link will fail if the header is present but there is no library
[14:48:26 CET] <Daemon404> J_Darnley, i would think so...
[14:48:44 CET] <Daemon404> but i dont remember the internal dirac decoder being amazing
[14:49:15 CET] <nevcairiel> ubitux: cant you just overwrite shlibdir? I use --shlibdir="@loader_path" when building for OSX, something similar would work for iOS without a new option?
[14:49:54 CET] <ubitux> this literally creates a @loader_path directory when doing a make install
[14:50:13 CET] <J_Darnley> Daemon404: what containers other than raw vc2 would be a good idea for muxing it in?
[14:50:20 CET] <nevcairiel> this is true, but i move it into an appropriate place after anyway
[14:50:33 CET] <nevcairiel> iOS or OSX are not systems where make install is particularly useful =p
[14:50:52 CET] <Daemon404> J_Darnley, i have no idea.
[14:50:57 CET] <J_Darnley> oh well
[14:51:22 CET] <ubitux> nevcairiel: i like to control both dir anyway
[14:51:38 CET] <Daemon404> oh GOD
[14:51:42 CET] <Daemon404> liekly/unlikely
[14:51:44 CET] <Daemon404> kill me now
[14:52:09 CET] <wm4> look forward to hundreds of patches adding it EVERYWHERE
[14:53:17 CET] <jrosser> J_Darnley: poeple might expect vc2 in mxf
[14:53:49 CET] <J_Darnley> thanks
[14:53:54 CET] <J_Darnley> I sorted my issue
[14:53:58 CET] <J_Darnley> mostly user error
[14:54:23 CET] <J_Darnley> I needed to give a framerate when decoding the vc2 file
[14:57:00 CET] <Daemon404> wm4, GNU codebases came to mind
[14:57:12 CET] <Daemon404> and i dont think any GNU codebase is really... maintainable/readable.
[14:57:27 CET] <Daemon404> not any of the core projects anyway
[14:57:32 CET] <J_Darnley> wow, neat glitch art
[14:57:40 CET] <wm4> we will convert to GNU coding style as well
[14:57:54 CET] <wm4> for a speedy and free future
[14:57:56 CET] <nevcairiel> i tried to find an issue in binutils once
[14:57:59 CET] <nevcairiel> the code is so fucking ugly
[14:58:27 CET] <nevcairiel> every second C construct is replaced by some crazy macro, every if has unlikely's
[14:59:51 CET] <nevcairiel> interestingly i found my issue =p
[15:00:02 CET] <Daemon404> how unlikely.
[15:00:13 CET] <nevcairiel> was mingws fault afterall
[15:00:29 CET] <nevcairiel> that was to be expected, yes, but still :p
[15:01:09 CET] <ubitux> poor ganesh
[15:01:30 CET] <ubitux> he was unactive for a while, and suddenly 2 angry devs jump at him at his first patch
[15:01:32 CET] <ubitux> :D
[15:02:00 CET] <nevcairiel> well he comes back with another idea for nuisance patches
[15:05:39 CET] <Nithiya> Hi... I would like to work on the project " TrueHD encoder". Can someone please help me how to get started?
[15:08:38 CET] <wm4> Nithiya: try to contact the mentor for this project
[15:10:30 CET] <Nithiya> But she is not in the list 
[15:11:37 CET] <wm4> " Mentor: Ramiro Polla (ramiro in #ffmpeg-devel on Freenode IRC, ramiro DOT polla AT gmail DOT com) "
[15:11:50 CET] <wm4> not on IRC, but there's a e-mail address
[15:14:43 CET] <Nithiya> wm4: Thank you
[16:19:26 CET] <ethe> ubitux: oh right, I'll make a patch for that quickly
[16:19:27 CET] <ubitux> mmh new bsf api
[16:19:36 CET] <ubitux> ethe: there is a patch on the ml already
[16:19:53 CET] <ubitux> rcombs: how is this libav bsf api going to fit with your ffmpeg changes?
[16:26:58 CET] <ethe> ubitux: so I dont need to do anything? Although, other systems could potentially have a working libdispatch/GCD as well--So maybe I need to add support for manually enabling, and checking for, it on other systems
[16:27:12 CET] <ubitux> ethe: you can comment on the patch
[16:28:50 CET] <ethe> err. yes... I can :)
[16:33:29 CET] Action: J_Darnley wonders whether the output is better now than before
[17:18:52 CET] <J_Darnley> okay, that output is definitely better
[17:26:19 CET] <ubitux> can't make the preload useful in any way on aarch64 :(
[17:26:35 CET] <ubitux> so i guess i'll push without it
[18:06:37 CET] <Daemon404> does any sane person want to chime in with me on this img2dec mimetype thing
[18:07:17 CET] <Daemon404> preferably someone who doesnt think webservers call 'file'
[18:08:41 CET] <ubitux> heh, nice the csel instruction
[18:09:34 CET] <wm4> Daemon404: well he admits that jpg might be problematic
[18:09:51 CET] <Daemon404> heh
[18:10:00 CET] <Daemon404> it's not just jpeg
[18:10:04 CET] <Daemon404> it is a problem for all http/image
[18:10:23 CET] <Daemon404> especially when stuff ends up getting detected as bloody mp3
[18:10:36 CET] <Daemon404> i dont get why you would not want to factor mimetype into probing
[18:11:17 CET] <wm4> he has a point that at least stuff like PNG should be very reliable and cheap for probing (just a 4 byte magic at the start of the stream)
[18:11:18 CET] <ubitux> images are just signal, depending on your PoV you can consider it sound
[18:11:23 CET] <ubitux> :s
[18:11:46 CET] <Daemon404> wm4, that's one sort of image only
[18:12:04 CET] <Daemon404> wm4, btw i think you asploded the mp3 demuxer recently
[18:12:10 CET] <Daemon404> i can make it loop infinitly over http
[18:12:16 CET] <Daemon404> due to unchecke avio_seek i think
[18:12:47 CET] <wm4> uh
[18:13:08 CET] <Daemon404> it's requesting a http range past teh end of the file, and gettign a 416, and it increments the pos by one, forever
[18:13:12 CET] <Daemon404> and keeps getting 416s
[18:13:17 CET] <wm4> that ffio_ensure_seekback abomination?
[18:13:25 CET] <Daemon404> possibly
[18:13:48 CET] <Daemon404> it's next on my list of things to investiage
[18:13:54 CET] <wm4> that code got pretty complex
[18:14:04 CET] <Daemon404> it was blowing some stuff up because, lavf being lavf, detected a bunch of urls as mp3
[18:14:07 CET] <Daemon404> and looped infinitely
[18:15:59 CET] <wm4> also lol @ mp3 probing
[18:16:09 CET] <Daemon404> he mentions mpeg a bunch of times
[18:16:11 CET] <Daemon404> i assume he means mp3
[18:16:30 CET] <wm4> I can still play random files in /bin as mp3 with lavf
[18:16:49 CET] <Daemon404> you know
[18:16:59 CET] <Daemon404> hmmm damn
[18:17:07 CET] <Daemon404> i guess i cant disable just mp3 probing
[18:17:13 CET] <Daemon404> because of the way its put in mov and stuff
[18:17:20 CET] <Daemon404> during build, i mena
[18:20:02 CET] <nevcairiel> Usually those are with extremely low scores, can't we make mp3 just ignore those files instead
[18:24:34 CET] <wm4> low scores will skip some legitimate mp3s
[18:24:59 CET] <Daemon404> i dont blame lavf for it, i blame whoever designed the mp3 format
[18:25:07 CET] <nevcairiel> Then make the probe smarter?
[18:25:33 CET] <wm4> many formats "support" id3v2
[18:25:44 CET] <wm4> and often id3v2s will contain large images
[18:25:48 CET] <wm4> it's not so easy
[18:25:54 CET] <Daemon404> short of reading the whole file, you cant have a 100% accurate mp3 probe, afaik
[18:26:05 CET] <nevcairiel> Then do that :p
[18:48:22 CET] <atomnuker> J_Darnley: you can contain Dirac/VC-2 in Ogg and Matroska
[18:49:22 CET] <atomnuker> both work with the encoder
[18:50:25 CET] <atomnuker> you can also output it to a mpegts stream, to the dismay of some (probably not strictly standards compliant) and pipe that into a media player
[18:57:24 CET] <wm4> <atomnuker> J_Darnley: you can contain Dirac/VC-2 in Ogg and Matroska <- sounds like one of those things only ffmpeg will be able to play
[18:59:47 CET] <rcombs> wm4: now I'm imagining patching the program loader to pass unrecognized files through libavformat probing, and if applicable treating mpv as the program interpreter
[19:00:13 CET] <rcombs> so you could mark a media file as +x and then run it as an executable
[19:00:19 CET] <rcombs> (note: this is a TERRIBLE IDEA)
[19:00:32 CET] <wm4> indeed
[19:00:35 CET] <JEEB> mateo`: tried your v2 branch and it seems like there's some timestamp weirdness with libmpv
[19:00:39 CET] <rcombs> /usr/bin/rickroll.mp4
[19:00:53 CET] <wm4> JEEB: did you make mpv feed it timestamps in microseconds or whatever?
[19:01:30 CET] <JEEB> hmm,I don't think I did
[19:02:07 CET] <atomnuker> wm4: well, AFAIK the ogg encapsulation is spec-compliant
[19:02:17 CET] <atomnuker> (as given by the BBC themselves)
[19:02:52 CET] <atomnuker> but yeah, I doubt anything else other than lavf has implemented that
[19:04:42 CET] <Daemon404> you can use libogg + a ton of manual work if you hate life
[19:09:26 CET] <BBB> ubitux: does that also fix shlibs on osx when not installing?
[19:50:29 CET] <J_Darnley> atomnuker: thanks for the suggestion about containers
[19:51:10 CET] <J_Darnley> I resolved my issue about the raw stream by just giving -r as an input option
[20:08:42 CET] <ubitux> BBB: no idea; default behaviour isn't changed
[20:09:08 CET] <BBB> I need to manually run name_install_tool every time I link any app with libav*.dylib
[20:09:42 CET] <ubitux> yes, it saves this operation
[20:46:09 CET] <wm4> jesus christ, I'm getting libav-devel mails on ffmpeg-devel
[20:46:14 CET] <wm4> thanks a lot claws-mail
[21:10:26 CET] <darkapex> atomnuker: As ramiro is unable to mentor for this GSoC term, would you like to mentor the TrueHD encoder project?
[21:12:46 CET] <mateo`> JEEB: can you describe what is happening ?
[21:13:06 CET] <JEEB> it keeps going either slower or faster, oscillating
[21:13:10 CET] <JEEB> weird stuff
[21:13:31 CET] <JEEB> in an earlier version of the decoder I used to get completely bonkers timestamps, but that doesn't seem to be an issue any more
[21:14:17 CET] <mateo`> is it with a particular sample ?
[21:16:21 CET] <JEEB> I tried one with mpv's matroska demuxer, and one with lavf
[21:16:23 CET] <wm4> mateo`: keep in mind that by default mpv sends absurd timestamps to the decoder
[21:16:32 CET] <JEEB> oh
[21:16:34 CET] <wm4> that's because they're reinterpret-casted double values
[21:17:14 CET] <JEEB> any params I can set to poke at that?
[21:17:26 CET] <mateo`> btw, tomorrow i'll take some time to update the patchset and include all wm4 remarks
[21:18:16 CET] <wm4> JEEB: vd_lavc.c uses microsecond timestamps specifically for mmal, you could enhance this
[21:18:27 CET] <wm4> JEEB: should be just a line of code
[21:20:34 CET] <JEEB> oh right
[21:20:36 CET] <JEEB> that thing
[21:20:42 CET] <JEEB> I might have poked at that once before
[21:21:28 CET] <wm4> mateo`: I'm thinking we might have to expose the required codec timebase as a new field in AVCodecContext...
[21:24:04 CET] <mateo`> why ? (i might be missing something here; i'm just forwarding the input pkt pts to the output frame pkt_pts)
[21:25:26 CET] <wm4> because these decoders tend to mess with timestamps in deep ways
[21:25:50 CET] <wm4> up to the point that if they're not in the unit they expect it might cause issues
[21:25:58 CET] <wm4> (because they're trying to be too clever)
[21:30:08 CET] <mateo`> sure, and it will be probably useful when i'll support surface output, because the timestamps you push to the decoder gets propagated to the surface timestamps and it could probably be useful to get the values scaled to microseconds (that's what the api is expecting)
[21:34:09 CET] <cone-867> ffmpeg 03Matthieu Bouron 07master:666e2edc41b7: configure: add missing --strip option to show_help()
[21:45:55 CET] <ubitux> damn, there are so much flavor of C version of yuv2rgb 
[21:48:41 CET] <ubitux> yuv2rgb_{X,1,2}_c_..  i'm curious about what these X, 1 and 2 mean
[21:49:05 CET] <wm4> how long until you consider zimg a viable alternative?
[21:50:45 CET] <ubitux> i didn't (completely) give up on subtitles, i'm not going to give up on sws :p
[21:54:27 CET] <ubitux> btw, unless i'm mistaken, it looks like it's not going to process the border when the stride is not large enough
[21:55:01 CET] <ubitux> i wonder if we need some kind of helper/fallback for most optimizations in sws
[21:55:23 CET] <ubitux> such that unlaligned/odd padding are not processed in asm but simply as C
[21:55:48 CET] <ubitux> asm process most of the pic, then you'd have a 2nd pass to fill the few remaining pixels
[21:55:56 CET] <ubitux> probably not very cache efficient though
[21:56:27 CET] <ubitux> doing it in asm itself is often very problematic
[21:58:24 CET] <Compn> zimg uses graphicsmagick code
[21:58:39 CET] <Compn> wonder why there was not much imagemagick / ffmpeg collaboration
[22:00:11 CET] <ubitux> what kind of collaboration?
[22:00:29 CET] <ubitux> Compn: it's like you're wondering about collaboration between gnome and kde
[22:00:40 CET] <ubitux> "can we merge some code?"
[22:01:42 CET] <Compn> more like google/on2 and ffmpeg or x264 and ffmpeg.
[22:01:52 CET] <Compn> which both have been done...
[22:02:05 CET] <wm4> <Compn> zimg uses graphicsmagick code <- the fuck? no
[22:02:17 CET] <Compn> sharing optimized code that does the same thing in both projects is a thing :P
[22:02:35 CET] <Compn> wm4 : https://github.com/buaazp/zimg/blob/master/src/zscale.c "* @brief scale image functions by graphicsmagick.
[22:02:57 CET] <Compn> probably you are talking about some other part of the code.
[22:03:04 CET] <wm4> wrong project
[22:03:09 CET] <Compn> or that :D
[22:03:09 CET] <Compn> lol
[22:04:01 CET] <wm4> https://github.com/sekrit-twc/zimg
[22:04:29 CET] <durandal_1707> Compn: what lies are you spreading? 
[22:06:02 CET] <fritsch> mateo`: you work on amlogic or mediacodec?
[22:06:33 CET] <Compn> durandal_1707 : all of the lies.
[22:06:41 CET] <mateo`> fritsch: mediacodec
[22:06:45 CET] <fritsch> mateo`: if on amlogic, you need to sort the dts and remember that it is some kind of "streaming" codec, that uses it's own pts for dropping and rendering is done completely without influence
[22:06:53 CET] <fritsch> mateo`: okay, then not that much of a beast
[22:11:45 CET] <mateo`> thanks for the info (i'm not familiar at all with amlogic)
[22:13:38 CET] <wm4> fritsch: that sounds so fucking broken
[22:14:29 CET] <fritsch> yes :-(
[22:14:45 CET] <fritsch> we currently investigate a way to get the "buffer" back
[22:14:54 CET] <fritsch> so that we have more control on rendering
[22:15:58 CET] <JEEB> ouch
[22:17:30 CET] <JEEB> Compn: 
[22:17:31 CET] <JEEB> 23:14 < anon32> didn't know that buaazp project existed before I started
[22:17:31 CET] <JEEB> 23:14 < anon32> it was originally meant to parody C.img
[22:19:13 CET] <JEEB> wbs: just checked out the latest thing that is supposed to become the "Common Media Format for Segmented Media" spec. edit lists are tolerated, but only for *audio* delay
[22:20:28 CET] <wm4> does libavformat export mp4 audio delay correctly yet?
[22:20:42 CET] <wm4> because I haven't found out yet if it does (also, too lazy to read mov.c)
[22:20:48 CET] <wbs> JEEB: what spec is that?
[22:20:51 CET] <wbs> wm4: afaik it does
[22:20:53 CET] <Daemon404> "mp4 audio delay" could mean like 5 different things
[22:21:09 CET] <JEEB> wbs: something posted on mp4-sys
[22:21:15 CET] <wm4> ok, I want to play m4a files gaplessly
[22:21:19 CET] <wm4> which of the 5 things do I need
[22:21:39 CET] <JEEB> pre-roll
[22:21:39 CET] <wbs> wm4: ah, the end trimming probably isn't exported correctly though
[22:21:56 CET] <JEEB> although no idea what itunes exports
[22:22:35 CET] <Daemon404> cool kids only listen to optimfrog
[22:23:29 CET] <JEEB> wbs: http://up-cat.net/p/bc0ac7c1
[22:25:14 CET] <JEEB> so basically using negative CTS offsets to make CTS offset zero @ sample[0] becomes canonical, and edit lists are only available for audio :D
[22:25:29 CET] <JEEB> this is not a finished document, but yeah...
[23:02:24 CET] <JEEB> mateo`: seems to have gotten fixed after adding mediacodec to mpv's timebase workaround :) sorry for poking
[23:09:11 CET] <Compn> JEEB : i dont know if i'm supposed to lol or not 
[00:00:00 CET] --- Fri Feb 26 2016