Recherche avancée

Sur d’autres sites (12833)

• Revision 8d3d2b76f3 : Tx size selection enhancements (1) Refines the modeling function and uses that

  22 juin 2013, par Deb Mukherjee

  Changed Paths :
   Modify /vp9/common/vp9_blockd.h

  
   Modify /vp9/encoder/vp9_encodeframe.c

  
   Modify /vp9/encoder/vp9_onyx_if.c

  
   Modify /vp9/encoder/vp9_onyx_int.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
  
  Tx size selection enhancements

  (1) Refines the modeling function and uses that to add some speed
  features. Specifically, intead of using a flag use_largest_txfm as
  a speed feature, an enum tx_size_search_method is used, of which
  two of the types are USE_FULL_RD and USE_LARGESTALL. Two other
  new types are added :
  USE_LARGESTINTRA (use largest only for intra)
  USE_LARGESTINTRA_MODELINTER (use largest for intra, and model for
  inter)

  (2) Another change is that the framework for deciding transform type
  is simplified to use a heuristic count based method rather than
  an rd based method using txfm_cache. In practice the new method
  is found to work just as well - with derf only -0.01 down.
  The new method is more compatible with the new framework where
  certain rd costs are based on full rd and certain others are
  based on modeled rd or are not computed. In this patch the existing
  rd based method is still kept for use in the USE_FULL_RD mode.
  In the other modes, the count based method is used.
  However the recommendation is to remove it eventually since the
  benefit is limited, and will remove a lot of complications in
  the code

  (3) Finally a bug is fixed with the existing use_largest_txfm speed feature
  that causes mismatches when the lossless mode and 4x4 WH transform is
  forced.

  Results on derf :
  USE_FULL_RD : +0.03% (due to change in the tables), 0% encode time reduction
  USE_LARGESTINTRA : -0.21%, 15% encode time reduction (this one is a
  pretty good compromise)
  USE_LARGESTINTRA_MODELINTER : -0.98%, 22% encode time reduction
  (currently the benefit of modeling is limited for txfm size selection,
  but keeping this enum as a placeholder) .
  USE_LARGESTALL : -1.05%, 27% encode-time reduction (same as existing
  use_largest_txfm speed feature).

  Change-Id : I4d60a5f9ce78fbc90cddf2f97ed91d8bc0d4f936

• Qt browser plugin with Live555 and FFMPEG

  7 mars 2014, par user1047400

  I built a widget in Qt that play a rtsp audio/video stream with Live555 and FFMPEG.
  I works and now I want to include it inside a Qt BrowserPlugin.
  My plugin at the moment is able to start the RTSP session (i can see packets start to arrive from the camera) but an error occurs and plugin stops with an error.

  Could anyone say me anything about this kind of problem ?

  The only thing that Firefox says is "anomalous plugin crash". In practice it starts for some seconds and than crashs, even if with WireShark I can see that the RTSP session is started and packets are coming from the camera to my PC.

  My .pro file is :

  QT += core
  
  QT += gui
  
  QT += multimedia
  
  
  
  CONFIG   += console
  
  CONFIG   -= app_bundle
  
  TEMPLATE = app
  
  
  
  TARGET = pluginvs
  
  
  
  win32 {
  
  RC_FILE     = pluginvs.rc
  
  } else:mac {
  
  QMAKE_INFO_PLIST = Info.plist
  
  REZ_FILES += pluginvs.r
  
  rsrc_files.files = pluginvs.rsrc
  
  rsrc_files.path = Contents/Resources
  
  QMAKE_BUNDLE_DATA += rsrc_files
  
  }
  
  
  
  SOURCES += \
  
  virtualscreen.cpp \
  
  videosink.cpp \
  
  threadlistener.cpp \
  
  rtspmanager.cpp \
  
  livetaskscheduler.cpp \
  
  audiosink.cpp \
  
  audioplayer.cpp \
  
  pluginvs.cpp
  
  
  
  HEADERS += \
  
  virtualscreen.h \
  
  videosink.h \
  
  threadlistener.h \
  
  rtspmanager.h \
  
  livetaskscheduler.h \
  
  audiosink.h \
  
  audioplayer.h
  
  
  
  include(src/qtbrowserplugin.pri)
  
  
  
  
  
  # Requied for some C99 defines
  
  DEFINES += __STDC_CONSTANT_MACROS
  
  
  
  FFMPEG_ROOT = C:/dev/ffmpeg/ffmpeg-git-059707e-win32-dev
  
  FFMPEG_LIBRARY_PATH = $$FFMPEG_ROOT/lib
  
  FFMPEG_INCLUDE_PATH = $$FFMPEG_ROOT/include
  
  LIVE555_LIBRARY_PATH = C:/dev/live/
  
  
  
  LIBS += -L$$FFMPEG_LIBRARY_PATH \
  
  $$LIVE555_LIBRARY_PATH/BasicUsageEnvironment/libBasicUsageEnvironment.a \
  
  $$LIVE555_LIBRARY_PATH/groupsock/libgroupsock.a \
  
  $$LIVE555_LIBRARY_PATH/UsageEnvironment/libUsageEnvironment.a \
  
  $$LIVE555_LIBRARY_PATH/liveMedia/libliveMedia.a \
  
  C:/MinGW/lib/libws2_32.a \
  
  -lavutil \
  
  -lavcodec \
  
  -lavformat \
  
  -lswscale
  
  
  
  INCLUDEPATH += $$FFMPEG_INCLUDE_PATH \
  
  $$LIVE555_LIBRARY_PATH/liveMedia/include \
  
  $$LIVE555_LIBRARY_PATH/BasicUsageEnvironment/include \
  
  $$LIVE555_LIBRARY_PATH/groupsock/include \
  
  $$LIVE555_LIBRARY_PATH/UsageEnvironment/include

  Thank you
   Antonio

• Convert m3u8 (HLS) to mpd (MPEG-DASH)

  24 mai, par Almog

  I have Live stream of HLS [https://82-80-192-30.vidnt.com/ipbc_IPBCchannel11LVMRepeat/definst/IPBCchannel11LVM_3.stream/playlist.m3u8] and I want to convert it to MPEG-DASH.

  



  What is the best practice ?

  



  The stream is already h264 aac therefore I understand I do not need to reencode and I just need to transmux.

  



  What should I use ?
ffmpeg ? mp4box ?

  



  Notes :

  



  


  1. I used nginx-rtmp-module (https://github.com/ut0mt8/nginx-rtmp-module/) in order to create DASH from RTMP stream according to this tutorial : https://isrv.pw/html5-live-streaming-with-mpeg-dash
But nginx-rtmp-module can get as input just rtmp streams and it did not work for me with HLS stream.

  


  2. I used ffmpeg in order to create dash from m3u8 as following :

     



     ffmpeg -i https://82-80-192-30.vidnt.com/ipbc_IPBCchannel11LVMRepeat/_definst_/IPBCchannel11LVM_3.stream/playlist.m3u8 -strict -2 -min_seg_duration 2000 -window_size 5 -extra_window_size 5 -use_template 1 -use_timeline 1 -f dash out.mpd

  


  



  But this is very limited. I can't control the segment duration.
The min_seg_duration parameter of ffmpeg does not work very well for me, and also it can set the minimum duration while I want to limit the maximum duration of each segment (the segment comes out with 10 seconds, while I need it to be 2-4 seconds as I'm playing live).