We have been initially working with the 2110 decode example on the github site (https://github.com/cbcrc/FFmpeg) and have been successfully streaming media with it. We have evolved our design and would like to operate with multiple media streams. We have a configuration where we are using gstreamer to stream two media files, and we are trying to connect to the audio streams in two different instances of ffmpeg. However we are noticing unexpected behavior. I was hoping someone could comment on this behavior, and if it is expected, or if you have any insight/suggestions as to what might be incorrect in my configuration or how I could identify/correct the issue. We have configured the ffmpeg instances to use the bshowvolume filter, so that ffplay can display an audio gauge for each output. A flow diagram of our experiment is shown below. (filenames in paranthesis)
(gst_AUD1)stream 1 --> ffmpeg_instance1 --> ffplay_instance1 (test1.sdp) (gst_AUD2)stream 2 --> ffmpeg_instance2 --→ffplay_instance2 (test2.sdp) A script is used to start ffplay/ffmpeg instances (ff_scrpt). The gstreamer instances are started one at a time afterward. The results are different based on stream order started. One ffmpeg (via its sdp file) is configured to connect to the higher IP addressed stream. The other ffmpeg is configured to connect to the lower IP addressed stream. I am trying to stream the audio media only, and connect & process the audio only (via the sdp file audio-only media specifications). The behavior we are seeing is the following: If the gstreamer with the higher IP address is started first, both ffmpeg instances connect with it. Once the gstreamer with the lower IP address is started, both ffmpeg instances switch over to it & play to its completion. (the ffmpeg-20211201-213419.log file)./ If the gstreamer with the lower IP address is started first, both ffmpeg instances connect with it. Once the gstreamer with the higher IP address is started, both ffmpeg instances switch over to it, but the ffplay display locks up when the first gstreamer stream stops (if it runs shorter than the second gstreamer stream). (ffmpeg-20211201-214224.log file) I was expecting the ffmpeg instances to connect to the multicast address that their respective sdp files specified, but it doesn't seem to be working that way. I have attached the log files for the two runs, the ffmpeg script, and the gstreamer scripts, and the sdp files. I can send the media files if desired but they are large. I am running in a Ubuntu 20.04.3 LTS environment. We have additionally tested with later versions of ffmpeg (downloaded from the ffmpeg site, not the ST2110 version) and have noted the same behavior. We additionally added a filter to the sdp file (added a=source-filter:incl IN IP4 239.0.0.0 192.168.68.112 after the “c=IN…” line to help with ffmpeg stream selection, and o=- 0 0 IN IP4 192.168.68.112 in the session area) and this provided no changes in behavior. (originally, the sdp files did not have this “a=…” line in them; and 192.168.68.112 is the IP address of the local PC doing the testing). Testing is being performed on 1 PC. Both streams have been verified to be present on the test system. The logs are on a google drive that is shared to everyone using this link: https://drive.google.com/drive/folders/1xv0bwAxDBWSrA-mJRRov0Oj4njh6ZQNw?usp=sharing Please let me know if you are able to provide any insight/assistance. Thank you, Robert Wood 407-457-9939 Robert E Wood Engineering [cid:c5403db5-c876-4c24-ae84-06db04a68c43]
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
