>> Gregory Maxwell gmail.com> writes:
>>> I don't know how to figure out how much it would 'cost' to have human
>>> contributors spot embedded penises snuck into transcodes and then
>>> figure out which of several contributing transcoders are doing it and
>>> blocking them, only to have the bad us
Lets see...
* all these tools will be needed for flattening sequences anyway. In
that case CPU costs are really really high like 1/5 or lower real-time
and the number of computation needed explodes much faster as every
"stable" edit necessitates a new flattening of some portion of the
sequence
MediaWiki Bugzilla Report for July 27, 2009 - August 03, 2009
Status changes this week
Bugs NEW : 216
Bugs ASSIGNED : 35
Bugs REOPENED : 31
Bugs RESOLVED
On Sun, Aug 2, 2009 at 6:29 PM, Michael Dale wrote:
[snip]
> two quick points.
> 1) you don't have to re-upload the whole video just the sha1 or some
> sort of hash of the assigned chunk.
But each re-encoder must download the source material.
I agree that uploads aren't much of an issue.
[snip]
two quick points.
1) you don't have to re-upload the whole video just the sha1 or some
sort of hash of the assigned chunk.
2) should be relatively strait froward to catch abuse via assigned user
id's to each chunk uploaded. But checking the sha1 a few times from
other random clients that are enc
Steve Bennett gmail.com> writes:
> Why are we suddenly concerned about someone sneaking obscenity onto a
> wiki? As if no one has ever snuck a rude picture onto a main page...
There is a slight difference between vandalism that shows up in recent changes
and one that leaves no trail at all excep
Gregory Maxwell wrote:
>
> (2) you're using gif transparency and are obsessed with compatibility
> with old IE. Scaling doesn't tend to work really well with binary
> transparency.
By the way, forgot to mention this earlier, but this is actually a very
good argument in favor of outputting thumbn
Aryeh Gregor wrote:
> On Sun, Aug 2, 2009 at 1:33 PM, Gregory Maxwell wrote:
>> In other cases the gif tends to be larger, loads slower, etc. They
>> can be converted to PNG losslessly, so you should probably do so.
>> What am I missing?
>
> That a lot of people don't know the above and upload GI
Brion Vibber wrote:
> On 8/2/09 7:26 AM, Ilmari Karonen wrote:
>> It seems to me that delivering *static* thumbnails of GIF images, either
>> in GIF or PNG format, would be a considerable improvement over the
>> current situation. And indeed, the code to do that seems to be already
>> in place: ju
On Sun, Aug 2, 2009 at 1:33 PM, Gregory Maxwell wrote:
> In other cases the gif tends to be larger, loads slower, etc. They
> can be converted to PNG losslessly, so you should probably do so.
> What am I missing?
That a lot of people don't know the above and upload GIFs anyway, and
until we can f
On Sun, Aug 2, 2009 at 10:26 AM, Ilmari Karonen wrote:
[snip]
> It seems to me that delivering *static* thumbnails of GIF images, either
> in GIF or PNG format, would be a considerable improvement over the
> current situation. And indeed, the code to do that seems to be already
> in place: just se
On 02/08/2009, at 5:36 PM, Brion Vibber wrote:
> Looks like Andrew put together an updated patch a couple months ago
> but
> didn't have a chance to test and confirm it was working properly.
> Anyone
> care to take a peek?
I can possibly poke this tomorrow, must have slipped through my
fing
On 8/2/09 7:26 AM, Ilmari Karonen wrote:
> It seems to me that delivering *static* thumbnails of GIF images, either
> in GIF or PNG format, would be a considerable improvement over the
> current situation. And indeed, the code to do that seems to be already
> in place: just set $wgMaxAnimatedGifAr
2009/8/2 Ilmari Karonen :
> It seems to me that delivering *static* thumbnails of GIF images, either
> in GIF or PNG format, would be a considerable improvement over the
> current situation. And indeed, the code to do that seems to be already
> in place: just set $wgMaxAnimatedGifArea = 0;
> So,
Currently, server side GIF thumbnailing on Wikimedia sites is disabled
entirely by setting $wgMediaHandlers['image/gif'] =
'BitmapHandler_ClientOnly';
This causes all GIF files to be send to the browser at original size
regardless of what size has been requested.
While most folks seem to have
Hoi,
Because it is no longer obvious that vandalism has taken place. You have to
look at the changes.. the whole time to find what might be an issue
Thanks,
GerardM
2009/8/2 Steve Bennett
> On Sun, Aug 2, 2009 at 12:16 AM, Tisza Gergő wrote:
> > Gregory Maxwell gmail.com> writes:
> >
> >>
On Sun, Aug 2, 2009 at 12:16 AM, Tisza Gergő wrote:
> Gregory Maxwell gmail.com> writes:
>
>> I don't know how to figure out how much it would 'cost' to have human
>> contributors spot embedded penises snuck into transcodes and then
>> figure out which of several contributing transcoders are doing
2009/8/2 Marco Schuster :
> Really? If they simply don't publish the source (and the binaries), then the
> only possible way for an attacker is fuzzing... and that can take long time.
I believe they use ffmpeg, like everyone does. The ffmpeg code has had
people kicking it for quite a while. Tran
On Sun, Aug 2, 2009 at 2:32 AM, Platonides wrote:
> > I'd actually be interested how YouTube and the other video hosters
> protect
> > themselves against hacker threats - did they code totally new
> de/en-coders?
>
> That would be even more risky than using existing, tested (de|en)coders.
>
Reall
19 matches
Mail list logo
