Recherche avancée

Sur d’autres sites (6349)

• Why iFrame is a good idea

  15 octobre 2009

  I’ve seen some hilariously uninformed posts about the new Apple iFrame specification. Let me take a minute to explain what it actually is.

  First off, as opposed to what the fellow in the Washington Post writes, it’s not really a new format. iFrame is just a way of using formats that we’ve already know and love. As the name suggests, iFrame is just an i-frame only H.264 specification, using AAC audio. An intraframe version of H.264 eh ? Sounds a lot like AVC-Intra, right ? Exactly. And for exactly the same reasons - edit-ability. Whereas AVC-Intra targets the high end, iFrame targets the low end.

  Even when used in intraframe mode, H.264 has some huge advantage over the older intraframe codecs like DV or DVCProHD. For example, significantly better entropy coding, adaptive quantization, and potentially variable bitrates. There are many others. Essentially, it’s what happens when you take DV and spend another 10 years working on making it better. That’s why Panasonic’s AVC-Intra cameras can do DVCProHD quality video at half (or less) the bitrate.

  Why does iFrame matter for editing ? Anyone who’s tried to edit video from one of the modern H.264 cameras without first transcoding to an intraframe format has experienced the huge CPU demands and sluggish performance. Behind the scenes it’s even worse. Because interframe H.264 can have very long GOPs, displaying any single frame can rely on dozens or even hundreds of other frames. Because of the complexity of H.264, building these frames is very high-cost. And it’s a variable cost. Decoding the first frame in a GOP is relatively trivial, while decoding the middle B-frame can be hugely expensive.

  Programs like iMovie mask that from the user in some cases, but at the expensive of high overhead. But, anyone who’s imported AVC-HD video into Final Cut Pro or iMovie knows that there’s a long "importing" step - behind the scenes, the applications are transcoding your video into an intraframe format, like Apple Intermediate or ProRes. It sort of defeats one of the main purposes of a file-based workflow.

  You’ve also probably noticed the amount of time it takes to export a video in an interframe format. Anyone who’s edited HDV in Final Cut Pro has experienced this. With DV, doing an "export to quicktime" is simply a matter of Final Cut Pro rewriting all of the data to disk - it’s essentially a file copy. With HDV, Final Cut Pro has to do a complete reencode of the whole timeline, to fit everything into the new GOP structure. Not only is this time consuming, but it’s essentially a generation loss.

  iFrame solves these issues by giving you an intraframe codec, with modern efficiency, which can be decoded by any of the H.264 decoders that we already know and love.

  Having this as an optional setting on cameras is a huge step forward for folks interested in editing video. Hopefully some of the manufacturers of AVC-HD cameras will adopt this format as well. I’ll gladly trade a little resolution for instant edit-ability.

• Continuous RTMP Streaming with FFmpeg Without Restarting the Process for New Videos

  3 avril 2024, par 刘小佳

  I'm facing a challenge with my workflow and would appreciate any guidance or solutions you might have. My business scenario involves a service that periodically generates new video files locally (e.g., 1.mp4, 2.mp4, ...). These files are then streamed to an RTMP server using FFmpeg, and clients pull the stream via HTTP-FLV for playback.

  


  My goal is to ensure continuous streaming between video files without restarting the FFmpeg process each time a new video is ready to be streamed. Restarting FFmpeg for each new file introduces a disconnect in the client playback, which I'm trying to avoid to maintain stream continuity.

  


  I've explored several approaches based on the FFmpeg Concatenate wiki (https://trac.ffmpeg.org/wiki/Concatenate), but haven't achieved the desired outcome :
  
Approach 1 :
  
Using a list.txt file with ffconcat version 1.0 and dynamically updating the file (next.mp4) being played :

  


  ffconcat version 1.0
file next.mp4
file next.mp4


  


  And then streaming with :
ffmpeg -re -stream_loop -1 -f concat -i list.txt -flush_packets 0 -f flv rtmp://xxx
  
However, when attempting to replace next.mp4 (e.g., moving 2.mp4 to next.mp4 during the streaming of 1.mp4), I encountered a "device busy" error.
  
Approach 2 :
  
Using a nested list approach where list1.txt includes 1.mp4 and list2.txt, and vice versa :

  


  // list1.txt
ffconcat version 1.0
file '1.mp4'
file 'list2.txt'
// list2.txt
ffconcat version 1.0
file '2.mp4'
file 'list1.txt'


  


  Streaming with : ffmpeg -re -stream_loop -1 -f concat -i list1.txt -flush_packets 0 -f flv rtmp://xxx
  
In this setup, I tried modifying list1.txt to replace 1.mp4 with 3.mp4 during the streaming of 2.mp4, but FFmpeg would loop back to 1.mp4 and 2.mp4 before streaming 3.mp4 in the next cycle.

  


  Am I missing something in my methods ? Does anyone have a better approach to fulfill this requirement ? Any help would be greatly appreciated !

  


• Can VideoView be detach and reattached without stopping the it ?

  31 octobre 2013, par Thierry-Dimitri Roy

  I'm building an app where the user clicks on a button to show a video full screen. Initially the video is attached to a view inside a ViewPager. To be able to show it fullscreen I detach it from its parent and reattach it to the root view. This works fine, except when the video is switched to fullscreen while playing. When I detach a playing VideoView it just stop and I need to restart it. This is not acceptable since the video starts buffering before resume. Here the part of the code where the detach is done :

      final ViewGroup parent = (ViewGroup) findViewById(R.id.parent);
  
  
  
      final ViewGroup root = (ViewGroup) findViewById(R.id.root);
  
  
  
      Button b = (Button) findViewById(R.id.button);
  
      b.setOnClickListener(new OnClickListener() {
  
  
  
          @Override
  
          public void onClick(View v) {
  
              parent.removeView(mVideoView);
  
  
  
              LayoutParams lp = new FrameLayout.LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT);
  
              root.addView(mVideoView, lp);
  
          }
  
      });

  Depending of the device, I have a different log error. Probably because the actual video player is provided by the manufacturer and not the Android SDK. Here are the error logs for a Nexus 7 :

  10-30 20:26:18.618 : D/NvOsDebugPrintf(124) : NvMMDecTVMRDestroyParser Begin
  10-30 20:26:18.618 : D/NvOsDebugPrintf(124) : --------- Closing TVMR Frame Delivery Thread -------------
  10-30 20:26:18.678 : D/NvOsDebugPrintf(124) : ------- NvAvpClose -------
  10-30 20:26:18.678 : D/NvOsDebugPrintf(124) : NvMMDecTVMRDestroyParser Done
  10-30 20:26:18.678 : D/NvOsDebugPrintf(124) : NvMMLiteTVMRDecPrivateClose Done

  I haven't been able to detach the video without stopping it. I tried using SurfaceView or TextureView without success.

  I also tried finding a third party video player. I found a commercial one (http://www.vitamio.org/) that I can't really use for business reason. I found an open source one, that hasn't been updated in the last year (https://code.google.com/p/dolphin-player/).

  I'm currently targeting Android 4.2 or better on tablet only.