rtp

What would cause a ConnectionReset on an UDP socket?

由 两盒软妹~` 提交于 2021-02-08 03:34:10
问题 I'm trying to work with the Managed Media Aggregation C# library (http://net7mma.codeplex.com) to handle a RTSP/RTP stream from a Freebox Set top box. Although the lib works fine with the sample RTSP feed, when working with the feed from my set top box, the RTP listener socket (a simple UDP socket listening every income on a specific port) throws a SocketException : ConnectionReset, and of course no data shows while Receiving (The data shows in Wireshark). Suppressing E_CONNRESET via the

ffmpeg decoding slow calling without avformat_find_stream_info

由 江枫思渺然 提交于 2021-02-08 00:24:05
问题 I am decoding h264 rtp stream with ffmpeg on android. I found a strange problem: if I don't call avformat_find_stream_info ,decoding P frame takes tens of micro seconds, by contrast, calling avformat_find_stream_info before decoding will reduce P frame decoding time to less than 1 ms on average. However, avformat_find_stream_info itself is time consuming on network streams. Are there anything I can do to make decoding fast without calling avformat_find_stream_info ? 回答1: When avformat_find

ffmpeg decoding slow calling without avformat_find_stream_info

由 China☆狼群 提交于 2021-02-08 00:22:27
问题 I am decoding h264 rtp stream with ffmpeg on android. I found a strange problem: if I don't call avformat_find_stream_info ,decoding P frame takes tens of micro seconds, by contrast, calling avformat_find_stream_info before decoding will reduce P frame decoding time to less than 1 ms on average. However, avformat_find_stream_info itself is time consuming on network streams. Are there anything I can do to make decoding fast without calling avformat_find_stream_info ? 回答1: When avformat_find

ffmpeg decoding slow calling without avformat_find_stream_info

由 拥有回忆 提交于 2021-02-08 00:20:27
问题 I am decoding h264 rtp stream with ffmpeg on android. I found a strange problem: if I don't call avformat_find_stream_info ,decoding P frame takes tens of micro seconds, by contrast, calling avformat_find_stream_info before decoding will reduce P frame decoding time to less than 1 ms on average. However, avformat_find_stream_info itself is time consuming on network streams. Are there anything I can do to make decoding fast without calling avformat_find_stream_info ? 回答1: When avformat_find

ffmpeg decoding slow calling without avformat_find_stream_info

由 蹲街弑〆低调 提交于 2021-02-08 00:19:43
问题 I am decoding h264 rtp stream with ffmpeg on android. I found a strange problem: if I don't call avformat_find_stream_info ,decoding P frame takes tens of micro seconds, by contrast, calling avformat_find_stream_info before decoding will reduce P frame decoding time to less than 1 ms on average. However, avformat_find_stream_info itself is time consuming on network streams. Are there anything I can do to make decoding fast without calling avformat_find_stream_info ? 回答1: When avformat_find

Write image frames into gstreamer rtp pipeline

由 生来就可爱ヽ(ⅴ＜●) 提交于 2021-01-29 17:38:24
问题 I am trying to use the gstreamer pipeline to view an rtp stream in vlc on my computer. I mostly looked into this thread. My end result is something like this #!/usr/bin/env python import gi import numpy as np gi.require_version('Gst', '1.0') from gi.repository import Gst, GObject import time class RtpPipeline(object): def __init__(self): self.number_frames = 0 self.fps = 30 self.duration = 1 / self.fps * Gst.SECOND # duration of a frame in nanoseconds self.launch_string = 'appsrc name=source

What is the max rtsp(over tcp) packet size?

由 只谈情不闲聊 提交于 2021-01-29 05:53:00
问题 I didn't see about it anything in Real Time Streaming Protocol (RTSP) , but when I sniffing , I saw the max rtsp packet size is 1440. And like you can see here RTSP - RTP over TCP RTP Data After the setup, RTP data will be sent through the TCP socket that is used for RTSP commands. The RTP data will be encapsulate in the following format | magic number | channel number | embedded data length | data | magic number - 1 byte value of hex 0x24 channel number - 1 byte value to denote the channel

基于live555的rtsp播放器之二十：完结

由 依然范特西╮ 提交于 2021-01-26 08:14:18
这是我工作之余完成的第一个软件，全凭爱好坚持下来，花了不少时间，也收获很多。 博客中很多内容都是亲身实践所得，有些内容甚至可以说是“全网首发 ”，比如网上多是ffmpeg拉流后ffmpeg录制，没搜到live555拉流ffmpeg录制的相关实现。 开发过程中，参考了许多开源项目，比如VLC中关于live555拉流部分；同时获得了公司流媒体大佬的大力支持，这里一并感谢！ 专栏中并未提到UDP丢包问题，实测用海康摄像头wifi链接家里100M宽带，客户端使用RTP over UDP模式拉流时，会出现丢包。客户端使用VLC时也会丢包，出现马赛克现象，说明live555源码中并未对丢包做过多的预防处理。但是把丢包问题留给上层处理是非常不合适的，因为上层不好判断哪一包丢了。比较靠谱的方法是深入live555源码，根据RTP包序号来判断丢包。 不过话说回来，UDP是不可靠传输协议，媒体包在因特网上传输时必然会面临着丢包。使用UDP的目的就是实时性好，如果加上丢包处理，势必会影响实时性。 UDP丢包处理的目的是用画面卡顿的代价来取代马赛克，然而RTP over TCP模式在相同的网络中就是卡顿无马赛克，那为何不直接用这种模式呢。 因此，个人觉得无特殊要求的话，这里没必要处理UDP丢包。 关于RTP over UDP和RTP over TCP的比较可以参考： http://thompsonng

appemit支持chrome等浏览器使用VLC 播放rtsp rtmp

由 不问归期 提交于 2021-01-24 23:32:15
appemit支持chrome等浏览器使用VLC 播放rtsp rtmp HTML5 的可以支持RTMP 但是无法播放RTSP，flash也止步于RTMP，最后同事推荐了个开源的好东东 VLC ，请教谷歌大神之后，这货果然可以用来让各浏览器（IE activex方式，谷歌、FF）实现播放RTSP视频流，那真是极好的~~ 废话不多说了附上参考文档和案例，大家自己看吧。 视频是用的海康网络摄像头（支持RTSP，标准H.264 RTP封装的设备），可以通过 rtsp://admin:12345@192.0.0.64:81/h264/ch1/main/av_stream 对摄像头进行读取RSTP流。在谷歌浏览器下实现web显示实时监控画面步骤： 1. 下载vlc - http://www.videolan.org/vlc/ 开源的好东西，并安装（本人 测试 系统为WIN8.1 64bit 下载32bit的就可以，XP也没问题）； 2. 安装，并勾选Mozila支持； 3. 实时播放代码如下 <object type='application/x-vlc-plugin' pluginspage="http://www.videolan.org/" id='vlc' events='false' width="720" height="410"> <param name='mrl' value

RTP

由 情到浓时终转凉″ 提交于 2021-01-24 15:07:37
实时传输协议（RTP）是一个Internet协议标准，它描述了程序管理多媒体数据实时传输的方式。最初在Internet工程任务组（IETF）的请求注解（RFC）1869中对RTP协议进行了描述，RTP由IETF的音视频传输工作组设计，它支持多个地域上分布的参与者的视频会议。RTP普遍应用于Internet的电话应用中。RTP本身并不保证多媒体数据的实时传输（因为这取决于网络特性），但是，当数据尽最大努力到达后它将提供必要的方法来管理这些数据。 　　RTP与控制协议（RTCP）配合工作，RTCP使得大的组播网络能够监视数据传输。监视能使接收器侦测到任何的包丢失，还可以补偿任何的延迟抖动。两个协议都独立于下面的传输层和网络层协议。RTP头中的信息将告诉接收器如何重建数据，并描述了比特流失如何打包的。通常，RTP工作于用户数据报协议（UDP）之上，但它也能使用其他的传输协议。会话发起协议（SIP）和H.232都使用RTP。 来源： oschina 链接： https://my.oschina.net/u/252980/blog/205037
订阅 rtp