-
Width and Height reversed
Hi,
I’m having some issues with FFMPEG reading video Width and Height backwards.
This happens through a web application when I upload a vertically oriented video. Basically anytime the height is greater than the width the values get switched for some reason. Has anybody had this problem before?
Any help is appreciated. Thanks.
-
9 Replies
-
Is this a problem with ffmpeg or with the web app you are loading the video to? i.e. does it play correctly on your computer before loading it to the web app?
If so, I would suspect that the dope who wrote the web app programmed it to assume that the larger of the two values is always the width.
-
I borrowed some PHP code that uses ffmpeg to get the video info. Here it is:
$command = ‘/usr/bin/ffmpeg’ . ‘ -i ‘ . $video . ‘ -vstats 2>&1’;
$output = shell_exec ( $command );$result = ereg ( ‘[0-9]?[0-9][0-9][0-9]x[0-9][0-9][0-9][0-9]?’, $output, $regs );
if (isset ( $regs [0] )) {
$vals = (explode ( ‘x’, $regs [0] ));
$width = $vals [0] ? $vals [0] : null;
$height = $vals [1] ? $vals [1] : null;
}echo $width . ” x ” . $height;
I don’t see anything wrong with this. I think it’s actually ffmpeg that is assuming the larger value is the width. How do I correct this? Any ideas? Thanks.
-
It doesn’t really matter what the PHP code is if you haven’t yet determined is ffmpeg is reading/encoding/whatever the file with the correct width height parameters.
Play the file with ffmpeg.
ffplay myVideoFile.xxxIs the orientation and width/height correct during playback? What does the terminal output say about the video stream when you play it? It’s output should include the frame size. If both of those are correct then you can start looking to see if PHP is parsing stdout / stderr correctly.
Or, if you like, instead of trying to parse all that goop with with PHP, you can just have the shell command return the values to you pre-parsed.
For width:
ffprobe -show_streams myVideoFile.xxx 2> /dev/null | grep width= | sed '1 s/.*\=//'For height:
ffprobe -show_streams myVideoFile.xxx 2> /dev/null | grep height= | sed '1 s/.*\=//' -
I appreciate your help. However, I am working on a hosted site. It looks like ffprobe was not installed with ffmpeg. Anyway, these commands do not work. Any ideas on how to returnn the width and height using just ffmpeg command? Thanks.
-
I would pester whoever provides the virtual OS image to upgrade their ffmpeg package. You don’t want to use ffmpeg to do this because it is strictly an encoder, so it always needs an output file. i.e. you will be re-encoding, or for best case scenario, copying the file each time you do this, which for a virtual host is a big waste of resources just to find out the width and height of the video. Especially if you are providing it for general public access and expect it to scale gracefully.
Perhaps ancient versions supported a “-vstats” option without requiring a file output back before the ffprobe utility was created, but if so that documentation is no longer easy to find.
I have a feeling that this is probably a very old version of ffmpeg, so in order to provide anything useful for you, you’ll probably need to post the terminal output that is generated for the command you are using. (in your case, what do you get from “echo $result;”)
-
Hey,
Again, thanks for all your suggestions and help. I’ve downloaded my own version of FFMPEG and run some of the other utilities (ffprobe, ffplay).
It is definitely ffmpeg that is interpreting the video wrong. Basically what is happening is that in QuickTime, the video plays as it should vertically as 720×1280. But, using ffplay or the ffprobe command you suggested before, the video is being read horizontally as 1280×720.
The file is MOV recorded on an iPhone. Not sure why this should make any difference, but maybe it does.
Any ideas at all what might cause this? And also any ideas for a fix?
Thanks.
-Aaron
-
If the width and height given by ffprobe are incorrect, then I would suggest writing a bug report to get it fixed; and include a sample video that demonstrates the problem.
https://www.ffmpeg.org/bugreports.html
-
I also have this problem and can provide more detailed information. Here’s output from ‘ffprobe -show_format -show_streams’ on a file shot by an iPhone user with Vertical Video Syndrome (see youtu.be/Bt9zSfinwFA for definition):
[STREAM]
index=0
codec_name=h264
codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
codec_type=video
codec_time_base=1/1200
codec_tag_string=avc1
codec_tag=0x31637661
width=1280
height=720
has_b_frames=0
pix_fmt=yuv420p
r_frame_rate=30000/1001
avg_frame_rate=82200/2743
time_base=1/600
start_time=0.000000
duration=9.143333
nb_frames=274
TAG:creation_time=2012-10-06 16:54:13
TAG:language=und
[/STREAM]
[STREAM]
index=1
codec_name=aac
codec_long_name=Advanced Audio Coding
codec_type=audio
codec_time_base=0/1
codec_tag_string=mp4a
codec_tag=0x6134706d
sample_rate=44100.000000
channels=1
bits_per_sample=0
r_frame_rate=0/0
avg_frame_rate=11025/256
time_base=1/44100
start_time=0.000000
duration=9.171882
nb_frames=395
TAG:creation_time=2012-10-06 16:54:13
TAG:language=und
[/STREAM]
[FORMAT]
filename=*redacted*
nb_streams=2
format_name=mov,mp4,m4a,3gp,3g2,mj2
format_long_name=QuickTime/MPEG-4/Motion JPEG 2000 format
start_time=0.000000
duration=9.171882
size=12316885.000000
bit_rate=10743169.000000
TAG:major_brand=qt
TAG:minor_version=0
TAG:compatible_brands=qt
TAG:creation_time=2012-10-06 16:54:13
TAG:encoder=5.1.1
TAG:encoder-eng=5.1.1
TAG:date=2012-10-06T09:54:13-0700
TAG:date-eng=2012-10-06T09:54:13-0700
[/FORMAT]File metadata shows it’s 1280×720(4:3), not 720×1280(3:4) ratio. Either Apple really recorded it “sideways”, or ffmpeg is lying to me (e.g. someone put in an assumption that width is always > height). Any other tools recommended (not based on libav) which I could use to confirm?
Staring at this, I see no other markers in the metadata that indicate orientation, but my eyes are tired.
-
I confirm that issue, did you happen to file a bug against ffmpeg? Did you find a workaround?
Reply to this Discussion! Login or Sign Up