<div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* On Mon Feb 05, 2007 at 09:00:07PM -0800, Chris Petersen wrote:<br>> The biggest problem with a *good* implementation of on-the-fly
<br>> transcoding is caching of the transcoded files. I'd rather not do this<br>> in mythweb, since it would mean writing a cache-management routine,<br>> along with having to update my personal backup scripts to ignore things
<br>> like flv, avi, etc.<br>><br>> Instead, having the backend be aware of transcoded files (or better yet,<br>> transcode them itself) would mean that auto-expire, etc. could be made<br>> aware of the other files and manage removing them, etc.
<br><br>This would fall under the plan with the recordedfile table idea that I've<br>been working on which would allow you to store multiple files per<br>recording. You could have a user job that automatically transcoded a
<br>recording to .flv and then inserted a record into the recordedfile table.<br>MythWeb would notice that there was a .flv file (by looking at a type or<br>description field) and could allow the user to stream that file<br>
via MythWeb. Files in this table would be accounted for in Myth the same<br>way that the original recording file is. The would be deleted with the<br>original file, their space would be taken into account by the Auto-Expirer,
<br>you could play any one you wanted from the Watch Recordings screen, etc..</blockquote>
<div> </div>Thanks for the great explanations Chris and Chris. I appreciate it.<br> </div>