On 9/18/2012 3:22 AM, Rubén Pérez wrote: > You have raised an interesting question, though. Even though we recommend > Red5 as our reference streaming server... how many adopters are actually > using it?
I am, as is USask I think. It's exceedingly easy to set up, and it just seems to work... Are you testing this patch against Red5 as well? G > Regards > > Rubén Pérez > TELTEK Video Research > www.teltek.es > > * To be sincere, I don't like the fact that the download/stream URLs are > "hard-coded" to the distributed mediapackage, and I would prefer they were > generated "on request", but that's another story. > > 2012/9/18 Tobias Wunden <[email protected]> > >> Hi Rubén, >> >> just to clarify: is this patch specializing the streaming distribution >> service to Wowza? Or does the patch work for streaming servers in general >> (which would be surprising)? If it *does* specialize the service to support >> Wowza streaming servers, then I suggest creating a new module >> (distribution-service-wowza) instead of patching the existing >> implementation, which is (and should remain to be) targeted at red5, which >> is what we are advertising to be Opencast's out of the box recommendation. >> >> Another option would be to allow for a way to configure as part of the >> workflow operation configuration how the path is being created. This way, >> we could keep one implementation to rule them all :-) >> >> Tobias >> >> On 13.09.2012, at 15:55, Rubén Pérez <[email protected]> wrote: >> >>> I have created an issue in Jira (MH-9180), and committed a patch for >> review at CR-MH-481 . Please do not hesitate to join the review and check >> if this works with the typical streaming servers. >>> >>> Rubén Pérez >>> TELTEK Video Research >>> www.teltek.es >>> >>> >>> >>> 2012/9/4 Rubén Pérez <[email protected]> >>> That was exactly my point. I didn't want to go and modify this and break >> it for the users of other streaming servers. I don't know if I should just >> commit it (and potentially break the trunk), or create a bug and attach it >> to this email, or perhaps to a bug report in Jira, I'm not sure. >>> >>> >>> Rubén Pérez >>> TELTEK Video Research >>> www.teltek.es >>> >>> >>> >>> 2012/9/4 Ruediger Rolf <[email protected]> >>> Hi Ruben, >>> >>> the current implementation works for us (with Wowza 3). MP4-Streaming >> with Red5 does not work properly so it cannot really be tested. If the >> behaviour of FMS is different. As you are a commiter and have the needed >> FMS server why don't you fix this bug. I am willing to do a code review and >> do some testing on Wowza. >>> >>> Rüdiger >>> >>> Am 04.09.2012 18:30, schrieb Rubén Pérez: >>>> I'm bringing this back to life because I'm seeing this bug has not been >> corrected in the 1.4.x branch --the "mp4" prefix is still added before the >> filename, and not right after the "application" part of the URL. >>>> >>>> However, I see an additional problem in FMS. For some reason I am >> unable to comprehend, you can NOT specify the .flv suffix in the FLV files, >> or they won't play. There is no way of disabling or changing this >> "feature". If, we use the "flv:" format, the stream plays perfectly, as >> long as you don't provide the extension at all i.e. >>>> >>>> rtmp://my.fms.server/demo/route/to/the/video.flv >>>> >>>> doesn't work, >>>> >>>> rtmp://my.fms.server/demo/flv:route/to/the/video.flv >>>> >>>> doesn't work either, but >>>> >>>> rtmp://my.fms.server/demo/flv:route/to/the/video >>>> >>>> >>>> I checked this with .mp4 videos and the result is that 1 and 3 work. >>>> >>>> My question is: does the 3rd option work for the other streaming >> servers, too. Because if it does, we have found a general way of writing >> the streaming URLs which is independent from the server used, i.e. to >> stream the file >>>> >>>> route/to/the/video.ext >>>> >>>> we use the URL >>>> >>>> rtmp://url.to.the.server/application_name/ext:route/to/the/video >>>> >>>> Can any of you confirm this? >>>> >>>> Regards >>>> >>>> Rubén Pérez >>>> TELTEK Video Research >>>> www.teltek.es >>>> >>>> >>>> >>>> 2012/4/13 Rute Santos <[email protected]> >>>> Hi Leslaw, >>>> >>>> I've just updated the ticket. >>>> Thanks, >>>> >>>> Rute >>>> >>>> >>>> On 4/13/2012 5:07 AM, Leslaw Zieleznik wrote: >>>>> Hi Rute, >>>>> >>>>> Did you open a ticket in JIRA as Tobias suggested, to apply the >> recommended format of the rpm link for Wowza and FMS? >>>>> >>>>> Regards, >>>>> Leslaw >>>>> >>>>> >>>>> On 11 Apr 2012, at 18:19, Rute Santos wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Looking at the Wowza tutorial link below, it seems that Wowza >> also needs the "mp4:" after the application name and before the directory >> path in the rtmp link. The only difference from FMS seems to be that it >> requires the "_definst_" instance name, which FMS assumes by default if no >> instance is informed: >>>>>> >>>>>> http://www.wowza.com/forums/content.php?35#playback >>>>>> >>>>>> This is the relevant note: >>>>>> >>>>>> Note: To play content that is not at the root of the content folder >> you must add the default application instance name to the URL. For example >> if you have a file at the path [install-dir]/content/myvideos/sample.mp4, >> the URLs for the different stream technologies are: >>>>>> >>>>>> Flash player (RTMP) >>>>>> Code: >>>>>> Server: rtmp://[wowza-address]/vod >>>>>> >>>>>> Stream: mp4:myvideos/sample.mp4 >>>>>> >>>>>> Single URL: >>>>>> rtmp://[wowza-address]/vod/_definst_/mp4:myvideos/sample.mp4 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thus, an rtmp link in the form: >> rtmp://server/matterhorn-engage/_definst_/mp4:dir1/dir2/file.mp4 should >> work with both FMS and Wowza. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Rute >>>>>> >>>>>> >>>>>> On 4/9/2012 11:37 AM, Rute Santos wrote: >>>>>>> Hi Ruben, Hank, >>>>>>> >>>>>>> I was looking at the Wowza documentation and it also has the >> concept of "application" as FMS does. So, I am just wondering if Wowza >> accepts both forms? I recall Hank said that the rtmp link is working with >> Wowza as is, but I was wondering if he could try to use the other form and >> see if it works too? I am curious... >>>>>>> Thanks, >>>>>>> >>>>>>> Rute >>>>>>> >>>>>>> >>>>>>> On 4/9/2012 11:33 AM, Hank Magnuski wrote: >>>>>>>> The "application" convention is certainly present in Wowza and I >> believe Red5 as well. >>>>>>>> >>>>>>>> Hank >>>>>>>> >>>>>>>> 2012/4/9 Rubén Pérez <[email protected]> >>>>>>>> It would be interesting to know if Wowza is effectively following >> the same convention. We have already have bizarre integration problems with >> FMS because it follows its own conventions as to the syntax of the media to >> stream. >>>>>>>> >>>>>>>> We would be happy to have that patch attached to the main source >> code, since we are FMS users ourselves, but I think we shouldn't stick to a >> certain notation if it's not shared by the popular streaming alternatives, >> too (I'm not saying it's not, just willing to get confirmation of it). I >> may be wrong here, but "application" seems like an internal FMS concept, >> which may not be share by other streaming servers. It also seems to me like >> an unnatural place to put the tag (I'd rather expect it to be before the >> filename or at the beginning of the URL), that's why I'm trying to be >> cautious here. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> 2012/4/9 Tobias Wunden <[email protected]> >>>>>>>> Hi Rute, >>>>>>>> >>>>>>>>> We use FMS here with our current system to stream mp4 files >> and the "mp4:" tag should come after the application name. So, if the file >> resides several directory levels below e.g. dir1/dir2/file.mp4, the rtmp >> link should contain "/app_name/mp4:dir1/dir2/file.mp4" and not >> "app_name/dir1/dir2/mp4:file.mp4". The links you list below don't have >> examples with many levels of directories. I don't know about Wowza, but I >> bet it is the same :) >>>>>>>>> I have a patch for this if anyone is interested (how should I >> submit it?) >>>>>>>> >>>>>>>> We are certainly interested to apply your patch if you've go this >> working! The correct for submitting patches is the following: >>>>>>>> >>>>>>>> 1) Open a ticket in JIRA describing your problem. >>>>>>>> 2) Us the "attach" function to attach your patch >>>>>>>> >>>>>>>> Also feel free to let the developers (on >> [email protected]) know that you've submitted a patch and >> would welcome feedback and integration (optional step :-) >>>>>>>> >>>>>>>> Tobias >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Matterhorn-users mailing list >>>>>>>> >>>>>>>> [email protected] >>>>>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Matterhorn-users mailing list >>>>>> [email protected] >>>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Matterhorn-users mailing list >>>>> >>>>> [email protected] >>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >>>> >>>> >>>> _______________________________________________ >>>> Matterhorn-users mailing list >>>> [email protected] >>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Matterhorn-users mailing list >>>> >>>> [email protected] >>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >>> >>> >>> -- >>> >>> ________________________________________________ >>> Rüdiger Rolf, M.A. >>> Universität Osnabrück - Zentrum virtUOS >>> Heger-Tor-Wall 12, 49069 Osnabrück >>> Telefon: (0541) 969-6511 - Fax: (0541) 969-16511 >>> E-Mail: >>> [email protected] >>> >>> Internet: >>> www.virtuos.uni-osnabrueck.de >>> >>> _______________________________________________ >>> Matterhorn-users mailing list >>> [email protected] >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >>> >>> >>> >>> _______________________________________________ >>> Matterhorn-users mailing list >>> [email protected] >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >> >> _______________________________________________ >> Matterhorn mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ >> > > > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
