After purchasing a paintball web-series I was a little disappointed to find my loot only available in 1080p. At about ~$4 an episode, you'd think they'd at least offer at least 1 other format, possibly for the old iPod Video's or in my case, an old netbook streaming media off my NAS via 802.11g.

In any case, doing the deed myself was surprising easy. Though I'd imagine someone without any prior knowledge of codecs, aspect ratio, and bitrate may run into trouble. I'd suggest they give my commands a shot.

Lets start off by making sure we have ffmpeg installed on the buffest rig you've got. This can be preety heavy lifting and can take quite sometime on older machines.

Now assuming we have our original file EP1_HD_1080p.mov in our current directory, running the following command will get us going.

1

ffmpeg -i EP1_HD_1080p.mov -ac 2 -qscale 5 -f mp4 -s 854x480 ep1_sd_480p.mp4

To break it down, here's the same command with placeholders.

1
2
3
4
5
6
7

ffmpeg \
    -i [input-filename] \
    -ac [# of audio-channels] \
    -qscale [quality-scale: 1-31 (1 = highest quality)] \
    -f [format: mp4, avi, mkv, ..] \
    -s [Resolution: (Width)x(Height)] \
    [output-filename]

Now you may have checked out some examples before mine and noticed others' had a lot more options. It just goes to show that ffmpeg is the go-to utility. Whether small job like mine or the demands of a release-group like "YIFY", you can't go wrong.

As always, good luck!

After 'inspecting' the source of a live webcast and the data that gets thrown around once the plugin is launched, I managed to get a 10$ webcast for free. To be honest, I feel like I just got lucky with this one.. While media is still woven into websites with embed tags as it was back when Geocities was booming, where besides the scrolling marquee we all insisted on looping our favorite song in the background, but this time theres all sorts of new protocols, plugins, and codecs at work. We can't just 'view-source' and expect to see 10-dollars-worth-of.mp4. There's nothing to worry about though, we only have to dig a little harder. Probably real hard if you're like me and have never had much experience with media plugins.. So lets get to it.

First, you're going to want to check out the source of the page where the plugin and stream play. Your browser's developer tools come in real handy and should have everything you need for sleuthing around.

Right now we just need to take note of the vendorID and mediaID parameters. Both were mentioned at least a few times thoughout the page I was working with.

Next we want to examine the SMIL file which will tell us exactly where we can find our stream. I found mine by using Firefox's network console and paying attention to the back-and-forth dialog going on between the browser's plugin and the webcast host. I suspect if you did the same you'd come up with similar, so here's mine to save you the trouble.

1

curl hxxp:||cdn.m0b1ler1der.c0m/m0b1ler1der/mobilestorefront/<vendorID>/media/file/<mediaID>/streams.smil

In the output of the previous command here should be a couple key-value pairs like content="http://yadayada.yup" and src="/theStreamsUWereLookinFor@rightHurr" to help you put together a URI to pass to your chosen media player.

This URI is direct access to the stream, but if it returns an error or otherwise you're going to need to invesigate further. My hope is that I've at least set you on the right foot toward success. As a final clue, here's what my result would've looked like using the example values I've used thus far.

1

http://yadayada.yup/i/theStreamsUWereLookinFor@rightHurr/master.m3u8

If you're wondering the origin of the parts of the URI not supplied explicitly in the SMIL, they were taken from a previous URI from the same site, before they started asking for money.

• Here's a few tips on how to maximize your performance when using an embedded device like Pogoplug, RaspberryPi, etc. *

Flash-Drive I/O

Flash memory is cheap and small. Most even have enough storage space that you can house your ROOTFS pretty comfortably. The downside is pretty sluggish reads/writes. Fortunately the pogoplug has 256MB's of RAM; By allocating some commonly written directories in RAM we gain speed plus the benefit of less write-cycles overall to our flash-memory. If you don't already know, flash memory has a limited number of writes, so this effectively prolongs the life of your drive/system.

Simply add/replace the appropriate lines to fstab ..

1
2
3
4
5

tmpfs /tmp         tmpfs nodev,nosuid,noatime           0 0
tmpfs /var/tmp     tmpfs nodev,nosuid,noatime           0 0
tmpfs /var/log     tmpfs nodev,nosuid,noatime,size=20M  0 0
tmpfs /var/run     tmpfs defaults,noatime,size=1M       0 0
tmpfs /var/lock    tmpfs defaults,noatime,size=1M       0 0

I/O Governor

The logic that is behind your drive/disk access can be tweaked reducing lag by appending the following line to /etc/rc.local

1

echo deadline > /sys/block/sda/queue/scheduler

Note That I don’t use the noop scheduler because deadline can be better as it group small accesses, which improve latency. The default, cfq is better suited for disk-drives.