So, I hacked the JUMPLAND Browser...

[Acid_Reign]

I realize this is probably too little too late, but it was something I put a lot of effort into this, so I thought I’d share my findings.

Although it turned out to be relatively easy to capture the Special with screen recorder technology (despite the graying out of the inner canvas when the browser window loses focus), I still wanted to figure out how and where the original video data was being stored.

At first, I thought it might have been a part of the downloadable SVA file itself—this was back before the Special was out, and all I had to go on were manga chapters—but it doesn’t seem to be a common/open format (if it’s even a real one; it could have just been an arbitrarily chosen set of letters to obscure the real technology behind it), and so with no existing research/examples to go on it’d be very difficult to try and decipher the code behind it.

Thankfully, that theory was incorrect, as when the SVA was made available, it was only 169 KB and clearly (read: painfully) streamed the video from somewhere else.

So, I decided to take a look at my firewall logs and see what server the browser was connecting to. The IP was 203.192.147.84 on port 1935. I tried accessing that address in my browser, but to no avail; it was just a blank page. I assumed I was missing the name of the file sitting on that server, so I needed to get the name.

The next step involved using a packet sniffer, Wireshark, to log all the network traffic taking place from the time I started streaming the Special, to whenever I had enough data to look at. I filtered it out to display only traffic from the aforementioned IP address, and sure enough, the raw video data was being sent over TCP/IP… unencrypted. This means that theoretically, one could let Wireshark run while the Special streamed, save all the data to disk, and reconstruct the video from there without having to crack anything. In fact, there are certain programs designed to do that.

But it would have been an unnecessary extra step, for as it turns out, the port, 1935, is simply the number assigned to RTMP, or Real Time Messaging Protocol. Which, as Wikipedia tells us, is “a proprietary protocol developed by Adobe Systems for streaming audio, video and data over the Internet, between a Flash player and a server.” And, as luck would have it, all there is to determining the source of the stream is looking at the RTMP header. It specifies the host, directory, and file name of the Flash video to be streamed. Looking through the logs at the specific sections that contain these strings, one can reconstruct the full URL of the resource the browser is connecting to.

The result of this labor is as follows:

[url]rtmp://fms-cache.stream.ne.jp:1935/jump/_definst_/db_en[/url]

That is the direct link to the English version of the Special. In fact, it works for any of the three animé and their respective localized subtitles; they are all stored in the same place. You merely have to replace the first and last two characters of the file name with the following values:

Animé

• db for Dragon Ball
• op for One Piece
• lb for Letter Bee

Languages

• ja for Japanese
• en for English
• fr for French
• de for German

Of course, they’re not directly accessible through most Web browsers: that would be HTTP, not RTMP, and although RTMP can be tunneled over HTTP, as is the case with a lot of other streaming video sites, obviously that option was not favored here, or else we wouldn’t have a proprietary browser to deal with in the first place. But, with a download manager like Orbit Downloader, it’s a piece of cake. Just create a new download, type in the URL and press OK. It will begin streaming the file over RTMP directly to your hard disk!

Note that although there is no file extension, it is an FLV (as you may have noticed in-browser from the style of player, and the Flash options upon right-clicking), so you should save them as such.

The fact that they are FLVs got me curious, since a user on JAPPO’s site posted a link to an FLV version of the Special very early on. At first, I dismissed it as being a compressed screen capture, due to the artifacts I was seeing. Turns out, I was wrong: it is a direct rip, as my fresh-off-the-server copy had identical attributes. So, I retract my previous statement. He, or whoever he got the file off of, must have had some experience with this type of thing before; I had to learn it all from scratch.

Which brings me to the reason I made this error in the first place. As you can see in the screenshot below, when playing the raw file in Media Player Classic, there appear some odd, blocky discoloration artifacts:



And yet, when played in FLV Player, it looks fine:



It turns out that the reason for this is because MPC was decoding the video through ffdshow, which uses an unofficial, open-source FLV decoder through libavcodec, while FLV Player uses the official, closed-source Adobe decoder. Unfortunately, so much free software is based on the code of the former, so really great programs like VLC and MPlayer suffer from this same defect. At least, they do on the versions I have. If you are using ffdshow and do not see these artifacts, please contact me!

Aside from a lot of anguish trying to rid myself of those nasty peculiarities (which don’t show up too often, but are still annoying), accessing the raw files also allowed me to be privy to some technical trivia in the form of metadata. This information may be of use to you in your own encodes:

• Video Codec: VP6F
• Audio Codec: MP3
• Audio Sample Rate: 16-bit, 44.1 kHz, Stereo
• Width: 704 pixels
• Height: 396 pixels
• Frame rate: 29.970000 fps
• Duration: 1999.016660 seconds
• Last Time Stamp: 1999016
• Last Key Frame Time Stamp: 1994993
• Creation Date: Friday, November 21st, 08:06:36 2008

The frame rate is interesting to me because it is not the 24 or 23.976 that I expected, as the rest of the series plays at, which are the film and digital film speeds respectively. I figured that, even if this wasn’t regarded a “movie” per se, it’d at least match the series for consistency’s sake. But instead, it’s 29.97, which is inherently television (and now Web) territory. Although it was obvious from the animation style already, this change, to me, marks the end of the old way of doing things, through-and-through. If there were new animations I would not be surprised to see them done in this same format.

Another interesting thing is that, although the playback dimensions are 704×396, the full picture seems to be 704×400, with the bottom 4 pixels being repeated. These effectively carry no important image information, and can be cropped if you are doing your own encodes off of these.

As it also happens, the playback dimensions are only 84 pixels short from being a valid DVD resolution. If you add in the letterbox borders it can easily be burned to disc (the aspect ratio will be slightly off, but that can be fixed if you mind it). This makes me wonder if the DVD was planned in advance and if this encode was simply a lower-bitrate, Flash-based output of the same end-product. It looks like it was even done in Flash initially, so I wouldn’t be surprised if a full-res DVD or even BD version of this came to light.

My last bit of food for thought as derived from this process is the fact that, for such a small video being shown in multiple languages for free, it sure seemed to be heavily guarded. Here’s a recap of all of the security measures in place:

• A browser was used instead of an on-site stream
• The browser grays out when it’s not in focus
• The content files are SVA
• The SVAs do not contain the actual content, just a reference to it
• RTMP was used instead of HTTP
• The links are not on the main Jump server
• The outside server does not even have a Web page
• There is no file extension (could be that this is to preclude it from FLV leeching; could also be standard practice; not sure)

Evidently, they weren’t enough, but it makes me wonder just exactly “how legal” this horde of ripping is in Jump’s eyes. I’m certainly curious as to how they’re reacting to all this.


Well, this has been long enough. Hope it’s helpful and opens up some good discussion. If you have any questions about this process or encoding, feel free to ask me. I have literally spent the good part of the past few days dealing exclusively with this video, trying to get it onto my computer in a format that suits me. Can not wait until that DVD arrives. Happy ripping!

[Captain Awesome]

An interesting read.

Thanks for clearing it up, I was wondering why there were so many weird artifacts when the filesize was so large for an .FLV, I never thought to try viewing it through FLVplayer (I throw everything through mpc and ffdshow), now it looks much crisper (especially during panning shots).

[desirecampbell]

Nice work.

[JAMM]

Awesome thinking man

Thanks a lot and I'm downloading the Japanese version so I can get screen shots without the English subs

[Tweaker]

I'm in utter awe of both your deduction skills and your technical expertise. Very well done!

With the raw files available, I'm hoping somebody can make a full-quality encode soon. I still have the ripped FLV, which has many distracting artifacts. The animation in the special is absolutely brilliant, and it deserves to be seen in as high quality as possible.

[SaiyaMel]

Very informative! Thanks.

I'm surprised there isn't one subbed in Spanish...

[Kienzan88gt]

Wow, thank you so much for breaking all that down, it was very helpful. Also thank you for sharing this with us, after so many days trying to figure this out yourself, I'm sure everyone who is interested in seeing the special with the best quality appreciates this a lot ^^.

[Forgotten Hero]

I'll be doing that process later, but I just used SUPER for all the streaming of the FLV.

[Taku128]

But, with a download manager like Orbit Downloader, it’s a piece of cake. Just create a new download, type in the URL and press OK. It will begin streaming the file over RTMP directly to your hard disk!

Installing that program made the internet slow down to a crawl. I had to uninstall it to get it to run at normal speed again. Is this normal?

[Acid_Reign]

Thanks everyone! Glad you all found it useful.

With the raw files available, I'm hoping somebody can make a full-quality encode soon. I still have the ripped FLV, which has many distracting artifacts. The animation in the special is absolutely brilliant, and it deserves to be seen in as high quality as possible.

I tried making a full-quality encode, but man, was it a pain in the ass. Essentially, since there is no free version of the Flash video decoder, I was relegated to trying to capture the non-streaming version as it played through FLV Player, the way others have done with the streaming version. This has the advantage of no jitteriness, or freezing in the video, but also the disadvantage of needing a lossless intermediate encoder, which usually requires a lot of disk space, and in my case, would often create a file so big it would crash my screen capture software.

Not only that, but the rate of capture depends on the speed at which your computer can encode each frame, so for every 30 frames the software may only capture 15 of them, causing the final playback speed to be ridiculously fast. Syncing it with the existing MP3 rip was a task in and of itself. Add to that the fact that half of my encoders mysteriously stopped working, and it becomes obvious why the past three days hasn’t gotten me anywhere.

But, I’m still determined, just not going to drive myself crazy over it anymore. I will hopefully have something to show for all this within the week.

I'll be doing that process later, but I just used SUPER for all the streaming of the FLV.

I know nothing about SUPER, but a quick Google shows me it’s FFmpeg-based, same as ffdshow, which is in turn built upon the libavcodec, which is what is causing the ugly glitches. You will be hard-pressed to find something more suitable… but if you do, let me know!

Installing that program made the internet slow down to a crawl. I had to uninstall it to get it to run at normal speed again. Is this normal?

Not really, no. Granted, large downloads can often slow down your connection, but I didn’t encounter any massive performance hits. Of course, it varies depending on your computer and connection speed, so maybe try limiting your Internet traffic if that’s an issue. Although, there are many other RTMP-capable downloaders out there, so look around; maybe another one will suit you better.

[Taku128]

Installing that program made the internet slow down to a crawl. I had to uninstall it to get it to run at normal speed again. Is this normal?

Not really, no. Granted, large downloads can often slow down your connection, but I didn’t encounter any massive performance hits. Of course, it varies depending on your computer and connection speed, so maybe try limiting your Internet traffic if that’s an issue. Although, there are many other RTMP-capable downloaders out there, so look around; maybe another one will suit you better.

I wasn't doing anything with the program yet. When it installed I had to close my internet browser, so after it finished I tried to come back to the forums to get the link, but every site I went to was slow.

[MajinVejitaXV]

I know nothing about SUPER, but a quick Google shows me it’s FFmpeg-based, same as ffdshow, which is in turn built upon the libavcodec, which is what is causing the ugly glitches. You will be hard-pressed to find something more suitable… but if you do, let me know!

Hm, with the full Adobe suite, is there a program that could convert the video to a different compression type? I too noticed the artifacting and such (especially in the final pan across the cast looking on at Goku and Vegeta's argument), and even encoded an H.264 MP4 to play on my television, but the artifacting remained. I'm assuming that's because the program I used to encode also used some of the above libraries to decompress the initial stream before re-encoding it.

Great thread though. I was going to do something similar to what you did with the packet sniffer, but in all honesty I just didn't have the time. You did better than I would have irregardless though

-Corey