Re: [FFmpeg-devel] [PATCH v3 1/2] avformat/rtsp: fix infinite loop with udp transport
On Wed, 30. Sep 12:41, Martin Storsjö wrote:
> Hi,
>
> On Sun, 27 Sep 2020, Zhao Zhili wrote:
>
> > Fix #8840.
> >
> > Steps to reproduce:
> > 1. sender:
> > ./ffmpeg -i test.mp4 -c copy -f rtsp -rtsp_transport udp
> > rtsp://localhost:12345/live.sdp
> > 2. receiver:
> > ./ffmpeg_g -y -rtsp_flags listen -timeout 100 -i
> > rtsp://localhost:12345/live.sdp -c copy test.mp4
> > ---
> > v3: mention the ticket.
> >
> > libavformat/rtsp.c| 2 ++
> > libavformat/rtsp.h| 1 +
> > libavformat/rtspdec.c | 2 +-
> > 3 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> > index 5d8491b74b..597413803f 100644
> > --- a/libavformat/rtsp.c
> > +++ b/libavformat/rtsp.c
> > @@ -2051,6 +2051,8 @@ static int udp_read_packet(AVFormatContext *s,
> > RTSPStream **prtsp_st,
> > if ((ret = parse_rtsp_message(s)) < 0) {
> > return ret;
> > }
> > +if (rt->state == RTSP_STATE_TEARDOWN)
> > +return AVERROR_EOF;
> > }
> > #endif
> > } else if (n == 0 && ++timeout_cnt >= MAX_TIMEOUTS) {
> > diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
> > index 54a9a30c16..481cc0c3ce 100644
> > --- a/libavformat/rtsp.h
> > +++ b/libavformat/rtsp.h
> > @@ -198,6 +198,7 @@ enum RTSPClientState {
> > RTSP_STATE_STREAMING, /**< initialized and sending/receiving data */
> > RTSP_STATE_PAUSED, /**< initialized, but not receiving data */
> > RTSP_STATE_SEEKING, /**< initialized, requesting a seek */
> > +RTSP_STATE_TEARDOWN,/**< initialized, in teardown state */
> > };
> >
> > /**
> > diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
> > index dfa29913bf..ec786a469a 100644
> > --- a/libavformat/rtspdec.c
> > +++ b/libavformat/rtspdec.c
> > @@ -494,7 +494,7 @@ int ff_rtsp_parse_streaming_commands(AVFormatContext *s)
> > "Public: ANNOUNCE, PAUSE, SETUP, TEARDOWN, "
> > "RECORD\r\n", request.seq);
> > } else if (methodcode == TEARDOWN) {
> > -rt->state = RTSP_STATE_IDLE;
> > +rt->state = RTSP_STATE_TEARDOWN;
> > ret = rtsp_send_reply(s, RTSP_STATUS_OK, NULL , request.seq);
> > }
> > return ret;
> > --
> > 2.17.1
Martin, thanks for looking over the patch.
>
> I think this approach to fixing it, adding a new state, is a bit of
> overkill. This usecase actually used to work originally, but I bisected it
> and it broke in f6161fccf8c5720ceac1ed1df8ba60ff8fed69f5. So with that in
> mind, it's pretty straightforward to fix it by retaining the original
> behaviour from before that commit. I'll send an alternative patch that does
> that.
I made the suggestion to add TEARDOWN state because I thought it's safer than
relying on the idle state, and it made the code more readable.
Looking at your patch, I think it's a clean/elegant solution, and also looks
good to me.
--
Andriy
___
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 1/4] avcodec/cbs: add an AVClass to CodedBitstreamType for option handling
On 9/20/2020 2:24 PM, James Almer wrote: > So unit parsing may be configured with caller set options. > > Signed-off-by: James Almer > --- > libavcodec/cbs.c | 9 + > libavcodec/cbs_internal.h | 6 ++ > 2 files changed, 15 insertions(+) Ping for the set @Mark. Don't want to push this one without your opinion. ___ 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 1/2] avcodec/vc1_block: Fix integer overflow in ac value
On Wed, Sep 02, 2020 at 11:39:48PM +0200, Michael Niedermayer wrote: > Fixes: signed integer overflow: 25488 * 87381 cannot be represented in type > 'int' > Fixes: > 24765/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-5108259565076480 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/vc1_block.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin 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 2/2] avformat/dxa: Use av_rescale() for duration computation
On Wed, Sep 02, 2020 at 11:39:49PM +0200, Michael Niedermayer wrote: > Fixes: signed integer overflow: 822400 * 1629552639 cannot be represented > in type 'long' > Fixes: > 24908/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4658478506049536 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/dxa.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras 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 2/2] avformat/asfdec_f: Change order or operations slightly
On Sat, Sep 12, 2020 at 08:18:55PM +0200, Michael Niedermayer wrote: > Fixes: signed integer overflow: 20 * 5184056935931942919 cannot be > represented in type 'long' > Fixes: > 25466/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4798660247552000 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/asfdec_f.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier 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 2/2] swresample/audioconvert: Fix left shift of negative value
On Tue, Sep 29, 2020 at 05:52:44PM +0200, Andreas Rheinhardt wrote: > Fixes ticket #8219. > > Signed-off-by: Andreas Rheinhardt > --- > libswresample/audioconvert.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. 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] rtsp: Fix infinite loop in listen mode with UDP transport
On Wed, 30 Sep 2020, Zhao Zhili wrote: Hi Martin, On 9/30/20 5:41 PM, Martin Storsjö wrote: In listen mode with UDP transport, once the sender has sent the TEARDOWN and closed the connection, poll will indicate that one can read from the connection (indicating that the socket has reached EOF and should be closed by the receiver as well). In this case, parse_rtsp_message won't try to parse the command (because it's no longer in state STREAMING), but previously just returned zero. Prior to f6161fccf8c5720ceac1ed1df8ba60ff8fed69f5, this caused udp_read_packet to return zero, which is treated as EOF by read_packet. But after that commit, udp_read_packet would continue if parse_rtsp_message didn't return an explicit error code. To keep the original behaviour from before that commit, more explicitly return an error in parse_rtsp_message when in the wrong state. Fixes: #8840 --- libavformat/rtsp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c index 5d8491b74b..ad12f2ae98 100644 --- a/libavformat/rtsp.c +++ b/libavformat/rtsp.c @@ -1970,7 +1970,7 @@ static int parse_rtsp_message(AVFormatContext *s) av_log(s, AV_LOG_WARNING, "Unable to answer to TEARDOWN\n"); } else -return 0; +return AVERROR_EOF; Does the else part needs the same fix? Which else part do you refer to? The else above (with the warning)? Yes that bit looks a bit odd to me as well - your patch 2/2 looks like a good fix for that. I tried a similar approach in http://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/267437.html. I'm less keen on that approach. As the problem is with listen mode, I'd cautiously avoid changing code that is general to both modes. The intended behavior (e.g., return value) of parse_rtsp_message is not quite clear to me, could you help improve it, like adding some documentation? Well I'm not sure how much there is to document. It's a static function that is called from one single place in the code, so the documentation of it is the code surrounding the single call to it. Ideally it'd follow common conventions like returning a negative value on error and zero/positive on success that one should continue from. // Martin ___ 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 2/9] avformat/aviobuf: check if requested seekback buffer is already read
On Tue, Sep 29, 2020 at 11:10:14PM +0200, Marton Balint wrote: > Existing code did not check if the requested seekback buffer is > already read entirely. In this case, nothing has to be done to guarantee > seekback. > > Signed-off-by: Marton Balint > --- > libavformat/aviobuf.c | 3 +++ > 1 file changed, 3 insertions(+) Its interresting this needs a seperate check but LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. 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] fate: add scale filters for big-endian architectures.
Michael Niedermayer (12020-09-30): > > confirmed to work on qemu mips > > so should be ok Sorry, I missed that part of your mail. Pushed. > ping, big endian is still broken A few minutes ago, I still did not see these failures on fate.ffmpeg.org. Any idea why? > also i realize that this has a disadvantage, and that is that it adds > quite a bit of extra human work. Because now every time a fate test > is added theres an additional thing to consider which is specific > to big endian and which most developers cannot easily test I think you are painting this too darkly, the pattern is quite simple: tests that output high bit depth require a final conversion filter. We can be careful when reviewing commits that add tests. And if it does not work, there is something weirdly broken that needs to be investigated, so it is a good thing we know about it. Regards, -- Nicolas George 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 2/2] avformat/movenc: Make some AVCodecTag tables static
They are not used anywhere else.
Signed-off-by: Andreas Rheinhardt
---
libavformat/movenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7d89cd579a..6c10500149 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7113,7 +7113,7 @@ static const AVCodecTag codec_3gp_tags[] = {
{ AV_CODEC_ID_NONE, 0 },
};
-const AVCodecTag codec_mp4_tags[] = {
+static const AVCodecTag codec_mp4_tags[] = {
{ AV_CODEC_ID_MPEG4, MKTAG('m', 'p', '4', 'v') },
{ AV_CODEC_ID_H264,MKTAG('a', 'v', 'c', '1') },
{ AV_CODEC_ID_H264,MKTAG('a', 'v', 'c', '3') },
@@ -7149,7 +7149,7 @@ const AVCodecTag codec_mp4_tags[] = {
{ AV_CODEC_ID_NONE, 0 },
};
-const AVCodecTag codec_ism_tags[] = {
+static const AVCodecTag codec_ism_tags[] = {
{ AV_CODEC_ID_WMAPRO , MKTAG('w', 'm', 'a', ' ') },
{ AV_CODEC_ID_NONE,0 },
};
--
2.25.1
___
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 1/2] avformat/movenc: Fix segfault when remuxing rtp hint stream
When remuxing an rtp hint stream (or any stream with the tag "rtp "),
the mov muxer treats this as one of the rtp hint tracks it creates
internally when ordered to do so; yet this track lacks the
AVFormatContext for the hinting rtp muxer, leading to segfaults in
mov_write_udta_sdp() if a "trak" atom is written for this stream; if not,
the stream's codecpar is freed by mov_free() as if the mov muxer owned
it (it does for the internally created "rtp " tracks), but without
resetting st->codecpar, leading to double-frees lateron. This commit
therefore ignores said tag which makes rtp hint streams unremuxable.
This fixes tickets #8181 and #8186.
Signed-off-by: Andreas Rheinhardt
---
This is the mov-equivalent of ticket #7079.
libavformat/movenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 265465f97b..7d89cd579a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1652,6 +1652,10 @@ static unsigned int mov_get_codec_tag(AVFormatContext
*s, MOVTrack *track)
{
unsigned int tag = track->par->codec_tag;
+// "rtp " is used to distinguish internally created RTP-hint tracks
+// (with rtp_ctx) from other tracks.
+if (tag == MKTAG('r','t','p',' '))
+tag = 0;
if (!tag || (s->strict_std_compliance >= FF_COMPLIANCE_NORMAL &&
(track->par->codec_id == AV_CODEC_ID_DVVIDEO ||
track->par->codec_id == AV_CODEC_ID_RAWVIDEO ||
--
2.25.1
___
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] rtsp: Fix infinite loop in listen mode with UDP transport
Hi Martin,
On 9/30/20 5:41 PM, Martin Storsjö wrote:
In listen mode with UDP transport, once the sender has sent
the TEARDOWN and closed the connection, poll will indicate that
one can read from the connection (indicating that the socket has
reached EOF and should be closed by the receiver as well). In this
case, parse_rtsp_message won't try to parse the command (because
it's no longer in state STREAMING), but previously just returned
zero.
Prior to f6161fccf8c5720ceac1ed1df8ba60ff8fed69f5, this caused
udp_read_packet to return zero, which is treated as EOF by
read_packet. But after that commit, udp_read_packet would continue
if parse_rtsp_message didn't return an explicit error code.
To keep the original behaviour from before that commit, more
explicitly return an error in parse_rtsp_message when in the wrong
state.
Fixes: #8840
---
libavformat/rtsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 5d8491b74b..ad12f2ae98 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1970,7 +1970,7 @@ static int parse_rtsp_message(AVFormatContext *s)
av_log(s, AV_LOG_WARNING,
"Unable to answer to TEARDOWN\n");
} else
-return 0;
+return AVERROR_EOF;
Does the else part needs the same fix?
I tried a similar approach in
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/267437.html.
The intended behavior (e.g., return value) of parse_rtsp_message is not
quite clear
to me, could you help improve it, like adding some documentation?
} else {
RTSPMessageHeader reply;
ret = ff_rtsp_read_reply(s, , NULL, 0, NULL);
___
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/movenc: Fix stack overflow when remuxing timecode tracks
There are two possible kinds of timecode tracks (with tag "tmcd") in the
mov muxer: Tracks created internally by the muxer and timecode tracks
sent by the user. If any of the latter exists, the former are
deactivated. The former all belong to another track, the source
track; the latter don't have a source track set, but the index of the
source track is initially zeroed by av_mallocz_array(). This is a
problem since 3d894db700cc1e360a7a75ab9ac8bf67ac6670a3: Said commit added
a function that calculates the duration of tracks and the duration of
timecode tracks is calculated by rescaling the duration (calculated by
the very same function) of the source track. This gives an infinite
recursion if the first track (the one that will be treated as source
track for all timecode tracks) is a timecode track itself, leading to a
stack overflow.
This commit fixes this by not using the nonexistent source track
when calculating the duration of timecode tracks not created internally
by the mov muxer.
Signed-off-by: Andreas Rheinhardt
---
1. Remuxing timecode tracks is currently impossible for mp4 (the codec
tag validation fails); I wonder whether this is actually intended given
that there is a warning that timecode metadata is ignored if an explicit
timecode track is present.
2. There is another place where the src_track field is used even when a
timecode track doesn't have a src_track: When writing the moov tag
(lines 4156-4166). This will probably also need to be fixed, but it is
not dangerous.
3. There is btw no validation that a track with "tmcd" tag is a data
stream.
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 2006fcee4b..265465f97b 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2901,7 +2901,7 @@ static int mov_write_minf_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContext
static int64_t calc_pts_duration(MOVMuxContext *mov, MOVTrack *track)
{
-if (track->tag == MKTAG('t','m','c','d')) {
+if (track->tag == MKTAG('t','m','c','d') && mov->nb_meta_tmcd) {
// tmcd tracks gets track_duration set in mov_write_moov_tag from
// another track's duration, while the end_pts may be left at zero.
// Calculate the pts duration for that track instead.
--
2.25.1
___
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 19/25] avcodec/utils: Remove always-true check
Andreas Rheinhardt:
> The first thing avcodec_open2() allocates is the AVCodecInternal. If
> allocating it fails, a jump to end occurs; but if an error happens after
> its allocation, a jump to free_and_end happens which frees all
> allocations performed so far and then jumps to end. Yet free_and_end
> contained a check for AVCodecInternal (after having already dereferenced
> it to check whether ff_thread_free() needs to be called) which is of
> course always true. So remove it.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/utils.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 94b9e94584..8e7c3125aa 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1043,7 +1043,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> av_dict_free();
> av_freep(>priv_data);
> av_freep(>subtitle_header);
> -if (avci) {
> +
> av_frame_free(>to_free);
> av_frame_free(>compat_decode_frame);
> av_frame_free(>buffer_frame);
> @@ -1056,7 +1056,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
> av_bsf_free(>bsf);
>
> av_buffer_unref(>pool);
> -}
> av_freep();
> avctx->internal = NULL;
> avctx->codec = NULL;
>
Will apply the rest of this patchset this evening unless there are
objections.
- 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".
Re: [FFmpeg-devel] FFmpeg for android
Hi, I am not sure this mailing list is the right place to discuss about that but I am actively work with FFmpeg and Android since multiple years. My work is based on this project https://github.com/olivierayache/xuggle-xuggler which is fully working with Android and support HW encoding/decoding Best Olivier Ayache Le mer. 30 sept. 2020 à 10:15, shaheer cs a écrit : > Hi, > Greetings of the day, > > > Iam an android developer. And iam currently working on video streaming > platform when user can do video compression,video trim etc. So I found that > by using FFmpeg I can achieve most of my application functionality(Thanks > for being best tool for developer like me) I have done POC with prebuild > FFmpeg binaries which is developed by some people and I face > Some difficulties like to support 32bit and 64 bit for android, lack of > codec etc.. so I have finalize that should build FFmpeg and JNI class > myself. Now I am facing lack of tutorial, examples and documentation where > how to build ourself. So here I request you to help me on this by providing > any above. > > I looking forward to reply from you. > > Thanking you > Shaheer cs > > ___ > 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 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] rtsp: Fix infinite loop in listen mode with UDP transport
In listen mode with UDP transport, once the sender has sent
the TEARDOWN and closed the connection, poll will indicate that
one can read from the connection (indicating that the socket has
reached EOF and should be closed by the receiver as well). In this
case, parse_rtsp_message won't try to parse the command (because
it's no longer in state STREAMING), but previously just returned
zero.
Prior to f6161fccf8c5720ceac1ed1df8ba60ff8fed69f5, this caused
udp_read_packet to return zero, which is treated as EOF by
read_packet. But after that commit, udp_read_packet would continue
if parse_rtsp_message didn't return an explicit error code.
To keep the original behaviour from before that commit, more
explicitly return an error in parse_rtsp_message when in the wrong
state.
Fixes: #8840
---
libavformat/rtsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 5d8491b74b..ad12f2ae98 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1970,7 +1970,7 @@ static int parse_rtsp_message(AVFormatContext *s)
av_log(s, AV_LOG_WARNING,
"Unable to answer to TEARDOWN\n");
} else
-return 0;
+return AVERROR_EOF;
} else {
RTSPMessageHeader reply;
ret = ff_rtsp_read_reply(s, , NULL, 0, NULL);
--
2.24.3 (Apple Git-128)
___
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 v3 2/2] avformat/rtsp: fix parse_rtsp_message
On Sun, 27 Sep 2020, Zhao Zhili wrote:
1. Remove the assumption that the message method is TEARDOWN.
2. Don't ignore the error code of ff_rtsp_parse_streaming_commands.
---
libavformat/rtsp.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 597413803f..3e69ab7287 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1964,11 +1964,7 @@ static int parse_rtsp_message(AVFormatContext *s)
if (rt->rtsp_flags & RTSP_FLAG_LISTEN) {
if (rt->state == RTSP_STATE_STREAMING) {
-if (!ff_rtsp_parse_streaming_commands(s))
-return AVERROR_EOF;
-else
-av_log(s, AV_LOG_WARNING,
- "Unable to answer to TEARDOWN\n");
+return ff_rtsp_parse_streaming_commands(s);
} else
return 0;
} else {
--
2.17.1
This looks ok to me.
// Martin
___
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 v3 1/2] avformat/rtsp: fix infinite loop with udp transport
Hi,
On Sun, 27 Sep 2020, Zhao Zhili wrote:
Fix #8840.
Steps to reproduce:
1. sender:
./ffmpeg -i test.mp4 -c copy -f rtsp -rtsp_transport udp
rtsp://localhost:12345/live.sdp
2. receiver:
./ffmpeg_g -y -rtsp_flags listen -timeout 100 -i
rtsp://localhost:12345/live.sdp -c copy test.mp4
---
v3: mention the ticket.
libavformat/rtsp.c| 2 ++
libavformat/rtsp.h| 1 +
libavformat/rtspdec.c | 2 +-
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 5d8491b74b..597413803f 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -2051,6 +2051,8 @@ static int udp_read_packet(AVFormatContext *s, RTSPStream
**prtsp_st,
if ((ret = parse_rtsp_message(s)) < 0) {
return ret;
}
+if (rt->state == RTSP_STATE_TEARDOWN)
+return AVERROR_EOF;
}
#endif
} else if (n == 0 && ++timeout_cnt >= MAX_TIMEOUTS) {
diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
index 54a9a30c16..481cc0c3ce 100644
--- a/libavformat/rtsp.h
+++ b/libavformat/rtsp.h
@@ -198,6 +198,7 @@ enum RTSPClientState {
RTSP_STATE_STREAMING, /**< initialized and sending/receiving data */
RTSP_STATE_PAUSED, /**< initialized, but not receiving data */
RTSP_STATE_SEEKING, /**< initialized, requesting a seek */
+RTSP_STATE_TEARDOWN,/**< initialized, in teardown state */
};
/**
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index dfa29913bf..ec786a469a 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -494,7 +494,7 @@ int ff_rtsp_parse_streaming_commands(AVFormatContext *s)
"Public: ANNOUNCE, PAUSE, SETUP, TEARDOWN, "
"RECORD\r\n", request.seq);
} else if (methodcode == TEARDOWN) {
-rt->state = RTSP_STATE_IDLE;
+rt->state = RTSP_STATE_TEARDOWN;
ret = rtsp_send_reply(s, RTSP_STATUS_OK, NULL , request.seq);
}
return ret;
--
2.17.1
I think this approach to fixing it, adding a new state, is a bit of
overkill. This usecase actually used to work originally, but I bisected it
and it broke in f6161fccf8c5720ceac1ed1df8ba60ff8fed69f5. So with that in
mind, it's pretty straightforward to fix it by retaining the original
behaviour from before that commit. I'll send an alternative patch that
does that.
// Martin
___
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/adxdec: demux multiple blocks at once
Improves decoding speed by 24x
Signed-off-by: Paul B Mahol
---
libavformat/adxdec.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/libavformat/adxdec.c b/libavformat/adxdec.c
index ccd5049acd..a265c87dea 100644
--- a/libavformat/adxdec.c
+++ b/libavformat/adxdec.c
@@ -53,6 +53,9 @@ static int adx_read_packet(AVFormatContext *s, AVPacket *pkt)
AVCodecParameters *par = s->streams[0]->codecpar;
int ret, size;
+if (avio_feof(s->pb))
+return AVERROR_EOF;
+
if (par->channels <= 0) {
av_log(s, AV_LOG_ERROR, "invalid number of channels %d\n",
par->channels);
return AVERROR_INVALIDDATA;
@@ -63,16 +66,21 @@ static int adx_read_packet(AVFormatContext *s, AVPacket
*pkt)
pkt->pos = avio_tell(s->pb);
pkt->stream_index = 0;
-ret = av_get_packet(s->pb, pkt, size);
-if (ret != size) {
-return ret < 0 ? ret : AVERROR(EIO);
-}
-if (AV_RB16(pkt->data) & 0x8000) {
-return AVERROR_EOF;
+ret = av_get_packet(s->pb, pkt, size * 128);
+if (ret < 0)
+return ret;
+if ((ret % size) && ret >= size) {
+size = ret - (ret % size);
+av_shrink_packet(pkt, size);
+pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
+} else if (ret < size) {
+return AVERROR(EIO);
+} else {
+size = ret;
}
-pkt->size = size;
-pkt->duration = 1;
-pkt->pts = (pkt->pos - c->header_size) / size;
+
+pkt->duration = size / (BLOCK_SIZE * par->channels);
+pkt->pts = (pkt->pos - c->header_size) / (BLOCK_SIZE * par->channels);
return 0;
}
--
2.17.1
___
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] FFmpeg for android
Hi, Greetings of the day, Iam an android developer. And iam currently working on video streaming platform when user can do video compression,video trim etc. So I found that by using FFmpeg I can achieve most of my application functionality(Thanks for being best tool for developer like me) I have done POC with prebuild FFmpeg binaries which is developed by some people and I face Some difficulties like to support 32bit and 64 bit for android, lack of codec etc.. so I have finalize that should build FFmpeg and JNI class myself. Now I am facing lack of tutorial, examples and documentation where how to build ourself. So here I request you to help me on this by providing any above. I looking forward to reply from you. Thanking you Shaheer cs ___ 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 v2 3/3] avformat/mxfdec: Read Apple private Content Light Level from MXF
On Thu, Sep 17, 2020 at 10:49:31PM +0200, Tomas Härdin wrote: > mån 2020-09-14 klockan 12:23 +0200 skrev Tomas Härdin: > > ons 2020-09-09 klockan 15:56 +0100 skrev Harry Mallon: > > > * As embedded by Apple Compressor > > > > > > Signed-off-by: Harry Mallon > > > --- > > > libavformat/mxfdec.c| 27 + > > > tests/fate/mxf.mak | 4 + > > > tests/ref/fate/mxf-probe-applehdr10 | 169 > > > > > > > Sweet, I don't have to write the test myself .) > > > > Just ran FATE, the entire patch set works fine. We just need to get > > that sample into the sample suite then all three of them can be > > pushed. > > I'll see what I can do. > > FATE suite updated, FATE passes -> patchset pushed fails on big endian --- src/tests/ref/fate/mxf-probe-applehdr10 2020-09-28 23:21:12.291897976 +0200 +++ tests/data/fate/mxf-probe-applehdr102020-09-30 09:31:38.614653806 +0200 @@ -14,7 +14,7 @@ has_b_frames=0 sample_aspect_ratio=1:1 display_aspect_ratio=16:9 -pix_fmt=yuv422p10le +pix_fmt=yuv422p10be level=-99 color_range=tv color_space=bt2020nc Test mxf-probe-applehdr10 failed. Look at tests/data/fate/mxf-probe-applehdr10.err for details. src/tests/Makefile:255: recipe for target 'fate-mxf-probe-applehdr10' failed make: *** [fate-mxf-probe-applehdr10] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus 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] fate: add scale filters for big-endian architectures.
On Wed, Sep 16, 2020 at 08:52:41PM +0200, Michael Niedermayer wrote: > On Mon, Sep 14, 2020 at 09:26:53PM +0200, Nicolas George wrote: [...] > > tests/fate/bmp.mak | 6 +++--- > > tests/fate/dnxhd.mak| 4 ++-- > > tests/fate/filter-video.mak | 18 +- > > tests/fate/fits.mak | 8 > > tests/fate/gif.mak | 10 +- > > tests/fate/h264.mak | 34 +- > > tests/fate/hevc.mak | 12 ++-- > > tests/fate/image.mak| 2 +- > > tests/fate/microsoft.mak| 4 ++-- > > tests/fate/pixlet.mak | 2 +- > > tests/fate/prores.mak | 16 > > tests/fate/video.mak| 16 > > tests/fate/vpx.mak | 4 ++-- > > 13 files changed, 68 insertions(+), 68 deletions(-) > > confirmed to work on qemu mips > so should be ok ping, big endian is still broken also i realize that this has a disadvantage, and that is that it adds quite a bit of extra human work. Because now every time a fate test is added theres an additional thing to consider which is specific to big endian and which most developers cannot easily test thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes 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/libsrt: rename streamid
Rename streamid to avoid name clashes.
Signed-off-by: raghavendra
---
libavformat/libsrt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 4025b24976..a490a386e6 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -134,7 +134,7 @@ static const AVOption libsrt_options[] = {
{ "rcvbuf", "Receive buffer size (in bytes)",
OFFSET(rcvbuf), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, INT_MAX, .flags = D|E },
{ "lossmaxttl", "Maximum possible packet reorder tolerance",
OFFSET(lossmaxttl), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, INT_MAX, .flags = D|E },
{ "minversion", "The minimum SRT version that is required from the
peer", OFFSET(minversion), AV_OPT_TYPE_INT, { .i64 =
-1 }, -1, INT_MAX, .flags = D|E },
-{ "streamid", "A string of up to 512 characters that an Initiator
can pass to a Responder", OFFSET(streamid), AV_OPT_TYPE_STRING, { .str =
NULL }, .flags = D|E },
+{ "srt_streamid", "A string of up to 512 characters that an Initiator
can pass to a Responder", OFFSET(streamid), AV_OPT_TYPE_STRING, { .str =
NULL }, .flags = D|E },
{ "smoother", "The type of Smoother used for the transmission for
that socket", OFFSET(smoother), AV_OPT_TYPE_STRING, { .str =
NULL }, .flags = D|E },
{ "messageapi", "Enable message API",
OFFSET(messageapi), AV_OPT_TYPE_BOOL, { .i64 = -1 },
-1, 1, .flags = D|E },
{ "transtype", "The transmission type for the socket",
OFFSET(transtype),AV_OPT_TYPE_INT, { .i64 =
SRTT_INVALID }, SRTT_LIVE, SRTT_INVALID, .flags = D|E, "transtype" },
@@ -599,7 +599,7 @@ static int libsrt_open(URLContext *h, const char *uri, int
flags)
if (av_find_info_tag(buf, sizeof(buf), "minversion", p)) {
s->minversion = strtol(buf, NULL, 0);
}
-if (av_find_info_tag(buf, sizeof(buf), "streamid", p)) {
+if (av_find_info_tag(buf, sizeof(buf), "srt_streamid", p)) {
av_freep(>streamid);
s->streamid = av_strdup(buf);
if (!s->streamid) {
--
2.25.1
___
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".
