Recherche avancée

Sur d’autres sites (6607)

• H.264 - Green frames when streaming over TCP using FFmpeg

  29 août 2017, par Naseeb Panghal

  I am using FC23 machine and FFMPEG version is 2.8.10

  Using below command, I can stream flv over tcp successfully and able to receive it successfully at receiver side as well. I play it using vlc player. Both audio and video are played well.

  ./ffmpeg -f x11grab -s 1920x1080 -framerate 15 -i :0.0 -f alsa -ac 2 -i hw:1 -vcodec libx264 -r 30 -pix_fmt yuv420p -tune zerolatency -preset ultrafast -acodec aac -strict -2 -ar 48000 -ab 96k -f flv -metadata streamName=naseeb.sdp tcp ://127.0.0.1:6666

  But in actually i need to do this using an application. So i wrote an application in ’C’ language.
  I have done following things in the application.

   1. Open `AVOutputFormat` using below API
  
      fmt = av_guess_format("flv", NULL , NULL);
  
   2. Get `AVFormatContext` using below API
  
      avformat_alloc_output_context2(&oc, fmt, NULL, NULL);
  
   3. Then added streams(audio and video) using required APIs
  
   4. Then open codecs using required APIs
  
   5. Then set the output using below API
  
      ret = avio_open(&oc->pb, filename, AVIO_FLAG_WRITE);

  (A) If I need to write flv into a file on system then I provide filename in step 5 as muxer.flv.
  

  • result : When I play muxer.flv using VLC player both video and audio are played well
    

  (B) If I need to stream flv over tcp then I provide filename as tcp://127.0.0.1:6666.
  

  • result : When it is streamed over network then Green frames are shown for video (yet audio works very well). Is there an extra setting required when I need to stream it over network ?

  I have no doubt on Receiver side as it works very well with FFmpeg utility (command mentioned above).
  Currently I have downloaded ffmpeg 2.8.10 source code and looking into ffmpeg.c file for some extra setting. Till now I have not found anything helpful.

  Please suggest something why Green frames shown when flv is sent on network where it works well when dump on system hard disk.

• lower latency LAN video streaming to Android ? [closed]

  8 janvier 2020, par LargeMoneyBanks

  I am trying to stream desktop video from windows to an Android device on the same network, but seeing huge latency even streaming windows to windows.

  Technically streaming to a unity game using this asset that doesnt support udp but DOES support HTTPS,HTTP,HLS,RTSP,RTMP. https://assetstore.unity.com/packages/tools/video/ump-android-ios-56044

  With some help from a friend I am using ffmpeg for capture, encoding, and streaming with this command :

  .\ffmpeg -threads 8 -f gdigrab -framerate 60 -i desktop -c:v libx264 -refs 3 -g 60 -loglevel debug -pix_fmt yuv420p -slices 8 -an -preset ultrafast -tune zerolatency -f mpegts -listen 1 tcp://0.0.0.0:1234

  Latency is still around 4 seconds even playing the stream on the same PC as hosting, and fiddling with the network cache. Lowering resolution, fps etc doesn’t change latency. This is my first endeavor into optimizing any kind of streaming so I am a little lost. Anyone know what I might be doing wrong or how I can get to at least under 1 second ?

  Thank you !

• FFMPEG G711ulaw Rhythmic Distortion [closed]

  8 juillet 2024, par nsd123

  I am using ffmpeg take audio in from my microphone, rtp stream it to a multicast address as g711ulaw audio, and then play that audio through various devices.

  


  In my network I have other workstations, as well as a digital telephone type device.
My workstations are using Windows.

  


  I am taking the microphone input with this ffmpeg command :
ffmpeg -f dshow -i audio="" -pcm_mulaw -ab 64k -ac 1 -ar 8000 -f rtp rtp :// : ?localaddr=

  


  This command transmits the microphone data successfully to other workstations on the network, where I can use ffplay or other means to listen to the rtp stream and hear clear audio.

  


  On the telephone device, when it gets converted to analog to play, it's picking up this strange, rhythmic burp/clicking/noise, like every time its getting information, its interpreting the header as voice data or something.

  


  The output of the ffmpeg command says the pcm_s16le codec is the native one, and seems to convert it just fine.

  


  Is there any kind of option I should be using in my ffmpeg command that sounds like it could resolve this issue ? Or does this kind of interference typically occur for a specific reason ?

  


  Its not the hardware, I've tested that (other audio able to play clearly).
I've tried a few other codecs to no success.
I've tried a few ffmpeg options, but there are so many options, they've just been successful stabs in the dark