[rtmpdump] Why does --swfVfy require an argument?

[Patron Anejo]

RE: David Woodhouse's objections to swfVfy requiring an argument

It seems to me that --swfVfy as an inline instruction is essential to the
way get_iplayer works. RTMPDump depends on the user (or a helper
application) to provide it with the URL of the compressed swf player file.
 The URL that get_iplayer provides to RTMPDump is hard-coded--it is
statically defined in the perl script *get_iplayer.pl*. When the BBC updates
the location of the player file, a* web browser *can respond to the 301
Error and find the embedded player at its new URL--the web page does not
need its HTML source recoded. However, RTMPDump and get_iplayer don't
respond to 301 in the same way--to avoid manually updating .swfinfo and
hand-recoding get_iplayer.pl, an opportunity must exist for get_iplayer to
provide RTMPDump with a revised-URL instruction that overrides the
deprecated swf player URL provided upstream. Once parsed, the best way I
have found to introduce a new swf player URL into the RTMPDump/get_iplayer
process is:

get_iplayer --prefs-add --rtmp-tv-opts="--swfAge=0 --swfVfy=
http://www.bbc.co.uk/emp/revisions/18269_21576_10player.swf"

In the absence of --swfVfy, the only end-user instructions available to
redirect flvstreamer and update .swfinfo seems to be:

get_iplayer --prefs-add --rtmp-tv-opts="swfAge=0 --swfUrl=
http://www.bbc.co.uk/emp/revisions/18269_21576_10player.swf
--swfhash=756ef5b1b33f59e88680ba06bcbc967e34468c82119df9e3789965513e7e57f5
--swfsize=000f9c9b"

Is the way --swfVfy is implemented in danger of being changed? Circumvention
issues aside, --swfVfy provides a very useful downstream opportunity to
introduce an entirely new swf player URL conflict-free. I don't doubt that
I'm missing something, but unless the end-user is expected to hand-recode
strawberry perl, what other options exist when a relocated swf player breaks
get_iplayer function?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mplayerhq.hu/pipermail/rtmpdump/attachments/20110504/756d90f7/attachment.html>