User talk:Zhuyifei1999/Archive 24

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Quality on video2commons

Hi Zhuyifei1999, I have uploaded the video file:Chroicocephalus ridibundus, Viveiro.ogv with video2commons tool, but it has a lot of "lines/artifacts" that the original video didn't had. Format webm has more quality? How can I configure the tool to get more quality? I don't mind to wait. Bye, --Elisardojm (talk) 18:29, 23 January 2017 (UTC)

@Elisardojm: Could you try webm? OGG Theora compression is inferior to VP8 compression in WebM. Also note that the same filename may not work due to upload warnings. You might have to change the filename a bit and rename it after the upload. --Zhuyifei1999 (talk) 18:40, 23 January 2017 (UTC)
@Elisardojm: Actually no. The webm 1080p videoscaler output at [1] looks just fine for me, except for some interlacing issues. I can't check the uploaded OGG as it is too large for my bandwidth. Have you checked the quality of the uploaded video (output from video2commons) or the down-scaled videos (output from videoscalers)? --Zhuyifei1999 (talk) 19:26, 23 January 2017 (UTC)
Hmm. Lower res video do not seem to have interlacing issues... I'm looking into it --Zhuyifei1999 (talk) 19:37, 23 January 2017 (UTC)
Downloaded part of the file:Chroicocephalus ridibundus, Viveiro.ogv and the (temporarily stored) mp4 file upload to v2c, both have interlacing issues, so it's not a v2c problem --Zhuyifei1999 (talk) 19:44, 23 January 2017 (UTC)
Hey..., Did you change anything to the file? When I reviewed the video, quality was more poor, the fish had pixeled lines and now it had dissapeared. And the transcodification states were different, there was only a few, now there are a lot. Perhaps, the upload was in progress when I checked the video? I'm uploading anothertime the video in webm format, with this we could compare qualities. Bye and thanks for your help, --Elisardojm (talk) 19:47, 23 January 2017 (UTC)
@Elisardojm: I didn't change anything. Wikimedia's videoscalers was busy scaling the videos for regular use. Lower qualities gets scaled faster. Right not I'm working on deinterlacing the video. --Zhuyifei1999 (talk) 19:56, 23 January 2017 (UTC)
Ok file has been deinterlaced --Zhuyifei1999 (talk) 20:12, 23 January 2017 (UTC)
Ah, I understand now...
The webm version it's just now uploaded too, File:Chroicocephalus ridibundus, Viveiro2.webm, but I don't know what it's the best... Bye, --Elisardojm (talk) 21:58, 23 January 2017 (UTC)
No..., the ogv version is more sharp, isn't it? Bye, --Elisardojm (talk) 22:02, 23 January 2017 (UTC)
@Elisardojm: That's hard to tell. The quality should be similar, but since I've deinterlaced the ogv version and not the webm, I'd prefer the ogv version instead. --Zhuyifei1999 (talk) 07:38, 24 January 2017 (UTC)
And, how can I deinterlace the vídeos at Commons? Bye, --Elisardojm (talk) 19:06, 24 January 2017 (UTC)
As far as I know, there is no tools.wmflabs.org tool that can do deinterlacing. You can choose to:
  • Request at Commons:Graphic_Lab/Video_and_sound_workshop. This is probably the easiest way, but you have to depend on others.
  • Install a software capable of deinterlacing. I use FFmpeg.
  • Search online. I can't guarantee that this method works though.
--Zhuyifei1999 (talk) 19:14, 24 January 2017 (UTC)
Thanks!! Cheers, --Elisardojm (talk) 20:01, 24 January 2017 (UTC)

File:Wybory 1989 grupa 4 plakatow wyborczych Wiki.jpg

Thank you very much,

Paul Fishman PL (talk) 15:53, 25 January 2017 (UTC)

FlickreviewR 2 Pass and then Issue

I've noticed over the past month or so that there are a couple images, like File:Get Out of Jail Free Card.jpg, that FlickreviewR 2 passes, and then says size_not_found seconds later. I've ended up undoing the size_not_found edit on most of them, but that seems like a bug for the bot. Elisfkc (talk) 17:24, 26 January 2017 (UTC)

Hmm. This is really weird. My best guess would be that they are two bot runs. The first passed, and mediawiki fails to update the category in time before the second bot run, and by chance the second one fails (what is this chance even?!). I just raised the delay between bot runs to a minute, hopefully that will avoid it. --Zhuyifei1999 (talk) 17:38, 26 January 2017 (UTC)

Hi. The tool may need to have a means to self-intervene when it has tried and failed to add a flickr url after a number of iterations. In this situation, the url that the bot is trying to add is on the blacklist, and it just keeps trying to add and add and add and ... the url. Maybe it needs a count of attempts to add a url for an image, and after that failure it writes the image somewhere for manual intervention. In this situation I have deleted the problematic file.  — billinghurst sDrewth 09:08, 28 January 2017 (UTC)

Alright that error is ignored during each bot run, so that other images aren't affected. I'll do a bot test. Note that the script gets restarted very frequently (there's a wrapper that, regardless of the exit status, will restart the script anyhow after 60 seconds the script exits.), so it will look like being stuck in an infinite loop anyhow. --Zhuyifei1999 (talk) 09:43, 28 January 2017 (UTC)
Yeah the commit works as expected. Thanks for notifying me :) --Zhuyifei1999 (talk) 09:48, 28 January 2017 (UTC)

TaskError

Hi. I got this error for several files: "An exception occurred: TaskError: /usr/bin/ffmpeg -y -i /srv/v2c/output/c96bae634e0b6155/dl.mp4 -threads 0 -skip_threshold 0 -bufsize 6000k -rc_init_occupancy 4000 -qmin 19 -qmax 19 -vcodec libvpx -f webm -ss 0 -aq 6 -acodec libvorbis -pass 2 -passlogfile /srv/v2c/output/c96bae634e0b6155/dl.mp4.webm.log /srv/v2c/output/c96bae634e0b6155/dl.mp4.webm Exitcode: 1". --Sporti (talk) 07:12, 29 January 2017 (UTC)

I'm looking into it (running it manually without muting the verbose information). They are large files so it'll take some time --Zhuyifei1999 (talk) 07:53, 29 January 2017 (UTC)
The error I see is file size limit exceeded. Somehow for Krog čez Javor _ Lap Over Javor the 1.8G mp4 got bloated into a 5G webm at 00:58:47.58, hit ulimit, and was forced to terminate. Perhaps the encoding quality is too high for such fast-moving videos. YouTube seems to encode them at a lower quality. --Zhuyifei1999 (talk) 15:06, 29 January 2017 (UTC)
I guess those will have to wait. Trying one with VP9 and another one to ogv to see if this changes the size. --Sporti (talk) 16:09, 29 January 2017 (UTC)
VP9 will probably time out. If I remember correctly, there were one site that claim it to be 50x slower. (And Opus is probably still broken) Ogv will probably result in an even larger size. --Zhuyifei1999 (talk) 16:24, 29 January 2017 (UTC)
Yes both ended with TaskError aswell. --Sporti (talk) 08:11, 30 January 2017 (UTC)

18:45, 30 January 2017 (UTC)

19:45, 6 February 2017 (UTC)

Parsing error?

Hi, can you work out what the possible parsing error identified on File:An Iron Age Gold stater from ESSEX NULL Celtic Coin Index reference, 98.022 (FindID 328137).jpg would have been? As the very large batch upload is near the end of its run, I'm concerned that we avoid mass-marking parsing errors that may not be there. Thanks -- (talk) 19:03, 8 February 2017 (UTC)

Most likely false positive. They keep happening ever since the link updates are moved to job queue. Normally the bot will remove it after a few hours. --Zhuyifei1999 (talk) 19:25, 8 February 2017 (UTC)
Thanks. Drop me a note if there's anything for me to be concerned about. -- (talk) 20:06, 8 February 2017 (UTC)

Hi, per Jasonanaggie the uploader intends to re-upload this huge video. It's a technically interesting case discussed in Commons:Categories for discussion/2017/01/Category:Video_display_resolution_0_x_0, and the file page (license, author, category, cleanup request, about an hour of my time) was already fixed. @Jasonanaggie: Therefore it might be simpler to restore the good file page and wait for the correct video, instead of starting from scratch. –2A03:2267:0:0:5535:3CA8:BFE6:19FB 08:20, 9 February 2017 (UTC)

What do you mean by wait for the correct video? A broken file by itself is a valid reason for deletion (Commons:Deletion_policy#General:_speedy_deletion lists corrupted files), there's no point to keep a broken video forever waiting for a "fixed" version. If the correct video is already uploaded, you're free to poke me or any other admin for a history merge; otherwise, you can also request for a copy of it's file description page. --Zhuyifei1999 (talk) 09:09, 9 February 2017 (UTC)
I mean that a speedy deletion was a bad idea for a mostly solved problem (sans new upload), where the edit history demonstrates serious bugs: The uploader knows {{PD-USGov}}, and a tool creating unsuited Special:Upload defaults like {{own}} and {{CC-BY-SA}} is dangerous for all users. A formal UNDEL + history merge could waste more time, the speedy fix hides the symptom for non-admins, there are unsolved technical issues with this case. –2A03:2267:0:0:5535:3CA8:BFE6:19FB 10:31, 9 February 2017 (UTC)
The file was uploaded with the toollabs:videoconvert tool; you're free to contact its maintainer User:Prolineserver about it. Regarding this specific file, it is an invalid EBML with error "the data size of the entry exceeds the number of bytes remaining in the parent entry (file position #47)". If further investigation is needed, I can temporary undelete this file if necessary. --Zhuyifei1999 (talk) 13:52, 9 February 2017 (UTC)
Thanks for pinging the author of this tool here, maybe they are still around and contribute a phab:-link to show that it's a known problem. While waiting for that to happen somewhere I've introduced the uploader to the secrets of COM:CSD vs. bulk deletion requests. @Rehman: Interested to offer a 3rd opinion on CSD here? My one and only attempt to get a 3rd opinion on UNDEL related to speedy deletions ended inconclusively. –193.96.224.16 07:58, 12 February 2017 (UTC)
Hi 193.96.224.16. I'm not too sure if I understand you correctly. As Zhuyifei1999 stated, once the fixed version is uploaded (on the same or different file name, doesn't matter), we can easily do a history-merge, it's no big deal. I can help you get that done in not time, once the new file is in. But for now, undeleting the corrupted file is not the way to go. Let us know if you need any further clarifications. Kind regards, Rehman 08:06, 12 February 2017 (UTC)
Thanks for info, I wasn't aware of "history merge is easy". However, it's not directly related to "exercising elevated rights SHOULD NOT IAR". IOU resolved: –2A03:2267:0:0:84D:D0E9:3511:C546 08:51, 12 February 2017 (UTC)
Look, what are you talking about? Deletion of corrupted files is per policy and not en:WP:Ignore all rules. And I have absolutely no idea what are you talking about with IOU --Zhuyifei1999 (talk) 09:00, 12 February 2017 (UTC)
Hi, I tried to use this file as an example for at least one technical problem in a CfD (see above), you speedily closed a DR as deleted, maybe interpreting it as "uploader request" CSD G7, I asked for an undeletion, you said no, let's agree to disagree, I'm delighted that I got a 3rd opinion without UNDEL, and not getting the 3rd opinion I hoped for is a good thing, otherwise why would I ask? Have a nice weekend, wasting precious admin time in an attempt to report a technical problem was never my plan, I'm sorry. –2A03:2267:0:0:84D:D0E9:3511:C546 09:44, 12 February 2017 (UTC)
Regarding this technical issue, videoconvert's transcoding is on tool labs grid engine with ubuntu trusty (14.04 LTS)'s libav. It has numerous issues that I don't want to go into here, because of my bias against that tool. --Zhuyifei1999 (talk) 09:51, 12 February 2017 (UTC)

18:06, 13 February 2017 (UTC)

Your feedback matters: Final reminder to take the global Wikimedia survey

(Sorry to write in Engilsh)

VP9

I was encoding those UHD videos as VP9 (if they worked) so that the created file would be less incredibly large. - Reventtalk 22:18, 18 February 2017 (UTC)

It takes forever to encode them... --Zhuyifei1999 (talk) 04:02, 19 February 2017 (UTC)

Could you explain the strange behaviour of FlickreviewR 2? --jdx Re: 17:12, 19 February 2017 (UTC)

Not sure. This was asked by @Elisfkc: earlier where I gave the best explanation I can think of, and did a modification to the bot's looping script (which wraps outside the main python script) to (hopefully) decrease the rate in which this happens. (Any ideas whether it did?) --Zhuyifei1999 (talk) 00:29, 20 February 2017 (UTC)

19:25, 20 February 2017 (UTC)

Thanks for video2commons

Hi, I only wanted to thanks you for that great tool video2commons!! :) Cheers, --Elisardojm (talk) 11:51, 21 February 2017 (UTC)

19:55, 27 February 2017 (UTC)

FlickreviewR 2 leaving behind images

At the moment, it seems that your bot is leaving images behind on Category:Flickr review needed. For instance, these (File:An A350 gets it winglets (32927117661).jpg, File:An A350 gets it winglets (32927122251).jpg, & File:An A350 gets it winglets (32927125031).jpg) images that I uploaded at 16:18 on 23 February 2017 have not been reviewed, but at least 13 other images I have uploaded since (like File:Newark (32257249203).jpg & File:Sailors assigned to USS Coronado swim in the South China Sea. (33030626916).jpg) have been reviewed. I don't know why it is doing this, but I figured I'd give you a heads up. Elisfkc (talk) 17:29, 23 February 2017 (UTC)

I see a ton of errors in the logs in the review of File:Entrevistas Diversas (31828600794).jpg, will look into it tomorrow --Zhuyifei1999 (talk) 19:05, 23 February 2017 (UTC)
Flickreviewr attempts to download the original version of that file, but it redirects to an image that shows "this photo is no longer available". The bot then crashes immediately after that due to unexpected inter-site redirect. --Zhuyifei1999 (talk) 08:31, 24 February 2017 (UTC)

23:23, 6 March 2017 (UTC)