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

burek burek021 at gmail.com
Wed Sep 10 02:05:02 CEST 2014


[00:14] <rcombs> J_Darnley: correct
[00:20] <J_Darnley> Then I wonder what my problem is.
[00:31] <J_Darnley> Bloody hell do I hate git config.  I can never tell it to do what I want it to.
[00:32] <wm4> what's the problem?
[00:32] <J_Darnley> I wanted to remove a config option
[00:33] <J_Darnley> I just edited the file
[00:33] <wm4> heh
[00:33] <wm4> yeah I also usually edit it manually
[01:22] <cone-636> ffmpeg.git 03Michael Niedermayer 07master:5109ce2017c1: avformat/mpeg: increase score for short mpeg-ps by 1
[01:24] <wm4> anyone following the debian ML flame? what's the status of the ffmpeg package?
[01:37] <rcombs> can trac be made to have git hashes become links pointing at that commit in gitweb?
[01:58] <Compn> wm4 : its not being discussed on debian-devel , so i'd assume its being discussed somewhere else.
[02:18] <cone-636> ffmpeg.git 03Michael Niedermayer 07master:02946120fc30: avfilter/vf_cropdetect: Do not check lines or columns twice on black frames
[02:46] <michaelni> rcombs, yes but it slows trac down by a large factor, if you or someone else knows a way to achive it without slowdown (this requires writing code not just changing config) that would be welcome
[02:50] <jamrial> Compn: if it's not being discussed on debian-level, where would it be discussed?
[02:56] <rcombs> michaelni: if you want to go full lazy-mode and hardcode the repo URL, you could just do this, which would definitely have negligible slowdown: https://gist.github.com/d484f5fadbe5c7c53561
[02:58] <rcombs> and I'm about 62% sure it'd work
[02:59] <wm4> enough to push to production!
[03:00] <rcombs> possibly s/fragment/label/
[03:00] <rcombs> I don't know my way around Trac's codebase at all, so that's just a basic "make the links point at something"
[03:02] <rcombs> just found the bit that generates the <a>s that don't point at anything right now and made them point at the videolan gitweb
[03:06] <Compn> jamrial : ask siretart ?
[03:36] <michaelni> rcombs, tried the patch, seems to make no difference
[03:44] <rcombs> michaelni: oh, are you using the revision_links.py sample plugin?
[03:47] <rcombs> AH, here it is
[03:48] <rcombs> https://gist.github.com/1cac6792381487f102b8
[03:48] <michaelni> locate revision_links.py ---> no hits
[03:49] <rcombs> yeah, I found the git wiki syntax provider
[03:52] <rcombs> (this would probably be easier if I'd set up a local trac installation to screw with, but ~lazy~)
[04:00] <BBB> http://kojevnikov.com/faster-fast-fourier-transform.html
[04:00] <BBB> our fft is slow?
[04:05] <rcombs> sft
[04:06] <michaelni> rcombs, i think its working
[04:07] <rcombs> works here!
[04:07] <rcombs> probably disregards 20 edge-cases, but hits the general one pretty well
[04:09] Action: michaelni wonders why some .py files from trac had dos line endings and some unix style ...
[04:09] <rcombs> ghuuu
[04:17] <Compn> michaelni : so where are we on bug bounties ? did anyone ask spi ?
[04:19] <michaelni> Compn, dunno, probably not ... 
[04:19] <Compn> i didnt know spi had rules about donations...
[04:19] <Compn> where are those rules ?
[04:19] <Compn> i just thought they were 'ours' after people donated.
[04:21] <michaelni> AFAIK SPIs rules are just the US "Non profit rules", whatever they are called correctly IANAL
[04:21] <michaelni> that is as SPI is a 503 non profit whatever they are limited to what they can do with the money ...
[04:21] <Compn> right
[04:22] <Compn> but even in a non profit company, you can still pay your own salary
[04:22] <Compn> and your own salary can be anything... theres a lot of sick people in usa running charities getting paid $400k/ yr
[04:23] <Compn> maybe it has to be carefully worded.
[04:25] <Plorkyeran> your compensation does have to be typical for your position, but that's a very loose requirement
[04:25] <Plorkyeran> it mostly just means that you have to transfer money to yourself in the most tax-intensive manner possible
[05:33] <cone-759> ffmpeg.git 03Antonio Ospite 07master:5a8e51f661bf: avdevice/x11grab: rename the "w" Window to "root" in paint_mouse_pointer
[05:33] <cone-759> ffmpeg.git 03Antonio Ospite 07master:69c34a6ac986: avdevice/x11grab: fix cursor drawing in multi-screen setup
[05:33] <cone-759> ffmpeg.git 03Michael Niedermayer 07master:f7bbe0f414f8: avformat/mpeg: update comment on probe score
[07:13] <ubitux> BBB: https://trac.ffmpeg.org/ticket/3921#comment:2
[07:14] <ubitux> (-#comment:2)
[08:05] <ubitux> rcombs: :(((
[08:05] <ubitux> noo :(
[08:05] <rcombs> ubitux: une problème?
[08:05] <ubitux> oui
[08:06] <ubitux> that idea thing
[08:06] <ubitux> id*
[08:06] <rcombs> sorry, got user reports of it happening in the wild
[08:06] <ubitux> user gone wild
[08:07] <ubitux> i wonder how that can happen
[08:07] <ubitux> except users editing the file themselves 
[08:07] <rcombs> that's probably it :\
[08:07] <ubitux> well i'll have a look
[08:07] <rcombs> the actual parser is super-loose about these things
[08:08] <rcombs> (which is good)
[08:08] <rcombs> it's just the probe that gets picky
[08:16] <rcombs> all the best bug reports are swiftly replied to with ":((( noo :("
[12:23] <cone-854> ffmpeg.git 03Gabriel Dume 07master:9752d07d33d5: dirac: K&R formatting cosmetics
[12:24] <cone-854> ffmpeg.git 03Michael Niedermayer 07master:b63052839a6b: Merge commit '9752d07d33d5370f7819865fbb5e582b982aad06'
[13:00] <BBB> ubitux: ah good
[13:00] <ubitux> i started having a look already
[13:01] <ubitux> but.. braaaains ~
[13:03] <ubitux> on avx the difference is not that marked
[13:03] <ubitux> http://pastie.org/pastes/9538762/text
[13:03] <ubitux> here are the results on avx
[13:03] <ubitux> the guy tested on an i7, so sse only
[13:04] <ubitux> i7 920*
[15:12] <ubitux> 15:07:00 < Tim-Work> General question: is G-Streamer open source frame work built on top of LibAV?
[15:12] <ubitux> 15:08:43 < koda> yes
[15:12] <ubitux> lol
[15:13] <Daemon404> close
[15:13] <Daemon404> but instead of libav, i'd say "build on a pile of feces"
[15:13] <Daemon404> wherr plugin libs are irrelevant
[17:06] <cone-854> ffmpeg.git 03Michael Niedermayer 07master:881f96c4c2ef: avcodec/rawenc: drop sizeof(AVFrame) dependency
[17:06] <cone-854> ffmpeg.git 03Pascal Massimino 07master:e3fd6a3a4e3d: av_filter/x86/idet: MMX/SSE2 implementation of 16bits filter_line()
[19:08] <cone-854> ffmpeg.git 03Henrik Gramner 07master:176a0fca3fd6: x86inc: Make ym# behave the same way as xm#
[19:08] <cone-854> ffmpeg.git 03Michael Niedermayer 07master:87120217b53b: Merge commit '176a0fca3fd64f91d585f96137388e00d8c101b6'
[19:10] <cone-854> ffmpeg.git 03Loren Merritt 07master:ec217218c27d: x86inc: Free up variable name "n" in global namespace
[19:10] <cone-854> ffmpeg.git 03Michael Niedermayer 07master:d2f1f2c74f2d: Merge commit 'ec217218c27d53c5b323323e6ef862bcdbcabe5f'
[19:11] <cone-854> ffmpeg.git 03Henrik Gramner 07master:f629705b0239: x86inc: Make INIT_CPUFLAGS support an arbitrary number of cpuflags
[19:11] <cone-854> ffmpeg.git 03Michael Niedermayer 07master:5309e7e6aa1e: Merge commit 'f629705b0239c80fddc1b0b15ed4bb9042c77d23'
[19:44] <cone-854> ffmpeg.git 03Gabriel Dume 07master:ee0ebd3c1412: dv: K&R formatting cosmetics
[19:44] <cone-854> ffmpeg.git 03Michael Niedermayer 07master:96b069450cd0: Merge commit 'ee0ebd3c1412fdd9d80aa97c98d1a20b893f1f47'
[20:15] <JEEB> is AAC in MPEG-TS ever muxed in as stream_type 0x04?
[20:16] <JEEB> or is it as the spec says, complete bullshit
[20:18] <nevcairiel> 0x04 is for mp2 audio, isnt it
[20:19] <JEEB> yes
[20:19] <JEEB> 13818-3
[20:22] <nevcairiel> then why would there be aac in there
[20:22] <nevcairiel> just call BS
[20:22] <nevcairiel> broken files, should not encourage users to make them
[20:22] <JEEB> yeah, either misparsing of the front packet or BS indeed
[20:22] <Daemon404> every time you say BS i think of japanese satelite.
[20:22] <JEEB> BS and CS
[20:22] <JEEB> CS being paid and BS being non-paid
[20:29] <JEEB> it's supposedly a broadcast file, from a channel I know is supposed to mux shit relatively sanely. So I wonder if it's a misparse (0x47 but not a packet start). But too bad the guy who passed me the sample is a fucking retard
[20:29] <JEEB> and didn't cap his shit either so it's like "uh ok I'll try asking if anyone or anything fucked with the stream"
[20:30] <nevcairiel> ignore and move on
[20:31] <JEEB> also 80 megabits throughput yaay
[20:36] <JEEB> ok
[20:36] <JEEB> seems to have been a case of a crappy DVB-S receiver fucking up PMT and shit
[20:36] <JEEB> I didn't even know those pieces of shit could do such stuff
[20:36] <JEEB> here I was thinking that they'd just fucking dump shit unless you used a lolstupid application
[20:37] <line0> iirc you can't "just dump"
[20:37] <line0> a transport stream usually contains more than one channel
[20:37] <JEEB> well true
[20:37] <line0> so there's plenty of opportunities to fuck up
[20:37] <JEEB> the simplest mode of my receiver application just dumps that up
[20:38] <nevcairiel> yeah trying to strip out only one channel is easy to fuck up
[20:38] <JEEB> the less simple mode attempts to cut off that specific channel
[20:38] <JEEB> but yeah, that shit is software
[20:38] <JEEB> unless the receiver is doing it itself
[20:38] <JEEB> which I would facepalm at if it was actually doing that (and being buggy)
[20:51] <Compn> we must support all broken encoders :D
[20:52] <wm4> that's the tragedy of open source multimedia
[20:53] <nevcairiel> imho its better for everyones sanity if we dont accept things that are blatant and obvious spec violations
[20:53] <JEEB> yes
[20:54] <JEEB> I was just trying to find out if there was actual reason for it getting (mis)read as that, or if it was just retarded shit
[20:54] <JEEB> it ended up being retarded shit
[21:27] <cone-854> ffmpeg.git 03Michael Niedermayer 07master:35a9959acad3: avcodec/snow: make new_picture const
[21:33] <ubitux> wm4: you really like to make friends :))
[21:33] <wm4> shut up troll
[21:33] <ubitux> :D
[21:39] <cone-854> ffmpeg.git 03Clément BSsch 07master:c7d8dbad14ed: avformat: remove FF_API_ASS_SSA dead code
[21:39] <ubitux> TIL pango includes a "simplified" copy of fribidi
[21:40] <ubitux> (and uses hb)
[21:40] <wm4> huh
[21:40] <wm4> a copy?
[21:41] <ubitux> yup
[21:41] <wm4> or more like a fork?
[21:41] <wm4> or a rewrite?
[21:41] <wm4> I know there's a simple fribidi somewhere...
[21:41] <ubitux> afaict it's from the author of fribidi himself
[21:41] <ubitux> need to recheck
[21:41] <wm4> also, upstream fribidi is not thread-safe by default (so multiple threads using fribidi, even independently, causes issues)
[21:41] <ubitux> yep, he still didn't make a release
[21:42] <ubitux> pango/mini-fribidi
[21:42] <ubitux> "Include a stripped-down version of fribidi to avoid the extra dependency."
[21:42] <ubitux> not from the author actually
[21:42] <wm4> lol
[21:42] <ubitux> but, i see commits from Behdad Esfahbod in that directory
[21:42] <Daemon404> vendoring is the root of all evil
[21:42] <wm4> you know I really wonder why they have to avoid fribidi as dependency, if they depend on glib anyway
[21:42] <ubitux> not sure if that was cherry-picked
[21:43] <ubitux> yeah... :D
[21:43] <Daemon404> wm4, pango is already part of the clusterfuck of desktop linux deps anyway
[21:43] <wm4> yeah
[21:43] <ubitux> yeah but you might need font rendering elsewhere than on desktop
[21:44] <ubitux> and that glib is a real cancer
[21:44] <wm4> also, harfbuzz itself depends on glib (even though there's an alternative lib that does the same as they need from glib, but just in about a hundred lines of codes)
[21:44] <Daemon404> ubitux, i tried to built librsvg once
[21:44] <Daemon404> never again
[21:44] <Daemon404> build*
[21:45] <ubitux> oh wut hb deps on glib2 as well?
[21:45] <ubitux> :(
[21:45] <wm4> it needs either glib, icu, or that tiny lib zgreg (from libass) wrote
[21:46] <ubitux> well glib2 is pulled by systemd anyway nowadays ;)
[21:48] <wm4> wut
[21:48] <wm4> no, systemd can't use glib
[21:48] <wm4> and AFAIK doesn't?
[21:48] <wm4> glib aborts on out of memory
[21:48] <wm4> maybe that's fine with desktop apps, but for init 0 it's a pretty bad idea
[21:48] <nevcairiel> and thats a reason not to use it in systemd now?
[21:48] <nevcairiel> :p
[21:48] <wm4> err, pid 0
[21:49] <wm4> it should
[21:49] <kepstin-laptop> there is no pid 0 :) (init is 1)
[21:49] <J_Darnley> michaelni: I hope merging those x264asm patches didn't involve much work.
[21:50] <wm4> kepstin-laptop: oops!
[21:50] Action: kepstin-laptop notes that the part of systemd that runs as 'init' doesn't link to glib, but some of the tools do.
[21:50] <ubitux> wm4: it does
[21:50] <ubitux> configure.ac:AS_IF([test "x$enable_gudev" = "xyes"], [ PKG_CHECK_MODULES([GLIB], [glib-2.0 >= 2.22.0 gobject-2.0 >= 2.22.0 gio-2.0]) ])
[21:50] <ubitux> configure.ac:AS_IF([test "x$enable_gudev" = "xyes"], [ AC_DEFINE(HAVE_GLIB, 1, [Define if glib is available]) ])
[21:50] <wm4> probably for some tools as kepstin-laptop said
[21:51] <ubitux> http://pastie.org/pastes/9539865/text
[21:51] <wm4> systemd doesn't use libdbus either
[21:51] <wm4> it's fun how they don't eat their own dog food
[21:51] <ubitux> gudev yum yum
[21:51] <nevcairiel> systemd depends on libdbus on debian at least though, no idea if it actually uses it :p
[22:00] <wm4> Daemon404 is apparently also making friends
[22:00] <ubitux> :D
[22:00] <Daemon404> i dunno, trying to get me barred from VDD
[22:00] <Daemon404> oh well.
[22:08] <ubitux> wm4: systemd still seems to hard dep on dbus which is glib based anyway
[22:09] <ubitux> might end up being dropped with kdbus, but what do i know..
[22:09] <wm4> right
[22:09] <wm4> weird
[22:09] <wm4> but it's clear that systemd really needs kdbus to fix reliability issues
[22:10] <wm4> which is bullshit
[22:16] <ubitux> mmh maybe dbus isn't glib based actually
[22:16] <ubitux> maybe that changed
[22:17] <wm4> hm 
[22:17] <wm4> you're right
[22:17] <wm4> ldd `which dbus-daemon `|grep glib
[22:17] <wm4> no output
[22:20] <kepstin-laptop> there is a gobject-based api for using dbus, but it's actually part of glib now (used to be a separate package)
[22:21] <ubitux> i see no deps on dbus in glib
[22:22] <kepstin-laptop> I don't think it deps on any part of dbus, it's rather an independent implementation of the wire protocol.
[22:22] <ubitux> interesting
[00:00] --- Wed Sep 10 2014


More information about the Ffmpeg-devel-irc mailing list