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

[burek]

[00:00] <Compn> i think we do need some spies. seems like there is zero communications within groups
[00:00] <Compn> between the groups, i eman
[00:00] <Daemon404> plenty of conspiracy theories though
[00:01] <Compn> we live in a world full of half-truths. theories are all we got!
[00:01] Action: ubitux is also an evil spy
[00:02] <Daemon404> https://github.com/mplayer2/mplayer2/commit/95e81df132e3dbc555974d125e56ae701a0f6968.patch <-- i guess wm4 wears his tinfoil at
[00:02] <Daemon404> oh well
[00:02] <Daemon404> hat*
[00:02] <wm4> ?
[00:02] <Daemon404> no real name in git
[00:03] <Daemon404> or even a email
[00:04] <cone-961> ffmpeg.git 03Peter Ross 07master:c16f768d73cc: ffmpeg: replace magic number with VSYNC_CFR
[00:05] <wm4> Daemon404: are you like those people who freak out when someone posts without real name to a newsgroup?
[00:05] <Compn> i support wm4's non-named psuedo-anonymous internet usage
[00:05] <Compn> just so you know :P
[00:06] <Daemon404> wm4, no, but i generally think people who dont put their realname on git are tinfoil hats
[00:06] <Daemon404> akin to /. commenters :P
[00:06] <Compn> Daemon404 : how come you dont put your real name in your irc client ?
[00:06] Action: Compn slaps Daemon404
[00:06] <Compn> Daemon404 is ~who_knows at pdpc/supporter/student/Daemon404 * daemon404
[00:07] <Compn> look at that tin foil hat!
[00:07] <Compn> even hides his ip!
[00:07] <Daemon404> git != irc
[00:07] <Daemon404> dont make invalid comparisons
[00:07] <Compn> derp = derp
[00:07] <Daemon404> thats an assignment operator
[00:07] <Daemon404> such buggy code.
[00:07] <Compn> ==
[00:07] <Daemon404> missing ;
[00:07] <Compn> GOTO QUIT;
[00:08] <Daemon404> if that's basic, it doesn't need a ;
[00:08] <Compn> wm4 : see, you cant be on defensive. if someone calls you out, turn it right back and call them out for doing the exact same thing
[00:08] <Daemon404> except i dont
[00:08] <Daemon404> and you are quite bad at trolling
[00:08] <Compn> and then call them a hypocrite for good measure
[00:11] <ubitux> asshole vs hypocrite
[00:11] <ubitux> @_@
[00:11] <Daemon404> this is the internet man
[00:11] Action: Daemon404 calls Compn and pooface
[00:12] <wm4> Daemon404: I even submitted a patch to ffmpeg "anonymously", how's that for tinfoil hattery?
[00:12] <Daemon404> metallic
[00:12] <wm4> (it was about libmpcodecs stuff in lavfi, don't want to be associated with that)
[00:12] <Daemon404> lul
[00:12] <ubitux> and so now we can put an official anonymous name on the anonymous commit
[00:13] <Compn> ffmpeg still has some anonymous authors
[00:13] <Daemon404> very few
[00:13] <Compn> some encryption and codecs reverse engineerings
[00:13] <Daemon404> and the few there are are kinda known anyway
[00:13] <ubitux> Gerard Lantau? :)
[00:13] <Daemon404> Elvis
[00:13] <Compn> the entire project is a lie!
[00:13] <ubitux> Speedy Gonzales?
[00:13] <Compn> speedy :)
[00:14] <Compn> maybe we'll get a santa clause commit this month
[00:14] <Compn> bringing the kids apple intermediate codec support
[00:14] <wm4> I'm wondering who Gynvael Coldwind is, is he real?
[00:15] <Compn> the guy who works with j00ru ?
[00:15] <wm4> yes
[00:15] <Compn> are any of those exploit people real?
[00:15] <Compn> hes got a blog > http://gynvael.coldwind.pl/
[00:16] <Compn> or she
[00:28] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:d7599bd8e240: h264: dont mess with frame gaps on second fields.
[01:16] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:1662bd350a47: lavf: fix integer overflows
[01:16] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:1e901ffc6194: wrap_timestamp: remove unneeded check
[01:18] <wm4> why do some AVComponentDescriptor have offset_plus1 set to 0? is that intended and does av_read_image_line() behave correctly with it?
[01:19] <wm4> e.g. AV_PIX_FMT_BGR444BE
[01:28] <ubitux> i'm transcoding from a short mkv to webm
[01:28] <ubitux> and i get half of the frames dropped
[01:28] <ubitux> any idea why?
[01:32] <michaelni> could be wrong framerate
[01:33] <ubitux> mmh indeed forcing -r 24 solve the issue
[01:33] <ubitux> though, input is detected at 24
[01:33] <ubitux> and output as well
[01:33] <Daemon404> dump its timestamps
[01:33] <Daemon404> see if it really is pure 24
[01:34] <Daemon404> matroska has no concept of a framerate
[01:34] <ubitux> it's likely not pure 24
[01:34] <ubitux> but it should drop half the frames if it's approximately 24
[01:35] <ubitux> on a side note, i will *never* understand how to make a proper webm encode without specifying bitrate
[01:35] <ubitux> well, vp8 encode
[01:35] <Daemon404> you expect vp8 to have a non-bitrate-based ratecontrol option?
[01:36] <Daemon404> a la crf?
[01:36] <Daemon404> lulz
[01:36] <ubitux> there is a crf option
[01:37] <Daemon404> let me rephrase
[01:37] <Daemon404> you expect libvpx crf to work?
[01:37] Action: Daemon404 has always had terrible terrible experiences with everything related to libvpx
[01:38] <ubitux> same here, but i don't know anything else
[01:38] <Daemon404> i know that using webm is pretty pointless
[01:39] <ubitux> well at least that's playable in a browser
[01:39] <ubitux> but to me, it just looks like options to libvpx don't make the output better
[01:40] <michaelni> ubitux, if you dont find the fps issue, then upload te file and ping me
[01:40] <ubitux> it just speed up or slow down encode
[01:40] <cbsrobot> Compn: they don't seem real - do they? http://icewall.wordpress.com/2008/11/04/it-underground-2008/
[01:40] <ubitux> michaelni: ok, i'll have a quick look when i'm done, thx
[01:43] Action: cbsrobot gets always some sort of artefacts encoding in webm
[01:45] <ubitux>     { "deadline",        "Time to spend encoding, in microseconds.", OFFSET(deadline),      AV_OPT_TYPE_INT, {.i64 = VPX_DL_GOOD_QUALITY}, INT_MIN, INT_MAX, VE, "quality"},
[01:45] <ubitux> "time to spend encoding"
[01:45] <ubitux> that's exactly that
[01:47] <ubitux> http://b.pkh.me/libvpx.jpg
[01:47] <ubitux> :/
[01:47] <ubitux> http://b.pkh.me/before-libvpx.jpg
[01:48] <ubitux> this is "best quality"
[01:49] <Daemon404> did you accidentally to -vf mosiac
[01:50] <ubitux> :(
[01:51] <ubitux> -vf bloodyvomit
[01:51] <Daemon404> -vf realmedia
[01:51] <iive> ubitux: doesn't sound right to me. how about" time allowed for encoding single frame"?
[01:52] <iive> ubitux: is this when they escape the whale?
[01:52] <ubitux> iive: yup :)
[01:53] <ubitux>   rc_target_bitrate:            256
[01:53] <ubitux> mmh i wonder if that isn't taking over any quality setting
[01:53] <Daemon404> check libvpx.c
[01:53] <Daemon404> maybe it checks for a flag
[01:55] <ubitux> it seems that's because avctx->bit_rate=200000
[01:57] <ubitux> maybe not only
[02:00] <ubitux> oh, -b:v 0 -crf 20 looks good.
[02:00] <Daemon404> usability--;
[02:00] <ubitux> i wonder if we shouldn't just ignore bitrate setting when crf is set
[02:00] <Daemon404> i wuld think thats the sane thing to do
[02:04] <ubitux> yepee i can finally makes sane webm files.
[02:04] <ubitux> -s
[02:56] <ubitux> Daemon404: were you talking to the git-tag name or the name of the author?
[02:56] <ubitux> s/to/about the/
[02:56] <Daemon404> author
[02:56] <Daemon404> tag is correct
[02:56] <ubitux> oh ok
[02:56] <ubitux> then i'll apply as is
[02:57] <ubitux> unless wm4 wants something else
[02:57] <wm4> ?
[02:57] <ubitux> wm4: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-December/135756.html
[02:58] <wm4> *shrug*
[02:58] <ubitux> :))
[02:59] <wm4> ubitux: while we're at it, can you look at AV_PIX_FMT_UYYVYY411?
[02:59] <wm4> somehow I think its pixdesc entry doesn't make much sense
[02:59] <wm4> surely I'm wrong...
[03:00] <ubitux> i'm not sure i'll be of much help for that one
[03:00] <wm4> and also, as I said above, some formats (including AV_PIX_FMT_BGR444BE) have component entries with offset_plus1 set to 0
[03:12] <ubitux> i'm not familiar with the pix fmt sorry :p
[03:16] <ubitux> pross-au: would be nice to have some fate test for this stuff
[03:16] <ubitux> (bayer rgb)
[04:06] <ubitux> argh i missed that saste removed the av_expr_free
[04:06] <ubitux> well, will fix tomorrow.
[05:22] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:718eab527b9a: ffmpeg: Improve filter input fps selection heuristic.
[05:41] <Zeranoe> I'm getting this error when trying to compile FFmpeg with utvideo 12.0.0: "libavcodec/libutvideodec.cpp:68:18: error: 'UTVF_RGB32_WIN' was not declared in this scope"
[05:50] <Daemon404> s/UTVF_RGB24_WIN/UTVF_NFCC_BGR_BU/ && s/UTVF_RGB32_WIN/UTVF_NFCC_BGRA_TD/ i believe
[05:50] <Daemon404> i might just remove libutvideo support
[05:50] <Daemon404> itll be useless once utv encoder gets threading
[11:03] <cone-242> ffmpeg.git 03Stefano Sabatini 07master:cb0f97b59d67: ffplay: improve robustness of opt_codec(), and add options acodec,vcodec,scodec
[11:03] <cone-242> ffmpeg.git 03Stefano Sabatini 07master:1cbb11cda79e: ffplay: set codec_id in codec context
[11:03] <cone-242> ffmpeg.git 03Stefano Sabatini 07master:013b700771ec: ffplay: provide some feedback in case the codec cannot be set
[11:06] <burek> does anyone have any experience in setting up a single machine to be a cross-compiler for multiple architectures
[11:06] <burek> we could set up one such to auto-build static binaries for x86, amd64 and arm
[11:06] <burek> and/or win32
[11:12] <burek> also, if someone has got some spare time to explain how the data is formed on fate.ffmpeg.org, out of ${build}/config.fate, ${build}/tests/data/fate/*.rep and *.log
[11:12] <burek> i know it might be trivial to you devs, but it's not quite perfectly clear to me
[11:12] <burek> so, i appreciate any help
[11:39] <saste> burek: i never messed up with a fate setup
[11:39] <saste> so i can't help very much...
[12:34] <cone-242> ffmpeg.git 03Piotr Bandurski 07master:d0bdcbcb28a7: thp: set duration
[12:34] <cone-242> ffmpeg.git 03James Almer 07master:7959c26fb04d: brstm: fix number of samples for the last block
[12:34] <cone-242> ffmpeg.git 03Piotr Bandurski 07master:5648069270d5: aiff: support in24/in32 tags
[12:47] <cone-242> ffmpeg.git 03Paul B Mahol 07master:f4fe4fa89f0b: Remove 8SVX_RAW on next lavc mayor bump
[13:03] <cone-242> ffmpeg.git 03Paul B Mahol 07master:1081d7874690: build: fix idf demuxer dependency
[13:11] <ubitux> saste: you removed the av_expr_free in lavfi/crop
[13:11] <ubitux> so it leaks in fate
[13:12] <cone-242> ffmpeg.git 03Justin Ruggles 07master:230acdde264e: lavr: move AudioMix struct definition to audio_mix.c
[13:12] <cone-242> ffmpeg.git 03Janne Grunau 07master:27c8337e595a: h264-mt: handle NAL_DPAs before calling ff_thread_finish_setup
[13:12] <cone-242> ffmpeg.git 03Michael Niedermayer 07master:dde4832b64c5: Merge commit '27c8337e595a058347150269d5c2c48281e4285b'
[13:20] <cone-242> ffmpeg.git 03Stefano Sabatini 07master:94877aad57bd: lavfi/crop: free x and y parsed expression objects
[13:20] <ubitux> thanks
[13:20] <saste> ubitux: do you want to review the overlay patch?
[13:21] <ubitux> no i don't plan to
[13:21] <saste> i'm waiting for nicolas to review it, but no reply so far
[13:21] <ubitux> yeah i know :p
[13:21] <ubitux> i'm waiting for this as well :(
[13:21] <ubitux> maybe send him a mail?
[13:22] <saste> ubitux, are you going to clean up the framework, after all draw slice use is gone?
[13:22] <ubitux> "cleanup" is a big word
[13:22] <saste> i mean remove the unused code
[13:22] <ubitux> most likely i'll just look if we can just reduce diff
[13:22] <cone-242> ffmpeg.git 03Janne Grunau 07master:a421bbfe83ad: h264: fix memleak on error during SPS parsing
[13:22] <cone-242> ffmpeg.git 03Michael Niedermayer 07master:efb4f96a7a8b: Merge remote-tracking branch 'qatar/master'
[13:22] <durandal_1707> ubitux: heard about timed text format?
[13:23] <ubitux> maybe :p
[13:23] <ubitux> context?
[13:23] <durandal_1707> it is stored in 3gpp2
[13:24] <ubitux> the gpac xml thing?
[13:24] <durandal_1707> as 'gadi'
[13:24] <durandal_1707> ^wrong that is asset..
[13:26] <ubitux> durandal_1707: http://gpac.wp.mines-telecom.fr/mp4box/ttxt-format-documentation/  this?
[13:26] <nevcairiel> timed text as in tx3g?
[13:26] <nevcairiel> aka mpeg-4 part 17?
[13:26] <ubitux> don't we support this one?
[13:27] <nevcairiel> at least it has a codec id, not sure how complete the decoder is
[13:28] <durandal_1707> 3gpp2 ts.26245  "3GPP2 Timed Text"
[13:44] <cone-242> ffmpeg.git 03Michael Niedermayer 07master:5b09c3407e17: doc/filters: fix "Dolby Pro Logic II" option name
[13:44] <wm4> ubitux: kate->ass support when?
[13:45] <ubitux> kate ?
[13:45] <ubitux> sample?
[13:46] <wm4> http://wiki.xiph.org/index.php/OggKate
[13:47] <nevcairiel> everyone has their own subtitle codec these days
[13:47] <ubitux> iirc we support text subtitles in ogg, i guess that's something else?
[13:48] <ubitux> "Kate is an overlay codec, originally designed for karaoke and text, that can be multiplixed in Ogg."
[13:48] <ubitux> nooooooooooo
[13:49] <ubitux> :'(
[13:49] <wm4> I knew you'd love it
[13:49] <nevcairiel> its an ugly mixture of images and text, apparently
[13:49] <durandal_1707> "though I haven't looked at this one in detail, since I'd already had a working Kate implementation by that time"
[13:49] <ubitux> wm4: please don't tell me you have a sample
[13:49] <wm4> ubitux: open source people like using it, I think
[13:50] <durandal_1707> mplayer support that?
[13:50] <wm4> durandal_1707: no
[13:50] <durandal_1707> there is lib?
[13:51] <wm4> yes
[13:51] <wm4> there's even a mplayer patch for it (it patches demux_ogg, hurr hurr)
[13:51] <wm4> VLC supports it AFAIK
[13:52] <wm4> ubitux: samples collection (probably not what you want): http://git.xiph.org/?p=users/oggk/kate.git;a=tree;f=examples/kate
[13:52] <j-b> nevcairiel: of course, everyone has. It is so simple to create a simple one... but sooo difficult to make a good advanced one.
[13:53] <wm4> ubitux: "real" sample: http://people.xiph.org/~oggk/elephants_dream/elephantsdream-with-subtitles.ogg
[13:53] <ubitux> http://git.xiph.org/?p=users/oggk/kate.git;a=blob;f=examples/kate/karaoke.kate;hb=HEAD no, seriously? :D
[13:53] <nevcairiel> j-b: its like lossless audio!
[13:53] <wm4> ubitux: also, I'm practically trolling - barely anyone wants/needs this format
[13:53] <ubitux> that's a good news
[13:54] <j-b> nevcairiel: lossless is even worse, because there are already good lossless codecs, so the reason tod do one is stupid
[13:55] <durandal_1707> there are no good audio lossless codec
[13:55] <nevcairiel> good sure, perfect maybe not
[13:56] <ubitux> the .kate syntax looks particularly insane
[13:57] <ubitux> like timing information not being prefixed by a directive like the others settings
[13:58] <ubitux> it's almost missing trailing ';'
[13:59] <iive> like most xiph things...
[14:07] <cone-242> ffmpeg.git 03Paul B Mahol 07master:5be38f9421da: brstm: add missing new line to request for sample messages
[14:29] <ubitux> http://wingolog.org/archives/2012/12/12/corps-bespoke-text-codecs  text codecs!
[15:06] <cone-242> ffmpeg.git 03Michael Niedermayer 07master:633ae5a2101c: mjpegenc: fix 444 block count so it is below 10
[15:06] <cone-242> ffmpeg.git 03Michael Niedermayer 07master:de89dff8da7b: brstm: ask for samples for version != 1.0
[16:33] <saste> uhm texi2pod is hacky
[16:34] <saste> the more i think about it, the more i see that an haskell reimplementation in pandoc would be easier
[16:57] <cone-242> ffmpeg.git 03Piotr Bandurski 07master:cb8163d0bdf6: bfi: set duration
[17:27] <ubitux> dvd&
[17:27] <ubitux> :(
[17:28] <nevcairiel> you should just write code to parse the ifo and find the palette!
[17:29] <ubitux> yes, i could do that, but how to integrate this in the project?
[17:29] <ubitux> i mean, where do you do that?
[17:29] <wm4> clearly it should be a demuxer
[17:30] <ubitux> ifo demuxer?
[17:30] <ubitux> there are multiple files
[17:30] <wm4> it was a joke, because ffmpeg seems to add many useless things as demuxers (like that concat thing recently)
[17:31] <ubitux> useless? :)
[17:31] <ubitux> are you serious?
[17:31] <ubitux> it's pretty useful&
[17:31] <beastd> hi
[17:32] <Compn> encoding multiple files is very useful
[17:32] Action: Compn has no idea how concat works :D
[17:32] <ubitux> concat demuxer makes possible to concat without re-encoding
[17:33] <ubitux> "hi i want to concat mp4"
[17:34] <wm4> then the ffmpeg frontend should support that?
[17:34] <ubitux> concat at ffmpeg level? why not, but the frontend is pretty huge already
[17:35] <ubitux> and we can use it in ffplay too now
[17:38] <saste> wm4, the concat thing was one of the most requested features
[17:39] <saste> and something about 10% of the question on -user was about: how can i concat things together?
[17:39] <wm4> were all of these about files with same codecs etc.
[18:01] <Compn> mencoder has had multiple file input for years
[18:01] <Compn> its about time ffmpeg got it...
[18:02] <Compn> i remember people even using mencoder to put them in one file, so ffmpeg could finish it
[18:02] <wm4> I think a concat demuxer will break pretty hard with files that are even slightly differently encoded, but maybe I don't know enough about ffmpeg's architecture
[18:03] <nevcairiel> depends on the codec, some support changing parameters
[18:03] <nevcairiel> you can concat two completely different h264 streams, and the decoder should happily decode it, at least if you disable mt
[18:03] <nevcairiel> the l guys are working on getting mt to also fully support h264 parameters changes
[18:03] <wm4> but what if the other file is not h264
[18:04] <nevcairiel> well then you
[18:04] <nevcairiel> are screwed
[18:04] <nevcairiel> :P
[18:04] <wm4> back to mencoder!
[18:04] <nevcairiel> but thats more then "slightly differently"
[18:04] <nevcairiel> :)
[18:04] <wm4> true
[18:04] <nevcairiel> can't ffmpeg even do this, it just requires re-encoding?
[18:55] <Daemon404> what the FUCK
[18:55] <Daemon404> so i review a patch, explain why it's wrong
[18:55] <Daemon404> paul comes along
[18:55] <Daemon404> "applied."
[18:55] <Daemon404> what the actual fuck.
[18:59] <beastd> Daemon404: Which patch?
[19:00] <Daemon404> thp: set duration
[19:00] Action: beastd is looking
[19:03] <beastd> Got it.
[19:06] <beastd> Imho reply to "Applied."-mail and ask why it was committed and that it looks wrong and like it only works by coincident. so you would at least have expected further explanation before pushing.
[19:10] <Daemon404> beastd, $5 says paul gets pissy or insults me
[19:10] <Daemon404> as usual
[19:10] <Daemon404> or replies with "isnt it obvious?" sort of emails
[19:10] <nevcairiel> there are more days then not when i think he isnt one to have push access
[19:11] <Daemon404> this kind of hting happens a lot
[19:11] <Daemon404> this isn't teh first time he has completely ignored my reviews
[19:11] <Daemon404> to his own patches too
[19:12] <Daemon404> one time he even claimed "i left libav so i didnth ave to do this" and called me a libav spy
[19:12] <Daemon404> (this is all public on teh mailing list bw)
[19:13] <nevcairiel> yeah he reacts volatile to criticism
[19:13] <Daemon404> unless it's michael :P
[19:13] <nevcairiel> i suppose
[19:15] <Daemon404> i already know thw response
[19:15] <beastd> Daemon404: Sorry I have to go now.
[19:15] <Daemon404> "it works so push it"
[19:15] <Daemon404> even if it uses black magic
[19:16] <Daemon404> explicit code is for chumps!
[19:16] <beastd> But imho try it. I think someone else might also reply.
[19:16] <beastd> got to go now. sorry
[19:16] <Daemon404> cya
[19:16] Action: beastd is in a hurry
[19:16] <Daemon404> oh fuck me
[19:17] <Daemon404> he even applied the wrogn freakign patch
[19:17] <Daemon404> with the shitty commit message
[19:17] <Daemon404> from jamal
[19:17] <Daemon404> even when he submitte a better one
[19:17] <Daemon404> :logic:
[19:19] <Daemon404> and michael has gone and pshed similar patches from piotr with the same black magic
[19:19] <Daemon404> lovely
[19:19] <Daemon404> glad to know reviews are nicely ignored withotu explanation all around
[19:20] <wm4> well, there's also Libav with a proper and strict review process...
[19:20] <Daemon404> libav is the opposite problem
[19:20] <Daemon404> bikeshed till death
[19:20] <Daemon404> but i'd GLADLY take it over this
[19:20] <wm4> haha, why did I expect such a reply
[19:21] <wm4> is there any chance the two projects will merge again?
[19:21] <michaelni> Daemon404, can you explain what problem the patch has that i applied ?
[19:21] <Daemon404> michaelni, see review fot thp: duation
[19:21] <Daemon404> [13:15] <@Daemon404> "it works so push it"
[19:21] <Daemon404> [13:15] <@Daemon404> even if it uses black magic
[19:21] <Daemon404> [13:16] <@Daemon404> explicit code is for chumps!
[19:22] <Daemon404> even then it's not excusable to do what paul did.
[19:24] <michaelni> Daemon404, the patches look correct (iam not talking about attitude, commit messages or such here, just the code)
[19:24] <Daemon404> michaelni, no explanation is given why why it should not be doen explicitly
[19:25] <Daemon404> doing implicit magic to convert nb_frames to a duration is just bad practice
[19:25] <michaelni> what do you mean by "explixitly" ?
[19:25] <Daemon404> it makes code hard to follow, and could possibly mess up on vfr content
[19:25] <Daemon404> explicility calculating teh duartion
[19:25] <Daemon404> nb_frames !+ duration
[19:25] <Daemon404> er, !=
[19:26] <Daemon404> hell there isnt even a comment
[19:26] <Daemon404> or a func call/macro
[19:27] <Daemon404> unless you happen to know ffmpeg has a secret special case for when duration == nb_frames
[19:28] <michaelni> Daemon404, how could a CFR format like thp contain VFR ?
[19:29] <Daemon404> i know that
[19:29] <Daemon404> now the read the rets of what i wrote
[19:29] <Daemon404> it's just degrading code clarity even more
[19:34] <michaelni> Daemon404, I did read it but it makes 0 sense to me. Its not clear what you talk about or what you mean by explicit.
[19:35] <Daemon404> holy. fuck.
[19:35] <Daemon404> if im reading that demuxer
[19:35] <Daemon404> and i see duration = framecount;
[19:35] <Daemon404> it's a big WTF
[19:35] <Daemon404> I, as a reader, do not know has a secret special case for this
[19:36] <Daemon404> and there is nothing to indicate this
[19:36] <Daemon404> in fact, it looks wrong.
[19:36] <michaelni> what secret special case ?
[19:36] <Daemon404> duration == nb_frames
[19:36] <Daemon404> duration is in time_base
[19:36] <Daemon404> not frames
[19:36] <michaelni> timebase == 1/fps -> nb_frames == duration
[19:37] <michaelni> no special case here
[19:38] <Daemon404> it's still quite nonobvious enough it need a comment
[19:38] <Daemon404> i mean, time_base is nto explicitly set in that demuxer
[19:38] <michaelni> avpriv_set_pts_info()
[19:39] <Daemon404> "The denominator and numerator are switched because 1/fps is required."
[19:39] <Daemon404> nice and vague.
[19:39] <Daemon404> in any case, paul could have replied with that
[19:40] <Daemon404> and oh look  avpriv_set_pts_info has absolutely no documentation on what it does aside from its source :|
[19:42] <michaelni> not hard to fix, only question is do you want to or should i ?
[19:43] <Daemon404> i will
[19:43] Action: michaelni looks and sees doxy above avpriv_set_pts_info
[19:43] <Daemon404> http://ffmpeg.org/doxygen/trunk/libavformat_2utils_8c-source.html#l03853
[19:43] <Daemon404> i dont
[19:46] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/utils.c;h=92207be1bcac117283397e5a491ac20bb750c5a2;hb=HEAD#l3853
[19:46] <Daemon404> nor here
[19:47] <michaelni> http://ffmpeg.org/doxygen/trunk/libavformat_2internal_8h.html#ab5542950d6beb910dc9237aac99989e
[19:47] <Daemon404> doxygen's docs dont show above it's actual impl, which is where hyperlinks from other source files go
[19:48] <Daemon404> that's kind of misleading,  to say the leats
[19:48] <michaelni> yes, i dont know why thats happening like that
[19:50] <Daemon404> though "sets the stream pts" doesnt really mean the same as "Set's the time base"
[19:50] <Daemon404> ill sitll submit a patch to clarify the doxy
[19:51] <Daemon404> in hindsight, "pts for a stream" is completely nonsense
[19:51] <Daemon404> given what pts is an acronym for
[19:53] <michaelni> please do and thanks
[19:53] <Daemon404> i am still unhappy with paul though.
[19:54] <Daemon404> i dont know how someone manages to apply the wrong patch either :|
[19:54] <nevcairiel> even if the original patch was correct, if someone is doing a review and asking questions, ignoring that person and simply applying the patch is plain rude
[19:55] <Daemon404> exactly
[19:55] <Daemon404> and he obviously didnt read the trhead with jamal
[19:55] <Daemon404> or he would have applied jamal's updated patch
[19:55] <Daemon404> that's just bad.
[19:56] <saste> Daemon404, you tend to overreact, also don't jump to conclusions
[19:56] <Daemon404> saste, do tell if you have another conclusion
[19:56] <saste> maybe he missed the mail or he fucked his mailer
[19:57] <Daemon404> saste, he has told me to my face he ignroes my reviews
[19:57] <Daemon404> in the past
[19:57] <saste> it sometimes happen to main to get stashed mails for hours
[19:57] <Daemon404> i have no reason to think this has changed
[19:57] <Daemon404> saste, the trhead was month+ old
[19:57] <Daemon404> i revived it
[19:57] <michaelni> btw gmx had a mail delivery problem a few days ago and i had random mails being 5+ hous late
[19:57] <Daemon404> youre tellign me he coincidentally applied it
[19:58] <Daemon404> the day after i reviewed?
[19:59] <Daemon404> on TWO threads?
[20:00] <saste> Daemon404, i'm just saying that that is not impossible
[20:01] <Daemon404> it's just extremely unlikely.
[20:01] <saste> even if he did that purposefully, just screaming and bitching won't help
[20:01] <saste> i suggest to reply on list, and ask why that happened
[20:01] <Daemon404> i did.
[20:01] <Daemon404> i dotn expect him to reply
[20:01] <nevcairiel> he will either get no reply, or being insulted on irc
[20:02] <Daemon404> ^ historical evidence says this
[20:02] <nevcairiel> or a very meaningless reply
[20:02] <nevcairiel> (which is as good as none)
[20:24] <saste> how can i call make clean *only* for the doc dir?
[20:25] <Daemon404> rm -r doc/* ?
[20:25] <Daemon404> for an otu of tree build
[20:25] <saste> good for blasting the source as well ... ;-)
[20:25] <Daemon404> hence out of tree build :P
[20:25] <Daemon404> i forget that people do in tree builds
[20:25] <saste> we have a clean target, but can't be called from the doc dir
[20:47] <cone-242> ffmpeg.git 03Clément BSsch 07master:7fb49639e6b1: lavu: make sure av_pix_fmt_desc_next returns a valid pix fmt.
[20:47] <cone-242> ffmpeg.git 03Clément BSsch 07master:9ad6b130201f: lavu/pixdesc: fix a const qualifier discarding warning.
[21:03] <michaelni> Daemon404, http://ffmpeg.org/doxygen/trunk/libavformat_2utils_8c.html#aab5542950d6beb910dc9237aac99989e
[21:03] <michaelni> ubitux, we now have doxygen 1.8.2 on ffmpeg.org
[21:03] <ubitux> oh, nice :)
[21:05] <cone-242> ffmpeg.git 03Clément BSsch 07master:0212c1c43dc4: swr/doxy: fix missing quote in code example.
[21:05] <ubitux> thx, that looks better
[21:12] <ubitux> https://www.ffmpeg.org/doxygen/trunk/group__lavu.html  why so much "file version.h"?
[21:13] <michaelni> ubitux, how would i know ?
[21:14] <ubitux> maybe someone else knows doxygen a little :p
[21:14] <ubitux> well anyway, this stuff should please at least one person
[21:14] Action: ubitux looks at Daemon404 
[21:20] <Daemon404> michaelni, oic
[21:20] <Daemon404> nice
[21:20] <Daemon404> i do make quite heavy use of ffmpeg.org's doxy
[21:20] <Daemon404> ubitux, indeed
[21:22] <Daemon404> hmm
[21:22] <Daemon404> what is this sox resample support?
[21:23] <Daemon404> i.e. why is it needed
[21:38] <michaelni> Daemon404, its not needed, it just gives users more choice, like xvid support gives them more choice in the mpeg4 encoder
[21:39] <Daemon404> well xvid had a real valid benefit
[21:39] <Daemon404> of being far easier to get non-horrible quality out of
[21:39] <cone-242> ffmpeg.git 03Michael Niedermayer 07master:55b243cade72: doc/examples/resampling_audio.c: fix path
[21:47] <ubitux> ok now, i need to figure out the range of clipping for the strength in gradfun&
[21:52] <cbsrobot> anybody with an ubuntu here ?
[22:05] <saste> ubitux: http://git.videolan.org/?p=ffmpeg.git => points to a summary
[22:05] <saste> i want a log
[22:07] <ubitux> it's said to be about browsing, why not a=tree?
[22:08] <ubitux> also i'm not so fond of having such URL
[22:08] <ubitux> since this will end up in manuals
[22:08] <ubitux> and might last very long in distro
[22:08] <ubitux> while videolan might decide from one day to another to switch to something else for viewing
[22:09] <ubitux> and thus break these urls
[22:09] <ubitux> pointing on source.ffmpeg.org (or something similar) is safer since we can redirect to any videolan url/listing/...
[22:17] <saste> ubitux, yes this is a valid argument, i'll change it
[00:00] --- Mon Dec 17 2012