Utilities like get_iplayer will already pass a --swfUrl argument; why do I need to provide it again? I have the option to add extra rtmpdump arguments in the get_iplayer config files, but I don't necessarily know the correct swfURL -- that's calculated by get_iplayer itself. -- dwmw2
David Woodhouse wrote:
Utilities like get_iplayer will already pass a --swfUrl argument; why do I need to provide it again?
The manpage says why. The swfVfy option was intended to replace the swfUrl option.
On Tue, 2010-05-11 at 06:45 -0700, Howard Chu wrote:
David Woodhouse wrote:
Utilities like get_iplayer will already pass a --swfUrl argument; why do I need to provide it again?
The manpage says why.
The swfVfy option was intended to replace the swfUrl option.
Unfortunately that's not massively practical. People who write tools like get_iplayer are too scared to include explicit references to rtmpdump and --swfVfy; they use flvstreamer instead and leave the task of actually making things _work_ to the end-user. If we could just enable SWF Verification (or have it default to being enabled) without having to re-provide the SWF URL, that would be a lot easier. -- dwmw2
David Woodhouse wrote:
On Tue, 2010-05-11 at 06:45 -0700, Howard Chu wrote:
David Woodhouse wrote:
Utilities like get_iplayer will already pass a --swfUrl argument; why do I need to provide it again?
The manpage says why.
The swfVfy option was intended to replace the swfUrl option.
Unfortunately that's not massively practical. People who write tools like get_iplayer are too scared to include explicit references to rtmpdump and --swfVfy; they use flvstreamer instead and leave the task of actually making things _work_ to the end-user.
If we could just enable SWF Verification (or have it default to being enabled) without having to re-provide the SWF URL, that would be a lot easier.
It's far too late to be questioning this now. The option has already been deployed through several versions. Also, I was in close communication with the get_iplayer author when this option was added, he didn't have any problem with it. You seem to be putting words into other people's mouths. There are good reasons not to leave SWF verification enabled all the time in the code. It changes the handshake version, and it frequently costs time both in making an HTTP connection to retrieve the SWF, and in computing the actual hash and response. It was a good decision at the time. In retrospect it may not have been so great. In the new API swfVfy is a boolean option, but I don't see how to smoothly transition rtmpdump to the new API just yet.
On Tue, 2010-05-11 at 08:43 -0700, Howard Chu wrote:
David Woodhouse wrote:
On Tue, 2010-05-11 at 06:45 -0700, Howard Chu wrote:
David Woodhouse wrote:
Utilities like get_iplayer will already pass a --swfUrl argument; why do I need to provide it again?
The manpage says why.
The swfVfy option was intended to replace the swfUrl option.
Unfortunately that's not massively practical. People who write tools like get_iplayer are too scared to include explicit references to rtmpdump and --swfVfy; they use flvstreamer instead and leave the task of actually making things _work_ to the end-user.
If we could just enable SWF Verification (or have it default to being enabled) without having to re-provide the SWF URL, that would be a lot easier.
It's far too late to be questioning this now. The option has already been deployed through several versions.
Also, I was in close communication with the get_iplayer author when this option was added, he didn't have any problem with it. You seem to be putting words into other people's mouths.
Unfortunately the original author of get_iplayer author has now stopped working on it -- precisely because of the SWF Verification issue. When I asked the owner of the get_iplayer project on github, he said "I can't support it directly in get_iplayer".
There are good reasons not to leave SWF verification enabled all the time in the code. It changes the handshake version, and it frequently costs time both in making an HTTP connection to retrieve the SWF, and in computing the actual hash and response.
Yeah, I did look briefly at that option and decide that it wasn't feasible.
It was a good decision at the time. In retrospect it may not have been so great. In the new API swfVfy is a boolean option, but I don't see how to smoothly transition rtmpdump to the new API just yet.
One possibility is to add a command-line option which _is_ a boolean, and just enables the swfVfy flag without affecting swfURL. That doesn't break compatibility with the existing --swfVfy option. You could call it something like --enableSwfVfy. -- dwmw2
participants (2)
-
David Woodhouse -
Howard Chu