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

[burek]

[00:03] <cone-577> ffmpeg.git 03Luca Barbato 07master:c6074a30ba3b: opt: Fix the documentation mentioning av_set_string3
[00:03] <cone-577> ffmpeg.git 03Michael Niedermayer 07master:1e16492b989e: Merge commit 'c6074a30ba3b5fb4319ee6ee599656d58548cdc8'
[00:12] <ubitux> is anyone opposed to the fact that i take over xbr code?
[00:20] <cone-577> ffmpeg.git 03Luca Barbato 07master:c9c7d59b7d26: tiff: Use av_mallocz_array
[00:20] <cone-577> ffmpeg.git 03Michael Niedermayer 07master:dadc1f5ee9d9: Merge commit 'c9c7d59b7d26f0328d612995dd9256337ae1cbfb'
[00:23] <michaelni> ubitux, you should ask arwa, as she ported the code otherwise no objections and thanks!
[00:23] <ubitux> ok
[00:33] <cone-577> ffmpeg.git 03Vignesh Venkatasubramanian 07master:597d826123dc: lavf/webmdashenc: Representation IDs should be unique.
[00:50] <ubitux> damn, we can do so much better than this code...
[00:50] <ubitux> gonna take me a little while though
[00:54] Action: Daemon404 pats ubitux 
[01:05] <cone-577> ffmpeg.git 03Marton Balint 07master:eaf4ab9802d5: ffplay: signal the frame queue before closing audio
[01:05] <cone-577> ffmpeg.git 03Michael Niedermayer 07master:12aab852c58d: Merge remote-tracking branch 'cus/stable'
[01:07] <michaelni> ubitux, btw, that huge rgb/yuv table is ugly ...
[01:07] <ubitux> i know
[01:08] <ubitux> again, i did that to be bitexact with the (modern) reference
[01:08] <michaelni> its not bitexact to the xbr reference code i saw
[01:11] <michaelni> and i dont think the refernce makes that much sense
[01:38] <ubitux> michaelni: yes, we can probably replace it with direct computation
[01:38] <ubitux> last time i tried (using the colorspace macros) it was a bit slower though, but well maybe not worth the lut
[03:40] <cone-577> ffmpeg.git 03Michael Niedermayer 07master:9d6ad68fa445: avcodec/h264_parser: Avoid adding SEI to the global header
[07:00] <jamrial> valgrind doesn't like the new opt test
[08:44] <xxthink> where to find the code that the parameter "-re "? is set?
[08:45] <xxthink> I have debugged and can'f find where the "-re" parameter works
[08:45] <xxthink> I guess it maybe at the function open_input_file
[08:46] <xxthink> thanks in advanced
[08:46] <ubitux> git grep '"re"'
[08:46] <ubitux> start from here
[08:47] <ubitux> the git grep rate_emu
[08:47] <ubitux> and you'll end up in ffmpeg.c, 2 occurences
[08:48] <xxthink> ubitux, thank you very much!!!
[08:48] <xxthink> I find it!
[10:56] <j-b> 'matin
[13:00] <cone-300> ffmpeg.git 03Reimar Döffinger 07master:5e8e2f3861df: configure: Hack to treat x32 as x86_64.
[13:00] <cone-300> ffmpeg.git 03Carl Eugen Hoyos 07master:0ea54d698be6: lavd/avfoundation: Remove unused -frame_rate option.
[13:53] <cone-300> ffmpeg.git 03Carl Eugen Hoyos 07master:1f4bce894a15: lavf/tcp: Clarify that the -timeout option takes microseconds.
[14:59] <ubitux> > Edits are not restricted to fall on sample times.
[14:59] <ubitux> damn mp4
[15:00] <Daemon404> of course now
[15:00] <Daemon404> not
[15:01] <ubitux> if i'm understand it well, it means you need to decode in order to slice a & v to match these edit list
[15:01] <Daemon404> yes
[15:01] <Daemon404> it's not something for a demxuer to do.
[15:01] <ubitux> awesome&
[15:01] <Daemon404> similar to orderec chapters
[15:01] <Daemon404> same deal.
[15:01] <ubitux> does that accuracy matters in practice?
[15:02] <Daemon404> depends how inaccurate i geuss?
[15:02] <Daemon404> i dont know why you would ever want to put timeline stuff in a demxuer though
[15:02] <Daemon404> application of it, at least.
[15:02] <ubitux> well, it's supposed to be at format level
[15:02] <Daemon404> why?
[15:03] <Daemon404> timeliens arent format level
[15:03] <Daemon404> theyre metadata
[15:03] <ubitux> i wonder how this can be honored properly in ffmpeg design
[15:04] <Daemon404> it cant be, at a demuxer level
[15:04] <Daemon404> the least bad idea i can think of is exporting it somehow
[15:04] <Daemon404> same for matroska
[15:04] <Daemon404> similar to other metadata (replaygain?)
[15:05] <ubitux> so we would associate a timeline field in the AVStream?
[15:05] <Daemon404> it's ugly regardless
[15:05] <Daemon404> it gets uglier still
[15:06] <ubitux> i don't really see a clean solution
[15:06] <Daemon404> cause currently, the mov/mp4 demuxer applyes the first edit (and no others)
[15:06] <Daemon404> which is really "Special" behavior
[15:06] <Daemon404> so exportign edits would be a "regression"
[15:06] <ubitux> i was under the impression that the edit list could be honored at demuxer level by dropping packets (and scaling timestamps - there is a rate factor too)
[15:07] <nevcairiel> in my matroska demuxer i seek around the stream, dropping wouldnt cover enough cases
[15:07] <Daemon404> if youre trimming by time, it's fairly obvious that you cant just drop packets
[15:07] <ubitux> well i mean, building the internal index differently
[15:08] <ubitux> like ignoring some referenced samples etc
[15:08] <Daemon404> i really think putting it in lavf is a terrible idea
[15:08] <wm4> ubitux: IMO there should be a high level API which handles such things
[15:08] <Daemon404> >high level
[15:08] <wm4> lavc and lavf are awfully low level anyway
[15:08] <Daemon404> >libav*
[15:08] <Daemon404> dohohohohoho
[15:08] <ubitux> wm4: i'm fine with that TBH
[15:09] <wm4> most people just want video and audio frames from a file (or the reverse)
[15:09] <wm4> they don't want to connect dozens of components
[15:09] <Daemon404> i lvoe writing the 50 boilerplate loops, wm4 
[15:09] <Daemon404> dont hate
[15:09] <wm4> and such an API could handle ordered chapters and edit lists with ease
[15:09] <nevcairiel> i like having control of how threading and buffering works for the loops
[15:10] <nevcairiel> doubt any high level api would make me happy :D
[15:10] <ubitux> so we could say that we add an avformat option, telling demuxers to export an AVStream->timeline and not try to drop the packets themselves
[15:10] <wm4> it would make many API users happy
[15:10] <ubitux> and let the highlevel api deal with that?
[15:10] <wm4> ubitux: sure why not
[15:10] <Daemon404> that seems fairly reasonable to me
[15:10] <wm4> does mp4 do that per stream?
[15:10] <ubitux> i wonder how this is going to affect... stream copy for instance.
[15:10] <ubitux> wm4: yes
[15:10] <Daemon404> wm4, yes
[15:10] <wm4> disgusting
[15:11] <ubitux> i guess some format do that at presentation level?
[15:11] <Daemon404> ubitux, well it should simpyl be unsupported for stream copy, no?
[15:11] <ubitux> i guess...
[15:11] <Daemon404> ubitux, mp4 and matroska are at presentation level
[15:11] <ubitux> ?
[15:11] <Daemon404> im not aware of what otehr formats have timelines
[15:11] <ubitux> mp4 is at stream level
[15:11] <ubitux> not presentation
[15:11] <Daemon404> oh
[15:11] <Daemon404> i thought you meant application
[15:11] <Daemon404> yeah it does it per stream
[15:12] <Daemon404> matroska is even more special
[15:12] <Daemon404> because of editions
[15:12] <Daemon404> and stuff
[15:12] <ubitux> we don't have an opw minion to work on that?
[15:12] <ubitux> i have enough projects currently :(
[15:13] <Daemon404> im not sure there is any opw candidate who *could*
[15:13] <Daemon404> like, actually be able to.
[15:13] <Daemon404> it's not easy
[15:13] <ubitux> we need to know how much stuff we could put into these timelines
[15:15] <ubitux> i suppose we have: external file reference, time ranges (anything using chapter references?), rate, loops?, anything else?
[15:15] <Daemon404> i cannot rememebr if its possible, but i thought you could mix N video streams into one (this might be out of spec)
[15:15] <ubitux> ok
[15:15] <cone-300> ffmpeg.git 03Rong Yan 07master:e74e14608fa3: libswscale/ppc/swscale_altivec.c : fix hScale_altivec_real() yuv2planeX_16_altivec() yuv2planeX_8() for little endian
[15:15] <ubitux> well, let's export this as libavfilter filtergraph.
[15:16] Action: wm4 barfs
[15:16] <ubitux> that might actually work... :D
[15:16] <Daemon404> ubitux, btw i really like when the pts/dts is vfr AND the rate in edits varies
[15:16] <Daemon404> double vfr!
[15:16] <ubitux> :)
[15:16] <ubitux> i really wonder if i could just have a char *timeline with a libavfilter filtergraph to handle these timeline
[15:16] <Daemon404> hatst errible
[15:16] <ubitux> you sure are going to hate me for that though
[15:16] <Daemon404> api users will kill you
[15:17] <ubitux> :D
[15:17] <wm4> matroska has segment UID, and a list of segments: each with start and end time in nanoseconds, a segment UID reference, and the edition
[15:17] <wm4> <ubitux> i really wonder if i could just have a char *timeline with a libavfilter filtergraph to handle these timeline <- fuck no
[15:17] <ubitux> Daemon404: it would even work for matroska! you could movie=OP.mkv into the filtergraph @_@
[15:17] Action: Daemon404 does not use lavfi api
[15:17] <wm4> nobody wants to give that lavfi shit too much control
[15:18] <wm4> be honest and design a high level API
[15:18] <ubitux> well, we can imagine different export mode
[15:18] <Daemon404> the only it could be worse tahn exporting a filter string would be exporting tha tstring via av_log
[15:18] <Daemon404> only way*
[15:18] <wm4> lol
[15:18] <ubitux> :D
[15:19] <ubitux> actually i don't even need a new field
[15:19] <ubitux> i can use the metadata system
[15:19] Action: wm4 cries
[15:19] <ubitux> :D
[15:19] <Daemon404> metadata? or sidedata?
[15:19] <Daemon404> i get confused
[15:19] Action: ubitux laugh evily
[15:19] <ubitux> Daemon404: av_dict_set(&st->metadata, "timeline", "trim=...")
[15:20] <Daemon404> hurr durr
[15:20] <Daemon404> btw ubitux 
[15:20] <ubitux> yes?
[15:20] <Daemon404> there is already a hack^Wavoption in the mov demuxer
[15:20] <Daemon404> to disable edit application
[15:20] <Daemon404> (even though it only applies teh first edit anyway...|)
[15:20] <ubitux> yeah i'm on it
[15:20] <ubitux> i started moving it in a data area
[15:21] <ubitux> and move the adjustments into mov_build_index() instead
[15:21] <ubitux> i'm probably going to try that experimental timeline thing just for the lulz
[15:27] <wm4> I suppose you could try something like the concat demuxer, which tries to do sample accurate cutting by using certain avpacket side-data
[15:28] <wm4> AV_FRAME_DATA_SKIP_SAMPLES
[15:32] <ubitux> that works for audio
[15:32] <ubitux> what about video with not much keyframes?
[15:32] <ubitux> what about trailing samples for audio too?
[15:33] <Daemon404> yeah
[15:33] <wm4> ubitux: that side data handles trimming too
[15:33] <wm4> for video, no idea, maybe a flag whether the frame should be shown?
[15:34] <wm4> although I don't like this approach much, it'd allow for easy integration into existing code
[15:34] <ubitux> clearly, exporting a lavfi timeline as stream metadata is a better solution
[15:44] <ubitux> does anyone have samples with crazy edit lists?
[15:44] <ubitux> i only have one here, and it's not that obvious
[15:45] <ubitux> typically samples with stream timescale...
[15:45] <ubitux> + edit lists
[15:45] <wm4> highlight Daemon404 
[15:46] <Daemon404> i have lots
[15:46] <Daemon404> not directly on me though
[15:46] <Daemon404> there's one iOS app that generates crazy-as-fuck edit lists
[15:46] <Daemon404> i can get you a file
[15:47] <wm4> lol an iOS app?
[15:47] <Daemon404> yeah
[15:47] <Daemon404> it recoeds 1 second of video every day
[15:47] <Daemon404> and stiches it into a video over N days
[15:47] <Daemon404> and it uses edit lists to sync stuff
[15:47] <wm4> woah
[15:47] <ubitux> can you tell me the name of the app?
[15:48] <Daemon404> uh
[15:48] <Daemon404> not off the top of my head
[15:48] <Daemon404> let me ask the community person who told me
[15:48] <Daemon404> might be an hr or so
[15:48] <Daemon404> theyre in EST
[16:06] <Daemon404> ubitux, http://1secondeveryday.com/
[16:06] <Daemon404> thats it
[16:06] <ubitux> thank you
[16:07] <Daemon404> only the ios version does edit list stuff i think
[16:10] <ubitux> yeah probably, it's the iOS framework which is responsible for these edit lists
[16:11] <Daemon404> yea
[17:01] <gnafu> Daemon404: I can't imagine how I would feel if, after recording 7 years of 1-second-a-day videos, I miss /one day/.
[17:55] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:39dfe6801a3f: avcodec/dvbsubdec: Cleanup on *malloc failure
[18:42] <cone-300> ffmpeg.git 03James Almer 07master:84ccc317cecf: x86/flacdsp: separate decoder and encoder dsp initialization
[20:53] <cone-300> ffmpeg.git 03Michael Niedermayer 07master:d03867c24831: avcodec/dvbsubdec: av_assert* instead of assert()
[23:36] <cone-300> ffmpeg.git 03Lukasz Marek 07master:5dc0f607e795: lavu/opt: fix memleak in test
[23:36] <cone-300> ffmpeg.git 03Lukasz Marek 07master:5aed6f56d91b: ffserver_config: report not closed last tag
[23:36] <cone-300> ffmpeg.git 03Lukasz Marek 07master:173d51c982f1: lavu/opt: fix av_opt_get function
[00:00] --- Thu Nov 13 2014