Recherche avancée

Sur d’autres sites (1857)

• Developing A Shader-Based Video Codec

  22 juin 2013, par Multimedia Mike — Outlandish Brainstorms

  Early last month, this thing called ORBX.js was in the news. It ostensibly has something to do with streaming video and codec technology, which naturally catches my interest. The hype was kicked off by Mozilla honcho Brendan Eich when he posted an article asserting that HD video decoding could be entirely performed in JavaScript. We’ve seen this kind of thing before using Broadway– an H.264 decoder implemented entirely in JS. But that exposes some very obvious limitations (notably CPU usage).

  But this new video codec promises 1080p HD playback directly in JavaScript which is a lofty claim. How could it possibly do this ? I got the impression that performance was achieved using WebGL, an extension which allows JavaScript access to accelerated 3D graphics hardware. Browsing through the conversations surrounding the ORBX.js announcement, I found this confirmation from Eich himself :

  You’re right that WebGL does heavy lifting.

  As of this writing, ORBX.js remains some kind of private tech demo. If there were a public demo available, it would necessarily be easy to reverse engineer the downloadable JavaScript decoder.

  But the announcement was enough to make me wonder how it could be possible to create a video codec which effectively leverages 3D hardware.

  Prior Art
  In theorizing about this, it continually occurs to me that I can’t possibly be the first person to attempt to do this (or the ORBX.js people, for that matter). In googling on the matter, I found various forums and Q&A posts where people asked if it were possible to, e.g., accelerate JPEG decoding and presentation using 3D hardware, with no answers. I also found a blog post which describes a plan to use 3D hardware to accelerate VP8 video decoding. It was a project done under the banner of Google’s Summer of Code in 2011, though I’m not sure which open source group mentored the effort. The project did not end up producing the shader-based VP8 codec originally chartered but mentions that “The ‘client side’ of the VP8 VDPAU implementation is working and is currently being reviewed by the libvdpau maintainers.” I’m not sure what that means. Perhaps it includes modifications to the public API that supports VP8, but is waiting for the underlying hardware to actually implement VP8 decoding blocks in hardware.

  What’s So Hard About This ?
  Video decoding is a computationally intensive task. GPUs are known to be really awesome at chewing through computationally intensive tasks. So why aren’t GPUs a natural fit for decoding video codecs ?

  Generally, it boils down to parallelism, or lack of opportunities thereof. GPUs are really good at doing the exact same operations over lots of data at once. The problem is that decoding compressed video usually requires multiple phases that cannot be parallelized, and the individual phases often cannot be parallelized. In strictly mathematical terms, a compressed data stream will need to be decoded by applying a function f(x) over each data element, x₀ .. x_n. However, the function relies on having applied the function to the previous data element, i.e. :

  f(xn) = f(f(xn-1))
  

  What happens when you try to parallelize such an algorithm ? Temporal rifts in the space/time continuum, if you’re in a Star Trek episode. If you’re in the real world, you’ll get incorrect, unusuable data as the parallel computation is seeded with a bunch of invalid data at multiple points (which is illustrated in some of the pictures in the aforementioned blog post about accelerated VP8).

  Example : JPEG
  Let’s take a very general look at the various stages involved in decoding the ubiquitous JPEG format :

  
  
  

  What are the opportunities to parallelize these various phases ?
  

  • Huffman decoding (run length decoding and zig-zag reordering is assumed to be rolled into this phase) : not many opportunities for parallelizing the various Huffman formats out there, including this one. Decoding most Huffman streams is necessarily a sequential operation. I once hypothesized that it would be possible to engineer a codec to achieve some parallelism during the entropy decoding phase, and later found that On2′s VP8 codec employs the scheme. However, such a scheme is unlikely to break down to such a fine level that WebGL would require.
  • Reverse DC prediction : JPEG — and many other codecs — doesn’t store full DC coefficients. It stores differences in successive DC coefficients. Reversing this process can’t be parallelized. See the discussion in the previous section.
  • Dequantize coefficients : This could be very parallelized. It should be noted that software decoders often don’t dequantize all coefficients. Many coefficients are 0 and it’s a waste of a multiplication operation to dequantize. Thus, this phase is sometimes rolled into the Huffman decoding phase.
  • Invert discrete cosine transform : This seems like it could be highly parallelizable. I will be exploring this further in this post.
  • Convert YUV -> RGB for final display : This is a well-established use case for 3D acceleration.

  Crash Course in 3D Shaders and Humility
  So I wanted to see if I could accelerate some parts of JPEG decoding using something called shaders. I made an effort to understand 3D programming and its associated math throughout the 1990s but 3D technology left me behind a very long time ago while I got mixed up in this multimedia stuff. So I plowed through a few books concerning WebGL (thanks to my new Safari Books Online subscription). After I learned enough about WebGL/JS to be dangerous and just enough about shader programming to be absolutely lethal, I set out to try my hand at optimizing IDCT using shaders.

  Here’s my extremely high level (and probably hopelessly naive) view of the modern GPU shader programming model :

  
  
  

  The WebGL program written in JavaScript drives the show. It sends a set of vertices into the WebGL system and each vertex is processed through a vertex shader. Then, each pixel that falls within a set of vertices is sent through a fragment shader to compute the final pixel attributes (R, G, B, and alpha value). Another consideration is textures : This is data that the program uploads to GPU memory which can be accessed programmatically by the shaders).

  These shaders (vertex and fragment) are key to the GPU’s programmability. How are they programmed ? Using a special C-like shading language. Thought I : “C-like language ? I know C ! I should be able to master this in short order !” So I charged forward with my assumptions and proceeded to get smacked down repeatedly by the overall programming paradigm. I came to recognize this as a variation of the scientific method : Develop a hypothesis– in my case, a mental model of how the system works ; develop an experiment (short program) to prove or disprove the model ; realize something fundamental that I was overlooking ; formulate new hypothesis and repeat.

  First Approach : Vertex Workhorse
  My first pitch goes like this :

  • Upload DCT coefficients to GPU memory in the form of textures
  • Program a vertex mesh that encapsulates 16×16 macroblocks
  • Distribute the IDCT effort among multiple vertex shaders
  • Pass transformed Y, U, and V blocks to fragment shader which will convert the samples to RGB

  So the idea is that decoding of 16×16 macroblocks is parallelized. A macroblock embodies 6 blocks :

  
  
  

  It would be nice to process one of these 6 blocks in each vertex. But that means drawing a square with 6 vertices. How do you do that ? I eventually realized that drawing a square with 6 vertices is the recommended method for drawing a square on 3D hardware. Using 2 triangles, each with 3 vertices (0, 1, 2 ; 3, 4, 5) :

  
  
  

  A vertex shader knows which (x, y) coordinates it has been assigned, so it could figure out which sections of coefficients it needs to access within the textures. But how would a vertex shader know which of the 6 blocks it should process ? Solution : Misappropriate the vertex’s z coordinate. It’s not used for anything else in this case.

  So I set all of that up. Then I hit a new roadblock : How to get the reconstructed Y, U, and V samples transported to the fragment shader ? I have found that communicating between shaders is quite difficult. Texture memory ? WebGL doesn’t allow shaders to write back to texture memory ; shaders can only read it. The standard way to communicate data from a vertex shader to a fragment shader is to declare variables as “varying”. Up until this point, I knew about varying variables but there was something I didn’t quite understand about them and it nagged at me : If 3 different executions of a vertex shader set 3 different values to a varying variable, what value is passed to the fragment shader ?

  It turns out that the varying variable varies, which means that the GPU passes interpolated values to each fragment shader invocation. This completely destroys this idea.

  Second Idea : Vertex Workhorse, Take 2
  The revised pitch is to work around the interpolation issue by just having each vertex shader invocation performs all 6 block transforms. That seems like a lot of redundant. However, I figured out that I can draw a square with only 4 vertices by arranging them in an ‘N’ pattern and asking WebGL to draw a TRIANGLE_STRIP instead of TRIANGLES. Now it’s only doing the 4x the extra work, and not 6x. GPUs are supposed to be great at this type of work, so it shouldn’t matter, right ?

  I wired up an experiment and then ran into a new problem : While I was able to transform a block (or at least pretend to), and load up a varying array (that wouldn’t vary since all vertex shaders wrote the same values) to transmit to the fragment shader, the fragment shader can’t access specific values within the varying block. To clarify, a WebGL shader can use a constant value — or a value that can be evaluated as a constant at compile time — to index into arrays ; a WebGL shader can not compute an index into an array. Per my reading, this is a WebGL security consideration and the limitation may not be present in other OpenGL(-ES) implementations.

  Not Giving Up Yet : Choking The Fragment Shader
  You might want to be sitting down for this pitch :

  • Vertex shader only interpolates texture coordinates to transmit to fragment shader
  • Fragment shader performs IDCT for a single Y sample, U sample, and V sample
  • Fragment shader converts YUV -> RGB

  Seems straightforward enough. However, that step concerning IDCT for Y, U, and V entails a gargantuan number of operations. When computing the IDCT for an entire block of samples, it’s possible to leverage a lot of redundancy in the math which equates to far fewer overall operations. If you absolutely have to compute each sample individually, for an 8×8 block, that requires 64 multiplication/accumulation (MAC) operations per sample. For 3 color planes, and including a few extra multiplications involved in the RGB conversion, that tallies up to about 200 MACs per pixel. Then there’s the fact that this approach means a 4x redundant operations on the color planes.

  It’s crazy, but I just want to see if it can be done. My approach is to pre-compute a pile of IDCT constants in the JavaScript and transmit them to the fragment shader via uniform variables. For a first order optimization, the IDCT constants are formatted as 4-element vectors. This allows computing 16 dot products rather than 64 individual multiplication/addition operations. Ideally, GPU hardware executes the dot products faster (and there is also the possibility of lining these calculations up as matrices).

  I can report that I actually got a sample correctly transformed using this approach. Just one sample, through. Then I ran into some new problems :

  Problem #1 : Computing sample #1 vs. sample #0 requires a different table of 64 IDCT constants. Okay, so create a long table of 64 * 64 IDCT constants. However, this suffers from the same problem as seen in the previous approach : I can’t dynamically compute the index into this array. What’s the alternative ? Maintain 64 separate named arrays and implement 64 branches, when branching of any kind is ill-advised in shader programming to begin with ? I started to go down this path until I ran into…

  Problem #2 : Shaders can only be so large. 64 * 64 floats (4 bytes each) requires 16 kbytes of data and this well exceeds the amount of shader storage that I can assume is allowed. That brings this path of exploration to a screeching halt.

  Further Brainstorming
  I suppose I could forgo pre-computing the constants and directly compute the IDCT for each sample which would entail lots more multiplications as well as 128 cosine calculations per sample (384 considering all 3 color planes). I’m a little stuck with the transform idea right now. Maybe there are some other transforms I could try.

  Another idea would be vector quantization. What little ORBX.js literature is available indicates that there is a method to allow real-time streaming but that it requires GPU assistance to yield enough horsepower to make it feasible. When I think of such severe asymmetry between compression and decompression, my mind drifts towards VQ algorithms. As I come to understand the benefits and limitations of GPU acceleration, I think I can envision a way that something similar to SVQ1, with its copious, hierarchical vector tables stored as textures, could be implemented using shaders.

  So far, this all pertains to intra-coded video frames. What about opportunities for inter-coded frames ? The only approach that I can envision here is to use WebGL’s readPixels() function to fetch the rasterized frame out of the GPU, and then upload it again as a new texture which a new frame processing pipeline could reference. Whether this idea is plausible would require some profiling.

  Using interframes in such a manner seems to imply that the entire codec would need to operate in RGB space and not YUV.

  Conclusions
  The people behind ORBX.js have apparently figured out a way to create a shader-based video codec. I have yet to even begin to reason out a plausible approach. However, I’m glad I did this exercise since I have finally broken through my ignorance regarding modern GPU shader programming. It’s nice to have a topic like multimedia that allows me a jumping-off point to explore other areas.

• Segmentation Analytics : How to Leverage It on Your Site

  27 octobre 2023, par Erin — Analytics Tips

  The deeper you go with your customer analytics, the better your insights will be.

  The result ? Your marketing performance soars to new heights.

  Customer segmentation is one of the best ways businesses can align their marketing strategies with an effective output to generate better results. Marketers know that targeting the right people is one of the most important aspects of connecting with and converting web visitors into customers.

  By diving into customer segmentation analytics, you’ll be able to transform your loosely defined and abstract audience into tangible, understandable segments, so you can serve them better.

  In this guide, we’ll break down customer segmentation analytics, the different types, and how you can delve into these analytics on your website to grow your business.

  What is customer segmentation ?

  Before we dive into customer segmentation analytics, let’s take a step back and look at customer segmentation in general. 

  Customer segmentation is the process of dividing your customers up into different groups based on specific characteristics.

  These groups could be based on demographics like age or location or behaviours like recent purchases or website visits. 

  By splitting your audience into different segments, your marketing team will be able to craft highly targeted and relevant marketing campaigns that are more likely to convert.

  Additionally, customer segmentation allows businesses to gain new insights into their audience. For example, by diving deep into different segments, marketers can uncover pain points and desires, leading to increased conversion rates and return on investment.

  But, to grasp the different customer segments, organisations need to know how to collect, digest and interpret the data for usable insights to improve their business. That’s where segmentation analytics comes in.

  What is customer segmentation analytics ?

  Customer segmentation analytics splits customers into different groups within your analytics software to create more detailed customer data and improve targeting.

  

  With customer segmentation, you’re splitting your customers into different groups. With customer segmentation analytics, you’re doing this all within your analytics platform so you can understand them better.

  One example of splitting your customers up is by country. For example, let’s say you have a global customer base. So, you go into your analytics software and find that 90% of your website visitors come from five countries : the UK, the US, Australia, Germany and Japan.

  In this area, you could then create customer segmentation subsets based on these five countries. Moving forward, you could then hop into your analytics tool at any point in time and analyse the segments by country. 

  For example, if you wanted to see how well your recent marketing campaign impacted your Japanese customers, you could look at your Japanese subset within your analytics and dive into the data.

  The primary goal of customer segmentation analytics is to gather actionable data points to give you an in-depth understanding of your customers. By gathering data on your different audience segments, you’ll discover insights on your customers that you can use to optimise your website, marketing campaigns, mobile apps, product offerings and overall customer experience.

  Rather than lumping your entire customer base into a single mass, customer segmentation analytics allows you to meet even more specific and relevant needs and pain points of your customers to serve them better.

  By allowing you to “zoom in” on your audience, segmentation analytics helps you offer more value to your customers, giving you a competitive advantage in the marketplace.

  5 types of segmentation

  There are dozens of different ways to split up your customers into segments. The one you choose depends on your goals and marketing efforts. Each type of segmentation offers a different view of your customers so you can better understand their specific needs to reach them more effectively.

  While you can segment your customers in almost endless ways, five common types the majority fall under are :

  

  Geographic

  Another way to segment is by geography.

  This is important because you could have drastically different interests, pain points and desires based on where you live.

  If you’re running a global e-commerce website that sells a variety of clothing products, geographic segmentation can play a crucial role in optimising your website.

  For instance, you may observe that a significant portion of your website visitors are from countries in the Southern Hemisphere, where it’s currently summer. On the other hand, visitors from the Northern Hemisphere are experiencing winter. Utilising this information, you can tailor your marketing strategy and website accordingly to increase sells.

  Where someone comes from can significantly impact how they will respond to your messaging, brand and offer.

  Geographic segmentation typically includes the following subtypes :

  • Cities (i.e., Austin, Paris, Berlin, etc.)
  • State (i.e., Massachusetts)
  • Country (i.e., Thailand)

  Psychographic

  Another key segmentation type of psychographic. This is where you split your customers into different groups based on their lifestyles.

  Psychographic segmentation is a method of dividing your customers based on their habits, attitudes, values and opinions. You can unlock key emotional elements that impact your customers’ purchasing behaviours through this segmentation type.

  Psychographic segmentation typically includes the following subtypes :

  • Values
  • Habits
  • Opinions

  Behavioural

  While psychographic segmentation looks at your customers’ overall lifestyle and habits, behavioural segmentation aims to dive into the specific individual actions they take daily, especially when interacting with your brand or your website.

  Your customers won’t all interact with your brand the same way. They’ll act differently when interacting with your products and services for several reasons. 

  Behavioural segmentation can help reveal certain use cases, like why customers buy a certain product, how often they buy it, where they buy it and how they use it.

  By unpacking these key details about your audience’s behaviour, you can optimise your campaigns and messaging to get the most out of your marketing efforts to reach new and existing customers.

  Behavioural segmentation typically includes the following subtypes :

  • Interactions
  • Interests
  • Desires

  Technographic

  Another common segmentation type is technographic segmentation. As the name suggests, this technologically driven segment seeks to understand how your customers use technology.

  While this is one of the newest segmentation types marketers use, it’s a powerful method to help you understand the types of tech your customers use, how often they use it and the specific ways they use it.

  Technographic segmentation typically includes the following subtypes :

  • Smartphone type
  • Device type : smartphone, desktop, tablet
  • Apps
  • Video games

  Demographic

  The most common approach to segmentation is to split your customers up by demographics. 

  Demographic segmentation typically includes subtypes like language, job title, age or education.

  This can be helpful for tailoring your content, products, and marketing efforts to specific audience segments. One way to capture this information is by using web analytics tools, where language is often available as a data point.

  However, for accurate insights into other demographic segments like job titles, which may not be available (or accurate) in analytics tools, you may need to implement surveys or add fields to forms on your website to gather this specific information directly from your visitors.

  How to build website segmentation analytics

  With Matomo, you can create a variety of segments to divide your website visitors into different groups. Matomo’s Segments allows you to view segmentation analytics on subsets of your audience, like :

  • The device they used while visiting your site
  • What channel they entered your site from
  • What country they are located
  • Whether or not they visited a key page of your website
  • And more

  While it’s important to collect general data on every visitor you have to your website, a key to website growth is understanding each type of visitor you have.

  For example, here’s a screenshot of how you can segment all of your website’s visitors from New Zealand :

  

  The criteria you use to define these segments are based on the data collected within your web analytics platform.

  Here are some popular ways you can create some common themes on Matomo that can be used to create segments :

  Visit based segments

  Create segments in Matomo based on visitors’ patterns. 

  For example :

  • Do returning visitors show different traits than first-time visitors ?
  • Do people who arrive on your blog experience your website differently than those arriving on a landing page ?

  This information can inform your content strategy, user interface design and marketing efforts.

  Demographic segments

  Create segments in Matomo based on people’s demographics. 

  For example :

  • User’s browser language
  • Location

  This can enable you to tailor your approach to specific demographics, improving the performance of your marketing campaigns.

  Technographic segments

  Create segments in Matomo based on people’s technographics. 

  For example :

  • Web browser being used (i.e., Chrome, Safari, Firefox, etc.)
  • Device type (i.e., smartphone, tablet, desktop)

  This can inform how to optimise your website based on users’ technology preferences, enhancing the effectiveness of your website.

  Interaction based segments

  Create segments in Matomo based on interactions. 

  For example :

  • Events (i.e., when someone clicks a specific URL on your website)
  • Goals (i.e., when someone stays on your site for a certain period)

  Insights from this can empower you to fine-tune your content and user experience for increasing conversion rates.

  

  Campaign-based segments

  Create segments in Matomo based on campaigns. 

  For example :

  • Visitors arriving from specific traffic sources
  • Visitors arriving from specific advertising campaigns

  With these insights, you can assess the performance of your marketing efforts, optimise your ad spend and make data-driven decisions to enhance your campaigns for better results.

  Ecommerce segments

  Create segments in Matomo based on ecommerce. 

  For example :

  • Visitors who purchased vs. those who didn’t
  • Visitors who purchased a specific product

  This allows you to refine your website and marketing strategy for increased conversions and revenue.

  Leverage Matomo for your segmentation analytics

  By now, you can see the power of segmentation analytics and how they can be used to understand your customers and website visitors better. By breaking down your audience into groups, you’ll be able to gain insights into those segments to know how to serve them better with improved messaging and relevant products.

  If you’re ready to begin using segmentation analytics on your website, try Matomo. Start your 21-day free trial now — no credit card required.

  Matomo is an ideal choice for marketers looking for an easy-to-use, out-of-the-box web analytics solution that delivers accurate insights while keeping privacy and compliance at the forefront.

• How to transcribe the recording for speech recognization

  29 mai 2021, par DLim

  After downloading and uploading files related to the mozilla deeepspeech, I started using google colab. I am using mozilla/deepspeech for speech recognization. The code shown below is for recording my audio. After recording the audio, I want to use a function/method to transcribe the recording into text. Everything compiles, but the text does not come out correctly. Any thoughts in my code ?

  


  """&#xA;To write this piece of code I took inspiration/code from a lot of places.&#xA;It was late night, so I&#x27;m not sure how much I created or just copied o.O&#xA;Here are some of the possible references:&#xA;https://blog.addpipe.com/recording-audio-in-the-browser-using-pure-html5-and-minimal-javascript/&#xA;https://stackoverflow.com/a/18650249&#xA;https://hacks.mozilla.org/2014/06/easy-audio-capture-with-the-mediarecorder-api/&#xA;https://air.ghost.io/recording-to-an-audio-file-using-html5-and-js/&#xA;https://stackoverflow.com/a/49019356&#xA;"""&#xA;from google.colab.output import eval_js&#xA;from base64 import b64decode&#xA;from scipy.io.wavfile import read as wav_read&#xA;import io&#xA;import ffmpeg&#xA;&#xA;AUDIO_HTML = """&#xA;<code class="echappe-js">&lt;script&gt;&amp;#xA;var my_div = document.createElement(&quot;DIV&quot;);&amp;#xA;var my_p = document.createElement(&quot;P&quot;);&amp;#xA;var my_btn = document.createElement(&quot;BUTTON&quot;);&amp;#xA;var t = document.createTextNode(&quot;Press to start recording&quot;);&amp;#xA;&amp;#xA;my_btn.appendChild(t);&amp;#xA;//my_p.appendChild(my_btn);&amp;#xA;my_div.appendChild(my_btn);&amp;#xA;document.body.appendChild(my_div);&amp;#xA;&amp;#xA;var base64data = 0;&amp;#xA;var reader;&amp;#xA;var recorder, gumStream;&amp;#xA;var recordButton = my_btn;&amp;#xA;&amp;#xA;var handleSuccess = function(stream) {&amp;#xA;  gumStream = stream;&amp;#xA;  var options = {&amp;#xA;    //bitsPerSecond: 8000, //chrome seems to ignore, always 48k&amp;#xA;    mimeType : &amp;#x27;audio/webm;codecs=opus&amp;#x27;&amp;#xA;    //mimeType : &amp;#x27;audio/webm;codecs=pcm&amp;#x27;&amp;#xA;  };            &amp;#xA;  //recorder = new MediaRecorder(stream, options);&amp;#xA;  recorder = new MediaRecorder(stream);&amp;#xA;  recorder.ondataavailable = function(e) {            &amp;#xA;    var url = URL.createObjectURL(e.data);&amp;#xA;    var preview = document.createElement(&amp;#x27;audio&amp;#x27;);&amp;#xA;    preview.controls = true;&amp;#xA;    preview.src = url;&amp;#xA;    document.body.appendChild(preview);&amp;#xA;&amp;#xA;    reader = new FileReader();&amp;#xA;    reader.readAsDataURL(e.data); &amp;#xA;    reader.onloadend = function() {&amp;#xA;      base64data = reader.result;&amp;#xA;      //console.log(&quot;Inside FileReader:&quot; &amp;#x2B; base64data);&amp;#xA;    }&amp;#xA;  };&amp;#xA;  recorder.start();&amp;#xA;  };&amp;#xA;&amp;#xA;recordButton.innerText = &quot;Recording... press to stop&quot;;&amp;#xA;&amp;#xA;navigator.mediaDevices.getUserMedia({audio: true}).then(handleSuccess);&amp;#xA;&amp;#xA;&amp;#xA;function toggleRecording() {&amp;#xA;  if (recorder &amp;amp;&amp;amp; recorder.state == &quot;recording&quot;) {&amp;#xA;      recorder.stop();&amp;#xA;      gumStream.getAudioTracks()[0].stop();&amp;#xA;      recordButton.innerText = &quot;Saving the recording... pls wait!&quot;&amp;#xA;  }&amp;#xA;}&amp;#xA;&amp;#xA;// https://stackoverflow.com/a/951057&amp;#xA;function sleep(ms) {&amp;#xA;  return new Promise(resolve =&gt; setTimeout(resolve, ms));&amp;#xA;}&amp;#xA;&amp;#xA;var data = new Promise(resolve=&gt;{&amp;#xA;//recordButton.addEventListener(&quot;click&quot;, toggleRecording);&amp;#xA;recordButton.onclick = ()=&gt;{&amp;#xA;toggleRecording()&amp;#xA;&amp;#xA;sleep(2000).then(() =&gt; {&amp;#xA;  // wait 2000ms for the data to be available...&amp;#xA;  // ideally this should use something like await...&amp;#xA;  //console.log(&quot;Inside data:&quot; &amp;#x2B; base64data)&amp;#xA;  resolve(base64data.toString())&amp;#xA;&amp;#xA;});&amp;#xA;&amp;#xA;}&amp;#xA;});&amp;#xA;      &amp;#xA;&lt;/script&gt;&#xA;"""&#xA;&#xA;def get_audio() :&#xA;  display(HTML(AUDIO_HTML))&#xA;  data = eval_js("data")&#xA;  binary = b64decode(data.split(',')[1])&#xA;  &#xA;  process = (ffmpeg&#xA;    .input('pipe:0')&#xA;    .output('pipe:1', format='wav')&#xA;    .run_async(pipe_stdin=True, pipe_stdout=True, pipe_stderr=True, quiet=True, overwrite_output=True)&#xA;  )&#xA;  output, err = process.communicate(input=binary)&#xA;  &#xA;  riff_chunk_size = len(output) - 8&#xA;  # Break up the chunk size into four bytes, held in b.&#xA;  q = riff_chunk_size&#xA;  b = []&#xA;  for i in range(4) :&#xA;      q, r = divmod(q, 256)&#xA;      b.append(r)&#xA;&#xA;  # Replace bytes 4:8 in proc.stdout with the actual size of the RIFF chunk.&#xA;  riff = output[:4] + bytes(b) + output[8 :]&#xA;&#xA;  sr, audio = wav_read(io.BytesIO(riff))&#xA;&#xA;  return audio, sr&#xA;&#xA;audio, sr = get_audio()&#xA;

  


  def recordingTranscribe(audio):
  data16 = np.frombuffer(audio)
  return model.stt(data16)


  


  recordingTranscribe(audio)