michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 6.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
stevenliu has quit [Read error: Connection reset by peer]
stevenliu_ has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 252 seconds]
rvalue has joined #ffmpeg-devel
qeed has joined #ffmpeg-devel
qeed has quit [Remote host closed the connection]
qeed has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
thilo has quit [Ping timeout: 272 seconds]
thilo has joined #ffmpeg-devel
deer3 has quit [Ping timeout: 260 seconds]
deer3 has joined #ffmpeg-devel
deer3 has quit [Remote host closed the connection]
<cone-290>
ffmpeg Mattias Wadman master:78812cd147fa: avcodec/h2645_parse: Don't treat 0x000002 as a start code and truncate
\\Mr_C\\ has quit [Remote host closed the connection]
<cone-290>
ffmpeg Anton Khirnov master:75697836b1db: Require compilers to support C11.
rajivharlalka has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
Marth64 has joined #ffmpeg-devel
<courmisch>
elenril: where is the switch to alignedas?
<elenril>
the trolls wake up
<courmisch>
I've been up for 2 hours and I've not seen any troll
<courmisch>
well I've not seen anyone
<Marth64>
troll here reporting in
<Marth64>
with a question actually...
<Marth64>
elenril: > Demuxers are not supposed to set this, it's for the codec-layer framerate information.
<Marth64>
I assume this won't fly either right? sti->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
<elenril>
right
<Marth64>
cool, i'll toss it
<elenril>
you shouldn't touch avctx at all
<courmisch>
the earlier I wake up on Sunday the earlier I get to watch the next episode of Les carnets de l'apothicaire, so I'm not for slacking off in bed on that weekday
<elenril>
and you shouldn't need to
<Marth64>
i will just do my usual round of testing now and when i wake up, should have this updated in the ML within next 6-12 hrs
<Marth64>
fixed some other goofs as well
<Marth64>
any objection if i assume ".iso" extension for dvd demuxer?
<Marth64>
i don't see it taken by anything else
<Marth64>
but i also don't feel strongly about it
<nevcairiel>
do you have a probe function that could potentially identify a compatible iso and otherwise reject it?
<nevcairiel>
of course an iso could be anything
<nevcairiel>
a blu-ray, a dvd, something else entirely
MisterMinister has quit [Ping timeout: 264 seconds]
<Marth64>
nevcairiel: I do but it's not mature right now, and I want to take that one seriously from a security standpoint so wanted to focus on it in it's own patch later. My thought process behind claiming iso is, it's at least no worse than the current behavior (ffmpeg will take the ISO file and appears to read the mpeg-ps structures from it as if it is a binary blob without regard to filesystem)
<Marth64>
but also not necessary to claim it now, the usability can easily wait for a proper probe function.
<Marth64>
(security standpoint --> considerations to make for checking cdrom block devices, VIDEO_TS folder presence, etc. etc.)
<elenril>
a probe function can't reasonably do all that
<elenril>
it's supposed to be very fast and simple
<Marth64>
yeah, I think the cdrom checking is out the window, I also don't feel right about poking at people's block devices
<elenril>
any IO is probably out of question
<Marth64>
so in spirit also thinking something quick, light, secure
<Marth64>
yeah
<elenril>
because lavf will potentially call every demuxer's probe function when opening any file
<elenril>
possibly more than once
<Marth64>
yes exactly my fear. this i learned making a noob mistake couple months back, when i saw log messages from my demuxer when they shouldn't have belonged
<Marth64>
i will send some probe function and the menus support after the initial patch
<elenril>
sounds good
<Marth64>
ty
<elenril>
if you send your patch now, I might push it later today
<Marth64>
ok. let me hit the essential discs to test and i'll send it
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
rajivharlalka has quit [Quit: Connection closed for inactivity]
cone-290 has quit [Quit: transmission timeout]
rvalue has quit [Ping timeout: 240 seconds]
rvalue has joined #ffmpeg-devel
<Marth64>
elenril: could you give me 12 hours? i wanted to test with an actual dvd drive one last time and also try to catch some sleep and test with fresh eyes
<Marth64>
unless release is happening imminently
<Marth64>
i can send it now as is but the peace of mind would be nice
<Marth64>
haha, actually nvm. i left a disc in the drive (on a remote session.)
<haasn>
C11 got merged?
<JEEB>
apparently yes
<JEEB>
if I see 75697836b1db correctly :)
<haasn>
elenril: then in your patch assert(side_data_nb < 64) should be static_assert()
Traneptora has joined #ffmpeg-devel
cone-050 has joined #ffmpeg-devel
<cone-050>
ffmpeg Marton Balint master:2a12c04e35a4: avutil/channel_layout: change AV_CHAN_SILENCE to AV_CHAN_UNUSED in the docs
<cone-050>
ffmpeg Marton Balint master:f8f2142d61aa: avformat/mov: factorize reading the main part of the chnl atom to mov_chan
<cone-050>
ffmpeg Marton Balint master:65c9c52a5aa9: avutil/tests/channel_layout: add tests for av_channel_order_retype
<Traneptora>
elenril: do you have any suggestions for the issue of AVDisplayMatrix not agreeing with EXIF sidedata?
<Traneptora>
currently mjpeg decoder parses exif buffer and then attaches an avdisplaymatrix based on the orientation tag. the issue is if a user removes the displaymatrix side data (e.g. because they apply it), what should we do?
<JEEB>
the side data disappearing due to it being applied by f.ex. ffmpeg during the processing of the input sounds at least correct?
<Traneptora>
that's fine. the issue is that it won't affect what's written in the EXIF metadata
<Traneptora>
If I see this correctly, then these patches can lead to a situation
<Traneptora>
where an input packet has rotation metadata in exif which gets exported
<Traneptora>
changes the displaymatrix (e.g. applies the transformation to the image
<Traneptora>
twice -- as displaymatrix and as exif metadata side data. If the user
<Traneptora>
data and removes the displaymatrix side data before reencoding), the
<Traneptora>
exif data (that the user would probably not be aware of) would still be
<Traneptora>
there and get propagated into the output, corrupting it.
<Traneptora>
oops, didn't mean to spam
<Traneptora>
but this is what andreas brought up, and before I design a fix I'm trying to figure out what the fix *should* be
kepstin has quit [Remote host closed the connection]
<elenril>
Traneptora: how feasible would it be to not have it in exif data?
<Traneptora>
currently everything except TIFF treats exif as a block. to remove a tag requires you to adjust all the offsets, which essentially means reading and writing the whole block
<Traneptora>
it's possible, but also awkward
<Traneptora>
definitely doable though
<Traneptora>
if you were to do that, then you'd also need to add code to add the displaymatrix back into Exif upon writing, which can also be done but I haven't figured out how to handle weird matrices
kepstin has joined #ffmpeg-devel
<elenril>
didn't look at your set yet, but it's on my list
<elenril>
Ideally the code parsing exif would split it into some easilu modifiable for
<elenril>
m
<elenril>
which would include moving rotation to separate side data
* elenril
stabs courmisch
<courmisch>
wuh?
<Traneptora>
elenril: I can parse it as an AVDictionary *, but since AVSideData has to be flat, I can't attach the dictionary as side data, I have to reserialize it
<courmisch>
let _ = elenril;
Krowl has joined #ffmpeg-devel
<Traneptora>
$_ =~ $elenril;
mkver has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
<cone-050>
ffmpeg Jan Ekström master:e06ce6d2b45e: {avcodec,tests}: rename the bundled Mesa AV1 vulkan video headers
<JEEB>
BtbN: this should now fix the compilation for newer vulkan headers
<JEEB>
if I don't get complaints how this was done during today, I'll probably backport this to any branches which have this feature included (6.1 might have it?)
<mkver>
C11 has landed!
<JEEB>
aye
<courmisch>
the year is 2024 and FFmpeg still uses ad-hoc arithmetic overflow checks
<courmisch>
also the motivation is low that TDD does not work
Krowl has quit [Read error: Connection reset by peer]
<another|>
please adjust the year in your statement with an ad-hoc arithmetic calculation
<another|>
/s
<courmisch>
what GCC version does FFmpeg now assume (if GCC)?
<Lynne>
when c17?
<another|>
in 6 years /s
jamrial has joined #ffmpeg-devel
<cone-050>
ffmpeg James Almer master:b5911654c430: avutil/channel_layout: print known layout names in custom layout
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
<mkver>
Lynne: Do you want to apply your tx patch or shall I apply mine?
<nevcairiel>
c11 was "supported" in gcc 4.7, although atomics didnt arrive until 4.9, so probably that? i guess we have fallbacks for atomics for old gcc unless those were deleted at some point, so 4.7 should also work? does anyone care for that distinction?
Guest32 has joined #ffmpeg-devel
<Guest32>
Hi everyone, sorry to bother you all but I have a question related to the class udp. I'm currently transcoding a live content with a source rate of 25 fps. The input is UDP. My outputs are also UDP (Tee-muxer) and with 25 fps. Sometimes the encoding speed is going under 1x for a bit and goes back to 1x. Question: The fifo from UDP is used when the
<Guest32>
ffmpeg goes under 1x but at what moment is getting refilled is my encoding does not go above 1x ?
<Guest32>
My assumption is that ffmpeg can't refilled the fifo buffer is my encoding speed does not exceed 1x (ex: 1.01). if my encoding speed is just 1x (25fps) then I will process the frames but I will never get back on my initial buffer
<Lynne>
mkver: if that's an lgtm, I'll apply mine
<Guest32>
Please ? :)
<jamrial>
Guest32: usage questions go to #ffmpeg
<Guest32>
jamrial got it! thx
Guest32 has quit [Quit: Client closed]
Osmancorp has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 272 seconds]
Marth64 has joined #ffmpeg-devel
Osmancorp has quit [Ping timeout: 250 seconds]
Osmancorp has joined #ffmpeg-devel
darkapex has quit [Ping timeout: 256 seconds]
derpydoo has quit [Ping timeout: 260 seconds]
Marth64 has quit [Ping timeout: 272 seconds]
Marth64 has joined #ffmpeg-devel
<mkver>
Lynne: It's not an LGTM, because I didn't look at your patch. Just saw there was one.
<cone-050>
ffmpeg Lynne master:c7ceff690f16: lavu/tx: correctly use a default scale parameter for all transform types
<BtbN>
hm, with C11 support, that means the minimum glibc version is now 2.28, which removed Ubuntu 18.04 support. I'm sure _someone_ will be upset about that.
<bencoh>
I recently built something that required glibc >= 2.28 at $job, and yeah, I eventually switched back because of that. I bet some people will dislike it :]
<cone-050>
ffmpeg Andreas Rheinhardt master:c149d86760ac: avfilter/vf_signature: Allocate arrays together
<cone-050>
ffmpeg Andreas Rheinhardt master:eeb99dcb51f2: avfilter/signature_lookup: Check for allocation error
<cone-050>
ffmpeg Andreas Rheinhardt master:bf82b6517e53: avfilter/signature_lookup: Allocate buffers jointly
<cone-050>
ffmpeg Andreas Rheinhardt master:626a076249c2: avfilter/signature_lookup: Remove useless error logs
<cone-050>
ffmpeg Andreas Rheinhardt master:cc36a9f5b935: avfilter/signature_lookup: Avoid branch when adding to linked list
<cone-050>
ffmpeg Andreas Rheinhardt master:db98b0e04e04: avfilter/avfilter: Avoid allocation for AVFilterInternal
<cone-050>
ffmpeg Andreas Rheinhardt master:a272c9cffa52: avfilter: Add a header for internal generic-layer APIs
<cone-050>
ffmpeg Andreas Rheinhardt master:a1aec776f13b: avfilter/avfiltergraph: Avoid indirection when freeing filtergraph
<cone-050>
ffmpeg Andreas Rheinhardt master:03567ed80cf1: avfilter/avfiltergraph: Avoid allocation for AVFilterGraphInternal
<cone-050>
ffmpeg Andreas Rheinhardt master:89eea4e19aad: avfilter/avfilter: Move AVFilterGraph private fields to FFFilterGraph
<cone-050>
ffmpeg Andreas Rheinhardt master:40b91eaea954: avfilter/avfilter: Move init_state to FilterLinkInternal
<cone-050>
ffmpeg Andreas Rheinhardt master:4a7329994a43: avfilter/avfilter: Move age_index to FilterLinkInternal
<cone-050>
ffmpeg Andreas Rheinhardt master:32538dafca37: avfilter/avfilter: Move frame_pool to FilterLinkInternal
<nevcairiel>
glibc documents c11 support in 2.16, why 2.28?
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
<courmisch>
library support for C11 is nonexistent on Windows, so I don't see why glibc would be a problem
<courmisch>
AFAIK, the library needs to add aligned_alloc(), which is trivially replaced with posix_memalign()
<courmisch>
(trivially on POSIX, not on Windows, ofc)
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
<BtbN>
no threads.h support before that, and generally a lot of random bugs
<BtbN>
I have a bunch of dependencies in my build where I intentionally hide C11 support. And recently openal just started hard depending on it
<ePirat>
jamrial, I can't really make sense of your aligned_malloc patch, how did you test this?
<jamrial>
ePirat: what do you mean?
<ePirat>
there is no aligned_malloc in C11
<ePirat>
there is aligned_alloc
<jamrial>
oh. yeah, my fault for testing only with mingw
<ePirat>
note that its only available on macOS starting with macOS 10.15, iOS 13 and tvOS 13, so dropping a bunch of still supported older targets
<ePirat>
currently stll supported by ffmpeg, that is
Marth64 has quit [Ping timeout: 260 seconds]
<jamrial>
ePirat: we already require c11, so aligned_alloc will be available
Marth64 has joined #ffmpeg-devel
<ePirat>
guess we just have to patch in VLC then
<ePirat>
as we still support macOS 10.11
<ePirat>
"10.15 was the first version to ship an implementation of aligned_alloc()", "Android only provides aligned_alloc when targeting API 28 or higher."
<jamrial>
what a shit show
<jamrial>
i withdrew the patch anyway. mkver mentioned aligned_alloc() isn't useful after all for our needs
klaxa_ is now known as klaxa
Osmancorp has quit [Quit: Client closed]
<mkver>
What a joke: _Static_assert is considered a declaration in the spec and GCC subjects it to -Wdeclaration-after-statement.
<elenril>
>You have been invited to join the Illuminati Brotherhood. We grant you access to wealth, fame and power. Should you be .Kindly contact: grandmasterpyramids@gmail.com
<elenril>
mkver: wtf
<JEEB>
hah @ static_assert and declaration-after-statement
<elenril>
I guess there's a C committee rule against adding things that are too useful
<mkver>
Not true. We are shooting ourselves in the foot with -Wdeclaration-after-statement.
<elenril>
I disagree
<mkver>
C committee abandoned this with C99.
<elenril>
I don't trust people to declare things in a sane way
<Gramner>
does the c standard even care about declarations after statements in the first place? that sounds more like a gcc bug
<mkver>
And I don't see how -Wdeclaration-after-statement would improve things.
<mkver>
Gramner: Only C89 had this restriction.
<elenril>
it enforces some basic semblance of structure
<mkver>
And we opt in to it via -Wdeclaration-after-statement
<Lynne>
elenril: I'm with mkver on this one, structure should be left up to the programmer and community, not the compiler to police
<jamrial>
i can see issues popping up with gotos if we just allow declarations to happen anywhere
<nevcairiel>
compilers generally complain if you combine those
Krowl has joined #ffmpeg-devel
<elenril>
Lynne: I wish I could trust our community to such an extent
qeed has quit [Remote host closed the connection]
qeed has joined #ffmpeg-devel
<mkver>
jamrial: Issues also happen because of the current programming style; see 85a6404d7e6c759ddf71d6374812d7ff719728ec and 5e1dac380bea627e5b7751e07bdabc0f4ee139c2
<cone-050>
ffmpeg Andreas Rheinhardt master:44620ade251f: fftools/ffmpeg_mux_init: Fix attachment_filename use-after-free
<cone-050>
ffmpeg Andreas Rheinhardt master:749e93d11de9: tests/fate-run: Do not ignore errors from intermediate commands
rvalue has joined #ffmpeg-devel
<mkver>
Is Nuo Mi on IRC?
<JEEB>
he was at some points at least, not now tho
michaelni has quit [Quit: Leaving]
Marth64 has quit [Ping timeout: 240 seconds]
Marth64 has joined #ffmpeg-devel
<haasn>
jamrial: isn't there a specific warning for jumping past a declaration?
<haasn>
or is that a C++ thing?
<jamrial>
i don't know
<haasn>
hrm
<haasn>
it's explicitly forbidden in C++ but there's apparently not a gcc/clang option you can set to enable warning for this under C semantics (according to chatgpt)
\\Mr_C\\ has joined #ffmpeg-devel
<mkver>
There is -Wjump-misses-init, but unfortunately it does not work that well with "goto fail".
<mkver>
It also warns when you jump over the definition of a variable if said variable is not used in the fail: block at all.
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
<Lynne>
elenril: trust them not to use them, or trust them to use them if needed?
<elenril>
trust them to us it in a way that does not hurt readability
<elenril>
"what is this 'future maintenance' thing you speak of"
AbleBacon has joined #ffmpeg-devel
michaelni has joined #ffmpeg-devel
<Lynne>
at least you admit that decl after statement could havve its rare uses in our codebase, we can work from here
<Gramner>
I recall gcc/clang complaining if you do dumb goto's
<JEEB>
I recall at least one case which didn't seem to get caught in another project (goto'ing skipping definition of a variable that was then touched after the location that was being jumped to)
kepstin has quit [Ping timeout: 268 seconds]
AbleBacon has quit [Remote host closed the connection]
AbleBacon has joined #ffmpeg-devel
kepstin has joined #ffmpeg-devel
AbleBacon_ has joined #ffmpeg-devel
zsoltiv_ has joined #ffmpeg-devel
AbleBacon__ has joined #ffmpeg-devel
AbleBacon has quit [Ping timeout: 246 seconds]
AbleBacon_ has quit [Ping timeout: 246 seconds]
AbleBacon__ is now known as AbleBacon
<jkqxz>
What would anyone expect a file (with associated namespace) called "hw_base_encode" to contain?
Krowl has quit [Read error: Connection reset by peer]
<jamrial>
an encode from some hw encoder using default settings?
<jkqxz>
(Trying to judge whether the name is reasonable, and if not what elements the name should have.)
<haasn>
mkver: can you work around it by just putting static assert inside its own block?
<haasn>
#define av_static_assert(cond) do { _Static_assert(cond, #cond); } while (0)
<mkver>
Of course one can. But it is not intuitive.
<mkver>
A public macro for this?
<elenril>
jkqxz: madness and depravity
<elenril>
clearly it should have been hw_encode_base
kasper93 has quit [Ping timeout: 256 seconds]
<haasn>
I use a macro for _Static_assert anyway because I don't understand why you need to put a separate error message string after the condition
<haasn>
or what problem that would ever solve
<Lynne>
Gramner: you mean error: int something; ?
<Lynne>
yeah, that's a language limit, c23 fixed it
<jkqxz>
elenril: Maybe that would have been marginally better, but is there anything clearer?
<JEEB>
what is the attempted meaning?
<elenril>
jkqxz: then i'd expect it to contain shared vendor-independent hw encoding code
<haasn>
or codec-independent
derpydoo has joined #ffmpeg-devel
<jkqxz>
It's intended to be "common elements of accelerator-type encoders" (for VAAPI and D3D12, and I guess Vulkan too).
* sdc
heya I'm reading through the patch submission checklist, for "If the patch fixes a bug, did you provide enough information, including a sample ... ", if I do git send-email do I just reply to patch email with the samples?
<sdc>
oops sorry not used to irc
<JEEB>
sdc: or you make a ticket on trac first and attach it there?
<Lynne>
jkqxz: common elements like management of DPBs and such?
<JEEB>
then you can also add a Fixes: line as well :D
<jkqxz>
A bit like the stuff in namespaced as "hwaccel" in decoders.
<sdc>
oh there already is a trac # that I'm fixing
<jkqxz>
Lynne: Yes.
<JEEB>
well that makes things easier :)
<Lynne>
jkqxz: nice, I got annyoed enough having to duplicate VAAPI's ref handling code to lose motivation
<Lynne>
but since it's codec-specific, I think libavcodec/h264enc_hw_base.c/h makes more sense
<jkqxz>
It isn't.
<jkqxz>
It's the common parts of VAAPI extracted to support D3D12 as well, with H.265 as the first implementation in D3D12 but should work for others.
<cone-050>
ffmpeg Lynne master:e43615fc2ab2: configure: fix compilation with glslang 14
<courmisch>
NG reported to CC
<psykose>
i'm sure the stern warning will be hugely successful
<Lynne>
jkqxz: so buffer management?
<Lynne>
rather than ref managment?
<Lynne>
I don't think that would warrant a common code
<BBB>
...
<jkqxz>
Why not? All of the usual suspects use the same structure.
<BBB>
psykose: it would be funny if it wasn't sad at the same time
<psykose>
yea
<BBB>
I'm sorry that we haven't made the mailinglist a beautiful place yet that we all wish it would be
<BBB>
we're working on it...
<Marth64>
enable html fight in rich text
<courmisch>
who answers for abuse@ffmpeg.org ?
<courmisch>
mailman.ffmpeg.org is hosting defamatory content against my person
<Marth64>
ai bots
<BBB>
oh dear
MisterMinister has quit [Ping timeout: 246 seconds]
Marth128 has joined #ffmpeg-devel
Marth64 has quit [Killed (NickServ (GHOST command used by Marth128!~Marth64@85.237.194.236))]
<Lynne>
jkqxz: creating buffers is a few lines in most cases?
<Lynne>
something like a generic submit API which keeps track of frames for you would be convenient, but wouldn't really make something easier
<jkqxz>
Deciding on the reference structure and keeping track of frame ordering and interdependency is not just a few lines.
Krowl has joined #ffmpeg-devel
galad has quit [Quit: ZNC 1.9.x-git-230-b1f873df-frankenznc - https://znc.in]
galad has joined #ffmpeg-devel
<elenril>
should also be useful when we decide to merge x264 into lavc
<courmisch>
the trolls are partying
<Lynne>
jkqxz: ah, I thought "It isn't" meant it didn't have the ref code
galad has quit [Client Quit]
omegatron has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
Marth128 has quit [Ping timeout: 264 seconds]
<haasn>
who can initiate a GA vote to have a person permanently removed from the mailing list?
Marth64 has quit [Ping timeout: 256 seconds]
<Lynne>
which one?
<courmisch>
for the record, it was NG that called "exploiting loophole" in "rules" "dishonest"
<courmisch>
I dunno if ignoring TC and CC before they are renewed counts as exploiting a loophole in rules
galad has joined #ffmpeg-devel
mkver has quit [Ping timeout: 246 seconds]
<elenril>
haasn: we have no rules for initiating GA votes
<elenril>
I'm thinking we'll need some soon
<courmisch>
the GA should vote 60% in favor of having a vote to have a vote
<courmisch>
cat /etc/sender
<courmisch>
george@nsup.org 554 Known troll account
<courmisch>
woops
<microchip_>
I herd you like voting, so I put a vote in your vote so you vote while voting?
<courmisch>
sorry that was t-t-totally a copy paste error
<haasn>
can I have a vote to vote if the vote to vote constitutes a valid vote?
<courmisch>
in fact that, the "REJECT" stanza is missing
AbleBacon_ has joined #ffmpeg-devel
<courmisch>
I think first we need the FFmpeg supreme court to be defined
<courmisch>
or the FFmpeg constitutional court, depending if you pick common law or code of law system
AbleBacon has quit [Ping timeout: 252 seconds]
AbleBacon_ is now known as AbleBacon
Krowl has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
av500 has quit [Ping timeout: 255 seconds]
kurosu has quit [Quit: Connection closed for inactivity]
cone-050 has quit [Quit: transmission timeout]
iive has joined #ffmpeg-devel
<compn>
courmisch, can you ignore mr george? it seems like ignoring small time people is the best policy that i've seen
<compn>
otherwise the problem gets larger
<compn>
threatening legal action for example makes people not want to associate with people who do such things
Traneptora has quit [Quit: Quit]
iive has quit [Quit: They came for me...]
HarshK23 has quit [Quit: Connection closed for inactivity]