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

[burek]

[00:13] <cone-589> ffmpeg.git 03Martin Storsjö 07master:9fc7184d1a9a: bfi: Avoid divisions by zero
[00:13] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:a6b79bb2b12b: Merge commit '9fc7184d1a9af8d97b3fc5c2ef9d0a647d6617ea'
[00:18] <cone-589> ffmpeg.git 03Martin Storsjö 07master:640a2427aafa: bfi: Add some very basic sanity checks for input packet sizes
[00:18] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:ccb6b056df35: Merge commit '640a2427aafa774b83316b7a8c5c2bdc28bfd269'
[00:36] <cone-589> ffmpeg.git 03Martin Storsjö 07master:c23198766219: mov: Make sure the read sample count is nonnegative
[00:36] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:143a19f5c73b: Merge commit 'c231987662194d009dd91bfc57c678e0e70ca161'
[00:46] <cone-589> ffmpeg.git 03Martin Storsjö 07master:a81cad8f86d1: pngdec: Stop trying to decode once inflate returns Z_STREAM_END
[00:46] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:9834874f8c54: Merge commit 'a81cad8f86d1feb7e4bfae29e43f3e994935a5c7'
[01:05] <cone-589> ffmpeg.git 03Martin Storsjö 07master:9fb0de86b49e: pcx: Consume the whole packet if giving up due to missing palette
[01:05] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:a612bb3099eb: Merge commit '9fb0de86b49e9fb0709a8ad1e1875e35da841887'
[01:16] <cone-589> ffmpeg.git 03Martin Storsjö 07master:30db94dc399f: xan: Use bytestream2 to limit reading to within the buffer
[01:16] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:b6dfb829132d: Merge commit '30db94dc399f6e4ef8905049d9b740556f0fce47'
[01:27] <cone-589> ffmpeg.git 03Martin Storsjö 07master:fc739b3eefa0: xan: Only read within the data that actually was initialized
[01:27] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:7d7fb61e0df7: Merge commit 'fc739b3eefa0b58d64e7661621da94a94dbc8a82'
[01:41] <cone-589> ffmpeg.git 03Martin Storsjö 07master:aa0dd5243476: xxan: Disallow odd width
[01:41] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:1ad36551eca9: Merge commit 'aa0dd52434768da64f1f3d8ae92bcf980c1adffc'
[01:46] <cone-589> ffmpeg.git 03Martin Storsjö 07master:7ba0cedbfeff: rpza: Fix a buffer size check
[01:46] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:1eead877669b: Merge commit '7ba0cedbfeff5671b264d1d7e90777057b5714c6'
[01:54] <cone-589> ffmpeg.git 03Martin Storsjö 07master:d1d99e3befea: pcx: Check the packet size before assuming it fits a palette
[01:54] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:c955bac7d5c1: Merge commit 'd1d99e3befea5d411ac3aae72dbdecce94f8b547'
[01:59] <cone-589> ffmpeg.git 03Martin Storsjö 07master:ff07ec143ebd: pcx: Return an error on broken palette if err_detect is set to 'explode'
[01:59] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:bbe50a8001ad: Merge commit 'ff07ec143ebd3833fd5a3f4b6c00474ac523a31f'
[02:14] <cone-589> ffmpeg.git 03Anton Khirnov 07master:93370d121642: mxfdec: set audio timebase to 1/samplerate
[02:14] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:c7fae9081dfd: Merge commit '93370d12164236d59645314871a1d6808b2a8ddb'
[02:20] <cone-589> ffmpeg.git 03Maxim Poliakovski 07master:23d0fdcf6f30: Add support for multichannel ATRAC3+ streams.
[02:20] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:7a28a9f68e88: Merge commit '23d0fdcf6f30843fc3f14084d80581f1ca10f1f3'
[02:34] <cone-589> ffmpeg.git 03Maxim Poliakovski 07master:487b54104a01: omadec: fix bitrate for ATRAC3+ streams
[02:34] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:5c7d86cbde71: Merge remote-tracking branch 'qatar/master'
[02:46] <lg_> '¶}	ºô-‡
[02:56] <lg_> 'ffmpeg -i a.mp4 -vcodec copy b.mp4' command and the 'cat a.mp4 | ffmpeg -i pipe:0 -vcodec copy -f h264 pipe:1 | cat > c.mp4' command execution result What is the difference?
[02:58] <lg_> I have a video a.mp4, want it to play directly in chrome.
[02:58] <Compn> ask in #ffmpeg
[02:59] <Compn> i dont think you can pipe mp4 without the faststart header...
[02:59] <Compn> stupid mp4 header at the end of the file
[03:01] <lg_> Compn, yes, i think so
[03:01] <lg_> Compn, But what is the solution?
[03:02] <lg_> Compn, I want use pipe to conversion.
[03:11] <lg_> Compn, do you have use pipe conversion solution?
[03:49] <Compn> want to use pipeeeeeeeee
[03:50] <Compn> no idea lg_
[03:50] <Compn> chrome wont open your mp4 file directly ?
[03:50] <lg_> yes i want to use pipe
[03:51] <lg_> yes, my mp4 may be missing headers 
[03:54] <lg_> can open using 'ffmpeg -i a.mp4 -vcodec copy b.mp4' command converted 
[10:16] <ubitux> Daemon404: the lut thing is done, i just need to rework one of them
[10:16] <ubitux> didn't find a time gap yet
[10:53] <cone-349> ffmpeg.git 03Paul B Mahol 07master:cd1b22d8e894: avfilter/dualinput: simplify
[11:28] <cone-349> ffmpeg.git 03Carl Eugen Hoyos 07master:e34ba4723ee5: Avoid img_segment_size == 0 in mtv demuxer.
[11:28] <cone-349> ffmpeg.git 03Michael Niedermayer 07master:b0b5012e77eb: Merge remote-tracking branch 'cehoyos/master'
[11:57] <cone-349> ffmpeg.git 03Timothy Gu 07master:8fd8ead23cdc: doc/t2h.init: remove resource-type and distribution meta elements
[12:04] <durandal_1707> saste: what about checking how slice threading makes rotate faster? (i can't)
[12:05] <cone-349> ffmpeg.git 03Michael Niedermayer 07master:0a0b7267b21c: configure: fix build with enable-xmm-clobber-test
[12:13] <saste_> durandal_1707, why can't you?
[12:13] <durandal_1707> i have single cpu
[12:18] <ubitux> durandal_1707: it's really cool all the threading improvements you do to lavfi, but i really don't get why you care about it :D
[12:18] <ubitux> (since you have a single cpu)
[12:18] <durandal_1707> for time when i'm on multicore cpu
[12:21] <ubitux> durandal_1707: does that happen?
[12:29] <durandal11707> ubitux: are you trying to tell me something?
[12:30] <ubitux> durandal11707: i'm just trying to understand why you don't seem to have access to that multicore cpu most (all) the time
[12:30] <ubitux> even though you seem to care about it :p
[12:33] <durandal11707> so i should care about things only that I have access to?
[12:38] <ubitux> i'm just surprised :)
[12:53] <BBB> hm there's still an issue in that ffvp9 patch with tiling (good thing I'm writing fate tests), don't push it yet :)
[12:54] <Compn> durandal11707 : do you need some funding for multicpu ?
[12:54] <Compn> ffmpeg has funds for that
[12:54] <durandal11707> i really doubt that
[12:55] <Compn> we do
[12:55] <Compn> its exactly what the funds are for
[12:55] <Compn> write up an invoice for whatever cpu you want, it will be funded :)
[12:55] <Compn> obv within reason, no $4k cpu server farm :P
[13:01] <cone-349> ffmpeg.git 03Paul B Mahol 07master:f4ab723a79fd: cmdutils: print command support in -filters.
[13:02] <michaelni> Compn, durandal11707, i second that, core developers should have multicore in 2013
[13:03] <michaelni> espeially wen they work on multithreading
[13:06] <saste_> durandal11707, we have 691.55$ left
[13:09] <Daemon404> pretty sure BBB had access to more cores than you can imagine
[13:09] <Daemon404> :P
[13:09] <Daemon404> >google
[13:09] <Daemon404> BBB, contnuing review toda
[13:09] <Daemon404> hopefully will finish
[13:10] <Daemon404> long patch is long
[13:14] <BBB> Daemon404: uh
[13:14] <BBB> Daemon404: I don't work at google anymore, you know that, right?
[13:14] <BBB> oh had, right, ok
[13:14] <BBB> nm
[13:15] <Daemon404> yeah
[13:15] <Daemon404> past tense
[13:17] <BBB> removed #if 0 block, will add a comment to that function
[13:17] <BBB> working on some more fate test coverage first
[13:17] <BBB> the fuzz seems relatively quiet now
[13:18] <BBB> it found 2 bugs so far, not too bad
[13:18] <BBB> one of which was some code I added in response to a review comment :-p
[13:18] <Daemon404> ;p
[13:19] <Daemon404> man, it lags my mail client to hit reply to that email
[13:20] <Daemon404> i wonder why there is no client with a proper gui + able to handle dev work
[13:31] <Compn> durandal11707 : so yes, please pick out a multicore cpu/mobo you would like. 
[13:31] Action: Compn afk
[13:36] <Daemon404> BBB, that code blob the LUT will replace is quite scary btw
[13:36] <Daemon404> or at least ugly~
[13:41] <BBB> ugly, yes
[13:46] <kierank> Daemon404: iirc h264 has worst stuff
[13:46] <kierank> for mbaff neighbour checking
[13:50] <durandal11707> why are there so many useless filters?
[13:50] <Daemon404> kierank, not shocking
[13:50] <Daemon404> g 42
[13:50] <Daemon404> woops
[13:54] Action: Daemon404 didnt know FASTDIV() was a thing
[13:59] <Daemon404> i keep forgetting vp8/9 do not have B frames
[14:09] <durandal11707> still?
[14:13] <ubitux> Daemon404: what is ugly? the code blob or the lut replacement?
[14:14] <durandal11707> i'm just interested by how much this slice threading can speed things up
[14:16] <Daemon404> ubitux, the blob
[14:16] <Daemon404> BBB, sent
[14:16] <Daemon404> now, lunch.
[14:17] <BBB> cool, will address over the next few days, ty
[14:21] <iive> lut may be simple, but they also tend to be quite slow.
[14:23] <durandal11707> hmm, really?
[14:24] <durandal11707> i expect they benchmarked it w/out lut
[14:26] <iive> that's why I would request benchmark numbers:)
[14:27] <iive> and to be honest, I missed the context of the conversation, so I have no idea what the code in question looks like.
[14:30] <iive> i just assumed it is about eq2 filter.
[14:31] <durandal11707> no its about ffvp9
[14:32] <iive> if we assume that lut is entirely in the cache, the bottleneck would be reading the pixel data. it should be done one byte at a time, that byte should be looked up and then written. You can speed that up by reading a whole register and splitting/merging the data. Simd would be faster is most cases, because it would read a lot more at once.
[14:34] <cone-349> ffmpeg.git 03Michael Niedermayer 07master:54197c7aae74: skip_bits: dont call UPDATE_CACHE
[14:36] <iive> well, then it depends what the code does.
[14:38] <ubitux> i didn't bench
[14:39] <ubitux> https://github.com/ubitux/FFmpeg/commit/dce2119dcd5a94677ab1fe4df616a03bf5c46619
[14:39] <ubitux> i want to reduce this one: https://github.com/ubitux/FFmpeg/commit/dce2119dcd5a94677ab1fe4df616a03bf5c46619#diff-73b2f06f81e7f6cdc34af712153ea2f2R1377
[14:39] <ubitux> before submitting
[14:39] <ubitux> i'll try to look at it asap
[14:46] <iive> I can't say i like the old code, but i can't say the new one is better. 1024 table is just huge... and most of the data is redundant.
[14:47] <ubitux> that table is annoying
[14:47] <ubitux> that's why it's not considered done yet 
[14:47] <ubitux> the other are more sexy
[14:47] <iive> also, conditions are also slowing down factor, and replacing if() with  ?: is not helping.
[14:47] <ubitux> we can reduce some of the branching
[14:50] <iive> it would be best if you can calculate these values, without using branching or lookups.
[14:53] <ubitux> yes that's the plan
[14:56] <iive> and always benchmark :)
[14:56] <iive> bbl
[15:16] <cone-349> ffmpeg.git 03Paul B Mahol 07master:862773907a74: avfilter/vf_rotate: support slice threading
[15:16] <cone-349> ffmpeg.git 03Paul B Mahol 07master:2a6a3d4317e6: avfilter/vf_hflip: refactor plane dimensions calculation
[15:16] <cone-349> ffmpeg.git 03Paul B Mahol 07master:0a4aea6db914: avfilter/vf_hflip: support slice threading
[15:42] <durandal11707> what about splitting config.h for lavfi,lavf and lavc ?
[15:59] <iive> durandal11707: why?
[16:00] <durandal11707> if you add something to lavf you do not need to recompile lavfi & lavc
[16:06] <iive> then why make only 3 separate files... let put every option in its own file ;)
[16:07] <durandal11707> that does not make sense
[16:07] <durandal11707> libs are separate
[16:08] <iive> how often do you add stuff to lavf that changes config.h and how much time does it take to compile the rest. (btw ccache a preprocessor mode, that is more efficient in this case).
[16:08] <durandal11707> not at all
[16:08] <durandal11707> obviously you do not compile ffmpeg every day
[16:10] <iive> a/have a
[16:11] <iive> i always do clean build.
[16:12] <iive> it could become nightmare if for some reason the different files get out of sync, or distribution install libraries compiled at different time with different options.
[16:14] <Daemon404> i clean build for every tiny change during dev work would be insanity
[16:15] <Daemon404> our configure is hilariou slow
[16:15] <Daemon404> hilariously*
[16:15] <iive> it is pandora's box.
[16:16] <iive> i do not call configure for every tiny change... during development.
[16:16] <cone-349> ffmpeg.git 03Michael Niedermayer 07master:31b6300f4d71: doc: try to add a link from the vf_scale sws_flags to the scaler docs
[16:16] <iive> btw, does ffmpeg configure checks if new config.h is content identical to the old one?
[16:17] <durandal11707> michaelni: do that really work across files?
[16:17] <michaelni> it worked locally
[16:23] <saste_> durandal11707, no
[16:24] <saste_> gets to be fixed now
[16:37] <ubitux> Daemon404: i think the anonymous struct only matters for public api
[16:38] <Daemon404> it's been enforced lately in internal code
[16:38] <ubitux> internally, i think the redundancy of struct name & typedef really sucks
[16:38] <Daemon404> in Libav
[16:38] <ubitux> for what reason?
[16:38] <Daemon404> afaik.
[16:38] <Daemon404> Diego reasons
[16:38] <ubitux> ok so no technical reason
[16:38] <Daemon404> i didnt say You Should Do THis
[16:39] <Daemon404> just that This Is What's Been Done
[16:44] <cone-349> ffmpeg.git 03Stefano Sabatini 07master:fd0a1647f26a: doc/filters/scale: fix MAN rendering of @ref arguments
[16:56] <durandal11707> ubitux: did you had usecase when doing silencedetect filter?
[16:56] <ubitux> yes, detecting broadcasting downtime
[16:57] <ubitux> from a "always on" audio streaming relay
[16:57] <ubitux> another usecase would be to automatically trim sound or detect track change when an audio album is recorded into a single track for instance
[16:58] <durandal11707> and how would auto trim work?
[16:58] <ubitux> ffprobe + another filter
[16:58] <ubitux> metadata scriptinge to the rescue i guess
[16:58] <ubitux> -e
[16:59] <ubitux> durandal11707: note that it's a 2 hours work filter, and i didn't do extensive tests
[17:06] <durandal11707> its metadata is not in samples
[17:20] <durandal_1707> ubitux: i'm thinkinkg of writing silenceremove , and i do not think i can use silencedetect metadata
[17:20] <ubitux> you can't adjust it?
[17:30] <cone-349> ffmpeg.git 03Stefano Sabatini 07master:d17aaad63081: doc/filters/scale: mention and link scaler options
[17:30] <cone-349> ffmpeg.git 03Stefano Sabatini 07master:8fafaf183426: doc: move sws_dither option description to scaler.texi
[17:32] <durandal_1707> ubitux: i do not think so, also silenceremove would remove some non-silence samples, which silencedetect would never do....
[17:32] <ubitux> do as you please
[17:32] <ubitux> note that we have something like 3 filters to detect volume/silence
[18:06] <cone-349> ffmpeg.git 03Paul B Mahol 07master:fc0d8cf18592: fate: add fieldorder test
[21:36] <ubitux> ok so no one wants to look at the dvbsub bugs? :(
[21:37] <durandal_1707> nobody knows aything about subtitles
[21:40] <ubitux> :(
[21:41] <ubitux> i guess i won't have any review to my dvdsub/vobsub patchset as well?
[21:52] <cone-349> ffmpeg.git 03wm4 07master:01e3340fb602: swscale: make bilinear scaling the default
[21:53] <iive> ubitux: i though you are the expert.
[21:54] <ubitux> iive: i fucking hate subtitles... i just happen to often needs them :(
[21:54] <ubitux> and i'm definitely not a bitmap sub expert
[21:57] <wm4> lol
[21:58] <wm4> ubitux: I can post a reply that it works for me, if that helps for getting the patches pushed faster
[21:59] <ubitux> i will push anyway in a day or two
[22:04] <ubitux> btw, i'm going to ask again
[22:04] <ubitux> i have someone for the website development
[22:04] <ubitux> what do you guys want?
[22:04] <ubitux> or do NOT want
[22:04] <ubitux> (except flash and java applet)
[22:05] <ubitux> !js?
[22:05] <ubitux> no all-in-one solution such as bootstrap?
[22:05] <ubitux> no dynamic backend?
[22:07] <ubitux> (no one care?)
[22:09] <iive> i browse with noscript, so just keep it simple :)
[22:10] <durandal_1707> ubitux: something that works in ie7 only
[22:11] <ubitux> durandal_1707: deal.
[22:11] <mateo`> ubitux: responsive design
[22:11] <ubitux> what the hell is that supposed to mean?
[22:11] <ubitux> mateo`: are you into buzzworld?
[22:11] <mateo`> just playing bingo :D
[22:11] <iive> it means, that you can talk to it, and it would reply to you.
[22:12] <mateo`> don't ruin my game :D
[22:12] <iive> and make it sure to increase the synergy.
[22:12] <ubitux> so we need a lot of animated gif for lsd effect
[22:12] Action: ubitux starts encoding some gif
[22:13] <durandal_1707> just put mng
[22:14] <mateo`> ubitux: maybe a more "modern" look like what the libav guys have done using bootstrap. Could be more appealing for "people"
[22:15] <ubitux> yes, but the question is more about the veto
[22:15] <ubitux> like what we want to avoid
[22:15] <durandal_1707> ubitux: js script is fine as long its not the only way to browse
[22:16] <Daemon404> i say do it 1997 geocities style
[22:16] <Daemon404> tiled animed gif background
[22:16] <Daemon404> preferabl diablo.
[22:16] <durandal_1707> we really should not promote gif
[22:16] <Daemon404> well. 1998.
[22:16] <ubitux> well typically, some question that arise: should we do drop down menu or not
[22:16] <ubitux> i'd rather not personally
[22:17] <Daemon404> ubitux, i think it helps increase discoverability
[22:17] <Daemon404> i.e. you dont need to follow a maze of links
[22:17] <Daemon404> to find stuff
[22:17] <ubitux> i'd better have a flexible tree menu on the left or right
[22:17] <wm4> does ffmpeg have full mng support yet?
[22:17] <ubitux> see how we fight every time we want to add something in the top menu :(
[22:17] <ubitux> like we can't add the coverage menu currently
[22:18] <Daemon404> i mostly pay it no attention
[22:18] <Daemon404> probably the only thing i *dont* troll about
[22:18] <mateo`> ubitux: would a drop down menu be usefull ?
[22:18] <ubitux> design, future ©®"
[22:18] <Daemon404> ive got it
[22:19] <durandal_1707> well right side is empty so put all links to right and not on top
[22:19] <Daemon404> we put all of ubitux's SWFs on the front page
[22:19] <Daemon404> audio and all
[22:19] <ubitux> Daemon404: :D
[22:19] <ubitux> Daemon404: my swf got validated by z0r.de!)
[22:19] <ubitux> 5 of them!
[22:20] <ubitux> that reminds me i have some unsubmitted patches for ffmpeg
[22:20] <Daemon404> ul
[22:20] <Daemon404> lul
[22:20] <ubitux> there are required to make some z0r compliant swf ;)
[22:20] <mateo`> ubitux: mmm, drop down menu is not the future imho
[22:21] <ubitux> i don't like them ya know
[22:21] <ubitux> :p
[22:21] <mateo`> having a search would be nice
[22:22] <ubitux> ffmpeg-all.html
[22:22] <ubitux> ^F
[22:22] <ubitux> mateo`: that requires dynamic language, likely (unless you do awesomeness like on lolicri.es)
[22:22] <ubitux> and this problably means server maintainance pain
[22:23] <Daemon404> that url is so weeaboo
[22:23] <Daemon404> it hurts
[22:23] <Daemon404> physically hurts
[22:23] <ubitux> :D
[22:23] <ubitux> i feel jealousy
[22:24] <durandal_1707> first page should have chat window
[22:25] <durandal_1707> and there should be torrents to fetch ffmpeg?
[22:25] <mateo`> a qwebirc instance :)
[22:25] <ubitux> "meet the sexy Rodriguez, your FFmpeg hotline"
[22:25] <mateo`> + twitch like, ffmpeg development gone wild ... LIVE !
[22:26] Action: durandal_1707 is serious
[22:26] Action: ubitux too
[22:26] <mateo`> easter eggs: famous videos of ubitux hunting lolies
[22:26] <ubitux> :)
[22:27] <durandal_1707> and one thing i really miss is custom theme, iirc mplayer had/have this
[22:27] <ubitux> durandal_1707: so a webrtc directly linked to #ffmpeg?
[22:28] <mateo`> ubitux: could be great
[22:28] <ubitux> "IRC support" spawning a random web irc client
[22:28] <mateo`> or a qwebirc instance but ... server maintenance burden
[22:29] <mateo`> I really think that a search would be a greate addition to the website
[22:29] <durandal_1707> if actual work was not done by server
[22:30] <ubitux> as i said, it's possible with static pages and js
[22:30] <ubitux> you need to build a db of keywords though
[22:30] <ubitux> and that might be a pain to do
[22:31] <ubitux> especially when parsing the few kB (mB?) of doc)
[23:46] <wm4> oh gawd someone turned ffplay into a library
[00:00] --- Tue Oct  1 2013