Video linked by URL instead of local or Youtube/Vimeo


At the moment we can either stream video through Youtube/Vimeo or add locally. I’d like an option where we can add a simple URL, which might be a video within a folder on the website or indeed another website. Possibly even though a source like Amazon S3.

The video can then be uploaded separately via FTP, but I can see various advantages with this option.


I am currently using two different approaches to do this. The first option is to use an HTML Widget and the second is to use a reference video file.

Example 1:
Enter the following code snippet into the HTML widget…

<video width="100%" height="100%" poster="" controls="">
<source src="" type="video/mp4">
Your browser does not support the video tag.

In the above case, “video” and “/video” entries initiate and terminate an HTML5 video code segment. The “width=” and “Height=” code elements set video display scaling as a percentage within the browser’s current total display window allocation. The “img=” code segment points to an image to be used as the video player’s “poster” frame. (In this case, I used a project image already stored as a project asset. Normally relative addressing would be used here but I used absolute addressing to maintain external functionality. NOTE: for best results, poster image should have the same dimensions/aspect ratio as the sourced video file display.) The “controls=” code segment tells the browser to display the default video controls. The “src=” code segment points to the absolute URL of an external video URL or the relative URL of a video file stored locally on your website. (In this example it points to the external URL for an Apple movie trailer.) The “type=” code segment tells the browser that the MOV file contains MPEG-4 audio/video data. And the last text line included in the code is an error trap indicating the browser does not support HTML5 video playback.

Example 2:
In this example, I made a reference video pointing to a video file already stored on a server as depicted below…

In this case the reference file is only 185 bytes but points to more than 100 MBs of audio and video data on the Internet. If you then change the MOV extension to MP4, the file can then be imported and used like any “small” standalone MP4 video asset in the Blocs app.


Old topic but still a feature I need for posting several dozens of videos ranging from 2.5 to 4.5 hours in length. However, when I recently tried using the Blocs v3.1.2 HTML Widget bric to insert code based on the Video bric, I ran into a new problem. When I inserted following code into the widget editor:

<div class="embed-responsive embed-responsive-4by3 ">
<video class="embed-responsive-item" poster="img/09CCIS.jpg" controls="controls" data-src="Video/09CCIS.m4v" >
Your browser does not support HTML5 video.

This is the HTML code that was generated:

<div class="embed-responsive embed-responsive-4by3 ">
<video class="embed-responsive-item lazyload" poster="img/09CCIS.jpg" controls="controls" data-src="img/lazyload-ph.png" data-src="Video/09CCIS.m4v" >
Your browser does not support HTML5 video.

Which, for some unknown reason, included this little gem of extraneous code between the poster image reference and the video URL reference that breaks proper playback of the URL referenced video:


However, if I manually delete this code tidbit from the webpage HTML file, then the video plays normally as originally expected. Unfortunately, each time I use the “File > Export > Quick Export” option to publish the project to my MacMini server, the unwanted code is re-inserted back into the file and must again be purged. Is this a bug or am I doing something wrong?


Thanks, @JayWalker for taking the time to explain this. It was really easy to understand.


I think this is fundamentally the reason why Google doesn’t index images or video if lazyloading is enabled in Blocs. Everything stops at that lazyload-ph.png file. It would be good to report this as a bug. Google lists methods that don’t cause this problem.


Somebody wrote something about that issue when you are working with code widget. Try to make the preview off.



I also read the “Shenanigans” post and so “Preview” was turned off when I ran the tests. My question is primarily an attempt to determine if entry of the problematic additional code is a bug in Blocs 3 or if the app is programmed to do this for some specific, albeit unknown to me, reason. As previously indicated, my code is based on the Video tag code generated by the Blocs 3 Video bric as depicted here:

<video class="embed-responsive-item lazyload" poster="img/02TBC.jpg" controls="controls" data-src="vid/02TBC%20copy.mp4">
Your browser does not support HTML5 video.

When I compared the output of the Video and HTML Widget brics, I noted this difference in the code generated for the webpage and decided to manually remove the offending “data-src” reference that, as mentioned above, appears to break Video tag processing. Not being a web programmer, I do not understand what, if any, of the HTML Widget code is generating the additional unneeded/unwanted code and is the primary reason I used a functional approach to locate the problem. Currently in the process of documenting this problem in minor detail for SJAUG (South Jersey Apple User Group) members who may be interested in using Blocs as an alternative to other, more traditional design applications. Just wanted to know if this was an easily fixed bug or intentional function within Blocs. For any who may be interested, have added a rendering comparison of unpurged and purged code on my TEST website that mentions this problem to fellow group members.


Thanks for the link. Will see what I can learn further about this topic a bit later today after reviewing current recommended bug reporting procedures.


In the event anyone else needs to add further information regarding this or other code fragment issues, a formal Bug Report has been sent.

Follow-up for the benefit of any interested Blocs users:
Apparently it took Norm less time to troubleshoot the original problem than it took me to realize how to the fix issues created by Norm’s simple solution—i.e., to simply disable the '“Lazy Loading” option in the “File > Export > Export Project > Export Settings” window. Once this is done, the new setting is “remembered” when you next use the “File > Export > Quick Export” option and continues to prevent generation of the offending code. Unfortunately, he neglected to realize and/or point out that this also disabled use of “embed-responsive” code previously copied from the Video bric webpage HTML file output (with “lazy Loading” enabled) to the HTML Widget. Once this code was also removed, the videos played correctly using URL references in the HTML Widget.