Local files should resize properly on MW 1.39.x #59
Comments
kghbln
changed the title
|
This should be fixed in the develop branch! |
|
Same problem in MediaWiki 1.35, develop branches fixes it, thanks! |
|
Hello, |
|
Could you try purging the corresponding |
|
Same issue after update MediaWiki to 1.40.0, php 8.1.2 and switching to it from the "original" EmbedVideo version. Develop branche doesn't fixes it.
but they appear in source code: Thanks
|
|
Are the video dimensions visible on the filepage? Or are they missing? |
|
Is missing (unlike the pictures): |
|
Can you try purging the page and see if this helps? (i.e. ?action=purge) |
|
Already done but without results. I can try to upload a new video file... Update: unfortunately same problem with new one. |
Shoot! I'll put this back on my todo! |
|
I can also confirm the bug in v1.39.4. Pictures are shown with resolution: Videos not: I also tested the development branch yesterday without success. |
|
While upgrading from 1.39.3 to 1.39.4, I updated EmbedVideo from 3.2.6 to 3.2.7 and it caused this issue. |
|
I compared both v3.2.6 and v3.2.7 and tested some settings. When comparing vertical and horizontal videos you can see that in v3.2.6 the videos where resized for the same height:
In v3.2.7 it is resized on the same width (needed to zoom to 50% to fit it):
I only used |
|
all mp4 video files doens't have any width/height in the database, thats why the above mentioned if-clause is always TRUE.
I can't figure out how to update these entries. The width/height are not updated with the maintenance scripts:
|
|
one last test from my side. I'm now out. I'm not deep enough in the matter to understand or test anything more. Sorry. Test file resolution according to VLC: I uploaded a new file and set the withdt/height manually: On the mediawiki file page I see smaller resolutions: When inserting in a page I still have the wrong resolution: This resolution is the if-clause from v3.2.7: |
|
So these are actually two separate issues. The first issue is, that the video metadata isn't correctly retrieved by FFProbe, which results in the filehandler returning 0 for width and height. This in turn causes the if-clause to run an invalid calculation. To get the correct height the I've pushed two commits. The first one refactors the FFProbe logic, and raises the required MW version to 1.37+ The second one fixes the height calculation. |
|
Just tried it out with the development version (sorry, couldn't format it as code.): Internal error: [c9e61965368620ee7b049b8c] /index.php/ ArgumentCountError: Too few arguments to function MediaWiki\Extension\EmbedVideo\Media\FFProbe\FFProbe::__construct(), 1 passed in /extensions/EmbedVideo/includes/Media/AudioHandler.php on line 297 and exactly 2 expectedBacktrace: from /extensions/EmbedVideo/includes/Media/FFProbe/FFProbe.php(46) |
Sorry my mistake, fixed in 50d92e8 |
|
The developer branch is working. With Without |
|
While this now resizes the videos to a common size, the underlying issue still does not seem to be resolved.
|
|
ffmpeg is now installed. It was not mentioned as dependency in the description/installation, therefore it was not installed. Now I have width and height in the table for newly uploaded video: On the file page I have detailed video information, but an When implementing the video on a page with VisualEditor the first try to save the page gets an HTTP error 502, second or third try is working. When resizing the video the size is always a square: When deleting the test-video I get following error, but the video is successfully deleted: |
|
I don't know if the |
|
thank you. One thing I noticed regarding resizing: In the source it is saved as: When changing the dimensions in the source to |
|
That's indeed a very weird issue. I can't really pinpoint the origin, but the wikitext VE sends already includes the "square" size. So this seems like it is an issue with VE. I'll try to investigate, but any help is appreciated. |
Nope ) I already suspected it, but I didn't find any info that it is a requirements.
Thanks for the great job and fast response! |
|
Seems as if ffmpeg has one more issue for me... On a vertical video, it seems that the width and height are swaped:
|
I've just tested this locally and can't confirm :/ Using an example video from https://www.pexels.com/search/videos/vertical/ everything is shown correctly. If you want, you can provide me your file so that I can test with this particular example |
|
Thank you for testing. I checked my video files, and it seems that these videos (shot with an iPhone) do not have used the phone rotation correctly, therefore these are switched in the metadata. |
|
Hi @octfx, I don't know if you would prefer I open a new issue but I'm still having this problem on the master branch of this extension running against MediaWiki 1.40.1. I have No errors are logged to the PHP error log ( I've confirmed that the php user has permission to execute both those executables, and from the command line I can run |
|
If the ffmpeg call fails a warning should be generated. Can you check if the |
|
Thanks for the reply. Yes, <?php
// Replace this with the path of the file you want to probe
$filepath = '/path/to/media.mp4';
$escapedFilepath = escapeshellarg($filepath);
$cmd = "/usr/local/bin/ffprobe $escapedFilepath";
// Define descriptors for the process to open
$descriptorspec = [
0 => ["pipe", "r"],
1 => ["pipe", "w"],
2 => ["pipe", "w"]
];
// Open the process using proc_open
$process = proc_open($cmd, $descriptorspec, $pipes, null, null);
if (is_resource($process)) {
// Close STDIN pipe
fclose($pipes[0]);
// Read the outputs
$stdout = stream_get_contents($pipes[1]);
$stderr = stream_get_contents($pipes[2]);
fclose($pipes[1]);
fclose($pipes[2]);
// Close the process and get the return value
$return_value = proc_close($process);
// Output the results
echo "STDOUT:\n$stdout\n";
echo "STDERR:\n$stderr\n";
echo "Return value: $return_value\n";
} else {
echo "Failed to open process.";
}
?>giving me |
Reference
Setup
Issue
This also happens when embedding on pages with
[[File:Big Buck Bunny 1080 10s 1MB.mp4|800px]].I made sure that no local custom CSS is involved.
I do not know how 1.36 to 1.38 behave. However, they are either EOL or will be EOL very soon.
In comparison On 1.35x it works perfectly for
[[File:Big Buck Bunny 1080 10s 1MB.mp4|800px]]The text was updated successfully, but these errors were encountered: