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

[burek]

[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