Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
On 1/12/19 09:05, Andreas Rheinhardt wrote:
ggarr...@gmail.com:
From: Gonzalo Garramuño
Moved the check inside and at the end of the if (pktl) as per Michael
Niedermayer's suggestion.
This patch is based on one from Blake Senftner ( bsenftner at earthlink.net ).
The hanging in av_read_frame can be reproduced with an rtmp stream that is
aborted midway and ffplay (for example) playing that stream.
---
libavformat/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442dd1..653918d5a5 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1836,6 +1836,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
>internal->packet_buffer_end, pkt);
goto return_packet;
}
+
+if (ff_check_interrupt(>interrupt_callback)) {
+av_log(s, AV_LOG_DEBUG, "interrupted\n");
+return AVERROR_EXIT;
+}
}
ret = read_frame_internal(s, pkt);
This patch makes it possible for pkt to be still uninitialised after
the call to av_read_frame() if I am not mistaken (namely if the packet
list was initially not empty and the interrupt was triggered before
read_frame_internal() has been called). If so, this clashes with a
recently proposed patch by me
(https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/253662.html).
One could either allow av_read_frame() to return unclean packets on
error or you would have to add the necessary initializations in your
code (or you would have to make sure that your code is not triggered
before the first call to read_frame_internal()).
- Andreas
I am afraid I do not know enough of the ffmpeg internals to make the
initialization changes you propose.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
On Sun, Dec 01, 2019 at 12:05:00PM +, Andreas Rheinhardt wrote:
> ggarr...@gmail.com:
> > From: Gonzalo Garramuño
> >
> > Moved the check inside and at the end of the if (pktl) as per Michael
> > Niedermayer's suggestion.
> > This patch is based on one from Blake Senftner ( bsenftner at earthlink.net
> > ).
> >
> > The hanging in av_read_frame can be reproduced with an rtmp stream that is
> > aborted midway and ffplay (for example) playing that stream.
> > ---
> > libavformat/utils.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 8196442dd1..653918d5a5 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -1836,6 +1836,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
> >
> > >internal->packet_buffer_end, pkt);
> > goto return_packet;
> > }
> > +
> > +if (ff_check_interrupt(>interrupt_callback)) {
> > +av_log(s, AV_LOG_DEBUG, "interrupted\n");
> > +return AVERROR_EXIT;
> > +}
> > }
> >
> > ret = read_frame_internal(s, pkt);
> >This patch makes it possible for pkt to be still uninitialised after
> the call to av_read_frame() if I am not mistaken (namely if the packet
> list was initially not empty and the interrupt was triggered before
> read_frame_internal() has been called). If so, this clashes with a
> recently proposed patch by me
> (https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/253662.html).
> One could either allow av_read_frame() to return unclean packets on
> error or you would have to add the necessary initializations in your
> code (or you would have to make sure that your code is not triggered
> before the first call to read_frame_internal()).
One could theoretically argue that it would make sense to only call the
check after the first read_frame_internal and only before each
read_frame_internal. Sadly thats not as simple to achieve as moving
the code around, so i didnt suggest it previously
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
ggarr...@gmail.com:
> From: Gonzalo Garramuño
>
> Moved the check inside and at the end of the if (pktl) as per Michael
> Niedermayer's suggestion.
> This patch is based on one from Blake Senftner ( bsenftner at earthlink.net ).
>
> The hanging in av_read_frame can be reproduced with an rtmp stream that is
> aborted midway and ffplay (for example) playing that stream.
> ---
> libavformat/utils.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 8196442dd1..653918d5a5 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1836,6 +1836,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
>
> >internal->packet_buffer_end, pkt);
> goto return_packet;
> }
> +
> +if (ff_check_interrupt(>interrupt_callback)) {
> +av_log(s, AV_LOG_DEBUG, "interrupted\n");
> +return AVERROR_EXIT;
> +}
> }
>
> ret = read_frame_internal(s, pkt);
>This patch makes it possible for pkt to be still uninitialised after
the call to av_read_frame() if I am not mistaken (namely if the packet
list was initially not empty and the interrupt was triggered before
read_frame_internal() has been called). If so, this clashes with a
recently proposed patch by me
(https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/253662.html).
One could either allow av_read_frame() to return unclean packets on
error or you would have to add the necessary initializations in your
code (or you would have to make sure that your code is not triggered
before the first call to read_frame_internal()).
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
From: Gonzalo Garramuño
Moved the check inside and at the end of the if (pktl) as per Michael
Niedermayer's suggestion.
This patch is based on one from Blake Senftner ( bsenftner at earthlink.net ).
The hanging in av_read_frame can be reproduced with an rtmp stream that is
aborted midway and ffplay (for example) playing that stream.
---
libavformat/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442dd1..653918d5a5 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1836,6 +1836,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
>internal->packet_buffer_end, pkt);
goto return_packet;
}
+
+if (ff_check_interrupt(>interrupt_callback)) {
+av_log(s, AV_LOG_DEBUG, "interrupted\n");
+return AVERROR_EXIT;
+}
}
ret = read_frame_internal(s, pkt);
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
On 29/11/19 15:35, Michael Niedermayer wrote: also, do we have a testcase where this loop hangs ? if not please provide a testcase I don't have an easy testcase, but it can be seen with any rtmp stream. A full test case can be reproduced like this: Compile and create a nginx server like it is specified here: https://github.com/arut/nginx-rtmp-module/wiki/Getting-started-with-nginx-rtmp Start the nginx server: /usr/local/nginx/sbin/nginx Start ffmpeg streaming: ffmpeg -re -i long.mov -c copy -f flv rtmp://localhost/myapp/mystream In another window, play the stream: ffplay rtmp://localhost/myapp/mystream Now, abort the ffmpeg process by CTRL-C. ffplay will eventually hang and not allow it to close it when clicking on the close window button. With the patch, ffplay will eventually become responsive once again after the timeout period. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
Am Sa., 30. Nov. 2019 um 00:52 Uhr schrieb : > > From: Gonzalo Garramuño > > Moved the check inside and at the end of the if (pktl) as per Michael > Niedermayer's suggestion. > This patch is based on one from bsenftner at earthlink.net. Please mention his name as suggested. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
From: Gonzalo Garramuño
Moved the check inside and at the end of the if (pktl) as per Michael
Niedermayer's suggestion.
This patch is based on one from bsenftner at earthlink.net.
The hanging in av_read_frame can be reproduced with an rtmp stream that is
aborted midway and ffplay (for example) playing that stream.
---
libavformat/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442dd1..653918d5a5 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1836,6 +1836,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
>internal->packet_buffer_end, pkt);
goto return_packet;
}
+
+if (ff_check_interrupt(>interrupt_callback)) {
+av_log(s, AV_LOG_DEBUG, "interrupted\n");
+return AVERROR_EXIT;
+}
}
ret = read_frame_internal(s, pkt);
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
On Thu, Nov 28, 2019 at 08:58:54PM -0300, ggarr...@gmail.com wrote:
> From: Gonzalo Garramuño
>
> Moved the check inside if (pktl) as per Michael Niedermayer's suggestion.
> This patch is based on one from bsenftner at earthlink.net.
> ---
> libavformat/utils.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 8196442dd1..1f5754d7d3 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1795,6 +1795,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
> AVPacketList *pktl = s->internal->packet_buffer;
>
> if (pktl) {
> +if (ff_check_interrupt(>interrupt_callback)) {
> +av_log(s, AV_LOG_DEBUG, "interrupted\n");
> +return AVERROR_EXIT;
> +}
> +
> AVPacket *next_pkt = >pkt;
>
> if (next_pkt->dts != AV_NOPTS_VALUE) {
I would put it at the end of the "if (pktl) {" body
because if a packet gets processed and returned no interrupt check is needed
also, do we have a testcase where this loop hangs ?
if not please provide a testcase
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
From: Gonzalo Garramuño
Moved the check inside if (pktl) as per Michael Niedermayer's suggestion.
This patch is based on one from bsenftner at earthlink.net.
---
libavformat/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442dd1..1f5754d7d3 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1795,6 +1795,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
AVPacketList *pktl = s->internal->packet_buffer;
if (pktl) {
+if (ff_check_interrupt(>interrupt_callback)) {
+av_log(s, AV_LOG_DEBUG, "interrupted\n");
+return AVERROR_EXIT;
+}
+
AVPacket *next_pkt = >pkt;
if (next_pkt->dts != AV_NOPTS_VALUE) {
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
On Tue, Nov 26, 2019 at 02:45:05PM -0300, gga wrote:
>
>
> On 26/11/19 14:31, Michael Niedermayer wrote:
> >On Thu, Nov 21, 2019 at 06:27:10PM -0300, ggarr...@gmail.com wrote:
> >>From: Gonzalo Garramuño
> >>
> >>This patch is based on a patch by bsenftner at earthlink.net.
> >>---
> >> libavformat/utils.c | 5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >>diff --git a/libavformat/utils.c b/libavformat/utils.c
> >>index 8196442dd1..c3c2c77c0c 100644
> >>--- a/libavformat/utils.c
> >>+++ b/libavformat/utils.c
> >>@@ -1838,6 +1838,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
> >> }
> >> }
> >>+if (ff_check_interrupt(>interrupt_callback)) {
> >>+av_log(s, AV_LOG_DEBUG, "interrupted\n");
> >>+return AVERROR_EXIT;
> >>+}
> >>+
> >I think this can be moved into the if() above, which might
> >reduce the number of calls.
> >
> >thx
> >[...]
> >
> It would probably reduce only one call, as pktl (the if above) is a list
> that will get filled probably as soon as there is a packet. Or maybe I am
> reading the code wrong? Also, if it does not get filled, we probably want
> to exit anyway, too.
we want to call ff_check_interrupt() between time consuming operations
but calling it before everything seems a bit odd to me.
Why did one call av_read_frame() if one wants to interrupt before doing
anything
Now if the list is empty the loop has just been entered so why would we
interrupt here ?
maybe iam missing something but this doesnt seem to be usefull
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The day soldiers stop bringing you their problems is the day you have stopped
leading them. They have either lost confidence that you can help or concluded
you do not care. Either case is a failure of leadership. - Colin Powell
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
On 26/11/19 14:31, Michael Niedermayer wrote:
On Thu, Nov 21, 2019 at 06:27:10PM -0300, ggarr...@gmail.com wrote:
From: Gonzalo Garramuño
This patch is based on a patch by bsenftner at earthlink.net.
---
libavformat/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442dd1..c3c2c77c0c 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1838,6 +1838,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
}
}
+if (ff_check_interrupt(>interrupt_callback)) {
+av_log(s, AV_LOG_DEBUG, "interrupted\n");
+return AVERROR_EXIT;
+}
+
I think this can be moved into the if() above, which might
reduce the number of calls.
thx
[...]
It would probably reduce only one call, as pktl (the if above) is a list
that will get filled probably as soon as there is a packet. Or maybe I
am reading the code wrong? Also, if it does not get filled, we probably
want to exit anyway, too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
On Thu, Nov 21, 2019 at 06:27:10PM -0300, ggarr...@gmail.com wrote:
> From: Gonzalo Garramuño
>
> This patch is based on a patch by bsenftner at earthlink.net.
> ---
> libavformat/utils.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 8196442dd1..c3c2c77c0c 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1838,6 +1838,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
> }
> }
>
> +if (ff_check_interrupt(>interrupt_callback)) {
> +av_log(s, AV_LOG_DEBUG, "interrupted\n");
> +return AVERROR_EXIT;
> +}
> +
I think this can be moved into the if() above, which might
reduce the number of calls.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
Friendly ping. Does the patch need anything else for approval?
On 21/11/19 18:27, ggarr...@gmail.com wrote:
From: Gonzalo Garramuño
This patch is based on a patch by bsenftner at earthlink.net.
---
libavformat/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442dd1..c3c2c77c0c 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1838,6 +1838,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
}
}
+if (ff_check_interrupt(>interrupt_callback)) {
+av_log(s, AV_LOG_DEBUG, "interrupted\n");
+return AVERROR_EXIT;
+}
+
ret = read_frame_internal(s, pkt);
if (ret < 0) {
if (pktl && ret != AVERROR(EAGAIN)) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.
From: Gonzalo Garramuño
This patch is based on a patch by bsenftner at earthlink.net.
---
libavformat/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442dd1..c3c2c77c0c 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1838,6 +1838,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
}
}
+if (ff_check_interrupt(>interrupt_callback)) {
+av_log(s, AV_LOG_DEBUG, "interrupted\n");
+return AVERROR_EXIT;
+}
+
ret = read_frame_internal(s, pkt);
if (ret < 0) {
if (pktl && ret != AVERROR(EAGAIN)) {
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
