Retrieving an mpegts stream with only stuffed PAT,
results in endless reading.
This change adds a new timeout that specifies a
timespan in AV_TIME_BASE units until when a full
packet must be read successfully.
Signed-off-by: Wolfgang Haupt
---
libavformat/mpegts.c | 16
1 file
This fixes mpegts infinitely parsing streams that contain
only stuffed PATs, which apparently happens on some dead
livetv sources.
Wolfgang Haupt (1):
Add "no packet" timeout option for mpegts
libavformat/mpegts.c | 18 ++
1 file changed, 18 insertions(+)
This fixes mpegts infinitely parsing streams that contain
only stuffed PATs, which apparently happens on some dead
livetv sources.
Wolfgang Haupt (1):
Add "no packet" timeout option for mpegts
libavformat/mpegts.c | 18 ++
1 file changed, 18 insertions(+)
Retrieving an mpegts stream with only stuffed PAT,
results in endless reading.
This change adds a new timeout that specifies a
timespan in AV_TIME_BASE units until when a full
packet must be read successfully.
Signed-off-by: Wolfgang Haupt
---
libavformat/mpegts.c | 18 ++
1
This fixes mpegts infinitely parsing streams that contain
only stuffed PATs, which apparently happens on some dead
livetv sources.
Wolfgang Haupt (1):
Add "no packet" timeout option for mpegts
libavformat/mpegts.c | 18 ++
1 file changed, 18 insertions(+)
Hi,
Thanks for the reply. I checked the memory usage while building ffmpeg with
64 threads. The machine I tested has 128 GB ram. While I tested it I found
that maximum memory utilized by the build of ffmpeg was 17GB. Still the
build throws up error semaphore or child process wait (Error 87 :
On 17.05.21 03:50, Fei Wang wrote:
> Set all tiles size to create slice data buffer, hardware will use
> slice_data_offset/slice_data_size in slice parameter buffer to get
> each tile's data.
>
> This change will let it success to decode clip which has multi
> tiles data inside one OBU.
>
>
On 20.04.20 10:52, Wolfgang Haupt wrote:
On 20.04.20 10:08, Marton Balint wrote:
On Mon, 20 Apr 2020, Wolfgang Haupt wrote:
On 19.04.20 23:43, Marton Balint wrote:
On Sun, 19 Apr 2020, Wolfgang Haupt wrote:
On 19.04.20 14:53, Marton Balint wrote:
On Sun, 19 Apr 2020, Wolfgang Haupt
On 20.04.20 10:08, Marton Balint wrote:
On Mon, 20 Apr 2020, Wolfgang Haupt wrote:
On 19.04.20 23:43, Marton Balint wrote:
On Sun, 19 Apr 2020, Wolfgang Haupt wrote:
On 19.04.20 14:53, Marton Balint wrote:
On Sun, 19 Apr 2020, Wolfgang Haupt wrote:
ping
On 03.04.20 08:42, Wolfgang
On 19.04.20 23:43, Marton Balint wrote:
On Sun, 19 Apr 2020, Wolfgang Haupt wrote:
On 19.04.20 14:53, Marton Balint wrote:
On Sun, 19 Apr 2020, Wolfgang Haupt wrote:
ping
On 03.04.20 08:42, Wolfgang Haupt wrote:
Hey,
is someone up to review this patch?
It's an attempt to fix rtsp
On 19.04.20 14:53, Marton Balint wrote:
On Sun, 19 Apr 2020, Wolfgang Haupt wrote:
ping
On 03.04.20 08:42, Wolfgang Haupt wrote:
Hey,
is someone up to review this patch?
It's an attempt to fix rtsp streams that use udp multicasts as the
underlying
transmission protocol.
The idea
On 19.04.20 14:44, Marton Balint wrote:
On Sun, 19 Apr 2020, Wolfgang Haupt wrote:
ping
On 03.04.20 08:53, Wolfgang Haupt wrote:
Protocol options like buffer_size need to be passed to the
underlying transport implementation for udp multicasts as well.
---
libavformat/rtsp.c | 5 -
1
Protocol options like buffer_size need to be passed to the
underlying transport implementation for udp multicasts as well.
---
libavformat/rtsp.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 07ac371903..b56bebfde6
Protocol options like buffer_size need to be passed to the
underlying transport implementation for udp multicasts as well.
---
libavformat/rtsp.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 07ac371903..b56bebfde6
ping
On 03.04.20 08:53, Wolfgang Haupt wrote:
Protocol options like buffer_size need to be passed to the
underlying transport implementation for udp multicasts as well.
---
libavformat/rtsp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b
ping
On 03.04.20 08:42, Wolfgang Haupt wrote:
Hey,
is someone up to review this patch?
It's an attempt to fix rtsp streams that use udp multicasts as the
underlying
transmission protocol.
The idea was taken from live555 as the said stream worked in VLC.
It still applies cleanly on current
Protocol options like buffer_size need to be passed to the
underlying transport implementation for udp multicasts as well.
---
libavformat/rtsp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index a69484d78b..dbf626eb13 100644
---
:59, Wolfgang Haupt wrote:
If an rtsp server offers a udp multicast
address as response of a DESCRIBE command
the rtsp client is expected to issue
SETUP with "Transport: RTP/AVP/UDP;multicast".
Some rtsp servers bail out otherwise.
---
libavformat/rtsp.c | 3 +++
1 file changed, 3
On 2019-10-18 18:59, Wolfgang Haupt wrote:
If an rtsp server offers a udp multicast
address as response of a DESCRIBE command
the rtsp client is expected to issue
SETUP with "Transport: RTP/AVP/UDP;multicast".
Some rtsp servers bail out otherwise.
---
libavformat/rtsp.c | 3 ++
If an rtsp server offers a udp multicast
address as response of a DESCRIBE command
the rtsp client is expected to issue
SETUP with "Transport: RTP/AVP/UDP;multicast".
Some rtsp servers bail out otherwise.
---
libavformat/rtsp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
20 matches
Mail list logo
