The files appear in some temporary directory. I cannot remember where they are exactly. If you make an error when embedding action script into openlaszlo (should be something on action script level, xml markup would break the preprocessor itself), you get in the error message an exact pointer to the file where your error is put. -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095
On Wed, Mar 13, 2013 at 11:58 AM, Maxim Solodovnik <[email protected]> wrote: > @Alexey we currently using flex 4.5.0, 4.6.1 to create bytecode > "can be inspected/used" means autoconverted :) action script instead of > openlaszlo is also good :) > > can you please tell me how this can be inspected? > > @Sebastian I thought we use only view/label/dataset/connection in our swf10 > code .... all these primitives should be available in MXML. > > > > > On Wed, Mar 13, 2013 at 2:52 PM, Alexei Fedotov <[email protected]> > wrote: >> >> @Max AS3 means action script >> >> Modern OpenLaszlo compiles into AS3, these files can be inspected and >> used instead of openlaszlo files. >> Then standard Adobe tools create swf bytecode from AS3. >> >> >> -- >> With best regards / с наилучшими пожеланиями, >> Alexei Fedotov / Алексей Федотов, >> http://dataved.ru/ >> +7 916 562 8095 >> >> >> On Wed, Mar 13, 2013 at 11:18 AM, [email protected] >> <[email protected]> wrote: >> > MXML has certainly advantages in the sense of wider acceptance and >> > better >> > development tools. >> > But it really means to build something from scratch. >> > >> > Sebastian >> > >> > >> > 2013/3/13 Maxim Solodovnik <[email protected]> >> > >> >> @Alexey we currently using openlaszlo for video (not sure what do you >> >> mean >> >> by AS3). Currently our version of video components is built using >> >> flex.4.6.1 while actual version available for download is flex 4.9.1. >> >> I was hoping we will have less bugs and better performance if we will >> >> use >> >> MXML directly for our code. But this is just a guess. >> >> >> >> >> >> On Wed, Mar 13, 2013 at 2:00 PM, [email protected] < >> >> [email protected]> wrote: >> >> >> >>> You can simply disable h264 and build to swf11. >> >>> It is only about the codec not about SWF formats. >> >>> >> >>> I just compared and could not really find out if there are big >> >>> differences. >> >>> However it is definitly good to really compare the impacts on CPU and >> >>> bandwidth usage when switching the Codec for video encoding. >> >>> It seemed to me like encoding with h264 is using a second process (on >> >>> OSX >> >>> that process is called WindowsServer). It might be that h264 encoding >> >>> can >> >>> use some more system ressources. However... all just guessing at this >> >>> point. >> >>> >> >>> Sebastian >> >>> >> >>> >> >>> 2013/3/13 Maxim Solodovnik <[email protected]> >> >>> >> >>>> Maybe we can add conversion task to the GSOC ideas? do we need it? >> >>>> >> >>>> I don't see any problems with h264 >> >>>> I'm going to build >> >>>> 1) SWF11 with h264 support removed >> >>>> 2) SWF11 with different h264 profile >> >>>> 3) SWF10 >> >>>> >> >>>> and compare >> >>>> but i'm not expecting any major differences :( >> >>>> >> >>>> >> >>>> >> >>>> On Wed, Mar 13, 2013 at 1:17 PM, [email protected] < >> >>>> [email protected]> wrote: >> >>>> >> >>>>> No there is no such conversion. You have to rewrite the LZX to MXML >> >>>>> and >> >>>>> AS3 files. >> >>>>> What about the Video Codec? I don't think it makes sense to start a >> >>>>> RC2 >> >>>>> vote before this issue has been further analyzed. >> >>>>> Is there a given restriction that needs h264? >> >>>>> >> >>>>> Sebastian >> >>>>> >> >>>>> >> >>>>> 2013/3/13 Maxim Solodovnik <[email protected]> >> >>>>> >> >>>>>> @Sebastian, maybe you know, is there any possibility to >> >>>>>> automatically/semi-automatically convert our swf10 sources to >> >>>>>> "apache flex >> >>>>>> xml"? Since Openlaszlo seems to be not actively developed and flex >> >>>>>> is now >> >>>>>> part of Apache, maybe we can benefit from such conversion? >> >>>>>> >> >>>>>> >> >>>>>> On Tue, Mar 12, 2013 at 4:28 PM, Maxim Solodovnik < >> >>>>>> [email protected]> wrote: >> >>>>>> >> >>>>>>> I have forwarded all missing messages >> >>>>>>> >> >>>>>>> >> >>>>>>> On Tue, Mar 12, 2013 at 4:25 PM, [email protected] < >> >>>>>>> [email protected]> wrote: >> >>>>>>> >> >>>>>>>> you wrote me without CC'ing Irina or the list :) >> >>>>>>>> >> >>>>>>>> I missed the 'reply all' button somehow. >> >>>>>>>> >> >>>>>>>> Sebastian >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 2013/3/12 Maxim Solodovnik <[email protected]> >> >>>>>>>> >> >>>>>>>>> this one https://issues.apache.org/jira/browse/OPENMEETINGS-559 >> >>>>>>>>> >> >>>>>>>>> @Irina can you describe your problem more detailed? >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> On Tue, Mar 12, 2013 at 3:46 PM, [email protected] < >> >>>>>>>>> [email protected]> wrote: >> >>>>>>>>> >> >>>>>>>>>> We should simply do some tests to measure the actual video with >> >>>>>>>>>> h264 and the default Sorensen Codec. >> >>>>>>>>>> Then we have some numbers. >> >>>>>>>>>> >> >>>>>>>>>> What are the exact reports for "Flash Player crashing" ? >> >>>>>>>>>> >> >>>>>>>>>> Sebastian >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> 2013/3/12 Maxim Solodovnik <[email protected]> >> >>>>>>>>>> >> >>>>>>>>>>> I can add switching H264 off, but I'm not sure if this is the >> >>>>>>>>>>> problem. >> >>>>>>>>>>> Most claims are related to the crashing flash in browser. >> >>>>>>>>>>> Do you think this would help? >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On Tue, Mar 12, 2013 at 2:56 PM, [email protected] < >> >>>>>>>>>>> [email protected]> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> Sorry I did not meant default h323 I meant the default >> >>>>>>>>>>>> Sorenson Spark >> >>>>>>>>>>>> <http://en.wikipedia.org/wiki/Sorenson_Spark>(Sorenson H.263) >> >>>>>>>>>>>> >> >>>>>>>>>>>> Sebastian >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> 2013/3/12 [email protected] <[email protected]> >> >>>>>>>>>>>> >> >>>>>>>>>>>> h264 simply needs more computing time. >> >>>>>>>>>>>>> AEC also is enabled (which needs some percentages more CPU >> >>>>>>>>>>>>> power then the previous implementation). >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Switching to later Flex SDK is surely desirable but >> >>>>>>>>>>>>> basically >> >>>>>>>>>>>>> the performance is a Flash Player/VirtualMachine issue not a >> >>>>>>>>>>>>> Flash Compiler >> >>>>>>>>>>>>> issue. So as long as there is no Flash Player 12 that >> >>>>>>>>>>>>> requires a later Flex >> >>>>>>>>>>>>> SDK it is unlikely that you will gain performance >> >>>>>>>>>>>>> advantages. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I think there is a hardware acceleration for playback of >> >>>>>>>>>>>>> h264 >> >>>>>>>>>>>>> video, but I have really no idea about producing h264 in the >> >>>>>>>>>>>>> browser in >> >>>>>>>>>>>>> that context. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> From my point of view the main reason for using h264 is the >> >>>>>>>>>>>>> SIP >> >>>>>>>>>>>>> integration. For users that don't use SIP integration using >> >>>>>>>>>>>>> h264 will >> >>>>>>>>>>>>> simply just mean an annoying CPU usage. >> >>>>>>>>>>>>> The case is different for AEC from my point of view. AEC >> >>>>>>>>>>>>> brings >> >>>>>>>>>>>>> enhancement for everybody immediately. And the more of CPU >> >>>>>>>>>>>>> that it uses is >> >>>>>>>>>>>>> only 3-4 % from my point of view. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> So my preference would be to make the video codec use the >> >>>>>>>>>>>>> standard h323. To be honest: Who has ever complained in the >> >>>>>>>>>>>>> last couple of >> >>>>>>>>>>>>> years about video quality? The discussion is almost always >> >>>>>>>>>>>>> about audio >> >>>>>>>>>>>>> delay, audio quality, micro echo, bad microphones et cetera >> >>>>>>>>>>>>> but actually >> >>>>>>>>>>>>> never about video quality. >> >>>>>>>>>>>>> And from what I have seen h264 also brings no improvements >> >>>>>>>>>>>>> in >> >>>>>>>>>>>>> terms of bandwidth usage. >> >>>>>>>>>>>>> h264 could be available via configuration (or to enable SIP >> >>>>>>>>>>>>> integration), but h323 should be used by default. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Sebastian >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> 2013/3/12 Maxim Solodovnik <[email protected]> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> Hello Raju, Sebastian, >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> according to >> >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/OPENMEETINGS-559 and >> >>>>>>>>>>>>>> various user reports (including mail from Sebastian[1]) >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Main code changes were: adding EnchancedMicrophone and >> >>>>>>>>>>>>>> switch >> >>>>>>>>>>>>>> to h264 >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> According to the Google switching to h264 can cause higher >> >>>>>>>>>>>>>> CPU >> >>>>>>>>>>>>>> usage. >> >>>>>>>>>>>>>> Can this be fixed by changing H264Level? >> >>>>>>>>>>>>>> (currently H264Level.LEVEL_1_2 is used) >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Maybe you can us understand were performance/stability >> >>>>>>>>>>>>>> degradation caused by code changes? Or maybe it is because >> >>>>>>>>>>>>>> of Flex4.6.0? >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Can stability be improved by switching to Flex4.9.1? >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Thanks in advance for your help >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> [1] http://markmail.org/message/2el63qarsjmbvfyy >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> <http://markmail.org/message/2el63qarsjmbvfyy>-- >> >>>>>>>>>>>>>> WBR >> >>>>>>>>>>>>>> Maxim aka solomax >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> -- >> >>>>>>>>>>>>> Sebastian Wagner >> >>>>>>>>>>>>> https://twitter.com/#!/dead_lock >> >>>>>>>>>>>>> http://www.webbase-design.de >> >>>>>>>>>>>>> http://www.wagner-sebastian.com >> >>>>>>>>>>>>> [email protected] >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> -- >> >>>>>>>>>>>> Sebastian Wagner >> >>>>>>>>>>>> https://twitter.com/#!/dead_lock >> >>>>>>>>>>>> http://www.webbase-design.de >> >>>>>>>>>>>> http://www.wagner-sebastian.com >> >>>>>>>>>>>> [email protected] >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> -- >> >>>>>>>>>>> WBR >> >>>>>>>>>>> Maxim aka solomax >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> -- >> >>>>>>>>>> Sebastian Wagner >> >>>>>>>>>> https://twitter.com/#!/dead_lock >> >>>>>>>>>> http://www.webbase-design.de >> >>>>>>>>>> http://www.wagner-sebastian.com >> >>>>>>>>>> [email protected] >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> WBR >> >>>>>>>>> Maxim aka solomax >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Sebastian Wagner >> >>>>>>>> https://twitter.com/#!/dead_lock >> >>>>>>>> http://www.webbase-design.de >> >>>>>>>> http://www.wagner-sebastian.com >> >>>>>>>> [email protected] >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> WBR >> >>>>>>> Maxim aka solomax >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> WBR >> >>>>>> Maxim aka solomax >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Sebastian Wagner >> >>>>> https://twitter.com/#!/dead_lock >> >>>>> http://www.webbase-design.de >> >>>>> http://www.wagner-sebastian.com >> >>>>> [email protected] >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> WBR >> >>>> Maxim aka solomax >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Sebastian Wagner >> >>> https://twitter.com/#!/dead_lock >> >>> http://www.webbase-design.de >> >>> http://www.wagner-sebastian.com >> >>> [email protected] >> >>> >> >> >> >> >> >> >> >> -- >> >> WBR >> >> Maxim aka solomax >> >> >> > >> > >> > >> > -- >> > Sebastian Wagner >> > https://twitter.com/#!/dead_lock >> > http://www.webbase-design.de >> > http://www.wagner-sebastian.com >> > [email protected] > > > > > -- > WBR > Maxim aka solomax
