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

[burek]

[00:04] <durandal_1707> michaelni: is old api always used?
[00:06] <durandal_1707> looking at definition it is
[00:07] <burek> it crashed with 0.11.2
[00:07] <burek> "i have to go deeper"
[00:09] <durandal_1707> burek: stop wasting time on vlc
[00:09] <burek> ok, sorry
[00:09] <burek> thanks btw for the help so far :)
[00:10] <durandal_1707> instead report bug to them
[00:10] <burek> they usually ignore it or post some insulting comments
[00:10] <burek> so, no
[00:10] <burek> when they find it, they might fix it
[00:11] <durandal_1707> "insulting" in what way?
[00:17] <cone-67> ffmpeg.git 03Paul B Mahol 07master:185d1f3bfcac: lavfi: declare arrays that never change as static const
[00:17] <burek> long story.. shortly i mostly dont like dealing with their forum or bug tracker
[00:17] <burek> there are couple of people that are friendly and mostly helpful, but some are really... could be better
[00:20] <llogan> a least it isn't bugzilla
[00:22] <burek> i did a git checkout of previous version of vlc and now it doesn't crash :)
[00:31] <teratorn> does this indicate a bug in ffmpeg? or can someone guess why the `alignment' parameter is so whacked out? http://hastebin.com/mipuketoka.txt
[00:32] <teratorn> that's a segfault traceback by the way - which strikes me as odd, since avcodec_alloc_frame() takes no arguments, and shouldn't fail except with ENOMEM?
[00:32] <teratorn> I guess by returning NULL...
[00:40] <teratorn> OK nevermind - it seems I have memory corruption occurring elsewhere
[00:41] <cone-67> ffmpeg.git 03Stefano Sabatini 07master:042c2a1af8eb: doc: move HTML CSS to a dedicated file default.css
[00:41] <cone-67> ffmpeg.git 03Stefano Sabatini 07master:e64a7f2c78d6: doc/default.css: use ffmpeg.org website CSS
[00:44] <durandal_1707> j-b: you want vlc to be popular as ubuntu?
[00:45] <j-b> oh god, no!
[00:49] <burek> a guy on the forum said he just remuxed the a/v into swf and the video plays 3-5 times faster now :)
[00:49] <burek> ffmpeg -i test.flv -acodec copy -vcodec copy test.swf
[00:49] <burek> http://ffmpeg.gusari.org/viewtopic.php?f=11&t=767
[00:49] <llogan> that is a feature
[00:50] <burek> :D
[00:50] <burek> should we make a wiki article about it :)
[00:54] <saste> durandal_1707, nice swapuv simplification
[01:02] <cone-67> ffmpeg.git 03Michael Niedermayer 07master:28286a63d045: videodsp_template.c: fix year
[01:02] <cone-67> ffmpeg.git 03Michael Niedermayer 07master:90eaa989f102: x86/videodsp_init: Add back lost author attribution
[01:02] <cone-67> ffmpeg.git 03Michael Niedermayer 07master:e16bac7b33f6: videodsp: Fix project name
[01:03] <durandal_1707> isn't that because wrong fps is stored in muxed file?
[01:06] <cone-67> ffmpeg.git 03Stefano Sabatini 07master:6b50df6b3a11: doc/filters: rename reference to movie filter from "src_movie" to "movie"
[01:30] <cone-67> ffmpeg.git 03Paul B Mahol 07master:44fe118e0a5f: lavc/4xm: use bytestream2_get_bytes_left
[01:42] <durandal_1707> so there is no way to know that pixfmt is in yuv colorspace
[01:44] <saste> durandal_1707, what about !PIX_FMT_RGB?
[01:44] <durandal_1707> does not work with NV21
[01:45] <saste> why?
[01:46] <durandal_1707> NV21 is not YUV
[01:46] <saste> durandal_1707, you can check: two components in the same plane -> reject
[01:46] <saste> NV12 IS YUV
[01:46] <saste> uhm sorry for the unmeant upcase
[01:47] <saste> YUV refers to the colorspace, not to the packing
[01:47] <durandal_1707> yes, but it is not normal planar format
[01:47] <saste> yes the planar thing was silly
[01:47] <durandal_1707> oki, i just prefer less instructions....
[01:47] <saste> considered that it can be derived from the more detailed info in components
[01:48] <saste> maybe we could add an handler for that, since i compute the number of planes in various places IIRC
[01:51] <durandal_1707> saste: yes, handler to detect yuv formats is welcome
[01:51] <durandal_1707> currently many filters can use much more pixel formats than they do now
[01:52] <saste> durandal_1707, what do you exactly mean by "yuv formats"?
[01:52] <saste> YUV colorspace with at least three components
[01:53] <saste> to which you add the constraint of nb_planes >= 3
[01:53] <durandal_1707> yes and planar 
[01:53] <saste> planar = every component in a distinct plane
[01:54] <durandal_1707> generally many filters just support hardfixed amount of formats
[01:54] <saste> yes
[01:54] <durandal_1707> that is just bad when they can support much more
[01:54] <saste> an idea was to support some sort of formats filtering operations
[01:54] <saste> but nobody really worked on that
[01:54] <saste> lacking that, we can still inspect the components info
[01:55] <saste> you simply compute the nb of planes, and ask N>= 3
[02:05] <durandal_1707> and how you compute number of planes?
[02:06] <saste> durandal_1707,  you iterate through the components, and compute the number of distinct values
[02:07] <saste> for example you set array[N] and finally compute sum_i=0..3 array[i]
[02:09] <durandal_1707> hmm, shouldn't swapuv actually operate only if u and v planes are of same size?
[02:14] <saste> durandal_1707, no
[02:14] <saste> even if in practive u and v planes have always the same size
[02:29] <durandal_1707> well to be future proof i should check all comp entries
[02:47] <ubitux> saste: btw, does overlay still work fine with a still image after your patch?
[02:47] <saste> ubitux, i believe so
[02:50] <ubitux> okay
[02:50] <ubitux> also, are you going to review the tinterlace patch?
[03:10] <durandal_1707> crap, libav put float dsp into lavu, who cares about integers .....
[03:10] <durandal_1707> hack hack hack hack hack hack hack hack hack ......
[03:45] <cone-67> ffmpeg.git 03Michael Niedermayer 07master:5ffb5e7a2d69: 4xm: check the correct stream, fix fate
[03:45] <cone-67> ffmpeg.git 03Michael Niedermayer 07master:3f72dbe46207: ffplay: fix another use of context instead of frame parameters
[11:33] <durandal_1707> why google started to redirect each link?
[11:33] <divVerent> does anyone have ANY commercially produced dvd using multiple angles AND multiple titles?
[11:33] <divVerent> haha, I hate that feature as well
[11:33] <divVerent> because I have DNS blocked their tracking redirector... and suddenly it started to always hit on the first click
[11:34] <divVerent> what I want to know about DVDs - if there is more than one title, and more than one angle, do the same angle numbers typically correspond to each other across titles (i.e. mean the same)
[11:34] <divVerent> or is there no correlation
[11:34] <divVerent> not a standards question, but a "actual use" one :)
[11:45] <durandal_1707> why people reply to my commits in cvs-log ml
[11:45] <durandal_1707> i do not use cvs
[11:46] <divVerent> who does, nowadays
[11:47] <durandal_1707> i'm not subscribed to cvslog ml, i already receive enough spam
[11:47] <nevcairiel> its just called cvslog, has nothing to do with cvs anymore =p
[13:10] <durandal_1707> saste: can you explain your comment on patch?
[13:11] <saste> durandal_1707, i think the check could be simplified
[13:11] <saste> what i should explain in particular?
[13:13] <durandal_1707> only that specific check?
[13:13] <saste> durandal_1707, you compute the number of distinct planes, and require nb_planes >= 3 && !PIX_FMT_RGB
[13:14] <saste> I think this is enough (I may be wrong)
[13:14] <saste> how are you testing the supported formats?
[13:14] <saste> we have a tool for that
[13:17] <durandal_1707> saste: i use that tool
[13:17] <durandal_1707> saste: so you wana remove depth_minus1 ?
[13:18] <saste> durandal_1707, i think so, but i won't bet with no testing
[13:18] <durandal_1707> i think that is bad idea
[13:19] <durandal_1707> someone may add some f* format in future and swapuv start to use it
[13:19] <saste> that will be broken anyway
[13:20] <saste> since we assume depth(u) == depth(v) anyway
[13:20] <saste> see for example how we use log2_chroma_{w,h}
[13:22] <saste> lol nv12 is tagged as planar
[13:22] <saste> the same braindeadness of the original PixFmtInfo array
[13:23] <wm4> nv12 is both packed and planar
[13:23] <durandal_1707> that may change, eg. sws becoming better
[13:24] <durandal_1707> wm4: and there is no flag for packed
[13:45] <durandal_1707> saste: so what should I do to make you happy?
[13:53] <saste> durandal_1707, 1 million dollars should be fine
[13:53] <ubitux> a cake
[13:53] <nevcairiel> isnt this more the time of cookies
[13:53] <saste> durandal_1707, let me try a patch
[13:54] <cone-495> ffmpeg.git 03Reinhard Tartler 07master:9378be9f3252: prepare 9_beta3 release
[13:54] <cone-495> ffmpeg.git 03Justin Ruggles 07master:aef5150719f0: flac: only set channel layout if not previously set or on channel count change
[13:54] <cone-495> ffmpeg.git 03Michael Niedermayer 07master:98256622a66e: Merge remote-tracking branch 'qatar/master'
[13:59] <durandal_1707> does lavc support dvcpro?
[14:03] <saste> durandal_1707, http://paste.org/59126
[14:03] <saste> works fine here
[14:05] <saste> if you want to prevent bogus formats breaking the filter
[14:05] <saste> add a test
[14:05] <saste> but I'd rather adopt the philosophy: if it can't described by a pixel format then it is a codec
[14:05] <saste> so bogus formats should not be added in the first places
[14:05] <saste> *place
[14:06] <wm4> all depends how powerful the pixfmt description is
[14:06] <durandal_1707> saste: i do not like your hacking
[14:06] <saste> durandal_1707, what's an hack there?
[14:08] <durandal_1707> it is so ugly, that libav devs would not review it at all
[14:08] <saste> durandal_1707, ok it was fun, so a real comment ;-)
[14:09] <wm4> saste: IMO this should: 1. allow Y and Y+alpha formats, 2. make sure all components have same bit width and have no shifts, 3. make sure it's not bitstream crap
[14:10] <wm4> saste: also, there should be a simple way to get the number of planes (maybe there is, somewhere else)
[14:10] <wm4> saste: oh, and also ensure endian-ness to be native
[14:10] <durandal_1707> wm4: that last one is irellevant for swapuv
[14:11] <durandal_1707> if i posted fixed table i would already worked on something else by this time ...
[14:12] <durandal_1707> wm4: the idea is to write handlers to help filters to auto increase supported input/output formats when new pixfmt is introduced
[14:13] <durandal_1707> instead of manual checking billions of filters
[14:14] <saste> it depends on your definition of planar
[14:14] <saste> in my land it is: each component has a separate plane, which fits the current filter
[14:14] <wm4> then why do you check the RGB flag
[14:15] <saste> assumption: depth(u) = depth(v), which is by design (we reject YUV filters for which that property is not respected)
[14:15] <saste> wm4, because it is checking *YUV* planar
[14:15] <wm4> ok, the function you posted is named is_planar_yuv
[14:16] <saste> -> YUV filters-> YUV formats
[14:16] <durandal_1707> saste: where is that check?
[14:17] <saste> durandal_1707, !PIX_FMT_RGB
[14:17] <saste> note that PIX_FMT_RGB should not be there in the first place
[14:17] <durandal_1707> saste: assumption one .....
[14:25] <ubitux> we should write an api to request pre-defined query
[14:26] <ubitux> ff_gimme_pixfmt(FF_PIXFMT_SANE_PLANARS)
[14:26] <wm4> lately I had some fun with lavu pixel formats descriptors
[14:26] <wm4> and detected the fucked up way they mix endian-independent byte access and endian-dependent bit shifts in the same pixel format
[14:27] <durandal_1707> point or it did not happen
[14:29] <durandal_1707> ubitux: ok, you would decide if pix fmt is sane planar ?
[14:30] <durandal_1707> *how
[14:32] <ubitux> durandal_1707: FF_PIXFMT_PLANAR_SANE_LEVEL_3
[14:32] <ubitux> btw, unrelated
[14:32] <ubitux> ffplay frame step ('s') doesn't seem to work all the time
[14:33] <ubitux> seems it sometimes need you to press several time 's'
[14:33] <ubitux> (can be verified with drawtext + frame counter
[14:33] <ubitux> )
[14:33] <ubitux> is this known?
[14:34] <ubitux> saste: btw, about vf field, i have the answer now: it can be used to detect duplicated fields, and so help checking if the content is telecined or not
[14:35] <ubitux> (if a duplicated field shows up regularly)
[14:39] <saste> ubitux, i don't know the question to what you gave the answer
[14:40] <ubitux> i was wondering about the usage of vf field when you ported it
[14:41] <ubitux> you told me something like "likely debugging/analysis purpose"
[14:41] <ubitux> now i know exactly what that means :p
[14:41] <ubitux> you might already be aware of it though
[14:41] <ubitux> but now i feel satisfied
[14:44] <saste> ubitux, that or you can use it as an ubercheap deinterlacer
[14:44] <durandal_1707> ubercheap?
[14:44] <ubitux> field,scale=... ?
[14:45] <saste> <wm4> and detected the fucked up way they mix endian-independent byte access and endian-dependent bit shifts in the same pixel format
[14:45] <saste> wm4: what do you mean?
[14:45] <wm4> look at av_read_image_line() and observe how there's both endian swapping and shifting
[14:47] <wm4> in theory this would be reasonable, but the thing is, other components of pixel formats that use endian swapping & shifting are accessed with a 8 bit read
[14:50] <wm4> so, for example in the rgb555 format, it would use a 1 byte read to access the first component, but a 2 byte read + endian swapping to read a component that is spread over 2 bytes
[14:51] <saste> wm4, and what's wrong?
[14:52] <saste> the code is convoluted, but because the problem is convoluted
[14:52] <wm4> the most fun part is that actually nothing uses av_read_image_line (only a pixel format test filter)
[14:53] <saste> wm4, and for a reason
[14:53] <saste> that's not efficient code, meant only for testing pixdesc
[15:01] <durandal_1707> how should histogram filter behave? pass input to output unchanged?
[15:02] <ubitux> transform the input frame into a fancy histogram?
[15:02] <wm4> vf_gui when?
[15:03] <durandal_1707> same time when vf_wm4 
[15:05] <durandal_1707> vf_wm4 filter will output random subconcious messages into video
[15:06] <saste> durandal_1707, histogram filter != histogram equalization?
[15:06] <saste> if it is just a statistics filter, then yes, check volumedetect for an example
[15:07] <saste> it could also put some form of metadata in the output frames
[15:07] <durandal_1707> but i want to generate fancy graphs
[15:07] <saste> then ebur is your model
[15:08] <wm4> use libass for vector graphics drawing lol
[15:08] <wm4> (no really, you can do filled bezier shapes and such)
[15:08] <ubitux> who cares, you have [cv]ga font available
[15:08] <durandal_1707> but how would i then display frame and graph at same time?
[15:08] <ubitux> durandal_1707: split, pad, overlay
[15:08] <saste> durandal_1707, you can configure the filter to create two outputs
[15:09] <durandal_1707> and than user could overlay one of them on another?
[15:09] <saste> histogram=flags=display+metadata
[15:09] <ubitux> -vf 'split[x][y]; [x]pad=iw:ih*2[a]; [y]histogram[b]; [a][b]overlay=0:h'
[15:10] <saste> anyone has experience with HLS streaming to istuff devices?
[15:10] <ubitux> and you can now add 'drawtext=text=%{n}:expansion=normal:fontcolor=yellow:fontsize=50:fontfile=LiberationMono' at the end of the filtergraph too
[15:11] <saste> ubitux: we should also add text=%{metadata:score}
[15:11] <ubitux> :)
[15:12] <ubitux> btw, now i want a f_tetris.c
[15:12] <durandal_1707> i think writing vf_wm4 is more fun
[15:12] <ubitux> and play with command injection
[15:12] <wm4> ubitux: btw. do you know what elenril is planning for filter options? (I don't)
[15:12] <wm4> ubitux: I got reminded of this because of the very bad command interface
[15:13] <divVerent> I have a sample where av_read_frame() loops endlessly
[15:13] <ubitux> break everything i guess
[15:13] <wm4> which just takes a single string
[15:13] <divVerent> didn't have debug symbols in ffmpeg though
[15:13] <divVerent> it's a somewhat invalid vob file (it reports as 1 second length, while being a lot longer)
[15:13] <divVerent> waiting to get a debug build of ffmpeg, then trying again
[15:13] <ubitux> wm4: it's not that much a problem, except for escaping with file names
[15:13] <saste> wm4: why all this "ehy look at how your code sucks" attitude?
[15:14] <wm4> saste: you don't have to take it personally
[15:14] <divVerent> thing is, such interfaces DO suck if they take file names
[15:14] <divVerent> but from my experience with lavfi, I have no constructive idea of how it could have been done better
[15:14] <saste> divVerent, you mean drawtext?
[15:14] <divVerent> that too
[15:14] <divVerent> movie= source+
[15:14] <wm4> it could for example allow setting av_opts at runtime
[15:14] <divVerent> wm4: doesn't help ffmpeg.c though :P
[15:14] <divVerent> which has the same issue
[15:15] <divVerent> one idea to solve this "properly" is BTW an idea from SQL implementations
[15:15] <ubitux> wm4: how would that change anything for the user?
[15:15] <divVerent> where question marks are filled in by following args
[15:15] <divVerent> like
[15:15] <divVerent> but that's also bad for cmdline parsing :(
[15:15] <wm4> ubitux: I don't have this ffmpeg.c perspective
[15:15] <divVerent> -f lavfi -i "movie=?" foo.mkv
[15:15] <ubitux> wm4: let's take -vf 'split[x][y]; [x]pad=iw:ih*2[a]; [y]histogram[b]; [a][b]overlay=0:h, drawtext=text=%{n}:expansion=normal:fontcolor=yellow:fontsize=50:fontfile=LiberationMono'
[15:15] <ubitux> wm4: what would you prefer?
[15:15] <saste> let's say for example
[15:15] <divVerent> %{n} is actually good :P
[15:15] <wm4> ubitux: I'd shitcan this, and use Lua instead
[15:16] <wm4> ubitux: then build filtergraphs with Lua calls
[15:16] <divVerent> wm4: for ffmpeg.c perspoective maybe
[15:16] <divVerent> but why should external users of ffmpeg suddenly have to use Lua?
[15:16] <wm4> they don't
[15:16] <divVerent> they should build their filter graph with C functions anyway, ideally[tm]
[15:16] <wm4> they'd use the same API functions as the Lua wrapper
[15:16] <divVerent> WHO would then use Lua?
[15:17] <divVerent> for command line lua isn't well suited either
[15:17] <ubitux> wm4: how would that look in lua?
[15:17] <wm4> people who want to use ffmpeg.c and build complicated filter graphs
[15:17] <divVerent> wm4: no, all features have to stay available from command line
[15:17] <wm4> ubitux: I don't know, look at avisynth/vsynth for inspiration
[15:17] <divVerent> shouldn't need "control files" or such stuff
[15:17] <wm4> vsynth uses Python
[15:17] <wm4> (but also can be used as API)
[15:18] <divVerent> wm4: you are missing one thing here... ffmpeg filter graphs are "order independent"
[15:18] <divVerent> so a 1:1 translation is not always possible
[15:19] <saste> filtergraph actually is pretty independent from the rest of the lavfi implementation
[15:19] <saste> it would be possible to create an alternative syntax
[15:19] <saste> more avisynth like
[15:19] <divVerent> -vf "x, y = split(_); a = pad(x, "iw", "ih * 2"); b = histogram(y); _ = drawtext(overlay(a, b), ...);"
[15:19] <saste> or even do scripting with your language of choice (if we would have a external binding)
[15:19] <divVerent> that would still be acceptable from command line
[15:20] <divVerent> but this makes filters global scope-defined functions
[15:20] <divVerent> not a good idea for scripting use
[15:20] <divVerent> but good for command line
[15:20] <saste> for example scale(size="240x123", flags="..."); 
[15:20] <saste> once we support options in all filters
[15:20] <divVerent> also, the question is which language :P
[15:20] <divVerent> Python is right out
[15:20] <divVerent> for requiring multiline constructs in some cases
[15:20] <divVerent> which is not even possible from a command line option
[15:20] <saste> divVerent, brainfuck
[15:21] <divVerent> saste: add a regex library, then maybe ;)
[15:21] <divVerent> Lua is bad too, though
[15:21] <divVerent> for weird syntax in some cases
[15:21] <divVerent> but still
[15:21] <divVerent> before we think about doing THAT
[15:21] <divVerent> we shnould first replace the expression parser by a real scripting language
[15:21] <divVerent> also, in my example, the "iw" and "ih * 2" was obviously bad
[15:22] <divVerent> these should probably rather be lambdas
[15:22] <wm4> weird syntax in what cases?
[15:22] <wm4> Lua is perfect for embedding
[15:22] <wm4> better than makign stupid ad-hoc languages
[15:22] <divVerent> lambdas, for example
[15:22] <wm4> lambdas are a bit verbose
[15:22] <divVerent> the expression parser's "iw" really would become complex in lua
[15:23] <divVerent> function(p) return p.iw end
[15:23] <divVerent> is probably the simplest Lua way to do this
[15:23] <divVerent> I'd like something like
[15:23] <divVerent> (p -> p.iw)
[15:23] <divVerent> or EVEN python's
[15:23] <divVerent> lambda p: p.iw
[15:23] <saste> how would that be better for the end user?
[15:23] <divVerent> where p would be a params struct
[15:23] <divVerent> saste: the expression parser is "odd" in some ways
[15:23] <saste> hey look, you need to know Lua/Python if you want to scale a video
[15:23] <divVerent> having a program specific language IS bad
[15:24] <divVerent> saste: better than now
[15:24] <divVerent> "hey look, you have to know whatever weird stuff we invented"
[15:24] <divVerent> this would also mean
[15:24] <divVerent> that -vf scale=iw:ih won't work the same
[15:24] <divVerent> but would become
[15:24] <divVerent> -vf scale=p.iw:p.ih
[15:24] <divVerent> that would suck indeed
[15:24] <divVerent> -vf scale=320:240 would stay unaffected
[15:25] <divVerent> that would become out = scale(in, 320, 240)
[15:25] <divVerent> these functions would generally have to accept either constants or lambdas
[15:25] <divVerent> to keep usage simple enough
[15:25] <divVerent> REALLY bad would be always requiring those lambdas
[15:25] <divVerent> like
[15:25] <divVerent> out = scale(in, lambda p: 320, lambda p: 240)
[15:26] <saste> divVerent, honestly i think this is overdesign
[15:26] <saste> i think you're confusing two levels
[15:26] <saste> there is the option parsing logic
[15:27] <wm4> -vf "scale(in, 320, 240)" ?
[15:27] <divVerent> the option parsing logic IS bad in some cases
[15:27] <divVerent> also
[15:27] <divVerent> if we really used Python for this
[15:27] <saste> this is actually inconsistent, since we adopted a coarse view, we set the arguments with a single string
[15:27] <divVerent> we could also support the magic constants like iw, ih anyway
[15:27] <divVerent> using operator overloading
[15:27] <divVerent> so we can
[15:27] <divVerent> -vf "scale(in, iw * 2, ih * 2)"
[15:27] <divVerent> anyway
[15:27] <saste> that was good for mplayer, but for complex filters (containing generic strings) it can be tricky (escaping etc)
[15:27] <wm4> nothing was good in mplayewr
[15:28] <divVerent> yes, but filter_complex is also quite stupid in some ways
[15:28] <saste> another thing is the expression engine
[15:28] <wm4> its filter options suck to hell
[15:28] <divVerent> like, having multiple of these options is annoying
[15:28] <divVerent> because they can't use each other's targets
[15:28] <saste> the option/parsing thing can be resolved at different levels
[15:28] <saste> you can implement a separate parser, or write a scripting engine based on your language of choice
[15:28] <divVerent> but the other level is that stupid avexpr parser
[15:28] <divVerent> that SHOULD ideally be a sane scripting language instead, and an EXISTING one at that
[15:29] <divVerent> like, the available math functions are documented nowhere
[15:29] <saste> either with a language binding (any taker) or massaging an high-level description to the relatively low level avgraphparser description
[15:29] <divVerent> regarding avfilter
[15:29] <divVerent> that "just" needs a sane C way to create filter graphs
[15:29] <saste> divVerent, ffmpeg-utils(1)
[15:30] <divVerent> saste: ok, sorry
[15:30] <divVerent> "nowhere" is wrong
[15:30] <divVerent> but "in developer docs" is true
[15:30] <divVerent> ;)
[15:30] <wm4> oh yeah
[15:30] <divVerent> lots of OTHER stuff is duplicated across all the ffmpeg, ffplay, etc. manpages
[15:30] <divVerent> so why not this too
[15:30] <wm4> even the simple way to build avfilter from C is hard
[15:31] <saste> about the expression evaluation engine, that was created eons ago and served it well
[15:31] <saste> if we were going to create it from scratch, we would probably use a scripting engine
[15:32] <saste> divVerent, duplication in man pages is no more
[15:32] <divVerent> where is common stuff now
[15:32] <divVerent> like all the filters?
[15:32] <saste> divVerent, ffmpeg-filters(1)
[15:33] <ubitux> :)
[15:33] <ubitux> divVerent: split is visible here: https://www.ffmpeg.org/documentation.html
[15:33] Action: saste is expecting people now to scream: oh that sucks as well
[15:33] <saste> you people are never happy ;-)
[15:33] <ubitux> saste :D
[15:33] <divVerent> no, THAT is good
[15:33] <divVerent> it' also referred to the right way
[15:34] <ubitux> :)
[15:35] <divVerent> now ffmpeg-filters has to contain or refer to the expression evaluator docs
[15:35] <divVerent> like quoting and escaping already refers there
[15:35] <divVerent> and then it's actually good
[15:35] <divVerent> the new manpage design is a LOT better
[15:35] <divVerent> just hadn't noticed it :)
[16:18] <cone-495> ffmpeg.git 03Stefano Sabatini 07master:5e402a53191c: lavfi/overlay: switch to filter_frame API
[16:18] <cone-495> ffmpeg.git 03Stefano Sabatini 07master:bde1e8bf069a: lavfi/overlay: make use of av_opt_set_from_string()
[16:18] <cone-495> ffmpeg.git 03Stefano Sabatini 07master:35b97ad7c09e: doc/filters: rework and itemize examples for the overlay filter
[16:18] <cone-495> ffmpeg.git 03Stefano Sabatini 07master:0824aa67436d: doc/filters: add overlay daisy-chaining example
[16:22] <ubitux> yay
[16:23] <ubitux> nice, now we can sync again lavfi/video.c
[16:23] <saste> an overlay is soo much simpler
[16:24] <saste> *and
[16:25] <ubitux> :)
[16:25] <cone-495> ffmpeg.git 03Clément BSsch 07master:ba5ea7db9919: doc/filters: simplify escaping in aformat.
[16:25] <cone-495> ffmpeg.git 03Clément BSsch 07master:1330d1d0497f: doc/filters: reword introduction sentence of aformat.
[17:13] <ubitux> michaelni: will you look into dropping start_frame/draw_slice/end_frame from avfilter.c/video.c, or should we do it?
[17:14] <wm4> what's next on the simplification list?
[17:14] <michaelni> ubitux, iam happy to leave that to you/nicolas/saste
[17:15] <ubitux> ok&
[17:15] <ubitux> wm4: from us, maybe the get_video_buffer thing which seems done inefficiently sometimes
[17:15] <wm4> isn't this basically direct rendering
[17:15] <ubitux> wm4: from lav, the next plan is the bufferref-to-avframe afaik
[17:16] <ubitux> wm4: no idea, but the usage between filters look inconsistent to me
[17:16] <wm4> yes, and that's a good thing (barely anyone can understand this perms stuff)
[17:40] <saste> ubitux: what about "Split documentation into per-component manuals"
[17:41] <saste> or simply: per-component manuals
[17:52] <ubitux> sure sounds good
[17:56] <saste> documentation split into per-component manuals?
[17:56] <saste> i'll push this one since it is more grammatically consistent with the other entries
[17:56] <ubitux> sure
[17:57] <ubitux> i just wanted the "split doc" instead of "modular abstraction ..." buzzwords
[17:59] <cone-495> ffmpeg.git 03Stefano Sabatini 07master:5715d67bae08: Changelog: add entry about the new documentation layout design
[18:31] <ubitux> michaelni: so about the yuvj formats for vf pp, aren't they deprecated?
[18:32] <michaelni> they are but as long as they exist they should be supported
[18:33] <wm4> when will lavc stop outputting them?
[18:35] <michaelni> we first need full support for the colorspace type and range fields
[18:35] <wm4> what's missing?
[18:36] <nevcairiel> i think both sws and lavfi dont have such flags
[18:37] <wm4> sws does
[18:38] <nevcairiel> i think it doesnt work right, you have to use the J formats to get any kind of support out of it
[18:38] <nevcairiel> but then the whole colorspace thing is rather badly supported
[18:38] <nevcairiel> but yeah you're right, the flags are there, i just remembered issues with it
[18:39] <wm4> I think color range works fine now in swscale, though I wouldn't know if all conversion paths work
[18:43] <cone-495> ffmpeg.git 03Michael Niedermayer 07master:985aa0be828d: h264: Detect POC inconsistencies and try to handle them reasonably
[19:09] <cone-495> ffmpeg.git 03Johannes Nixdorf 07master:e749b5dd9873: configure: consider using /usr/include/openjpeg-1.5 when searching for openjpeg
[19:38] <ubitux> michaelni: i have something fun here
[19:38] <ubitux> if i do -vf format=yuvj422p,pp
[19:38] <ubitux> [auto-inserted scaler 0 @ 0x7f68b00338c0] w:256 h:256 fmt:rgb24 sar:0/1 -> w:256 h:256 fmt:yuvj422p sar:0/1 flags:0x4
[19:38] <ubitux> [auto-inserted scaler 1 @ 0x7f68b0033d00] w:256 h:256 fmt:yuvj422p sar:0/1 -> w:256 h:256 fmt:yuv420p sar:0/1 flags:0x4
[19:39] <ubitux> and so the filter never get the yuvj pix fmt
[19:39] <ubitux> (even though i have AV_PIX_FMT_YUVJ422P in the supported pix fmt)
[19:41] <wm4> so, what is the reason that pp should support the J formats
[19:41] <wm4> and why do you spend time on it
[19:41] <ubitux> hum actually&
[19:41] <ubitux> something looks wrong
[19:42] <ubitux> this: format=yuv422p,pp is supposed to work but:
[19:42] <ubitux> [auto-inserted scaler 0 @ 0x7f6a10033920] w:256 h:256 fmt:rgb24 sar:0/1 -> w:256 h:256 fmt:yuv422p sar:0/1 flags:0x4
[19:42] <ubitux> [auto-inserted scaler 1 @ 0x7f6a10033e60] w:256 h:256 fmt:yuv422p sar:0/1 -> w:256 h:256 fmt:yuv420p sar:0/1 flags:0x4
[19:42] <ubitux> oh or maybe that's for the output&
[19:42] <michaelni> filtfmts-test pp is listing all the formats
[19:42] <michaelni> ?
[19:44] <ubitux> yep
[19:44] <ubitux> i think the second scaler is inserted after pp actually, i was confused for nothing
[19:46] <ubitux> but still&
[19:47] <ubitux> input format is always 0 in the config props
[19:48] <ubitux> (yuv420p)
[19:52] <mfg> hello. I submitted a patch the other day to address some problem playing HLS streams from certain hosts. I haven't heard anything back about that patch and I have another small one for http.c as well. What should I do?
[19:52] <mfg> it was on the mailing list
[19:53] <ubitux> the patch making the hls demuxer honor the options for streams and not only the playlist?
[19:54] <mfg> yes
[19:54] <mfg> thats me
[19:54] <ubitux> i was hoping stefano would review it :(
[19:55] <mfg> me too?
[19:55] <ubitux> :)
[19:55] <ubitux> well, if no one review it in the next 12 hours i'll have a look
[19:56] <ubitux> (it gives me enough time to harass stefano to do it in my place)
[19:56] <mfg> ok, cool
[19:56] <mfg> while I have your attention... 
[19:57] <mfg> the fox soccer2go servers 403 when you request an m3u8 with the 'Range: %s\r\n' header field 
[19:57] <ubitux> michaelni: ok it seems to be a problem with ffplay
[19:57] <ubitux> mfg: -chunked_post 0?
[19:57] <mfg> no
[19:58] <mfg> its just on when seeking is set to probe
[19:58] <mfg> http.c line...
[19:58] <mfg> should be around 445 
[19:59] <ubitux> right ok
[20:00] <mfg> so, what also happen there is that we request the initial m3u8 and get rejected immediately. I was wondering if a suitable solution would be to prohibit seeking for m3u8s
[20:00] <mfg> just in http.c
[20:00] <mfg> i'm not really sure it makes sense for that sort of file
[20:01] <ubitux> naively, i'd suggest an http option to disable range/seeking, and use it in the hls demuxer for the playlist
[20:01] <mfg> there is one already
[20:01] <mfg> BUT
[20:01] <mfg> when we are probing, we don't know its HLS
[20:01] <ubitux> mmh
[20:01] <mfg> yeah
[20:03] <ubitux> i don't know the probing code, maybe someone else can comment
[20:13] <mfg> ubitux ok, i'll put it to the list after the first patch is finished.
[20:13] <mfg> ty
[20:30] <ubitux> saste: are you going to review the hls patches?
[20:30] <saste> which patches?
[20:30] <saste> my own patches?
[20:31] <ubitux> no, from the guy who sent one or two patches
[20:31] <saste> i'm not happy with how we specify options
[20:31] <ubitux> and a mail
[20:31] <saste> ??
[20:31] <ubitux> [FFmpeg-devel] [PATCH] Maintain HTTP options across multiple requests in HLS demuxer
[20:31] <saste> ah, that's not really my area (I mean HTTP)
[20:31] <ubitux> and [FFmpeg-devel] HLS and HTTP options
[20:31] Action: saste reminds he has to write ffget
[20:32] <ubitux> ok :p
[20:32] Action: ubitux is playing with graph2dot right now
[20:32] <ubitux> i have an issue with ffplay
[20:32] <ubitux> it seems to somehow get a scaler inserted to convert to yuv420p
[20:33] <ubitux> but not where appropriate
[20:33] <saste> i'm thinking about setting options like -f segment=list_size=10:list_filename=foo.m3u8:times='3,4,5,6'
[20:33] <ubitux> heh
[20:33] <saste> right now we have a namespace problem
[20:33] <saste> all options set in the same global environment, with no way to specify the context
[20:33] <saste> but for stream options
[20:34] <saste> and we can't set for example protocol and protocol options in a sane way
[20:34] <saste> something like -proto http=cache=1 ...
[20:35] <saste> some muxers adopted the conventions of prefixing the private option with the component name
[20:36] <saste> but even in that case there is the possibility of a namespace conflict (e.g. codec and muxer with the same name and same option names)
[20:41] <saste> right now also we have a bug-prone heuristics to determine the protocol, for example we can't force the file protocol for a file named like "http://this/is/a/weird/local/filename"
[20:43] <ubitux> yeah why not
[21:05] <edgy> Hi, why am I getting [mpeg2video @ 0x9a8fa0] mpeg_decode_postinit() failure? I can play the video but still that error shows
[22:00] <ubitux> fuck that shit, graphviz not working again
[22:01] <wm4> what's the problem?
[22:01] <ubitux> dot is not honoring the gradiant here
[22:01] <ubitux> basically, i get flat colors with http://www.graphviz.org/Gallery/gradient/g_c_n.html
[22:02] <wm4> maybe it has to do with whatever backend you're using?
[22:04] <ubitux> someone told me that it worked with his version
[22:04] <ubitux> so likely a regression
[22:05] <cone-495> ffmpeg.git 03Stefano Sabatini 07master:005b360b9c69: lavf/hlsenc: fix basename size computation off-by-one bug
[22:05] <cone-495> ffmpeg.git 03Stefano Sabatini 07master:60c801c679c8: lavf/hlsenc: reuse pattern string, rather than redefining it
[22:05] <ubitux> and also, since it's using autotools and moreover badly, it's a pain in the ass to test without installing on the system
[22:34] <cone-495> ffmpeg.git 03Michael Niedermayer 07master:bc5d6e4b9615: docs: point to aresample from asyncts docs
[22:37] <ubitux> mmh maybe it wasn't working actually
[22:42] <ubitux> http://b.pkh.me/lavfi.png i need gradiants :(
[22:59] <ubitux> oh it's in the dev version&
[23:03] <ubitux> actually i'm gonna do this differently
[23:09] <llogan> ubitux: that's quite the filterchain
[23:11] <ubitux> yes, but half of it makes no sense
[23:11] <ubitux> i'm going to make it way more pretty & useful now.
[23:19] <saste> ubitux, what's the color about?
[23:19] <ubitux> "type"
[23:20] <saste> input type ok
[23:23] <ubitux> i should be done soon :)
[23:33] <burek> is it possible to tell ffmpeg to split the video at some point so that the output starts with a keyframe?
[23:34] <burek> using -ss and -c copy
[23:35] <burek> ffmpeg -i input -ss x:y:z -c copy -force_first_keyframe output
[23:35] <burek> something like that
[23:38] <saste> burek: check the segment muxer
[23:39] <saste> you want to split the input *every time* a key frame is found?
[23:39] <burek> no
[23:39] <saste> whatever the time is?
[23:39] <burek> just one output file
[23:40] <saste> burek, right now you can probe the file, detect the first keyframe, and specify -segment_times T
[23:40] <saste> i'm working for a more automatic solution right now
[23:40] <saste> but might take some time
[23:40] <ubitux> http://b.pkh.me/lavfi2.png
[23:40] <ubitux> still a bit unreadable, but that's the idea.
[23:41] <burek> it would be beautiful if there would be an option like -first_key_frame or something, which would make ffmpeg not to start writing the output packets until a keyframe has been detected
[23:41] <burek> i also needed it millions of times, but now a guy asked on the forum which reminded me to ask you guys :)
[23:42] <saste> burek: you can simply use the muxer and discard the first segment
[23:42] <saste> not very nice though...
[23:43] <burek> wouldn't segmenter produce multiple files?
[23:43] <saste> -segment_times SPLIT_TIME
[23:43] <saste> just one split point
[23:46] <burek> hmm, i'll have to read the docs about it one more time to understand what you are suggesting :) thanks btw :)
[23:48] <saste> burek: ffmpeg -i INPUT -codec copy -segment_times SPLIT_TIME -f segment OUT
[23:48] <saste> should be enough
[23:48] <saste> burek: do you have experience with HLS streaming?
[23:49] <burek> apple?
[23:49] <saste> yep
[23:49] <saste> ipod/ipad
[23:50] <burek> not quite, but i've helped several people to get things working :D
[23:50] <burek> shoot the question and if i know ill answer :)
[23:50] <saste> uhm this is an ipod related question
[23:50] <saste> i'm streaming using hls/segment, the ipad reads the M3U8 file but then it somehow hangs
[23:50] <ubitux> saste: http://b.pkh.me/lavfi3.png
[23:51] <saste> it only reads the M3U8 file and the first segment, and hangs forever
[23:51] <saste> i suppose this is something ipod/pad specific, but can't figure out what is
[23:51] <burek> saste, do you have any working sample of hls media?
[23:52] <saste> i'm using synthetic media, i can show you the script
[23:53] <saste> ubitux, it is possible to put input pads at the top, and output pads at the bottom of the filter container?
[23:53] <ubitux> saste: not sure; it's always a pain to do such thing with graphviz
[23:54] <burek> saste, maybe you could see here: https://developer.apple.com/resources/http-streaming/examples/
[23:54] <burek> maybe comparing segments might help
[23:56] <saste> burek: i've been told that iOS is rather picky, so I'd like to know a report from someone which got it working in the first place
[23:56] <saste> so i have something from which to start to work, rather than guessing
[23:57] <burek> well the idea was to get some media that works for the ipod and to check those segments to see what do they have that your segments dont.. i dunno..
[00:00] --- Sun Dec 23 2012