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 : The
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.
>
> Signe
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
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 ide
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 100644
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 100644
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 cu
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
---
19 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 +++
1 file change
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 a/libavformat/rts
20 matches
Mail list logo
