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?