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

[burek]

[00:00] <saste> durandal_1707, ffmpeg -help full
[00:01] <durandal_1707> that output is to big
[00:02] <saste> why ffmpeg -h full is not documented?
[00:02] <durandal_1707> so what exact flags are missing?
[00:03] <saste> the ones marked in my patch
[00:04] <durandal_1707> ahh yes, there was even one in sws, which could not be even possible to set...
[00:05] <durandal_1707> ffmpeg should warn if such option is found
[00:14] <durandal_1707> saste: truncated is D|V
[00:14] <durandal_1707> or V|D
[00:15] <durandal_1707> input_preserved is V|E
[00:15] <durandal_1707> but it is not documented what it does... michaelni ???
[00:15] <saste> durandal_1707, I also wonder what they are useful for
[00:21] <cone-282> ffmpeg.git 03Vignesh Venkatasubramanian 07master:bcac6b438e67: lavf/oggopus: Fixing a log message
[00:35] <saste> boring doc patches...
[00:44] <cone-282> ffmpeg.git 03Carl Eugen Hoyos 07master:5c2be81b39ce: Do not suggest to increase probesize for image2 files.
[00:44] <cone-282> ffmpeg.git 03Michael Niedermayer 07master:7dea2eab7e3b: Merge remote-tracking branch 'cehoyos/master'
[00:44] <llogan> anyone want a 12" PowerBook G4 PPC laptop for development or fate?
[02:21] <Compn> llogan : ask on list
[02:21] <Compn> only 151 comments on 2686? psh
[02:39] <cone-282> ffmpeg.git 03Michael Niedermayer 07master:7129935ed298: avcodec/mjpegdec: Fix ljpeg RCT
[09:51] <ubitux> joolz is in berzerk mode
[10:48] <ubitux> durandal_1707: so, when is *bsd going to write a valgrind-like tool?
[10:50] Action: durandal_1707 is busy
[10:51] <durandal_1707> michaelni: so does it make sense to always initialize padding of extradata allocation?
[10:54] <cone-251> ffmpeg.git 03Vittorio Giovara 07master:187105ff8a02: Fix references to deleted avcodec_encode_video() function
[10:54] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:ff4548f223fc: Merge commit '187105ff8a02bafc9c58d9d8363bb3f55a415635'
[10:54] <cone-251> ffmpeg.git 03Martin Storsjö 07master:ede42109e73a: x86: Add an xmm clobbering wrapper for avcodec_encode_video2
[10:55] <durandal_1707> ubitux: it only shows bunch of false leaks and nothing about invalid writes/reads here
[11:17] <cone-251> ffmpeg.git 03Luca Barbato 07master:3feb3d6ce4be: mem: Introduce av_reallocp
[11:17] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:c74c3fb1420b: Merge commit '3feb3d6ce4be0a09a9f8f13d613bed25b523b6e7'
[11:19] <michaelni> durandal_1707, always zeroing padding cant hurt if its easy & simple to do
[11:19] <durandal_1707> hmm there are some invalid reads from vf_scale, line 247
[11:23] <cone-251> ffmpeg.git 03Luca Barbato 07master:97d35fa89f73: rtmp: Factor out publish specific code
[11:23] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:0483cfe8ca94: Merge commit '97d35fa89f73468d64f663bfc0686aa6cddd8b6a'
[11:28] <cone-251> ffmpeg.git 03Luca Barbato 07master:ffb7669e4734: rtmp: Support play method in listen mode
[11:28] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:953a4191b812: Merge commit 'ffb7669e47343ac0caa866361965fdb2bf6ed825'
[11:34] <cone-251> ffmpeg.git 03Luca Barbato 07master:666ed7eda1d5: rtmp: Drop an unneeded warning
[11:34] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:c9eb2ce08532: Merge commit '666ed7eda1d568638689ac7b0cef0a9e564ffbdf'
[11:40] <cone-251> ffmpeg.git 03Luca Barbato 07master:fe0337e89bbb: rtmp: Do not send the first field twice within the handshake
[11:40] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:9589b6190494: Merge commit 'fe0337e89bbbe84b7274fbb0d9d56ed992937931'
[11:44] <cone-251> ffmpeg.git 03Luca Barbato 07master:92ed83e393d2: rtmp: Store all the notify messages
[11:44] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:a275ff7e010a: Merge commit '92ed83e393d25b6d15920e90d56ee77de54a9728'
[11:49] <cone-251> ffmpeg.git 03Luca Barbato 07master:0a9425d7cfdf: flv: Do not export datastream as metadata
[11:49] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:22f79a2d605f: Merge commit '0a9425d7cfdf0113c3d32096c9406823efe0cd0a'
[12:08] <saste> ubitux: do you want to have a look at my ffprobe patches?
[12:08] <ubitux> -ss and log level?
[12:11] <saste> ubitux, yes
[12:12] <ubitux> saste: i'll have a look in about 1h or 2
[12:12] <ubitux> if i don't, nag me
[12:13] <ubitux> saste: what about fixing the examples? ;)
[12:13] <saste> ubitux, thanks
[12:14] <cone-251> ffmpeg.git 03Luca Barbato 07master:596e5d4783ca: lavf: Add a flag to enable/disable per-packet flushing
[12:14] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:96e6447d6233: Merge commit '596e5d4783ca951258a7c580951fd161f1785ec1'
[12:15] <ubitux> michaelni: from BBB "I've fixed some final bugs in the decoder (minor off-by-ones etc.) so it passes all fate tests under valgrind now."
[12:15] <ubitux> michaelni: he has no IRC/git right now
[12:15] <ubitux> anyway, vp9 should be soon ready, in case you're interested
[12:21] <cone-251> ffmpeg.git 03Clément BSsch 07master:73084391588b: lavf: Don't explicitly flush after each written packet in muxers
[12:21] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:7b836487a924: Merge commit '73084391588b0f150737990038829cac5013dd68'
[12:23] <saste> http://sourceforge.net/projects/ffprobe/
[12:23] <durandal_1707> ?
[12:23] <saste> ^^ wtf people are still downloading that old version
[12:24] <durandal_1707> who/when?
[12:24] <ubitux> :D
[12:24] <saste> check the stats, 24 downloads in the last week
[12:24] <ubitux>  24 Downloads (This Week)
[12:24] <ubitux> Last Update: 2013-04-25
[12:24] <ubitux> last update 2013? wth?
[12:25] <michaelni> "very good project Posted 03/20/2013 " :)
[12:25] <saste> uh, maybe I put some remarks in the docs discouraging users to use it
[12:25] <ubitux> "
[12:25] <ubitux> Awesome!! The best awaiting release ever. "
[12:25] <durandal_1707> into docs that nobody reads
[12:25] <ubitux>  Posted 02/09/2013 
[12:26] <durandal_1707> jusk ask to point it to ffmpeg
[12:26] <ubitux> saste: commit something with an error message
[12:27] <ubitux> (delete the project?)
[12:27] <saste> ubitux, probably they are sourceforge bots, meant to simulate users interest
[12:27] <ubitux> haha
[12:27] <cone-251> ffmpeg.git 03Martin Storsjö 07master:1daea5232fc9: x86: Add an xmm clobbering wrapper for avcodec_encode_video2
[12:27] <saste> yeah i should probably just kill it, or replace the code with a README -> DON'T USE ME
[12:27] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:8947de17f9e7: Merge commit '1daea5232fc9963ba93b1b6d07a2373f87c9b392'
[12:32] <durandal_1707> so how can delete such project?
[12:32] <durandal_1707> who is owner of it?
[12:33] <cone-251> ffmpeg.git 03Stefano Sabatini 07master:4149981b376d: doc/fftools-common-opts: document -help long and full output
[12:35] <saste> durandal_1707, i'm the owner
[12:35] <durandal_1707> then what are you waiting for?
[12:40] <ubitux> nevcairiel: "strictly speaking that's a bug. In practise, up to 6 it doesn't matter, only xmm6 and up are callee save on win64."
[12:40] <ubitux> (from Ronald, about xmm* reg count mismatch)
[12:51] <cone-251> ffmpeg.git 03Alexandra Khirnova 07master:68b467742092: lavf: Make probe_codec return an error code
[12:51] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:3f760214b44b: Merge commit '68b467742092364f9306283f40effde2c12efe08'
[12:57] <cone-251> ffmpeg.git 03Josh Allmann 07master:120af23cd5fc: rtmp: Send video on a separate channel.
[12:57] <nevcairiel> ubitux: ah, then i had it almost right :)
[12:57] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:c71541d42a59: Merge commit '120af23cd5fcfc539d9575d17d403247ab17109b'
[13:02] <cone-251> ffmpeg.git 03Josh Allmann 07master:d4aef9978091: rtmp: Follow Flash player numbering for channels.
[13:02] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:208f9dd2ef06: Merge commit 'd4aef997809167832ecc64e89dda8cb445e5fe10'
[13:08] <cone-251> ffmpeg.git 03Josh Allmann 07master:f8d1bb6723a6: rtmp: rename main_channel_id to stream_id.
[13:08] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:01b4689d2032: Merge remote-tracking branch 'qatar/master'
[13:15] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:e960b3e27e60: avformat/utils: Print warning if reallocating probe buffer failed
[13:35] <durandal_1707> if i'm not going to have more comments for pullup i will push it
[13:59] <durandal_1707> can i get help at converting inline assembly?
[14:07] <saste> how can i test pullup? Do I need a special file or can I generate it?
[14:08] <durandal_1707> you need telecined material
[14:08] <durandal_1707> or use telecine filter
[14:18] <durandal_1707> the inline asm args are just swapped or?
[14:50] <j-b> lol. someone still cares about HDS?
[14:55] <durandal_1707> huh mmx code in pullup for comb is buggy
[15:00] <durandal_1707> correction it is not comb but var
[15:01] <durandal_1707> could someone take look at it?
[15:05] <durandal_1707> actually it is not, it appears to be same as C code (i'm not asm expert)
[15:05] <durandal_1707> b is pointlessly increased
[15:05] <durandal_1707> what whoever did this smoked?
[15:06] <saste> btw we have a lot of filters from felker, anyone ever asked him if he wants to relicense the ported code?
[15:06] <saste> i sent him a few mails, never replied
[15:07] <saste> i'm told he's sometimes around the mplayer dev channel
[15:07] <ubitux> yes, "dalias"
[15:07] <ubitux> he's on #mplayerdev
[15:08] <saste> now?
[15:08] <ubitux> and probably the musl irc channel if there is any
[15:08] <ubitux> yes
[15:08] <saste> did anyone ever ask him?
[15:08] <ubitux> no idea
[15:08] <saste> not that I care about relicensing those filters, but ...
[15:08] <ubitux> no one talk on #mplayerdev
[15:08] Action: durandal_1707 now everyone joins #mplayerdev
[15:09] <ubitux> it's a zombie channel
[15:09] <ubitux> a lot of ppl, no one ever talk
[15:09] <durandal_1707> for more than year?
[15:09] <saste> they just stare each other
[15:11] <saste> i asked him with a pm
[15:13] <saste> durandal_1707, would it make sense to use dsputils for pullup?
[15:13] <Daemon404> ... isnt dsputils internal to lavc
[15:13] <Daemon404> aka ff_
[15:13] <durandal_1707> saste: you found function that can be reused?
[15:13] <saste> Daemon404, who cares, we already use it in lavfi
[15:13] <cone-251> ffmpeg.git 03Martin Storsjö 07master:1115689d54ea: svq3: Check for any negative return value from ff_h264_check_intra_pred_mode
[15:14] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:a64b99503b96: Merge commit '1115689d54ea95a084421f5a182b8dc56cbff978'
[15:14] <Daemon404> saste, ... n
[15:14] <Daemon404> no
[15:14] <Daemon404> thats a terrible idea
[15:14] <Daemon404> and terrible rationale
[15:14] <saste> durandal_1707, eheh
[15:14] <Daemon404> the point is to *reduce* internal cannibalization
[15:14] <saste> Daemon404, see for example mpdecimate
[15:14] <Daemon404> just because it is happengn currently doesnt mean you should add more
[15:14] <saste> note that the big plan was to move dsputils to a more shareable context (lavc -> lavu)
[15:15] <Daemon404> im of the opinion mpdecimat shouldnt exist btw
[15:15] <ubitux> Daemon404: why is that a bad idea?
[15:15] <Daemon404> ubitux, multiple reasons
[15:15] <saste> Daemon404, then all poor mplayer users would complain that we didn't port it
[15:15] <Daemon404> dogfooding for example
[15:15] <Daemon404> saste, there are no mplayer users
[15:15] <saste> theoretical complainers, but yet
[15:15] <ubitux> can you state them without trolling?
[15:15] <Daemon404> everyone uses mplayer 2 or mpv
[15:16] <Daemon404> ubitux, its basic design principle
[15:16] <ubitux> we need a dsp utils accessible outside libavcodec
[15:16] <Daemon404> TEHN DO THAT
[15:16] <ubitux> right now it's in libavcodec but it doesn't change the fact that we need to use those optimized functions
[15:16] <Daemon404> dont cannibalize
[15:16] <ubitux> doesn't change anything
[15:16] <Daemon404> ...
[15:17] <Daemon404> i am convince nobody involved in this project understands anything about good practice
[15:17] <Daemon404> convinced
[15:17] <ubitux> technically speaking, whether it's in lavu or lavc the code won't really change for those filters
[15:17] <ubitux> moving that code is not trivial and it should not be blocking development in lavfi
[15:18] <Daemon404> more important to have filters nobody uses than to properly design a lib
[15:18] <Daemon404> i know
[15:18] <ubitux> yes
[15:18] <Daemon404> pullup and mpdecimate... -_-
[15:18] <ubitux> more usage will help defines a good interface
[15:18] <ubitux> -s
[15:19] <ubitux> Daemon404: durandal_1707 is saying pullup has better result that fieldmatch with defaults ;)
[15:19] <Daemon404> then something is terribly wrong
[15:19] <ubitux> and dsputils are used elsewhere
[15:19] <ubitux> like scene detection in select
[15:19] <Daemon404> existence of poor practice does not mean "we should continue it"
[15:19] <Daemon404> thats a strawman argument
[15:19] <ubitux> it's not poor practice
[15:19] <Daemon404> ...
[15:20] <Daemon404> yes, cannibalizing INTERNAL apis betwene lib boundaries
[15:20] <Daemon404> IS
[15:20] <ubitux> it's avpriv'ed
[15:20] <Daemon404> the only reason we even export soem ff_ functions is because of our own carp usage
[15:20] <ubitux> so it's not really internal
[15:20] <Daemon404> dsputils is mostly ff_
[15:20] <ubitux> we're using the avpriv'ed interface
[15:20] <Daemon404> i think the existence of apriv_ at all says enough.
[15:21] <ubitux> anyway, 15:18:20 <@ubitux> more usage will help defines a good interface
[15:21] <ubitux> i believe in this ^
[15:21] <Daemon404> i do not.
[15:21] <ubitux> just like i believe the more filters we have, the more we can see the needs in a potential new api
[15:22] <Daemon404> that only works if:
[15:22] <ubitux> like what parts are redundant, what is generally a pain, etc
[15:22] <Daemon404> a) you provide filters that are good andn ot foudn elsewhere
[15:22] <Daemon404> b) anyone actually uses lavfi
[15:22] <cone-251> ffmpeg.git 03Martin Storsjö 07master:e1f3847f860a: mace: Make sure that the channel count is set to a valid value
[15:22] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:7163bbefa26d: Merge commit 'e1f3847f860a1094a46be4c5f10db8df616c3135'
[15:22] <ubitux> not really
[15:22] <ubitux> that's unrelated
[15:22] <ubitux> (to the point i'm defending)
[15:23] <saste> durandal_1707, i'm not sure there's something really reusable in dsputils
[15:23] <Daemon404> you guys really blow my mind with your bubble sometimes...
[15:23] <Daemon404> sigh
[15:23] <saste> those routines mostly work at the block level (8x8, 16x16 etc)
[15:24] <durandal_1707> and do something else
[15:24] <saste> anyway it was just a random idea
[15:27] <durandal_1707> does anyone know whereabouts of other mplayer developers?
[15:36] <cone-251> ffmpeg.git 03Martin Storsjö 07master:569d18aa9dc9: matroskadec: Verify realaudio codec parameters
[15:36] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:2c8d876dea15: Merge commit '569d18aa9dc989c37bb4d4b968026fe5afa6fff9'
[15:44] <cone-251> ffmpeg.git 03Martin Storsjö 07master:711c97016829: rv34: Check the return value from ff_rv34_decode_init
[15:44] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:b3dfda8a410d: Merge commit '711c970168297683860422e95d6b7e37ee3c8367'
[15:44] <durandal_1707> ubitux: what usally arguments you use with fieldmatch?
[15:45] <ubitux> i don't use it
[15:45] <ubitux> try changing the mode, eventually set the order
[15:46] <ubitux> and maybe full combmatcing, dunno
[15:46] <ubitux> ask Daemon404, he's our filtering expert
[15:48] <wm4_> durandal_1707: which devs
[15:48] <durandal_1707> wm4_: you are one of them?
[15:49] <ubitux> saste: do you think it would make sense to add a "alpha" bit to ffprobe's video stream info?
[15:49] <wm4_> huh
[15:49] <ubitux> saste: (for video stream with a pix format with an alpha layer)
[15:52] <wm4_> <saste> Daemon404, then all poor mplayer users would complain that we didn't port it <- dude, they'll just continue to use mplayer and mencoder
[15:52] <wm4_> mplayer won't even delete their own filters
[15:52] <saste> ubitux, isn't that info implied by the pixel format?
[15:52] <wm4_> even if they're ported to ffmpeg
[15:52] <wm4_> so if you target mplayer users, you get NOTHING in return
[15:52] <wm4_> _especially_ because mplayer's lavfi bridge (most likely) doesn't work
[15:53] <ubitux> saste: how is an external app (!api, think ffprobe parsing) is supposed to do that?
[15:53] <wm4_> and even if you say that you want to allow easy transition for users from mencoder to ffmpeg.c, it's not really your responsibility, is it
[15:54] <saste> ubitux: nit: remove the "Error" from the message; something like "Unable to open codecs"
[15:55] <saste> ^^ why^
[15:55] <saste> ^^ why?
[15:55] <ubitux> because it's not an error anymore? :(
[15:55] <ubitux> "nit"  anyway.
[15:56] <saste> ubitux, ok
[15:56] <cone-251> ffmpeg.git 03Martin Storsjö 07master:19b9659f3174: oggparseogm: Convert to use bytestream2
[15:56] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:a1fb3e512778: Merge commit '19b9659f3174599e8685d329c4330b1ea8c4c6db'
[15:56] <saste> for what regards the alpha bit, that information is not explicitly expressed in pixel desc, but can be inferred from the number of components
[15:57] <saste> this can be done parsing ffprobe -pix_fmts
[15:57] <ubitux> mmh i forgot this... but parsing this output is not reliable
[15:57] <saste> not sure i want to convert that to a parsable output
[15:57] <ubitux> yeah i understand
[15:58] <ubitux> :)
[15:58] <saste> same applies for list of codecs, formats, filters, etc, although it could be done easily
[16:04] <cone-251> ffmpeg.git 03Stefano Sabatini 07master:5d12ec8fb7e6: ffprobe: downgrade log level for non fatal errors in open_input_file()
[16:05] <wm4_> wow libav is going to implement aac-ld
[16:06] <wm4_> one of my first mpv bug reports was/is about the lack of aac ld support
[16:06] <Daemon404> :P
[16:06] <wm4_> mplayer/mplayer2 handled that with libfaad support
[16:07] <Daemon404> are we getting ELD too?
[16:07] <Daemon404> :P
[16:08] <wm4_> whatever that is
[16:09] <Daemon404> LD is only important because certaine apple prodcts did and/or do default to it
[16:09] <Daemon404> for no reason
[16:10] <cone-251> ffmpeg.git 03Martin Storsjö 07master:7f8d41eb097e: mov: Don't use a negative duration for setting other fields
[16:10] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:7f20440b4c17: Merge commit '7f8d41eb097e8d4223c9caf97dd332a2fdb29d52'
[16:11] <nevcairiel> ELD is to LD what HE is to LC
[16:11] <nevcairiel> there is even a ELDv2 to match up :p
[16:16] <ubitux> Daemon404 is going to be very angry in a few seconds
[16:16] <Daemon404> carl is a fuckign idiot
[16:16] <Daemon404> as usual
[16:16] <Daemon404> Nothing New (TM)
[16:17] <wm4_> Daemon404: what mplayer specific hacks are there left?
[16:17] <wm4_> I just want to make sure I'm not using them
[16:17] <Daemon404> libavcodec/utils.c:           avctx->codec_id != AV_CODEC_ID_PNG // For mplayer
[16:18] <durandal_1707> single hack in whole codebase
[16:18] <Daemon404> used to be far more
[16:18] <nevcairiel> not all the hacks are so nice to have a comment
[16:18] <Daemon404> that too
[16:19] <ubitux> Daemon404: do you have a better solution for that hack?
[16:19] <durandal_1707> some are mentioned in git log
[16:19] <ubitux> Daemon404: iirc it's a retro compat hack
[16:19] <ubitux> which means it prevents a regression
[16:19] <ubitux> but i need confirmation
[16:20] <wm4_> mplayer misuses API, mplayer breaks, hack libavcodec instead of fixing mplayer
[16:20] <wm4_> that was what happened in case Daemon404 just mentioned
[16:20] <Daemon404> yes.
[16:21] <Daemon404> also there are more commented in the codebase
[16:21] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2012-December/135569.html
[16:22] <ubitux> this is the reason of the hack, any better to suggest solution?
[16:22] <ubitux> and it's not really a "mplayer hack" except in practice
[16:23] <Daemon404> thats still mplayer misusing the api
[16:23] <Daemon404> and us changing it back to the (undocumented) behaviro
[16:23] <Daemon404> for them.
[16:23] <wm4_> "The advantage of this is that it is possible to encode images with
[16:23] <wm4_> lots of different resolutions without having to open and close
[16:23] <wm4_> the codec all the time, with all the processing overhead and
[16:23] <wm4_> memory fragmentation that causes."
[16:23] <cone-251> ffmpeg.git 03Martin Storsjö 07master:a92538b7c0de: ivi_common: Make sure color planes have been initialized
[16:23] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:8d0b899e38b7: Merge commit 'a92538b7c0defc86c55fb91f55dfa36aad192673'
[16:24] <wm4_> so it was a bad hack to cope with a bad property of the ffmpeg API? (can't change video size during encoding)
[16:24] <Daemon404> wm4_, encoder-specific behavior too
[16:24] <Daemon404> even nicer!
[16:25] <durandal_1707> you cant encode with every encoder that way/ without reinit - you will most likely get crash
[16:25] <Daemon404> thats the point
[16:25] <wm4_> wait what does cehoyos mean by "thieves"
[16:25] <Daemon404> wm4_, libav
[16:25] <nevcairiel> the fork of course
[16:25] <wm4_> seriously
[16:25] <Daemon404> yes
[16:26] <wm4_> I wonder what I'm in his eyes (because I forked a fork of mplayer)
[16:26] <nevcairiel> on the one hand he talks about not cursing on the mailing list, and in the same sentence he does that
[16:26] <nevcairiel> thats him for ya
[16:28] <ubitux> that's a good atmosphere we have today
[16:28] <ubitux> :))
[16:28] <wm4_> that reminds me, I should try to write a vsynth demuxer or so
[16:28] <Daemon404> wm4_, it seems pretty trivial
[16:28] <Compn> wm4 : if you really want to get mplayer/mencoder users, add binary codec loader to ffmpeg :)
[16:29] <wm4_> Daemon404: un-lazy-ing is not trivial though
[16:29] <Daemon404> Compn, so we can bundle WINE code from ancient times forever?
[16:29] <Daemon404> wm4_, tru.dat
[16:29] <Compn> you could use new code, i didnt say use mplayer loader ...
[16:29] <saste> Compn, they asked it at vdd
[16:29] <wm4_> I suspect a binary loader would be pretty simple
[16:29] <Compn> i know :)
[16:29] <saste> to get finally rid of mencoder
[16:29] <wm4_> you just have to write the actual decoder wrapper as separate wine binary
[16:29] <Daemon404> saste, is libwine a thing?
[16:30] <ubitux> Daemon404: google requested that
[16:30] <Daemon404> if so that would be nice to use
[16:30] <wm4_> because you can't link libwine code with native Linux code
[16:30] <Daemon404> ubitux, binary loading is rarely useufl for corps
[16:30] <Daemon404> since it violates many licenses
[16:30] <Compn> Daemon404 : no, srs, youtube uses mencoder binary loader
[16:30] <ubitux> google is above laws
[16:30] <wm4_> the old mplayer wine code though... that is a thing of the devil
[16:30] <Daemon404> ubitux, indeed
[16:30] <wm4_> it's one of the most ridiculously unclean code I've ever seen
[16:30] <wm4_> it's a miracle that it works
[16:31] <ubitux> it does?
[16:31] <Compn> did you rm it yet ?
[16:31] <Daemon404> ubitux, if binary loading were legal i would have just used mplayer+prores binary at vimeo
[16:31] <wm4_> I fully respect (and also hate) the guy who hacked it so hard until it worked
[16:31] <Daemon404> :P
[16:31] <wm4_> Compn: of course
[16:31] <Daemon404> but it violates apple's lice
[16:31] <Daemon404> er lic
[16:31] <Daemon404> (lol lice)
[16:31] <Daemon404> same goes for qtaacenc
[16:31] <Compn> internal use only :P
[16:32] <Compn> qt binary sucks tho
[16:32] <Daemon404> Compn, well we have fdk-aac now
[16:32] <wm4_> Daemon404: there's a chinese mplayer fork (for windows only) which can make use of ffdshow
[16:32] <Daemon404> so its fine
[16:32] <Daemon404> wm4_, WHY DID YOU TELL ME THIS
[16:32] <Daemon404> i will have nightmares
[16:33] <wm4_> just making a point that not all binary/dshow stuff will cause license problems
[16:33] <Daemon404> what is even the point of that?
[16:33] <wm4_> *shrug*
[16:33] <Daemon404> also for a while
[16:33] <Daemon404> using coreavc in mplayer was The Thing To DO
[16:33] <wm4_> maybe cargo culting
[16:33] <nevcairiel> ffdshow is like the mplayer in directshow, it has all the evil hacks
[16:33] <wm4_> "I heard ffdshow is awesome"
[16:34] <Daemon404> nevcairiel, good description
[16:34] <wm4_> nevcairiel: lol, how fitting
[16:34] <nevcairiel> although running it from mplayer is kinda pointless, they have the same kind of hacks
[16:34] <Compn> you know you can chain ffdshow to itself
[16:34] <nevcairiel> of course
[16:34] <Compn> ehe
[16:35] <Daemon404> nevcairiel, the day clsid came otu and said ffdshow is dead
[16:35] <Daemon404> i cried a little
[16:35] <Compn> by windows chinese fork, i assume you are talking about mplayer-ww ?
[16:35] <Daemon404> with joy.
[16:35] <Compn> i heard they were going to destroy all the mplayer hacks from ffdshow-tryouts
[16:35] <wm4_> Compn: yes
[16:35] <nevcairiel> Daemon404: although all the people crying over post-processing still use it
[16:35] <Daemon404> heh
[16:35] <Daemon404> better ad vs support to lav
[16:36] <Daemon404> i personally have never used pp support
[16:36] <Compn> too much cpu to do pp for me as well
[16:36] <Compn> so i never used it
[16:36] <wm4_> nevcairiel: what kind of postprocessing?
[16:36] <nevcairiel> might have been more useful when most video was still like 352x188
[16:36] <Compn> -vf fspp / -vf uspp  / -vf spp probably
[16:36] <cone-251> ffmpeg.git 03Martin Storsjö 07master:f875a732e367: mpeg4videodec: Check the width/height in mpeg4_decode_sprite_trajectory
[16:36] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:028f8c3ecb43: Merge commit 'f875a732e36786d49f3650e3235272891a820600'
[16:36] <Compn> does it even work on 1080 ? 
[16:37] <nevcairiel> wm4_: i dunno, sharpening and debanding seem to be common requests
[16:37] <Daemon404> nevcairiel, that is the reason people want libpsotproc to exist
[16:37] <Daemon404> for divx 3.11 ;-) 
[16:37] <Compn> whats the point, blurray takes all the noise and color corrects
[16:37] <Compn> er removes all of the film noise/grain
[16:37] <Daemon404> nevcairiel, people used gradfun a lot for pp
[16:37] <Daemon404> back in the early x264 days
[16:37] <Daemon404> pre-psy and pre-aq
[16:38] <Compn> doesnt ffmpeg itself havf pp stuff ? cant make a cheap lavfi wrapper for that ?
[16:38] <nevcairiel> i just dont wanna
[16:38] <nevcairiel> i have my principles!
[16:38] <Compn> ah
[16:38] <nevcairiel> the only thing i offer is deinterlacing
[16:38] <Compn> i mean, instead of porting mplayer spp filter
[16:38] <nevcairiel> which is kind of post-processing
[16:39] <Daemon404> spp filter relies on the dct coeffs
[16:39] <Daemon404> doesnt it?
[16:39] <Compn> probably somethin like that
[16:39] <wm4_> Compn: mplayer has half a dozen of *pp filters
[16:39] <wm4_> like vf_pp, vf_spp, ...
[16:39] <Daemon404> pp7
[16:39] <Compn> wm4_ : we can just take pp and rename it a few times :)
[16:39] <wm4_> and somehow all of them "must" be ported to lavfi
[16:39] <Compn> placebo-pp
[16:39] <wm4_> Compn: that would be a decent solution
[16:39] <Daemon404> Compn, avs has that
[16:39] <Daemon404> it's called undot()
[16:39] <wm4_> maybe nobody would notice
[16:40] <Compn> i'm sure like 6 months later someone would do screenshot compare between ffmpeg and mplayer :P
[16:40] <Compn> 'not binary compatable'
[16:44] <wm4_> ubitux: I'm having a strange issue with vobsubs... there's a idx/sub file with about 15 subtitle streams, and out of them, all work, except the last one
[16:44] <ubitux> ah?
[16:44] <ubitux> well, share it
[16:44] <wm4_> ubitux: and that stream contains packets according to ffprobe, but all packets have size=0
[16:44] <wm4_> https://www.dropbox.com/s/7pqzocr8fitp10n/Subs.7z 
[16:45] <wm4_> it works with mplayer's vobsub demuxer
[16:45] <cone-251> ffmpeg.git 03Martin Storsjö 07master:c39f7eba01cd: truemotion2: Use av_freep properly in an error path
[16:45] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:8fc441cee89c: Merge commit 'c39f7eba01cd656e8f0eed592f93d11814736650'
[16:45] <wm4_> the stream has the language code "vi"
[16:45] <Compn> its packed differently ? or 
[16:45] <ubitux> wm4_: i'll have a look
[16:45] <ubitux> thx
[16:47] <wm4_> no, thank you for having a look
[16:54] <cone-251> ffmpeg.git 03Martin Storsjö 07master:ea78a348d86a: eacmv: Make sure a reference frame exists before referencing it
[16:54] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:19769766740b: Merge commit 'ea78a348d86a3a733f6c1e0a65cfdd8283d924b9'
[17:01] <durandal_1707> Compn: i get in 10 years nobody will come with any screenshot
[17:01] <durandal_1707> *bet
[17:01] <durandal_1707> seriously what pp* left in lavfi are relevant?
[17:02] <Daemon404> i would argue none
[17:02] <Daemon404> but peopl would disagree
[17:02] <wm4_> unported are pp7, fspp, uspp
[17:03] <wm4_> uspp is described as "ultra simple/slow postprocess"
[17:03] <wm4_> huh
[17:03] <nevcairiel> arent those two s words usually on the opposite :p
[17:03] <Daemon404> no
[17:03] <Daemon404> naive algorithms are often slow
[17:03] <Daemon404> :)
[17:05] <Daemon404> ... lul looking to see if WINE had a punlic api
[17:05] <Daemon404> found https://api.wine.com
[17:05] <cone-251> ffmpeg.git 03Martin Storsjö 07master:b1db33159fdc: ffv1: Make sure at least one slice context is initialized
[17:05] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:102a1d9239fc: Merge commit 'b1db33159fdc2da4bdd8c75e4ff9a7dd0ef2f0c2'
[17:06] <durandal_1707> i will not allow any wine wrapper in ffmpeg
[17:06] <Daemon404> durandal_1707, i wouldnt want it
[17:06] <Daemon404> i was just curious
[17:08] <Compn> It's not our responsibility to account for other projects'
[17:08] <Compn> terrible hacky usage.
[17:08] <Compn> awwwwww
[17:08] <Compn> you know xbmc learned a lot from mplayer :)
[17:09] <Daemon404> is that kind of like a serial killer teaching his student?
[17:09] <nevcairiel> its worse, because its not illegal
[17:09] <Daemon404> ou heard it here folks
[17:09] <Daemon404> mplayer is worse than a serial killer
[17:09] <Compn> guys should start your own #mplayerbashing channel
[17:10] <wm4_> Compn: how so? xbmc is in OOP C++ for starters
[17:10] <Compn> wm4 : i mean , hacking their own dvd menu player , using mplayer on some os but not all of their ports
[17:11] <Daemon404> Compn, why? all the devs are here =p
[17:11] <nevcairiel> is mplayer actually still actively being developed? or just patched up for ffmpeg changes?
[17:12] <Daemon404> nevcairiel, why they removed their bundled mp3 lib (which was used for liek a pentium 2) just a few months ago!
[17:12] <Daemon404> progress~
[17:13] <Compn> hey
[17:13] <Compn> dont knock that
[17:13] <Compn> the mpg123 dev had to spend months to figure out why that lib was slower than our mp3lib :P
[17:13] <Compn> well, it helped that only diego had the last k3 cpu left :P
[17:14] <Compn> so mplayer's thing worked
[17:14] <Daemon404> Compn, he's sitll trying to keep 3dnow code around afaik :P
[17:14] <Daemon404> that cpu is still aliv
[17:14] <Daemon404> e
[17:14] <Daemon404> somehow
[17:14] <Compn> mplayer forked it because it was dead. someone came along and revived mpg123, then backported our faster hacks, now we can remove internal copy-fork
[17:15] <durandal_1707> i ported inline asm to yasm
[17:15] <Daemon404> durandal_1707, for what?
[17:15] <Daemon404> also +1
[17:15] <durandal_1707> pullup
[17:16] <Daemon404> o
[17:16] <Daemon404> ok
[17:16] <saste> flamefest, we were missing them since a few months
[17:17] <saste> now someone should mention hitler
[17:17] <wm4_> you just did
[17:17] <saste> that usually follows "weeds"
[17:17] <Daemon404> saste, much of the douchiness is actually from carl
[17:17] <durandal_1707> wm4_: no continue the list
[17:17] <durandal_1707> *now
[17:18] <cone-251> ffmpeg.git 03Luca Barbato 07master:c38854c39929: doc: Add missing hashes and dates to APIChanges
[17:18] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:09887096734e: Merge remote-tracking branch 'qatar/master'
[17:19] <durandal_1707> now just to write sse4 and avx variants and rule
[17:19] <Daemon404> im pretty impressed so many people are opposed to removing a shitty hack btw
[17:20] <durandal_1707> does XBMC still use that?
[17:21] <ubitux> it's the difference between trying to understand why the hack is here in the first place, and wanting to remove a hack for the sake of "purity of code" or similar shit
[17:21] <Daemon404> .................................
[17:21] <Daemon404> "No, I don't think "grep" is a tool you should 
[17:21] <Daemon404> use in your condition, it makes you look like 
[17:21] <Daemon404> a fool.
[17:21] <Daemon404> "
[17:21] <Daemon404> is carl like
[17:21] <Daemon404> functionally retarded?
[17:21] <durandal_1707> can't they just have hack in own repo, like they actually do for other stuff....
[17:22] <durandal_1707> isn't that ad hominem attack...
[17:22] <ubitux> Daemon404: he means that grepping mplayer randomly won't help you prove a point; for a bunch of those commits, it's likely they are problems revealed by mplayer
[17:23] <Daemon404> many are not
[17:23] <ubitux> not problems because mplayer misuse the api
[17:23] <Daemon404> durandal_1707, carl attacked me in 3-4 of those emails
[17:23] <Daemon404> im used to it
[17:23] <nevcairiel> anyone with at least half an understanding of the code will be able to tell if its a hack or a bug
[17:24] <Daemon404> he's also completely missing the point
[17:24] <Daemon404> and just demanding more examples
[17:24] <Daemon404> and attacking me
[17:24] Action: Daemon404 shrug
[17:24] <wm4_> it's fun when 2 line patches end up in flame wars
[17:25] <Daemon404> i really, really do not like carl
[17:25] <nevcairiel> and people wonder why i dont submit my custom patches =P
[17:25] <saste> ubitux, do you mean avformat_seek_file?
[17:25] <Daemon404> almst all his patches are hacks, he harps on others with his call-center like scripted response and yet doesn't follow his own damn rules
[17:25] <ubitux> saste: yes
[17:25] <wm4_> Daemon404: haha
[17:25] <Daemon404> mutliple people have tol me they purpose do nto report bugs to ffmpeg
[17:26] <Daemon404> beacause of carl
[17:26] <Daemon404> true story.
[17:26] <wm4_> me too
[17:26] <ubitux> <@Daemon404> durandal_1707, carl attacked me in 3-4 of those emails // i'm not sure you realize how aggressive you are actually...
[17:26] <wm4_> though I respect the amount of bug reports he's handling
[17:26] <Daemon404> ubitux, i know i am
[17:26] <Daemon404> i dont accuse people of being on drugs or call them a fool
[17:26] <Daemon404> etc
[17:26] <nevcairiel> its funny when he slaps someone for not posting a git format-patch thing, and an hour later posts his own  simple diff -u :p
[17:26] <Daemon404> nevcairiel, yes
[17:26] <Daemon404> i clled him out before
[17:26] <Daemon404> he ignored it
[17:26] <durandal_1707> you are all runners when not reporting bugs
[17:27] <Daemon404> durandal_1707, people cant be arsed to deal with carl on teh bug tracker
[17:27] <Daemon404> they dislike him that much
[17:27] <nevcairiel> when i find a bug i care about, i  usually just fix it myself
[17:27] <nevcairiel> or tell the user to report it to ffmpeg :D
[17:28] <durandal_1707> than i need to search at forums for bug reports ........
[17:28] <Daemon404> !!!
[17:28] <Daemon404> the aac bug is active again
[17:28] <Daemon404> epic bug continues
[17:29] <nevcairiel> carl went in there earlier and went totally OT on it
[17:29] <Daemon404> .. shocking.
[17:30] <durandal_1707> e32bbd411242658717b0dd637dd85d is really ugly,stupid,bad, etc hack
[17:31] <wm4_> lol
[17:32] <wm4_> this reflects some of mplayer's internal terribleness
[17:32] <nevcairiel> wtf
[17:32] <nevcairiel> i dont even
[17:36] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:aec91de54961: swscale/utils: Allow sws_setColorspaceDetails() to use the tables from sws_getColorspaceDetails()
[17:40] <Daemon404> lol nice
[17:40] Action: durandal_1707 wonders for how long will libav delay lxf patches
[17:52] <durandal_1707> should i push pullup with/out inline assembly?
[17:54] <Daemon404> durandal_1707, if you have converted it, i'd push without, and then push the yasm after
[17:54] <Daemon404> but really, as long as it gets replaced with yasm, either is ok
[17:57] <saste> durandal_1707, better to split it, so you separate port from new additions
[17:58] <Daemon404> the inline asm is from the port, no?
[18:01] <durandal_1707> i can make inline asm not be in port
[18:01] <durandal_1707> only yasm
[18:03] <saste> durandal_1707, anyway as I see it, you do the work, you have the last word, but i'd keep the port as close as possible to the original code (and do more changes in separate commits)
[18:07] <durandal_1707> conversion from inline is bitexact
[18:10] <durandal_1707> what is non-simd instruction for shifting?
[18:12] <nevcairiel> shr is logical shift
[18:12] <nevcairiel> sar arithmetic
[18:12] <nevcairiel> shr/shl etc
[18:13] <cone-251> ffmpeg.git 03Derek Buitenhuis 07master:fcb069af8ff3: lavc: Don't export ff_vdpau_vc1_decode_picture
[18:13] Action: wm4_ awaits the drama
[18:15] <Daemon404> wm4_, for what?
[18:16] <wm4_> for pushing this
[18:16] <wm4_> wasn't cehoyos against it?
[18:16] <Daemon404> he OK'd it
[18:16] <Daemon404> sicne XMBC doesnt need it now
[18:16] <nevcairiel> there have been $discussions
[18:17] <nevcairiel> but how do you know nothing else copied from xbmc and still needs it!?!?
[18:17] <Daemon404> lol
[18:20] <durandal_1707> 64bit doesn't have mmx but just mmxext?
[18:22] <nevcairiel> 64bit has mmx
[18:23] <nevcairiel> but its usually not used because mmx code can so easily be translated to sse2
[18:23] <durandal_1707> like?
[18:26] <durandal_1707> you can remove entries from .v files only shortly  after major bump
[18:27] <Daemon404> that symbol was never considered part of the API
[18:27] <Daemon404> it was also never added after a dump
[18:28] <Daemon404> im sure all 0 people who use it will miss it...
[18:29] <Daemon404> if you think it's a big issue, revert it
[19:03] <cone-251> ffmpeg.git 03Paul B Mahol 07master:9c774459a958: avfilter: port pullup filter from libmpcodecs
[19:06] <saste> durandal_1707, you gonna kill mp=pullup?
[19:07] <saste> also we have a related pullup ticket, it can be probably closed now
[19:10] <michaelni> /home/fate/src/ffmpeg/libavfilter/x86/vf_pullup.asm:60: error: invalid size for operand 1
[19:11] <michaelni> http://fate.ffmpeg.org/report.cgi?time=20130917170739&slot=x86_64-athlon64-gentoo-gcc
[19:14] <durandal_1707> i guess i just needs s/r4/r4q/ ?
[19:18] <durandal_1707> so anybody on x64 can try and confirm?
[19:20] <durandal_1707> or r4d ?
[19:22] <cone-251> ffmpeg.git 03Paul B Mahol 07master:112017e9908b: avfilter/x86/vf_pullup: try to fix build on x64
[19:43] <cone-251> ffmpeg.git 03Chih-Wei Huang 07master:985920433cdb: avformat/asfenc: fix a build error
[20:11] <durandal_1707> saste: i can remove mp=pullup, unless there is reason not to
[20:12] <saste> durandal_1707, I have no reasons for keeping it
[20:22] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:7703d19c4022: lavf/options_table: improve option help text
[20:31] <cone-251> ffmpeg.git 03Paul B Mahol 07master:78f680cb3664: avformat/smacker: use av_malloc_array() and check for allocation error
[20:32] <durandal_1707> oh, i used avformat
[20:33] <durandal_1707> Daemon404: what filters in lavfi(if any) you use?
[20:52] <ubitux> i have someone ready to work on a new version of the website
[20:52] <ubitux> anyone has any objection?
[20:52] <durandal_1707> elaborate 'new version'
[20:53] <durandal_1707> with javascript and bouncing flash and java?
[20:54] <ubitux> maybe some javascript, but it will be optionnal
[20:55] <ubitux> any general requests?
[20:56] <durandal_1707> ugh, why javascript?
[20:56] <ubitux> i asked for a better way of dealing with the menu (being able to extend it without exploding the current layout like currently)
[20:56] <ubitux> durandal_1707: it can be made full css
[20:57] <durandal_1707> i prefer non-javascript as i use elinks mostly
[20:57] <ubitux> ok
[21:01] <saste> durandal_1707, why not removing only pullup?
[21:02] <saste> also we still miss native eq filters, amongst the others
[21:04] <durandal_1707> its only adding gamma & contrast to hue file and adding another filter, and renaming vf_hue to vf_eq or similar
[21:05] <durandal_1707> also I wanted to see how the patch removing libmpcodecs looks like
[21:05] <saste> durandal_1707, big
[21:07] <durandal_1707> nothing compared to e4852fb38df0c3a43e19b5a74c44f8ea57e98951
[21:08] <durandal_1707> and the biggest filter is fspp, wtf?
[21:09] <durandal_1707> ah, file is full of nicely formated inline asm
[21:09] <saste> durandal_1707, why don't you start by removing pullup?
[21:10] <durandal_1707> eh, in small steps?
[21:10] <saste> no, what i mean is that mp=pullup removal should not be controversial
[21:11] <saste> and we have people claiming that some remaining mp pp filters are still useful
[21:11] <durandal_1707> *pp filters should be part of postproc
[21:11] <ubitux> durandal_1707: fspp is a copy from spp with tweaking
[21:12] <ubitux> so you should probably just copy spp and apply the diff
[21:12] <durandal_1707> i do not want to touch pp stuf
[21:19] <michaelni>  some of the *pp filters require idct, dct, wavelets, ... none of this is available in libpostproc
[21:20] <ubitux> durandal_1707: qp might be useful, fssp/pp7/uspp  some ppl wanted it
[21:20] <durandal_1707> saste: i can remove mp=pullup right now
[21:22] <cone-251> ffmpeg.git 03Lenny Wang 07master:29664fab0c22: OpenCL: convert meaningless "device id" output to "device name"
[21:33] <GoaLitiuM> does any native aac encoder developers visit/idle here? or do they have a channel of their own?
[21:34] <nevcairiel> i'm not aware that he is on irc at all
[21:37] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:9d052adbebf0: swscale/utils: Simplify scaler name printing code
[21:37] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:a446657d8cc2: swscale/utils: simplify cpu caps printing code
[21:50] <durandal_1707> please comment on [PATCH]  Make decoding alpha option for some codecs. and ignore fsckng libmpcodecs patch
[22:01] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:2d28950da9b2: swscale/utils: remove redundant NULL checks before sws_freeVec()
[23:27] <cone-251> ffmpeg.git 03mrlika 07master:ed72542539fb: lavd/v4l2: do not fail when VIDIOC_ENUMSTD returns EINVAL without a valid match
[00:00] --- Wed Sep 18 2013