[00:00] <ubitux> J_Darnley: i wanted to avoid building it at all [00:00] <ubitux> at least on the embedded device [00:01] <J_Darnley> Yeah. I don't know how or if it handles a separate "machine" [00:02] <BBB> I thought it did, that is, you'd basically assign the build host to be the fate instance [00:02] <BBB> and have a fate run prefix (similar to valgrind) to "export" the run to the actual device [00:04] <ubitux> ah so you'd run from the host [00:06] <BBB> right, kinda like adb [00:06] <BBB> (assuming you've used that) [00:07] <BBB> in fact I believe I've been able to "run" fate using adb [00:07] <BBB> it's not pleasant, I mean, it's really quite terrible because dab doesn't understand stderr/out are different [00:07] <BBB> but other than that it's quite ncie [00:07] <BBB> dab=adb [00:14] <ubitux> i guess i'll consider something along those lines next time then [03:02] <cone-356> ffmpeg.git 03Vittorio Giovara 07master:53c20f17c78d: vp8: K&R formatting cosmetics [03:02] <cone-356> ffmpeg.git 03Michael Niedermayer 07master:ae3313e15486: Merge commit '53c20f17c78d1d8a0fc2505868f201e69ff59cc5' [03:23] <cone-356> ffmpeg.git 03Martin Storsjö 07master:508a84e6726a: golomb: Fix the implementation of get_se_golomb_long [03:23] <cone-356> ffmpeg.git 03Michael Niedermayer 07master:30e159366e8b: Merge remote-tracking branch 'qatar/master' [03:30] <cone-356> ffmpeg.git 03Michael Niedermayer 07master:c01ddf845dcb: avformat/replaygain: remove unused variable [06:32] <cone-462> ffmpeg.git 03Peter Ross 07master:73a2d16bfab5: avformat/wtvdec: demux mpeg2 extradata [06:32] <cone-462> ffmpeg.git 03Peter Ross 07master:31ac3f306c45: avformat/wtvenc: pad judiciously when writing mpeg2 extradata [10:17] <ubitux> lol koda trolling on ffmpeg-devel [10:22] <ubitux> should i reply to the last one? [10:30] <wm4> I suggest fighting with lethal weapons [10:32] <ubitux> well i guess his point is just generate drama so i'll ignore unless directed to me [10:32] <wm4> haha ffmpeg as libav downstream [10:32] <wm4> ok that's pretty trollish [10:36] <ubitux> i want to reply :( [10:36] <ubitux> so much nonsense :( [10:37] <wm4> I'm replying [10:38] <wm4> but I won't hesitate to shift some blame on ffmpeg too [10:55] <ubitux> :) [10:56] <ubitux> i couldn't resist :( [11:24] <j-b> wm4: nice trolling though, but a bit inaccurate, if I may say [11:24] <j-b> I find Nicolas mail way more truthful [11:25] <wm4> j-b: what was inaccurate [11:26] <wm4> and is everything trolling now [11:27] <j-b> wm4: first, whether you like it or not, FFmpeg is a downstream of libav. What you are right about this, is that it does not matter, since with merges, downstream and upstream are quite complex notions. [11:27] <ubitux> > game of words [11:28] <wm4> it's a downstream only in a very technical sense of the word I can't really take that seriously [11:28] <j-b> wm4: then, it was not only that they did not like "MiNi", it's that he refused to apply to himself the rules that the rest of the project had to follow. [11:29] <j-b> wm4: sorry, but with the complete merges of qatar/master, this is exactly what is called a downstream. Not to mention the remark of Nicolas on ABI/API. [11:31] <j-b> wm4: what I don't get is why does being a downstream matter. [11:31] <ubitux> making a point [11:31] <wm4> obviously the downstream should follow the upstream is proper behavior [11:31] <ubitux> ...on which is the most important project, the source of all the truth [11:32] <j-b> on that, noone cares [11:32] <ubitux> exactly [11:32] <ubitux> :D [11:32] <j-b> Both projects are mismanaged and a piece of pain for everyone [11:32] <ubitux> also called a pop~ [11:32] <j-b> FFmpeg was a pain for years and everyone was complaining about it [11:32] <j-b> So, the right thing was to make it worse [11:33] <j-b> by having 2 forks [11:33] <wm4> lol [11:33] <wm4> so, was forking the better or worse thing that could happen? [11:34] <j-b> probably the worse [11:34] <wm4> isn't it fun [11:34] <j-b> not really, no. [11:34] <ubitux> a real fork would have been almost fine [11:34] <ubitux> main problem is that it was forked without renaming libs [11:35] <wm4> yes [11:35] <j-b> Well, sorry to say so, but with a proper fork, you wouldn't have lived. [11:35] <ubitux> that's one of the main problem for downstreams currently [11:36] <wm4> j-b: so what do we do? [11:36] <j-b> wm4: nothing :) [11:36] <j-b> wm4: keep going like you did [11:36] <wm4> telling both projects how retarded they are is probably not very helpful [11:36] <j-b> not really [11:37] <j-b> Someday, enough downstream will be pissed [11:37] <j-b> and a third fork will emerge [11:37] <wm4> and then history will repeat? [11:37] <j-b> no, and it will get out [11:37] <j-b> because it will be less insane [11:37] <ubitux> that fork will merge the merges of ffmpeg? [11:37] <wm4> but yes, a third fork hopefully absorbing both forks would be a solution [11:38] <wm4> it would need a project leader with enough skills in, er, project leading [11:38] <nevcairiel> like thats ever going to work [11:38] <j-b> ubitux: the libavcodec ones? probably. the libavfilter ones? probably not [11:38] <wm4> and making people play well together [11:38] <ubitux> j-b: vlc is not the only ffmpeg user you know& [11:38] <j-b> ubitux: I know [11:38] <j-b> ubitux: but I discuss with a lot of FFmpeg users [11:39] <ubitux> we have a lot of lavfi users [11:39] <j-b> yes [11:39] <j-b> and maybe one day, you will split correctly your repository [11:39] <ubitux> what for? [11:39] <j-b> instead of adding more mess in the same... [11:40] <j-b> I will stop arguging with you on that, because, it's impossible to discuss with you. [11:40] <j-b> and I don't want to be banned from here. [11:40] <wm4> when will vlc split its modules into separate repos? [11:40] <ubitux> i'm not arguying, nor i planed to ban anyone [11:41] <ubitux> i'm just wondering what issue you're trying to fix by splitting our libs in different repository [11:41] <j-b> wm4: totally different. the libvlccore API is not meant to be used outside. [11:41] <ubitux> ...while a lot of our users would actually have a single library [11:42] <j-b> wm4: yet, vlc, vlc/android, vlc/ios, vlc/winrt, vlc/webplugins and other are already split [11:42] <j-b> ubitux: a single library? what library? [11:42] <ubitux> libffmpeg or something [11:42] <j-b> sure, but it does not exist [11:42] <ubitux> a few people suggested that several times [11:42] <j-b> yep, I really see people using that [11:42] <ubitux> yeah but splitting libs wouldn't be a step in that direction [11:43] <j-b> how so? [11:43] <ubitux> because they will probably be more in desync [11:43] <wm4> because libavfilter would be separate from libffmpeg [11:43] <j-b> wm4: not at all. [11:43] <wm4> but yeah, maybe libavfilter is the one thing that could actually be split off [11:44] <wm4> OTOH, ffmpeg.c and ffplayer.c depend on it [11:44] <j-b> ubitux: and that might force you to ACTUALLY eat your own dog shit [11:44] <ubitux> :) [11:44] <j-b> ubitux: and care a BIT about versionning [11:44] <ubitux> we do [11:44] <j-b> Bullshit [11:44] <ubitux> prove it [11:45] <ubitux> (and not the vdpau thing, that's related to library names between the forks) [11:45] <j-b> http://upstream-tracker.org/versions/ffmpeg.html [11:46] <j-b> so, yes, you should split libavcodec+libavformat(+libavutil) from the rest. [11:46] <j-b> including tools [11:46] <ubitux> j-b: not sure how to interpret that; also, aren't most of those abi/api changes from libav? [11:46] <ubitux> if we bump, what's the problem? [11:46] <wm4> j-b: that seems to be an automatically generated report, and it doesn't know about the ABI rules put up by ffmpeg [11:47] <j-b> wm4: having rules about bumping does not make it less worse [11:47] <wm4> e.g. adding a field into a middle of the struct is allowed by these rules [11:48] <pross-au> sigh [11:48] <j-b> http://upstream-tracker.org/versions/cairo.html [11:48] <j-b> This is cairo [11:48] <j-b> used by everyone [11:49] <wm4> I see ABI problems in minor releases (hurrr) [11:49] <j-b> right [11:49] <j-b> This is over 8 years [11:50] <j-b> ubitux: the fact that it comes from libav does not change a thing for the users. [11:50] <ubitux> j-b: i know :( [11:50] <ubitux> j-b: but we can't do much about it [11:51] <wm4> anyway, I do think making structs opaque would be a good thing [11:51] <wm4> unfortunately libav disagrees [11:51] <nevcairiel> most of the reports for ffmpeg are false-positives based on the api/abi contract (ie. don't use fields after the marker point "internal"), not that I think this is a good concept and should probably just be moved into an Internal sub-object, but it still wouldn't break [11:51] <wm4> so go argue with them? [11:52] <j-b> wm4: I won't argue with them. I was just explaining why those projects are bad with versionning [11:52] <j-b> nevcairiel: there are even breakage of behaviours without ABI or API bumps. [11:52] <ubitux> that's our compatibility curse :( [11:53] <j-b> Well, if you used your libraries, maybe you would be less bad, sorry to say [11:53] <wm4> j-b: and to be fair, you can't really compare ffmpeg and cairo [11:54] <nevcairiel> that I can agree to, even from a api design standpoint, some of the api design ideas seem like noone ever used them before :p [11:54] <wm4> ffmpeg is a low level lib that deals with a constantly evolving subject (multimedia) [11:54] <wm4> cairo is a rendering API that was inspired by the (proven) post script rendering model (or something) [11:54] <j-b> ffmpeg is NOT a lib [11:55] <ubitux> we could probably take some ideas from the gst guys about that issue [11:55] <j-b> wm4: how is libavfilter or libavdevice evolving all the time? [11:55] <ubitux> but no idea how that would fit with libav merges [11:55] <wm4> j-b: well, recently they added opengl output support to libavdevice [11:56] <j-b> wm4: SOOO much NEW technology. Amazing. Wow [11:56] <pross-au> just wait for libavmesh [11:56] <wm4> whether that change is a good/useful thing is one question, but it certainly changes the requirements on the API [11:56] <wm4> ubitux: better look at ffms2 [11:56] <wm4> ubitux: it had a stable API and ABI for 10 years or so (with only a few minor breaks) [11:57] <ubitux> we can't avoid the break; the project is too large and has a too chaotic history [11:57] <ubitux> the idea is how to make it less painful for the users to deal with that issue [11:58] <ubitux> also, unless you can convince libav to change its behaviour concerning the abi/api evolution, that's harder for us to deal with that [11:59] <j-b> sure, but don't say you care about versions then [11:59] <ubitux> they're so proud of being the ones defining the api/abi so... you should see with them [11:59] <ubitux> j-b: well, we do care for changes coming from us [11:59] <j-b> You think I never complain about that to them? [11:59] <wm4> ubitux: you know, you could send patches to libav any time [11:59] <nevcairiel> caring and not being able to fix it are different things :D [11:59] <wm4> ubitux: you're not mini so you won't cause a jerk reflex [11:59] <ubitux> wm4: i have no solution to propose for the abi/api [12:00] <wm4> (because I'm pretty sure some libav devs do hate mini, despite what everyone says) [12:00] <ubitux> i could send a patch to libav-devel to rename the libs in libqatar* but they won't like it much [12:00] <j-b> but, yes, adding more libraries to the same, is not a good idea, since it encourages the libraries boundaries violations. [12:00] <wm4> ubitux: well, patches with 0% trolling content [12:00] <ubitux> wm4: i don't have any to suggest [12:00] <wm4> troll free, may contain traces of sarcasm [12:40] <BBB> such bad trolls... [12:40] <BBB> j-b: when are you moving to NY again? *hug* [15:21] <cone-372> ffmpeg.git 03Michael Niedermayer 07master:d9a3501c33a1: avutil/opt: dont crash on av_opt_set_dict() with NULL [15:21] <cone-372> ffmpeg.git 03Michael Niedermayer 07master:7aa3979b8c20: avformat/avio: also set generic URL context options [15:31] <superware> I have an H.264 stream over RTP, and I want to use FFmpeg avlib* to open and dump it to a mp4 file (no decoding/encoding), is there a tutorial that demonstrates something similar? I've tried doc/examples/muxing.c but couldn't understand how to achive my scenario.. [17:19] <cone-372> ffmpeg.git 03Peter Ross 07master:e61973db6c01: avformat/mpegtsenc: move startcode validity check to ff_check_h264_startcode [17:19] <cone-372> ffmpeg.git 03Peter Ross 07master:92d657b5f1a4: avformat/wtvenc: advise user when H264 startcode is not present [17:24] <wm4> ubitux: ok... so, ffmpeg uses AVFrame.metadata [17:25] <wm4> ubitux: but there is also AVFrameSideData.metadata [17:25] <wm4> ubitux: so, couldn't ffmpeg just use an empty side data type, and use that second metadata field? [17:27] <ubitux> so the current trending is to use AVFrameSideData instead of frame->metadata? [17:40] <wm4> ubitux: yes, see replaygain stuff [17:40] <wm4> ubitux: and using structs for side data [17:40] <wm4> ubitux: replaygain doesn't use the AVDictionary [17:41] <wm4> actually I wonder when AVFrameSideData.metadata is used at all (?) [17:41] <ubitux> moving to AVFrameSideData will require updates in a small dozen of filters [17:42] <ubitux> i'm also assuming they're properly raised up to ffprobe [17:42] <ubitux> and usable at this stage [20:47] <cone-372> ffmpeg.git 03Vadim Kalinsky 07master:234f0bcb0c73: lavd: Add QTKit input device. [21:08] <cone-372> ffmpeg.git 03Timothy Gu 07master:9e4e35b4d7c4: avconv_opt: fix avio_open2() return code check [21:08] <cone-372> ffmpeg.git 03Michael Niedermayer 07master:ce0ec108cd34: Merge commit '9e4e35b4d7c43a908944183a58aa389a23116fd6' [21:17] <cone-372> ffmpeg.git 03Timothy Gu 07master:68e95ab81be1: dnxhdenc: return meaningful return codes [21:17] <cone-372> ffmpeg.git 03Michael Niedermayer 07master:f22d9b1e0b63: Merge commit '68e95ab81be1aa3f47ab148dceb8711ef5f4212d' [21:20] <kierank> <devils advocate> [21:20] <kierank> possibly ffmpeg should just break API/ABI [21:20] <kierank> completely from libav [21:20] <kierank> and see what happens [21:20] <kierank> </devils advocate> [21:22] <ubitux> i don't think that would be a wise move until it's packaged in debian [21:28] <wm4> the ffmpeg build system is so frustrating [21:28] <cone-372> ffmpeg.git 03Timothy Gu 07master:3a5a965493fa: avconv: make the ASCII flow charts narrower to fit onto TTY [21:28] <cone-372> ffmpeg.git 03Michael Niedermayer 07master:9c77e57393cc: Merge remote-tracking branch 'qatar/master' [21:28] <wm4> update -> try to rebuild -> rebuild for some minutes -> suddenly some weird error about "No rule to make target..." [21:29] <wm4> it's that issue that happens when removing/renaming files or so [21:29] <wm4> try to fix it -> yeah no -> make clean & rebuild everything... [21:36] <superware> I've been trying all day to get an h.264 over RTP into a local mp4 file (dump/copy, no encoding/decoding). I'm reading the stream packets using av_read_frame into an AVPacket. How should I setup the output context? how can I define that av_write_frame won't do any decoding/encoding? [21:38] <ubitux> wm4: it sounds like something Diego would want to fix since he's moving files all the times and master the build system [21:50] <superware> or.. how should I mux AVPackets (h264/RTP) into mp4 file? [21:50] <ubitux> BBB: any suggestion for mc? (what i should do next) [21:50] <ubitux> since put/avg are done [22:12] <BBB> fullpel or 8tap subpel? [22:12] <ubitux> i did fullpell [22:13] <BBB> subpel is always number 1 in all profiles [22:13] <BBB> so I'd do subpel [22:13] <BBB> I haven't done the merged 2d x86 sims yet [22:13] <ubitux> (nothing new from yesterday except that it works - so what's sent in the patch) [22:13] <BBB> but I'll look into it :-p [22:13] <ubitux> ah you want to write some arm simd? [22:13] <ubitux> or you're suggesting me the 8tab subpel? [22:14] <BBB> yes [22:14] <BBB> I'll do the merged 2d x86 simd [22:14] <BBB> you should do the arm 8tap subpel simd [22:14] <BBB> I'd start with just 1d [22:14] <BBB> since 2d is well, hard [22:15] <BBB> and then a c wrapper around 2 1ds to get the 2d effect [22:15] <BBB> like we do for x86 [22:15] <BBB> but maybe later merge them all in assembly [22:15] <ubitux> ok [22:16] <j-b> m [22:16] Action: BBB hugs j-b [22:17] Action: j-b hugs BBB [23:13] <cone-372> ffmpeg.git 03Thilo Borgmann 07master:6d9bdd9d8b6a: doc/indevs: Fix example for QTKit usage. [23:42] <cone-372> ffmpeg.git 03Matt Oliver 07master:0f2588d7e5d2: Use intel compliant CDQ instead of CLTD in inline asm. [00:00] --- Mon Mar 31 2014