I'm afraid most of that went over my head but thanks for taking the time to
explain. Will try Desk Rabbit's suggestion of actually contacting RTE
Television.
Kenny Cargill
"VanguardLH" wrote in message
Kenny Cargill said:
I am trying to save the TV programme here:
http://www.rte.ie/player/gb/show/10102433/
because a couple of my friends appear in it,
Have tried the Firefox save flash extension, YouTube Downloader, Save
Flash
and none will save this.
Tried looking in Firefox temp internet files and i can see the ads with
MP4
extension but not the main part of the programme.
Any suggestions welcome.
You're assuming the video stream is encoded using a standard protocol,
like RTMP[E]. Nothing stops a site from delivering a Javascripted
player in the page you load from them or them delivering a Java applet
to use as the player. Their player knows what proprietary format the
site has encoded the video stream. Nothing else will.
If the RTMPE protocol is used, extremely few stream capture programs
will capture it. Despite Adobe documenting RTMPE as a substitute to use
RTMP over an SSL transport and declaring that it is not a DRM scheme,
and that a encrypted token needs to be sent to provide DRM protection,
Adobe has backtracked and now claims RTMPE is for content protection.
That is due mostly to the lazy users of RTMPE who don't want to bother
with generating an SWF security token.
Even commercial video stream capture programs were scared off by Adobe's
threat. Adobe didn't have to take anyone to court. They simply sent a
letter of intent to any software vendor that continue to permit capture
of RTMPE streams. Applian Replay Media Catcher used to capture RTMPE
streams until Adobe sent them a letter of intent. Jaksta continued
capturing RTMPE for awhile until Adobe scared them, too.
http://www.jaksta.com/support/jaksta-for-windows-faq/what-is-rtmpe/
http://www.jaksta.com/support/jaksta-for-windows-faq/what-is-swf-verification/
http://en.wikipedia.org/wiki/Protected_Streaming
http://www.adobe.com/devnet/adobe-m...ication-protected-http-dynamic-streaming.html
I have yet to find a source using RTMPE that actually implements SWF
verification so technically they are merely encrypting their content and
not protecting it (against copying). Although RTMPE was not supposed to
protect content (after delivery), it became used for that purpose
because of all the lazy or ignorant users that don't both with
implementing SWF verification. This is akin to Firefox not blocking all
non-secure content on an HTTPS site because, gee, it might break a
poorly designed site (and there are lots of them). There was how it was
designed versus how it got used.
For the specially coded Java[script] client delivered to you that
decodes a sites streamed content, you won't find a stream capture
program that will work. For RTMPE, you could try using rtmpdump which
is a command-line program. It's supposed to work for RTMPE but not for
RTMPE+SWFverification (since the latter is protected content). I think
there is some companion URL<something> program you can use to capture
the links on a page that you feed via parameters to the rtmpdump
program. Otherwise, look at using a screen capture program. Not a
screen snapshot program that takes static pictures of what is displayed
on the screen. I'm talking about recording a section of the screen.
These don't rely on any streaming protocol to capture. They just grab
what's shown on the screen. The Video Downloader add-on for Firefox has
this as a beta feature (it uses Camstudio libs which often fails for
snagging the audio so all you get is a silent video). Whatever you see
on the screen is what gets recorded. If there is jitter, hangs, or
pauses in the video then those are also recorded. It is capturing a
specific area of the screen, so if you move the app's window wherein the
video is displayed, you overlap that window with another one, or you
minimize that window then you end up recording something else. The area
being captured doesn't tag along with the moved window or compensate for
the window disappearing or getting overlapped by another window. I
never found Camstudio to be very good and tried using BB Flashback
screen recorder (free) for awhile but eventually gave up on that, too (I
think it was because playback of the recorded screen was jerky, audio
was poor or out of sync, or the stream video became jerky when the
BBFlashback recorder was loaded since the combo resulted in spiking CPU
usage to 100%).
The web browsers could obvious include their own stream capture mode but
they won't because they, too, are afraid of what Adobe would do. The
web browser makers aren't prepared to combat Adobe in court to prove
RTMPE is *not* a copy protection scheme but only provides secure
transport and that SWF verification *must* be used to provide copy
protection. Anyone that wins that battle would immediately force all
those lazy users of RTMPE to start implementing SWF verification. That
won't resolve where a site delivers their own Java[script] player that
understands the encoding used by that site. Since Java[script] is local
code (ran by your client), I suppose you could attempt to reverse
engineer their code and add your own to save the stream; however, all
they'd have to do is slightly change the encoding and your new decoder
and capturer would fail.
The streamed video at the site you mention is EXTREMELY jerky. A screen
recording would be just as crappy.
