[IMC-DC] WebM video cannot be uploaded, Dada can't recognize the container

[Luke Kuhn]

And the next update to Kdenlive will fix a problem that cuts off the end of Webm videos and prevents the length of the video from being readable in "properties" or to the browser, so users can slide the progress bar to a desired part. Thanks, will test with existing files, one short but a perfect Webm, one with the end-of-file issue, shortly.



> From: cbelcher at alchymedia.com
> To: lukekuhn at hotmail.com
> CC: imc-dc at lists.indymedia.org
> Subject: RE: WebM video cannot be uploaded, Dada can't recognize the container
> Date: Fri, 31 Dec 2010 22:07:18 -0500
> 
> I'll adjust the mime type list tonight.
> 
> -original message-
> Subject: WebM video cannot be uploaded, Dada can't recognize the container
> From: Luke Kuhn <lukekuhn at hotmail.com>
> Date: 12/31/2010 8:29 PM
> 
> 
> Right now the site cannot accept WebM video for direct upload in the way it will take mp4 video, as I just verified by a pair of tests.  Here is the text sent for an attempt to upload WebM video:
> Editorial Administration> Article> updateAttempted MIME type spoof. The file "Year_In-Review_test_SHORT.webm" has a MIME type of "application/octet-stream" but suffix is ".webm".
> 
> Current versions of Chromium and Firefox 4 open these without problems, still need to check a "default" install of Firefox 3.5 from a live disk.  If I send MP4 files, even with the headers in front, the firefox and Chromium plugins want to download the entire video before beginning to play it, which is a serious problem. Even worse,  browsers without added, patent-busting codec support(like I always install) cannot play H264 at all and Firefox instead of popping up a list of programs, pops up a directory list. Only someone hacker enough to find the executable for their external media player can then play them unless they download them first, then open them in something like Quicktime or Mplayer.  I do not know if a "typical" Windows machine, with the widely used but vulnerable quicktime plugin, or an Apple machine with a default install, can handle H264/mp4/headers in front files as incrremental downloads-or at all, as I do not have any machines with these OS's installed.
> WebM was explicitly written to bypass software patents by btarting from scratch. Any browser that can ever play it should be able to play it from a totally default installation, if not now, within a few update cycles. That will mean that any website that can accept the file will be able to offer it at least for a download the browser can then automatically play, like a "loaded," patent-defying browser install  can do now with an MP4 from our site. 
> Trouble is, this new format is newer than a lot of website programs, Dada obviously an example. The site does not recognize the container, which did not exist when Dada was written. H264 is also newer than Dada, but it goes into a pre-existing mp4 container that is just a modified Quicktime container, and Quicktime was around when Dada was still being maintained it seems.  WebM, by comparison, had to be both a new codec and a new container to get around the patents, thus it is a brand-new Mime type treated by Dada as a "mime spoof"
> As such, the file becomes an unknown "octet stream" which has to be treated as an executable until proven otherwise for obvious reasons.
> 
> 
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> mQGiBElz9bERBADHbO/o4DHTv5tNDs0N/QCL2nXKbLDMwLJatti6QtEDOB98yNeW
> 1oKaJ4B9kWJQanMy4fZZLPBriYybxUudU5RCqKY64KK3Pnc9oAMuYk5PxVO+7hrx
> 8GIShwJtEFVBpS4K59Re3VTK6r6uBNgBfteST3jy/XvuvXQSWi9408lCswCgnnGK
> KYYoOiI4G6k5WJaURzWn6vcD/2lW4sEUFnCfVSFuTdP0/CSJQq4XUJsys1thsm6W
> 320u7wt8VEvXUV8HfzmcqnYj9Tpi51XMCvqpi1vb2awxEE4PZ2AtKgWXkqfJHzl1
> IyqtGHyf5JOQUQJGdkf571f61cJhtyWCmlTMu9TLd5NilwwPtxMTrQSzA+f1xlaH
> +hneBAC1invLXDeypGmPr6buv1LYfaK3PMpwjAhxYvCKBsqjSk/KYiiliHyNIFnq
> xZdhTBLS6BjVJ7lNUHbKHmICToDaxbuTQdIKbBjMCAzf3xLZCiRP3F3jPF66QDO/
> iDTLzKkvjjNwIliI5xbUGhDQu3ym842NbmsrGBoE4b75S+5DzLQbTHVrZSA8bHVr
> ZWt1aG5AaG90bWFpbC5jb20+iGAEExECACAFAklz9bECGyMGCwkIBwMCBBUCCAME
> FgIDAQIeAQIXgAAKCRCrYZ03I1TDoo14AKCapTyOXADsXtR9oAjvSwAbF/zNIgCe
> OQvVHgmQ266jsNq1alG38b4UHzu5AQ0ESXP1tBAEALhyO0p3hLYVywLkgUEImo1M
> qthrNk6gIMdRKMULSHtyCQWz6trl8W/hqz8dLdlYAM7Mxv681PJHCC4PEo9bYIdk
> K7QJT62A8mQCHOtmX7uvGgeZBH53mdUct0D7LUyDW/mOxUp/yVy49LUhqO4YcNiA
> NdCk1/fzZq9Yc3XouZTTAAMFA/45PsuZ12ZZdZSCj0PH02ByN95qVzXYP7714eY2
> IFcFImuFsGqf3vrkbKPAhmypHDdzFIBuAyP2VkMW3T/2JPNtY7VelD6B1mUEJGvd
> rQCavsYox98QMAg34aD+UcqzDwwSPa+fDfy9JQIGQeUPhMGrzBc+ZGAvtq7xNMn9
> 6gqxnIhJBBgRAgAJBQJJc/W0AhsMAAoJEKthnTcjVMOiQBYAnjqEF54U0HUdJ3JE
> oYo/l5t7j7RRAJ98TzjlIc1pGxlnWBE91IIUq4FzZA==
> =mwCZ
> -----END PGP PUBLIC KEY BLOCK-----
> 
> 
>  		 	   		  
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.indymedia.org/pipermail/imc-dc/attachments/20110101/cb431d53/attachment.htm