Hi,

I'm experiencing something similar to this. With the flash fallback, any MP4 video I play has the wrong aspect ratio, and is squished up on the right hand of the screen, while 33% of the left side is just black. I'm not using a conventional browser - its a Samsung Smart TV (the TV has no html5 video support, but it does have flash for some reason).

EDIT: looked at the actionscript. the dimensions are correct in _model.metadata, but they are overwritten by the dimensions in _uiVideo.videoWidth and _uiVideo.videoHeigth, back to 100x100. I commented it out, now it works perfectly

@henrydn Which line did you comment out? Can you link to it?

@heff here you go. You can just ignore the logging stuff I added : henrydn@c3dbf41

@henrydn thanks! That should help dig into the issue.

Found a possibly related post.
http://forums.adobe.com/thread/430777

Hi,

have the same problem, image is squashed in top left, when going to FS and back, everything goes back to normal and video fills player.

Just ran into this problem with FLVs produced by the NGINX RTMP module (#1951). Putting this here in case other users have better Google foo than I.

I've tried the video-js.swf build at https://github.com/henrydn/video-js-swf/blob/master/bin/VideoJS.swf with no luck. I believe @henrydn is experiencing a different issue to @teu and I.

Running the files through ffmpeg with -codec copy (copying the streams into a new container) works. It definitely adds an onMetaData marker, and increases the filesize by over 300 bytes (mostly in the header, but five bytes are appended. I plan to read up more on the flv spec (chapter one in this document for those interested) to see what I can do about perhaps modifying the original file inline.

@garymoon Ran into the same issue today. I had somewhat of a convoluted setup, but this is just my $0.02 to the issue.

I have Wirecast sending RTMP to nginx, which pushes it to another nginx, which pushes it to wowza. Yeah I know, crazy, but this is the only way I could have achieved what I wanted on a short time.

Anyways, the first nginx had "meta copy;" set. Removing that fixed the issue of having the squished corner video. FWIW.

I still am experiencing this using V5.0.0rc2

I've tried using the publisher demo in Red5 and my laptop camera along with the my phone using a free Broadcaster app. It only seems to be an issue in Video JS.

If I full screen and exit, things seem to work fine again. I'm not sure what codec is being used (the two broadcast techniques seem to not show many options here).

I do notice that when I playback via red5's publisher app, there is a NetStream.Video.DimensionChange event. I'm guessing incorrect data is getting picked up from there... is there any chance this could be overriden in certain cases?. I'm using red5 as my backend server.

Because our Nginx instances are being streamed to by a wide variety of clients, the meta setting only fixed some of the recordings and not others. We're quite happy with running the video through ffmpeg post-recording - not only does it ensure correct metadata, but also gives us some flexibility in the container we're using. It takes under a minute to process a video several GB in size (since mostly it's just copying from one file to another) on AWS instance stores.

Yea, I found one way round was to manually resize the video. It's somewhat hacky, but for live videos I don't think using ffmepg / avconv is really much of an option.

    video.on 'play', ->
      tmp = do video.height
      __.setTimeout ->
        video.height tmp - 1
      , 500
      __.setTimeout ->
        video.height tmp
      , 1000

I'm using v4.12.9 ( I think that's the latest that bower have) and still have this issue. @virtualfunction Can you explain more about the fix?

My code above is coffeescript, it's hardly a fix, but more of a kludged workaround. All I'm doing is getting the height, setting it to be 1 pixel less 500 ms later and then restoring it 500ms later. the video var is just whatever the result of videojs call. I dunno if they are ideal setTimeout values (it might work with smaller values - all I do know is that you need to use setTimeout to make sure it happens after a repaint.

It seems that some of the metadata become available only after the SECOND call of HTTPVideoProvider::onMetadata() though _onmetadataFired flag was preventing them from being processed.
I made a hotfix 7f0294d for this issue, and it seems to work well for me.
Here is a compiled swf, and I will appreciate it if any feedback.

"Here is a compiled swf, and I will appreciate it if any feedback."
404

This swf does not solve the problem.

I think there are a couple different issues being discussed in this thread that are unrelated. I have the very same issue as the original poster "Heff" wrote back in 2013 where my video is being vertically squashed and there are black bars on the right and left side of the video. This happens frequently for higher bitrate videos such as 720p and 1080p but seems to be fine for lower quality videos. I'm also using the HLS plugin so if the 1080p quality video loads first, I get the issue 9 times out of 10.

The SWF that "qpSHiNqp" provided did in fact solve this issue for me. The link is no longer valid but the link that "Dimitros-pts" also included above in his post does in fact work and is the SWF I used.

With regard to "Dimitros-pts" and his issue, I think he is experiencing a different issue that the original poster "Heff" wrote. With "Dimitros-pts", he is experiencing a video that is 100x100 in size that doesn't fill the player window whereas Heff and myself have a vertically squashed image with black bars on the side. I don't think the SWF files was intended to fix the 100x100 issue, but instead fix the issue that I described (vertically squashed). That's why the SWF didn't work for him.

With that being said, I'm hoping there is a real fix to this problem that gets included in the actual build so I don't have to use a one-off SWF file with a fix that seems to be only a band-aid on the issue.

Any thoughts on what can be done to integrate into the current version? Is there a better way to fix this?

Resizing the height works, however, the video always remains square, regardless of whether you increase the width or not. CSS transformations also do not stretch the video horizontally. Is there a way to accomplish this or is there a fix?

I had added in onNetStreamStatus event "DimensionChange" and it's work
digitalStyx@be6de6c

@digitalStyx thanks! that fixed it for me too!

Is there a compiled swf with @digitalStyx 's fix somewhere? I also have the 100x100 issue...

@mattpepin check it https://github.com/digitalStyx/video-js-swf/tree/master/bin-debug

I am having the same issue as the first post, vertical squash until I toggle full-screen on. I tried videojs versions 5.6.0 and 5.7.1.
Also, the swf provided by @digitalStyx did not fix it for me. It actually made it worse as the image stopped adjusting itself when toggling full-screen.

I tried manually setting the width, height and aspectRatio of the player, but that did not work either. Setting width, height, and aspectRatio updated the values on the player object, but did not change the displayed image at all.

I tried some logic on 'play', similar to the band-aid fix suggested by @virtualfunction. It did not work, but I found that videoWidth and videoHeight returned 0, and after a delay they returned the correct values. width and height return 0 and aspectRatio returns undefined at any time until I set them manually.

Resizing the browser window triggers the video to display the correct image aspect ratio, just like toggling full-screen. What is it doing on resize? Maybe that is the key for a band-aid fix until the swf is fixed.

@adgoncal What kind of video/codec/protocol/system are you using with VideoJS. For example I had a problem with rtmp through WoWza system. Wowza not gave me the appropriate metadata. In nginx-rtmp module everything was correct.
Are you using video.js for playing livestream?

Yes, it is live stream using rtmp. The metadata is correct.

I'm experiencing the same issue - RTMP through CloudFront, my 16x9 video (encoded mp4 at 720x480) shows as pillarboxed 4x3 until going full screen and back - or even moving the slider on the timeline fixes it.

In my case the new swf file by @digitalStyx fixed it.

I recently started having to add more RTMP streams for a project at work. I just figured out what I need to do to construct the proper URLs from the API we're integrating, and the small 100x100 video in the upper left corner of the player started to appear. A different RTMP stream I have that's not related to the API doesn't have this issue at all. Is there a permanent fix for this issue in the works or a work-around I can do to solve this problem?

Hello guys, I had experienced the same issue while developing an RTMP server. If the server did not send an "onMetaData" to the player，then the image appear on the left top. If the server had send the "onMetaData" with "width, height ..."， then the image was all right.

I faced the problem with RTMP live streams from iOS device. The video isn't shown at all until I resize the video container.

digitalStyx's patch fixed the issue.

I also faced the problem with RTMP Live Streams in web, the video image is squashed in top left ,
digitalStyx's patch fixed the issue. replace video.swf with VideoJS.swf can relsove my problem, thanks for digitalStyx

@digitalStyx want to submit a PR with your fix?

thanks for digitalStyx

@gkatsev any news for this issue? I mean, integration of the patch into the code base and update SWF for video.js.

@fox-hellraiser The change seems reasonable but unfortunately, I don't have any test content to try it out with. Do you have content I can try or how to generate content that would fail? (The link the OP is no longer has data).

@gkatsev unfortunately, I do not have it either, and also cant reproduce now.

Hi @gkatsev

This problem still occurs. If publisher uses an custom swf (written by himself) to live streaming and it has not been implemented @setDataFrame(no one implements this :)) like as https://helpx.adobe.com/adobe-media-server/dev/adding-metadata-live-stream.html and also media server does not add own metadata, function onMetaData in videojs.swf it never fires.

In digitalStyx@be6de6c code onMetaData(new Object()); can be also in NetStream.Play.Start . I tested it several times and it works every time, of course it is only needed if we do not have the possibility to modify the publishing swf.

I will add that I have a more complicated case, because I combines separate audio and video sources on the server side as similar in https://github.com/WowzaMediaSystems/wse-plugin-avmix and I also have to add a block of metadata.

Thanks @digitalStyx for the fix and thanks @nicklive for providing a test case.
I've just merged the change and a release is imminent.

It's out now as 5.4.2! Thanks so much for everyone's patience with this!

@gkatsev can you also update https://github.com/videojs/videojs-flash with new version of "video-js-swf" and then https://github.com/videojs/video.js with new version of "videojs-flash"?

videojs-flash 2.1.2 has been published with the new swf.