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

[burek]

[00:27] <cone-710> ffmpeg.git 03Seppo Tomperi 07master:03cecf45c134: hevcdsp: ARM NEON optimized transforms
[01:27] <cone-710> ffmpeg.git 03Georg Lippitsch 07master:c0367f78d5a5: doc/indevs: Docs for Blackmagic high bit depth video/audio
[08:49] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:694671bc9af5: avfilter/f_sendcmd: consider it an error if there are no commands
[09:49] <j-b> 'morning
[10:00] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:d80fe5d4bce3: avcodec/vb: Check for av_mallocz() failure
[10:22] <ubitux> ok so, the thing about the dependencies
[10:23] <ubitux> (compilation)
[10:23] <ubitux> from yesterday
[10:23] <ubitux> if i edit a libavfilter/vf_*.c 
[10:23] <ubitux> libavdevice/avdevice.o gets recompiled
[10:23] <ubitux> as well as libavfilter/avfilter.o
[10:24] <ubitux> libavformat/utils.o libavcodec/utils.o libpostproc/postprocess.o libswresample/swresample.o libswscale/utils.o ...
[10:24] <ubitux> all of this gets rebuild
[10:24] <ubitux> i'm not sure this is really to be expected
[10:25] <ubitux> mmh maybe not all filters
[10:26] <ubitux> mmh that wasn't the trigger
[10:26] <ubitux> dammit
[10:26] <ubitux> what was it
[10:27] <ubitux> ok i don't get it.
[11:05] <ubitux> ok i get it, i'm an idiot; git commit --amend, adjusting the previous commit which was touching other files
[11:06] <ubitux> and so git probably touch them
[12:01] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:48ffaaaaef98: swresample/x86/rematrix_init: Use av_mallocz_array()
[12:01] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:b74ecb82fa51: swresample/x86/rematrix_init: Check av_malloc* return codes, forward errors
[15:04] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:5763f6750247: avformat/mov: Check dimensions before setting aspect
[15:20] <cone-22> ffmpeg.git 03Paul B Mahol 07master:238247b62291: avcodec/sgienc: return meaningful error code
[17:56] <ubitux> http://lucy.pkh.me/ffgif/outputs/ don't go there if you don't have much RAM
[17:56] <ubitux> if someone wants me to test more inputs, feel free to suggest
[17:59] <ubitux> i should add the sizes
[18:00] <nevcairiel> there is some serious color flashing in the BBB clip .. temporal g radients dont work well eh
[18:00] <ubitux> :(
[18:01] <nevcairiel> seems to be mostly in the bayer variants at least
[18:01] <nevcairiel> f_s and sierra looks much better in that regard
[18:02] <nevcairiel> and no dithering plays out of sync to the others :(
[18:02] <nevcairiel> guess it depends when the browser loaded it
[18:02] <ubitux> yeah :p
[18:06] <nevcairiel> quite some effort you put into this gif thing
[18:10] <ubitux> i added the sizes
[18:10] <ubitux> nevcairiel: yeah well... :)
[18:10] <ubitux> it's kind of fun
[18:11] <ubitux> anyway, going to send the new patchset i guess
[18:12] <ubitux> unless someone wants me to add an input?
[18:12] <ubitux> (but i think the page is heavy enough already :p)
[18:13] <nevcairiel> its always interesting to see how animated pixel art behaves with dithering, but not like I have any at hand
[18:14] <ubitux> i can maybe add a TAS videos or something
[18:15] <ubitux> nevcairiel: http://tasvideos.org/Movies-GBA-Stars-Moons.html pick anything you want and i'll add
[18:39] Action: beastd remembers playing aria of sorrow
[18:39] <beastd> must have been a decade ago...
[18:46] <wm4> why is the matroska parsing code so shitty
[18:47] <wm4> why am I wasting time on this fucking POS
[18:52] <wm4> and why are there 3 functions that add something to an array in mem.h
[18:55] <wm4> and none of them does what I want
[18:56] <jamrial> time to add a fourth? :p
[18:56] <wm4> time for static arrays
[18:56] <compn> wm4 : wrapper around libmatroska? 
[18:56] <compn> :P
[18:57] <wm4>  compn!*@* added to ignore list.
[18:57] <compn> took long enough :)
[19:04] <compn> wonder why we dont have wrappers to the official de/muxing libs though?
[19:40] <nevcairiel> the "official" mkv demuxer lib is stupid, its practically just a definition of all the ebml elements in a mkv file, you still need to interpret them yourself, so the advantage is truely minimal
[19:40] <nevcairiel> and many formats dont have a official lib either way
[21:11] <wm4> ubitux: just btw., this caught my eye: libavcodec/pgssubdec.c:139:    avctx->pix_fmt     = AV_PIX_FMT_PAL8;
[21:12] <wm4> dvdsubdec.c doesn't do the same though
[21:12] <ubitux> ahah, cool :)
[21:12] <ubitux> yeah dvdsub does it differently
[21:29] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:e8f814a90703: avformat/utils: Fix division by 0
[21:42] <cone-22> ffmpeg.git 03wm4 07master:6938a095cb02: matroska: don't complain about unknown elements
[21:50] <sdr__> hi all, how do we tell "true" ffmpeg from libav all version macros seam alike?
[21:50] <wm4> I suppose there's no way to resume an aborted fate run?
[21:50] <nevcairiel> micro is always >= 100 on ffmpeg
[21:50] <wm4> yeah, ffmpeg starts from 100, Libav from 0
[21:50] <wm4> (so silly)
[21:51] <sdr__> yes .. i was wandering if this is the case .. ok thanks lads! :)
[21:57] Action: Daemon404 stares at mp4toannexb
[21:58] <wm4> staring too long is unhealthy
[21:59] <Daemon404> afaict this is the only way to transmux mp4->ts?
[21:59] Action: wm4 watches vsynth_lena scroll by
[21:59] <wm4> so unfree
[21:59] <Daemon404> and also it is very brittle
[21:59] <wm4> yeah, I heard so
[22:00] <Daemon404> bleh
[22:01] <nevcairiel> the problem with that thing is that it has to inject the sps/pps into the stream to make it properly random access ... and that can go wrong a number of ways
[22:02] <Daemon404> i see
[22:02] <Daemon404> i should be more clear: this is for generating hls segments
[22:02] <nevcairiel> just converting the start codes to annexb wouldnt be all that much magic, and cannot go wrong much
[22:02] <Daemon404> yes
[22:02] <nevcairiel> I'm lucky and the only time we do hls generation is also when we're transcoding :D
[22:03] <Daemon404> well i am thinking "to properly random access" may be beside the point here
[22:03] <nevcairiel> how does it break for you?
[22:03] <Daemon404> it has generated broken streams for me in the past
[22:09] <Daemon404> seems hls requires each seg to start with sps/pps
[22:09] <Daemon404> nevcairiel, then shouldnt it be easy ^
[22:09] <kierank> no shit
[22:09] <kierank> each segment of course has to have sps pps
[22:09] <Daemon404> i never read the spec before
[22:09] <Daemon404> other formats dont have this requirement, so you never know
[22:10] <kierank> you can't decode the file without sps/pps
[22:10] <nevcairiel> the spec is kinda strict, implementations are a bit more flexible
[22:10] <Daemon404> kierank, and e.g. DASH has it separate
[22:10] <Daemon404> on its own
[22:10] <Daemon404> in my case, i wonder if a dumb copy would be OK
[22:11] <nevcairiel> i wonder if my current setup is really doing it .. its splitting on packet keyframes, I assume that libx264 encoder puts the sps/pps before the frame inside keyframe packets?
[22:11] <kierank> it does
[22:11] <Daemon404> it sets the type in any caase
[22:11] <kierank> it is mandatory to put sps/pps before the frame 
[22:12] <Daemon404> i am guessing mp4toannexb mostly screws up when there are mid-stream changes?
[22:12] <nevcairiel> i have had a few rare reports about our hls streams not working properly, but i  never bothered to get apples analyzer
[22:12] <nevcairiel> I should also look into this race condition when the playlist is being  re-written
[22:12] <nevcairiel> DASH uses a work-around for that, I should copy it
[22:12] <Daemon404> you mean the init sge?
[22:12] <Daemon404> seg*
[22:13] <nevcairiel> dashenc in avformat writes the new playlist into a .tmp file, and once writing is done, it uses a rename-replace action to replace the original file, so there shouldnt be a case where its half-done when serving it over http directly
[22:14] <Daemon404> oh that
[22:14] <Daemon404> it had some stupid work around on windows
[22:14] <nevcairiel> I think that was replaced recently
[22:14] <Daemon404> cant remember
[22:16] <nevcairiel> it just uses MoveFileEx which should do just that, the work-around part is that it takes wchars
[22:16] <wm4> @rcombs: do you have a link to your seekhead problem mkv file?
[22:17] <wm4> also fuck this @ how did it get here
[22:17] <kierank> twitter
[22:17] <nevcairiel> twitter user!
[22:17] <nevcairiel> :D
[22:17] <wm4> or github
[22:17] <wm4> and many other things unfortunately
[22:17] <nevcairiel> as long as you don't start using hashtags on irc
[22:17] <wm4> let's call it hungarian communication
[22:21] <wm4> ah the 2001's " This is important as many custom PAL8 video codecs that were designed to run on the IBM VGA graphics adapter use 6-bit palette components."
[22:22] <wm4> (second paragraph from the pixel format doxygen)
[22:22] <nevcairiel> heh
[22:39] <wm4> rcombs: found it
[22:39] <wm4> michaelni: seekhead sample https://www.dropbox.com/s/32ve4hp567ukikt/Maken-Ki%21%20-%20S01E02.mkv?dl=1
[22:41] <cone-22> ffmpeg.git 03Supraja Meedinti 07master:9a18247ec0cf: libavutil: optimize camellia cipher
[22:42] <michaelni> wm4, thx
[22:43] <nevcairiel> hm, i think its time i poke the aac thread again
[22:46] <nevcairiel> man trying to post in that ticket makes trac crawl
[22:49] <llogan> i wonder what kind of resources the constant spambots siphon
[22:49] <Daemon404> i dont understand why people spam it at all
[22:49] <Daemon404> return must be close to 0
[22:51] <llogan> it's for google, not people
[22:52] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:54eac5195d68: avutil/camellia: Fix indention & whitespace
[22:52] <cone-22> ffmpeg.git 03Michael Niedermayer 07master:f5d32acc3757: avutil/camellia: Remove redundant casts
[23:32] <rcombs> wm4: sorry, wasn't around, but it seems you found it
[23:33] <Daemon404> llogan, most people solve that by making robots.txt tell google to not index it
[23:33] <Daemon404> but that may be a bad idea for a bug tracker.
[23:35] <wm4> rcombs: yeah, grepped the irc log
[23:37] <BtbN> Daemon404, more people react to spam than you'd think. It's sad.
[23:38] <BtbN> If it's only 1% or less, that's still plenty of people.
[00:00] --- Tue Feb 10 2015