Roku Developer Program

[retrotom]

We've just launched our latest channel -- Fanime. Fanime's goal is to provide the latest and greatest in unlicensed fansub anime on your Roku. In Fanime, you will find anime releases that are categorized and rated according to public opinion. You can search for specific titles as well as check out what's new. We also provide multiple versions of any episodes done by multiple groups. So if you favor one group over another because of video quality or translation -- you can watch their work exclusively. We've also decided to spotlight each group by providing the anime releases they're responsible for. So once again, if you'd like to follow a particular group, you can check out their work across anime titles. This is a public beta while we continue to build up the library of titles. If you run into issues with any releases or titles not playing or missing subtitles or something like that -- PM me the details so that we can address the issue.

Add the channel code to your roku account at:
https://owner.roku.com/Account/ChannelCode/?code=fanimebeta

Many thanks,
RT

[kbenson]

• In the settings screen, some indicator of what font it is (even if it's just 10/34 or something) would be useful.


• Also in settings, the option to go forward and back a font would be useful.


• Increase/decrease font weight seem to have no effect.


• The subtitles appear to be a little close to the bottom when watching content, which seems a bit distracting to me (and may be cut off on some TVs, not sure).


• What's more, the subtitles overran the sides of the screen when the text was too large to fit on the screen (I increased size by one).

On the Roku, if you supply a bounding box for the font, and it has room to wrap down, it will do so automatically. I suggest looking into vertical alignment, aligning to the bottom, and supplying a large enough text box that it can automatically start higher and wrap down to the next line (I *think* it supports this).

[retrotom]

Thanks for the input.

About the font weight stuff -- I'm not entirely clear on how that works with the Roku. For example, setting it at a high value appears to do nothing, but setting it low (internally below 50 -- which is "normal"), text may not get rendered.

We will be adding an indication of the selected font size, color, etc. to the settings screen. Also, font settings are not being "lost" when you enter the screen -- we just revert back to defaults.

The subtitle code is a little tricky because we try to honor the original intent as much as possible. What that means is, we try to show/hide text at the exact time offsets that were originally specified by the author. So when you have multiple streams of conversation between two people or (especially in the case of anime) translations of background music, voices, or on screen text -- you already have multiple lines of text to display -- not one line. So, the difficulty we have (and have had) is that the bounding box solution is difficult to manage and implement. It does work, however. In my mind...it shouldn't work the way it does. If I say..."draw this string in this space" and there isn't enough room...the string should be truncated -- but it's not.

It's difficult to accurately assess how much on screen real estate a single line may need in reality. If we make the bounding box wrap, and there are two lines of text on the screen...then we may end up with "garbage" looking subtitles. If we make the bounding box big enough to really display two lines, then how do we not make it look like there's not too much space between "real" multiple lines. Get what I mean? This is especially apparent if we need to remove a line of text and replace it with another under it. How do we fill that space? If we move the subtitle down -- that looks weird. One solution that we've tried (with poor results) was to make it all one blob of text. The problem with that was that the Roku was extremely slow to render multiple lines of text for some reason. I have no idea why...but that was the case. The subtitles would always display after they were due to be displayed on those larger lines. Another solution we could try (using roFontMetrics) is to figure out the size of our displayed string and iteratively chop it up (using some kind of best-guess bisection method) until it fits on the screen. This has the same down fall of the bounding box though -- if you have two lines of dialog that get displayed as four because of the font -- the second you remove the top one -- it will look weird.

But...weighing user experience...it'd probably be more enjoyable to have it be weird for a second or two...than to not be able to read every other line of dialog. Ee'll figure it out and try to make it look/feel better. I've toyed around with the idea of extracting the fonts included with these files (all MKVs) and basically fully parsing the SubStationAlpha subtitles and displaying it exactly like intended. I like giving people an option on font size, color, etc. though. Anyways...thanks again for the feedback.

[kbenson]

The problem I had was that most of the first and last words were entirely gone, so making sense of the sentence was actually quite hard. There have been posts here about it not truncating text, so you may find some more info on that if you search. If you provide enough vertical space, it doesn't overflow the horizontal size, but auto-wraps to the next horizontal line, which is what I was referring to.

I think the winning solution might be to use roFontMetrics font character size to determine how many characters can display in the space allowed, and know it will need to wrap. Not too hard if you have the font character sizes (I've actually mapped sizes for some built in fonts).

Also, another nice feature would be (if possible through the font data you have) color the different speakers differently. I only mention that because I've seen a few fansubs that do this, and it's really nice. I can understand that being a major undertaking though.

[retrotom]

Coloring the different speakers a different color wouldn't be too hard. We already know, for the most part, when we have different speakers when I first parse the subtitles. You can pretty much assume (in SSA subs) that if you have two subs that overlap in time that they're different speakers. That's because SSA subs allow "\n" for multi-line subtitles. So, we'll know...and coloring for those shouldn't be too difficult to implement at all.

Yeah...the truncation of text would actually be ideal, IMO. It would be more ideal to truncate rather than wrap in most scenarios that I can think of. It would probably be best if it were configurable via a property of some kind.

The whole using FontMetrics to "wrap" is what I meant by bisection. The problem with wrapping (in general) is that usually it will put one or two words on a line; it short -- it looks weird if the sentence (or whatever) is just barely too long. Therefore, it's probably not better to just wrap the text. It's probably better to split the sentence in two -- you're taking up two lines anyways -- and have each line look relatively normal. Make sense? In most of those scenarios where the text is too long...it's only too long by a single word -- maybe two tops. Just wrapping it would look a little "off". I'll work on that and we'll see what we can do.

[kbenson]

Yeah, what I was referring to works the same for wrapping as for splitting in half. Something like the following semi-pseudo-code does what you described (I think).

stBoxWidth = 1280 ' Or whatever
stSize = 0
wordSizes = {}

' Find total string length, and compute word sizes for quicker computation on second pass
wordSize = 0
word = ""
for each CHAR in STRING.tokenize("") ' Does this work to get all chars?
    stSize = stSize + fontSize[CHAR]
    wordSize = wordSize + fontSize[CHAR]
    curWord = curWord + CHAR
    if CHAR = " "
        wordSizes[curWord] = wordSize
        wordSize = 0
        curWord = ""
    end if
end for

' Find how many lines we want to use to split the line (in case it goes over 2)
stLines = int(stSize/stBoxWidth)+1
stCutOff = int(stBoxWidth/stLines)

' If we have more than one line we want to display, add newlines at appropriate word boundaries
if stLines > 1
    ' Find where we want to insert a newline
    lineSize = 0
    for each WORD in STRING.tokenize(" ")
        lineSize = lineSize + wordSize[WORD]
        newSubTitle = newSubTitle + " " + WORD

        ' If we are over the per-line cutoff, add a newline
        if lineSize > stCutOff
            lineSize = 0
            newSubtitle = newSubtitle + "\n"
        end if
    end for
end if

In all probability, that's sub-optimal and riddled with typos and bugs.

[retrotom]

For reference, I think I'd do it something the following. I haven't coded or tested it yet...but it should work (in theory).

Disclaimer...this is pseudo-code:

app is a "global" object for the application settings, etc.
app.FontMetrics is an array of FontMetrics for application fonts -- helpful so that we don't have to recreate them all the time
app.ScreenWidth is the width of the screen returned from roDeviceInfo
subFont is the subtitle font; it can be italic or normal depending on how we parsed the subtitles from the original video
text is the subtitle text we need to render; note that in both of out channels we precalculate all subtitle offsets, etc. before we start video playback. We do this because trying to calculate this during video execution does not work on the Roku. There's not enough horsepower, so you need to know what you're drawing, when you're drawing it, and where before the video starts.

'get the displayed text size
size = app.FontMetrics[subFont].Size(text)

if size.w > (app.ScreenWidth - 40) then '40 is an arbitrary padding value here...it could be anything
     'we want to split the string roughly in half. We start looking at about 45% and split at the first space found. Hopefully that's between 45 and 55% of the string
     targetPos = CInt(size.w * .45)
     splitPos = instr(text, targetPos, " ")

     'probably do some looping/error checking to make sure that splitPos <> 0...but we'll skip that for now
     subLine1 = left(text, splitPos)
     subLine2 = mid(text, splitPos)

     'do something with the subtitle lines...push them onto a stack or something
end if

	
		

[kbenson]

Ah, interesting use of instr(), I hadn't thought of that. I did take care above to support more than two lines, and yours could easily be adapted to do that with your method, but I'm not sure if you have subtitles that large. Then again, if you allow people to select larger fonts, it will probably happen.

I'm interesting in how the Roku doesn't have enough power, is it just delayed too much, or can it actually not keep up at all (gets farther and farther behind)?

[retrotom]

It's both actually. It takes too long to render the text and that can cause issues. Since our subtitle solution is "time-aware"...it causes one of two issues. Either the text rendering gets behind and you have to skip subtitles, or you get blobs of text that "flash" on the screen because they took too long to render. Either way...it sucks from an end user perspective. Rendering large amounts of text is something I've noticed issues with on roImageCanvas and roGridScreen. For instance, if you set the "Description" property to a large blob of text on roGridScreen on multiple items (and you have the tooltip enabled) -- the screen loads slower. It doesn't matter that the text is truncated for you by roGridScreen -- it loads significantly slower. A strategy to deal with that was to use a short and long description for the Fanime channel. We can't use the long description shown on the roSpringboardScreen. Text rendering just doesn't appear to scale well. Why that is...I have no idea. An early test that I completed on roImageCanvas, that I'll need to confirm again, is that it has nothing to do with the size of font...but instead with the amount of characters. I can use a larger font with fewer characters...and it will render faster than a small font with more characters. Anyways, once we get the subtitle stuff figured out, we might release it much like your librokudev. Maybe you could include it. If used in combination with your roCSS, it could be really cool to use in certain scenarios.

[kbenson]

"retrotom" wrote:
Anyways, once we get the subtitle stuff figured out, we might release it much like your librokudev. Maybe you could include it.

That's the idea! It's not really supposed to be "my" librokudev at all, but a community project. Currently Geoff and I have the only commit bits on github, but we specifically set it up as a separate public repo, and just added our accounts as admins. The best contribution method for people without commit bits at github is supposed to be to fork the repo into your own account, make and commit your changes to that fork, and submit a pull request (which has a nifty button on their site) to have us pull in your change set.

If used in combination with your roCSS, it could be really cool to use in certain scenarios.

Yeah, ever since dealing with different text render sizes for the different built in fonts (in the Reversi test), I've been playing with an idea to normalize the font specification for built in fonts. Tweaking fonts to work well in both HD and SD is REALLY annoying (medium in HD == large in SD).