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

[burek]

[00:00] <jamrial> db0: the "more download options" page could become the actual thing the big "Download" button links to
[00:00] <db0> ok
[00:01] <jamrial> i really don't think linking to a source tarball of any kind is a good idea for a button like that
[00:01] <jamrial> 90% of users will flock to it and be all wtf is this
[00:01] <db0> that's what most frameworks do
[00:01] <db0> I don't get it either :P
[00:06] <jamrial> heh, true
[00:07] <jamrial> but in many cases they also detect the os and make the button link to a windows binary or installer, an rpm/deb package or such
[00:08] <db0> I couldn't find a good plugin to do that
[00:08] <jamrial> source tarball tends to be last resort when it can't reliably detect the os
[00:08] <db0> stackoverflow seems to give quick&dirty solutions
[00:08] <db0> so I gave up ^ ^
[00:10] <Daemon404> that website isnt going to work on a 4:3 monitor.
[00:11] <ubitux> it works on phones
[00:11] <db0> it's full responsive, tested on phones and tablets
[00:12] <Daemon404> thats nice but i use a pc
[00:12] <db0> it detects the size of the screen not your browser so a small screen or a tablet screen is the same
[00:12] <Daemon404> the right hand column is rendering kind bad
[00:12] <Daemon404> squished/very wrapped
[00:13] <Daemon404> with a scroll bar on the bottom
[00:13] <ubitux> browser/screenshot?
[00:15] <Daemon404> https://www.dropbox.com/s/iw7zxu31rre4jyr/browser.png
[00:15] <Daemon404> on my phone there are scrolling issues
[00:15] <Daemon404> scrolling the menu *also* scrolls the page
[00:15] <Daemon404> double scrolling effect
[00:16] <Daemon404> (chrome on android 4.2)
[00:21] <Daemon404> https://www.dropbox.com/s/81i331bb40l3f67/space.png <-- my only other comment is that there is a very large waste of space
[00:21] <Daemon404> that ends up squishing it to one side, like 90s fixed-width frame-based websites
[00:23] <J_Darnley> So that's what the missing chars are supposed to show
[00:23] <Daemon404> J_Darnley, i guess you block webfonts?
[00:24] <J_Darnley> Yep
[00:24] <Daemon404> are you a slashdot commenter?
[00:24] <J_Darnley> Yep
[00:24] <Daemon404> shocking.
[00:24] <J_Darnley> :)
[01:15] <cone-519> ffmpeg.git 03Nidhi Makhijani 07master:44386aaad870: cdg: Forward error from avio_size() in read_header() function
[01:15] <cone-519> ffmpeg.git 03Michael Niedermayer 07master:20ad2152ddc2: Merge commit '44386aaad870cbd80ae0d08247ebc663476446ff'
[01:15] <cone-519> ffmpeg.git 03Michael Niedermayer 07master:0089fb79cc11: avformat/cdg: Do not fail if filesize cannot be determined
[04:47] <Timothy_Gu> Daemon404: oh come on, you still use Windows? Even I switched to Linux
[04:51] <Timothy_Gu> ubitux: can you tell db0 that http://db0.galo.pe/ffmpeg-web/projects.html looks kinda ugly on a tablet (Nexus 7 2012 w/ Chrome), with wasteful whitespace and everything else
[04:53] <Timothy_Gu> Also http://db0.galo.pe/ffmpeg-web/documentation.html she should probably switch the icons for libraries and API
[05:33] Action: Compn bets new webpage is broken in opera
[05:34] <Compn> wow
[05:34] <Compn> its not, it actually works , even without javascript
[05:34] <Compn> db0 gets my seal of approval.
[05:34] <Timothy_Gu> Compn are you testing the new Chromium based Opera or the old Opera that M$ hated (and hates)
[05:35] <Compn> old opera
[05:35] <Compn> chrome opera is disgusting
[05:36] <Compn> m$ hated opera ?
[05:36] <Compn> really ?
[05:36] <Compn> strange i dont remember that
[05:36] <Compn> maybe it was before i started using opera (around v5 or v6 )
[05:37] <Compn> opera on phone is still so fast
[05:37] <Compn> also tablet
[05:37] <Compn> chrome broken :\
[05:37] Action: Compn should upgrade cyanogen
[05:40] <Compn> libav's site is still not looking 100% correct in opera :P
[05:40] <Compn> or firefox, if you zoom in a few times
[05:40] <cone-161> ffmpeg.git 03Michael Niedermayer 07master:9195c26d454c: avcodec/rv34: fix crash while seeking on very damaged file
[05:40] <Timothy_Gu> Compn https://en.wikipedia.org/wiki/History_of_the_Opera_web_browser#Second_MSN.com_controversy
[05:40] <Timothy_Gu> etc.
[05:41] <Timothy_Gu> Compn: is that why you dont use Libav?
[05:41] <Timothy_Gu> that was after v7 was released
[05:41] <Compn> ah , frequently sites will have broken css that mess opera up
[05:42] <Compn> it is global conspiracy :\
[05:42] <Compn> or they misdetect opera as IE5 or something stupid
[05:42] <Plorkyeran> chromera's not awful but it's not opera in any meaningful way
[05:44] <Compn> well chrome/chromium is awful
[05:44] <Compn> because i like to have 20-200 tabs open at any given time, ok?
[05:45] <Compn> and firefox/chrome just cant handle that
[05:45] <Timothy_Gu> firefox is nice for everything else than the UI (at least for me)
[05:45] <Plorkyeran> firefox handles a few hundred open tabs without any major problems for me
[05:45] <Timothy_Gu> which is why I use Chrome
[05:45] <Plorkyeran> takes a while to start up but otherwise it's fine
[05:46] <Compn> thats impressive Plorkyeran. i find firefox gets unresponsive on just one or two tabs
[05:46] <Compn> if left open for hours
[05:47] <Plorkyeran> all it takes is one bad page
[05:47] <Plorkyeran> and it doesn't have per-tab cpu usage tracking :/
[05:47] <Compn> install extension to unload background tabs
[05:47] <Compn> or pause them, etiher way
[05:48] <Plorkyeran> meh, just restart it whenever it gets bad
[05:48] <Plorkyeran> which is about once a week
[05:48] <Plorkyeran> I use nightly so there's always updates to install anyway
[05:49] <Compn> i find all browsers get unresponsive unless you disable javascript
[05:49] <Compn> flash also is good at freezing things up
[05:49] <Plorkyeran> I do use noscript
[05:49] <Plorkyeran> makes the internet much more usable imo
[05:52] <Compn> and then stop going to sites that dont work wihout javascript
[05:52] <Compn> night
[09:17] <ubitux> Timothy_Gu: ok
[09:18] <ubitux> Timothy_Gu: not sure about the icon switch for libraries & api; looks fine to me that way
[09:19] <ubitux> and btw, about any scaling issues, i think the problem lies in bootstrap & shit, so if there is a bug there, that's probably because of this :p
[11:33] <db0> I update the logo: http://db0.galo.pe/ffmpeg-web/
[11:33] <db0> it looks a bit messy, but I like it, it's cute
[11:51] <db0> or I can keep the current 3D one
[11:51] <db0> 3D: http://public.db0.fr/tmp/Screenshot%202014-07-11%20at%2011.49.44%20AM.png
[11:52] <db0> hand drawn: http://public.db0.fr/tmp/Screenshot%202014-07-11%20at%2011.50.19%20AM.png
[11:52] <db0> pick your favorite
[11:53] <db0> I'll push all of them in the repo anyway
[11:53] <cone-833> ffmpeg.git 03Anton Khirnov 07master:17e9d52c8c93: hevc_ps: remove a write-only variable
[11:53] <cone-833> ffmpeg.git 03Michael Niedermayer 07master:f351afb5f9de: Merge commit '17e9d52c8c93f47721ff481b8867922f4b4bd663'
[11:54] <ubitux> is this a paper clip your torn?
[11:54] <ubitux> -r
[11:57] <db0> here is the repo btw https://github.com/db0company/web/commits/master
[12:05] <cone-833> ffmpeg.git 03Mickaël Raulet 07master:1493b237bd3f: hevc: Replace nal type chek with equivalent IS_IRAP macro
[12:05] <cone-833> ffmpeg.git 03Michael Niedermayer 07master:673a2b381803: Merge commit '1493b237bd3f9707319ac58d315ce45312900c10'
[12:16] <cone-833> ffmpeg.git 03Mickaël Raulet 07master:f43789b76e66: hevc: set the keyframe flag on output frames
[12:16] <cone-833> ffmpeg.git 03Michael Niedermayer 07master:aa56c37c8ac5: Merge commit 'f43789b76e661acd93c21664678f140e53cfa1fa'
[12:28] <cone-833> ffmpeg.git 03Gildas Cocherel 07master:458e7c94830d: hevc: implement pic_output_flag handling
[12:28] <cone-833> ffmpeg.git 03Michael Niedermayer 07master:e1f4397e74f0: Merge commit '458e7c94830d1522997e33a0b5e87bd709e8a349'
[13:06] <cone-833> ffmpeg.git 03Luca Barbato 07master:f90729699db9: mov: Do not group tracks if more than one is enabled per type
[13:06] <cone-833> ffmpeg.git 03Michael Niedermayer 07master:4c91599484e1: Merge commit 'f90729699db9ede2bef2b28000f1795dab1b8996'
[13:12] <cone-833> ffmpeg.git 03Luca Barbato 07master:df2aa22203af: mov: Clarify tkhd flag settings
[13:13] <cone-833> ffmpeg.git 03Michael Niedermayer 07master:375d7ee8056a: Merge commit 'df2aa22203afc9377832bdf800df5dbd3aa9687e'
[15:44] <cone-833> ffmpeg.git 03Michael Niedermayer 07master:4932b1e8b852: avfilter/vf_libopencv: Use av_mallocz_array()
[15:44] <cone-833> ffmpeg.git 03Michael Niedermayer 07master:be55518fdbdf: avfilter/vf_deshake: Use av_malloc_array()
[15:44] <cone-833> ffmpeg.git 03Michael Niedermayer 07master:c9d64abedfc2: avfilter/vf_decimate: Use av_malloc_array()
[16:16] <ubitux> thardin: hey, it's not that messy anymore :(
[16:16] <kierank> It's somewhat usable now
[16:17] <wm4> it's still messy
[16:17] <thardin> I can't use filters like functions
[16:17] <Daemon404> >libavfilter
[16:17] <Daemon404> >NLE
[16:17] <Daemon404> >seeking
[16:17] <Daemon404> hahahahahAHAHAHAH
[16:17] <ubitux> thardin: can you give an example?
[16:17] <thardin> it steals program flow from the user
[16:17] <kierank> Daemon404: that's why pro editors only support a certain set of formats
[16:17] <thardin> as will pretty any graph based filter approach
[16:17] <Daemon404> kierank, lavfi is nto related to formats
[16:17] <Daemon404> itsj ust designed poorly.
[16:18] <kierank> Daemon404: seeking
[16:18] <Daemon404> there is no reason a filtering framework cant seek
[16:18] <Daemon404> they *chose* to cripple it based on libavformat
[16:18] <thardin> I'd rather lavfi were a set of simple functions that you call with a buffer and get (possibly) another buffer back
[16:18] <kierank> sure but seeking in certain file formats is inherently difficult/impossible
[16:18] <kierank> mpeg-ts for example
[16:18] <thardin> instead of "hoping" you get something out into a sink on the other end
[16:18] <wm4> thardin: you can use it like that
[16:18] <Daemon404> yes but thats unrelated to lavfi kierank 
[16:18] <thardin> you can?
[16:18] <kierank> Daemon404: related to NLE and seeking tho
[16:19] <Daemon404> sure
[16:19] <Daemon404> but we're talkign about filtering
[16:19] <wm4> thardin: sure, build a graph, then put in a frame, and try to get a frame out
[16:19] <Daemon404> not demuxing
[16:19] <Daemon404> wm4, it wont work with any temporal filters in lavfi
[16:19] <thardin> ehh, I don't like that
[16:19] <kierank> Daemon404: ahhh ok
[16:19] <kierank> temporal filters
[16:19] <wm4> thardin: but isn't that what you asked
[16:19] <Daemon404> lavfi has no concept of which frames it needs
[16:19] <ubitux> -vf "filter1=enable='between(t,10,20)', filter2=enable='between(t,20,30)'"
[16:19] Action: kierank does not trust lavfi timestamps
[16:19] <ubitux> here you go
[16:19] <ubitux> temporal filtering @_@
[16:20] <thardin> Daemon404: mlt does, iirc
[16:20] <wm4> lol timeline stuff
[16:20] <Daemon404> ubitux, i mean the API
[16:20] <wm4> ubitux: that's fucking clunky
[16:20] <wm4> and inflexible etc.
[16:20] <Daemon404> requesting frame N does not know how what frame dpes it has or needs
[16:20] <Daemon404> and it has no cache filter at all
[16:20] <Daemon404> burden ends up on the use
[16:20] <Daemon404> r
[16:21] <thardin> does lavf provide some api for getting frames by index yet?
[16:21] <wm4> no
[16:21] <Daemon404> lolno
[16:21] <wm4> it doesn't even provide correct timestamps if you seek somewhere
[16:21] <thardin> mlt does
[16:21] <Daemon404> i personally like vapoursynths way, where each filter tells VS how many frames before/after it needs
[16:21] <Daemon404> so vs can handle it without user intervention
[16:21] <Daemon404> but ofc this requires accurate seeking
[16:21] <thardin> tho its lavf wrapper is clunky, for obvious reasons
[16:22] <wm4> and getting a frame by index requires decoding for codecs that do prediction
[16:22] <wm4> so lavf can't even do it
[16:22] <thardin> yes
[16:22] <thardin> and then you cache the decoded frames
[16:22] <Daemon404> yes
[16:22] <Daemon404> all the sane NLE frameworks have a cache system
[16:22] <thardin> and then you can scrub back and forth
[16:23] <Daemon404> iirc vs has ~100 frame cache
[16:23] <wm4> if lavfi had a seek API, it could provide an "exact" source
[16:23] <Daemon404> for temporal filters to access
[16:23] <thardin> libavframe
[16:23] <thardin> for your "just gimme frames A-B" needs
[16:23] <wm4> thardin: ffms2?
[16:23] <Daemon404> wm4, or i just use ffms2 with vs :P
[16:23] <ubitux> 16:21:04 < thardin> does lavf provide some api for getting frames by index yet?
[16:23] <ubitux> yes
[16:23] <ubitux> (within filters)
[16:24] <thardin> >frame- and sample-accurate access (usually)
[16:24] <thardin> heh
[16:24] <wm4> lavf = libavformat
[16:24] <Daemon404> thardin, the usually is because of lavf
[16:24] <ubitux> ah oups, misread sorry
[16:24] <Daemon404> e.g. mpegts is lavf is a crapshoot
[16:24] <thardin> yeah, I recall having trouble with this when fixing seeking in mxf
[16:24] <thardin> "fixing"
[16:24] <Daemon404> thardin, fwiw we use ffms2 on petabytes of videos to seek :P
[16:24] <wm4> for most formats, frame exact access would require creating an index
[16:24] <Daemon404> (with a whitelist)
[16:25] <wm4> and lavf doesn't have such a concept
[16:25] <Daemon404> wm4, thats why you use ffms2 and getframe(n) ;)
[16:25] <wm4> or even worse, frame exact access might require decoding everything
[16:25] <Daemon404> although it wont work on hevc right now, because libav* doesnt set keyframes 'correctly'
[16:26] <Plorkyeran> I don't think it ever requires decoding everything barring things like infinite keyint
[16:26] <Plorkyeran> a bunch of formats require parsing every frame though
[16:27] <wm4> what about audio? can decoding be avoided?
[16:28] <Daemon404> not that audio decoding is exceptionally intense
[16:28] <wm4> anyway, seeking in lavf seems to be a bad mess
[16:29] <Plorkyeran> afaik most formats don't need to be decoded for any reason other than lavc api shortcomings
[16:29] <Plorkyeran> i.e. you need per-format code for "how big is the output of this packet" that doesn't exist
[16:30] <Plorkyeran> so that at least is potentially solveable but I don't think there's a trivial solution
[16:31] <Plorkyeran> a whitelist of formats where the audio PTSes can actually be trusted would be one way to go I guess
[16:32] <wm4> what does "trusted audio PTS" mean?
[16:33] <Plorkyeran> or perhaps there's a sufficiently reliable way to reconstruct timestamps that doesn't require decoding that I simply haven't figured out
[16:33] <Plorkyeran> with some formats you do have accurate timestamps for audio packets
[16:34] <thardin> aren't there parsers for stuff like that?
[16:34] <Plorkyeran> and constant sample rate
[16:34] <Plorkyeran> so obviously you can just calculate the number of samples between two packets
[16:34] <kierank> 3:24 PM <wm4> for most formats, frame exact access would require creating an index
[16:34] <kierank> this
[16:34] <Plorkyeran> but other formats have no timestamps on audio packets at all
[16:34] <Plorkyeran> or only some of them
[16:34] <Plorkyeran> or they're blatant lies
[16:35] <thardin> this is why use only certain formats
[16:35] <thardin> +you
[16:36] <wm4> so, apart from implementation issues, is there any realistic way we could get frame exact access into ffmpeg?
[16:36] <Plorkyeran> if you're writing pro software, sure
[16:36] <wm4> cp -r ffms2 ffmpeg/ ?
[16:36] <Plorkyeran> pick a few formats, support them correctly, tell people to convert to those
[16:37] <wm4> I mean API-wise
[16:37] <Plorkyeran> but for casual users supporting any insane files they find on the internet is the user-friendly thing to do
[16:37] <thardin> pfft, users
[16:38] <iive> ffms2 does that by parsing the whole file, afaik
[16:38] <Plorkyeran> I don't really see any reason why ffms2's api couldn't be a ffmpeg library
[16:39] <Plorkyeran> although I fear it would end up getting generalized until it's no longer actually easy to use...
[16:40] <Plorkyeran> ffms2 does make some limiting assumptions to simplify things (e.g. it can only open complete files on disk)
[16:43] <Daemon404> Plorkyeran, you cant have a simple high level api
[16:43] <Daemon404> you have to rape it until it is SUPER GENERIC
[16:43] <Daemon404> and really annoying to use
[16:44] <thardin> ^
[17:11] <Daemon404> Timothy_Gu, fyi i do not "run windows"
[17:11] <Daemon404> i run like 5 OSes at any given time at home.
[17:13] <cone-833> ffmpeg.git 03Michael Niedermayer 07master:c6c172d1738b: avformat/mpegts: skip updating programs/streams when determining duration
[17:18] <michaelni> thardin, if you want a simple API that simply feeds a buffer to a filter and gives a buffer back, that should not be hard to implement on top of the current API, a patch should be welcome
[17:19] <thardin> maybe one day if i find a need
[17:20] <michaelni> also patches & pull requests are also welcome to fix any other issue people run into of course
[17:49] <cone-833> ffmpeg.git 03Paul B Mahol 07master:6779bf3f0fcc: avformat/wavenc: use av_mallocz_array()
[20:35] <cone-601> ffmpeg.git 03Diego Biurrun 07master:117332024974: dsputil: Drop unused bit_depth parameter from all init functions
[20:35] <cone-601> ffmpeg.git 03Michael Niedermayer 07master:b8cdf0472674: Merge commit '1173320249745eab01c901a39054fc0fced33c87'
[20:45] <cone-601> ffmpeg.git 03Diego Biurrun 07master:6cc1409ba865: examples/output: Remove unused variable
[20:45] <cone-601> ffmpeg.git 03Michael Niedermayer 07master:15e933b77365: Merge commit '6cc1409ba8650fb7eaedc96e970664febc02a5e9'
[20:54] <michaelni> Daemon404, nevcairiel die one of you had time to look at the msvc/icl fate issue ?
[21:29] <kierank> anybody want money to work on x262 asm
[21:29] <kierank> ?
[21:36] <michaelni> not sure i have enough time, but if noone else "volunteers" i could try
[22:00] <iive> kierank: is x262 different that mpeg2?
[22:00] <iive> i mean... h262
[22:36] <Case> is it intentional that ffprobe, when ffmpeg is built with libfdk, reports AAC audio codec as "codec_name=libfdk_aac" instead of simply "codec_name=aac"?
[23:27] <kierank> iive: x262 is to h262 as x264 is to h264
[23:28] <iive> i corrected myself a second later.
[23:28] <iive> my question is, isn't h262 just mpeg2, and what asm do you actually need?
[00:00] --- Sat Jul 12 2014