Recherche avancée

Sur d’autres sites (6578)

• http live streaming based on a m3u file

  23 mars 2018, par 3agelx45

  I have an account on a platform of streaming (legal !). This platform provide me with a m3u file, the content looks like follow :

  #EXTM3U
  
  #EXTINF:-1 tvg-id="" tvg-name="|| something ||" tvg-logo="" group-title="",|| CAT1 ||
  
  http://someurl.domain:1234/video1.ts
  
  #EXTINF:-1 tvg-id="" tvg-name="video2" tvg-logo="" group-title="CAT1 part 1",VIDEO1
  
  http://someurl.domain:1234/video2.ts
  
  #EXTINF:-1 tvg-id="" tvg-name="video2" tvg-logo="" group-title="CAT1 part 1",VIDEO2
  
  .
  
  .
  
  .
  
  etc

  This file works fine using vlc from home. but when I travel I use Hotels hotspots and some do block the connection to someurl.domain:1234.

  is it possible to stream the m3u file using a light http server (stream the file from server side and reroute result to http). The idea is run a small iptv server from home on my raspberry which will allow me to bypass the "censorship" faced with some hotspots.

  Thanks !

• avformat/movenc : use correct iTunes copyright atom

  3 avril 2018, par Timo Teräs

  avformat/movenc : use correct iTunes copyright atom
  Support for writing copyright metadata was added in commit bed4fc54c9
  
  for 3GP, MOV and iTunes metadata. 3GP and MOV cases are formally
  
  specified. However, iTunes format does not have specification, and
  
  it seems to have been assumed that it would use the same atom as
  
  MOV (both being Apple formats).
  However, Apple uses 'cprt' atom for iTunes metadata (do note that
  
  the iTunes 'cprt' encoding is generic iTunes ItemList atom, not
  
  the 3GP 'cprt' encoding. These are also inside different parent
  
  atoms).
  Most references trying to document iTunes atoms mention only
  
  the 'cprt' tag. See :
  
   - http://atomicparsley.sourceforge.net/mpeg-4files.html
  
   - http://mutagen.readthedocs.io/en/latest/api/mp4.html
  Same applies to other software supporting this tag. Most of them
  
  encode and decode only the 'cprt' atom.
  ffmpeg mov demuxer supports both atoms in this context. There are
  
  few pieces of other software that support similarly both 'cprt' and
  
  the incorrect '\251cpy' atom in this context. I believe they do it in
  
  order to read the ffmpeg encoded incorrect copyright atom.
  In light of the above this changes the copyright atom to 'cprt' as
  
  it seems to be supported univerally and is the correct atom to use.
  Signed-off-by : Timo Teräs <timo.teras@iki.fi>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/movenc.c

• error : ‘avcodec_send_packet’ was not declared in this scope

  4 juillet 2018, par StarShine

  The following snippet of ffmpeg-based code is building and working on Windows VC2012, VC20155, VC2017.

  With gcc on Ubuntu LTS 16.04 this is giving me issues, more specifically it does not seem to recognize avcodec_send_packet, avcodec_receive_frame and struct AVCodecParameters, and possibly more functions and structures that I’m not currently using.

  error : ‘AVCodecParameters’ was not declared in this scope
  error : ‘avcodec_send_packet’ was not declared in this scope
  error : ‘avcodec_receive_frame ’ was not declared in this scope

  The code snippet is :

  // the includes are actually in a precompiled header, included in cmake
  
  extern "C" {
  
  
  
  #include <libavcodec></libavcodec>avcodec.h>
  
  #include <libavdevice></libavdevice>avdevice.h>
  
  #include <libavfilter></libavfilter>avfilter.h>
  
  #include <libpostproc></libpostproc>postprocess.h>
  
  #include <libswresample></libswresample>swresample.h>
  
  #include <libswscale></libswscale>swscale.h>
  
  #include <libavformat></libavformat>avformat.h>
  
  #include <libavutil></libavutil>avutil.h>   
  
  #include <libavutil></libavutil>avassert.h>
  
  #include <libavutil></libavutil>avstring.h>
  
  #include <libavutil></libavutil>bprint.h>
  
  #include <libavutil></libavutil>display.h>
  
  #include <libavutil></libavutil>mathematics.h>  
  
  #include <libavutil></libavutil>imgutils.h>
  
  //#include <libavutil></libavutil>libm.h>
  
  #include <libavutil></libavutil>parseutils.h>
  
  #include <libavutil></libavutil>pixdesc.h>
  
  #include <libavutil></libavutil>eval.h>
  
  #include <libavutil></libavutil>dict.h>
  
  #include <libavutil></libavutil>opt.h>
  
  #include <libavutil></libavutil>cpu.h>
  
  #include <libavutil></libavutil>ffversion.h>
  
  #include <libavutil></libavutil>version.h>
  
  
  
  }
  
  
  
  //
  
  ... 
  
  {
  
      if (av_read_frame(m_FormatContext, m_Packet) &lt; 0) {
  
          av_packet_unref(m_Packet);
  
          m_AllPacketsSent = true;
  
      } else {
  
          if (m_Packet->stream_index == m_StreamIndex) {                  
  
              avcodec_send_packet(m_CodecContext, m_Packet);
  
          }
  
      }
  
  }
  
  ...

  I read up on the ffmpeg history and learned that on Debian based systems at one point they followed the fork to libavutil when that came about, and then recently some of the platforms switched back to the ffmpeg branch due to the fact that ffmpeg was much more actively supported in terms of bugfixes, features and support. As a result, some of the interfaces were possibly broken.

  I’ve seen git fixes on a library called mediatombs who seem to have ecountered the same if not very similar issues with codecpar (which I initially also had and fixed the same way) :

  https://github.com/gerbera/gerbera/issues/52

  https://github.com/gerbera/gerbera/commit/32efd463f138557c54535225d84136df95bab3dd#diff-af3b638bc2a3e6c650974192a53c7291

  Here the commit seems to fix their specific issue by wrapping the codecpar field that is being renamed back to codec, which I also applied and works.

  I wonder if anyone knows which functions can be used for the errors given above, since in fact these functions are themselves replacing deprecated functionality according the ffmpeg avcodec.h header comments. (https://www.ffmpeg.org/doxygen/trunk/avcodec_8h_source.html). I hope this does not mean I would have to settle back into avcodec_encode_video2() type of functions ?

  Update :

  For reference, it seems it has also popped up here : https://github.com/Motion-Project/motion/issues/338. The issue seems to be resolved if you can rebuild your ffmpeg stack.

  Update :

  To resolve the version API mingle, I ended up wiping out any ffmpeg reference and rebuilding ffmpeg from sources. This seems to push things further along in the right direction ; I have my source compiling correctly but there is still something wrong with the way I’m linking things together.

  Also, I’m using CMake to set up my makefiles, and using find_package for some of the dependencies and handwritten find_path / find_library stuff for everything else. I’ve seen other people complain about the following linking issue, and a ton of case-specific replies but none of them really shed some light on what the actual problem is. My installed Ubuntu version of ALSA is 1.1.xx but still I get complaints about a 0.9 version I’m supposedly linking. Anyone knows what’s wrong with this ?

  Also, my libasound.so is symbol linked into libasound.so.2.0.0 if that clears anything up. (Hope that double slashed path at the end is correct also).

  /usr/bin/ld: /usr/lib/ffmpeg/libavdevice.a(alsa.o): undefined reference to symbol 'snd_pcm_hw_params_any@@ALSA_0.9' //usr/lib/x86_64-linux-gnu/libasound.so.2: