- 12 Dec, 2019 2 commits
-
-
Andreas Rheinhardt authored
These functions already free it themselves before they allocate the new extradata. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Andreas Rheinhardt authored
It is not uncommon to find code where the caller thinks to know better what the return value should be than the callee. E.g. something like "if (av_new_packet(pkt, size) < 0) return AVERROR(ENOMEM);". This commit changes several instances of this to instead forward the actual error. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 09 Aug, 2019 1 commit
-
-
Olivier Maignial authored
=== PROBLEM === I was trying to record h264 + aac streams from an RTSP server to mp4 file. using this command line: ffmpeg -v verbose -y -i "rtsp://<ip>/my_resources" -codec copy -bsf:a aac_adtstoasc test.mp4 FFmpeg then fail to record audio and output this logs: [rtsp @ 0xcda1f0] The profile-level-id field size is invalid (40) [rtsp @ 0xcda1f0] Error parsing AU headers ... [rtsp @ 0xcda1f0] Could not find codec parameters for stream 1 (Audio: aac, 48000 Hz, 1 channels): unspecified sample format In SDP provided by my RTSP server I had this fmtp line: a=fmtp:98 streamType=5; profile-level-id=40; mode=AAC-hbr; config=1188; sizeLength=13; indexLength=3; indexDeltaLength=3; In FFmpeg code, I found a check introduced by commit 24130234. It disallows values greater than 32 for fmtp line parameters. RFC-4566 (SDP: Session Description Protocol) do not give any limit of size on interger parameters given in an fmtp line. However, In RFC-6416 (RTP Payload Format for MPEG-4 Audio/Visual Streams) give examples of "profile-level-id" values for AAC, up to 55. === FIX === As each parameter may have its own min and max values I propose to introduce a range for each parameter. For this patch I used RFC-3640 and ISO/IEC 14496-1 as reference for validity ranges. This patch fix my problem and I now can record my RTSP AAC stream to mp4. It has passed the full fate tests suite sucessfully. Signed-off-by:
Olivier Maignial <olivier.maignial@smile.fr> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 14 Feb, 2018 1 commit
-
-
Carl Eugen Hoyos authored
Reviewed-by: Muhammad Faiz
-
- 11 Feb, 2017 1 commit
-
-
Carl Eugen Hoyos authored
Silences an "assignment discards ‘const’ qualifier" warning.
-
- 07 Feb, 2017 1 commit
-
-
Diego Biurrun authored
-
- 13 Jan, 2017 1 commit
-
-
Alexandra Hájková authored
-
- 21 Nov, 2016 1 commit
-
-
Diego Biurrun authored
libavformat/rtpdec_mpeg4.c:282:38: warning: passing argument 2 of ‘parse_fmtp_config’ discards ‘const’ qualifier from pointer target type
-
- 23 Aug, 2016 1 commit
-
-
Luca Barbato authored
-
- 04 May, 2016 1 commit
-
-
Vittorio Giovara authored
Signed-off-by:
Diego Biurrun <diego@biurrun.de>
-
- 23 Feb, 2016 1 commit
-
-
Anton Khirnov authored
Currently, AVStream contains an embedded AVCodecContext instance, which is used by demuxers to export stream parameters to the caller and by muxers to receive stream parameters from the caller. It is also used internally as the codec context that is passed to parsers. In addition, it is also widely used by the callers as the decoding (when demuxer) or encoding (when muxing) context, though this has been officially discouraged since Libav 11. There are multiple important problems with this approach: - the fields in AVCodecContext are in general one of * stream parameters * codec options * codec state However, it's not clear which ones are which. It is consequently unclear which fields are a demuxer allowed to set or a muxer allowed to read. This leads to erratic behaviour depending on whether decoding or encoding is being performed or not (and whether it uses the AVStream embedded codec context). - various synchronization issues arising from the fact that the same context is used by several different APIs (muxers/demuxers, parsers, bitstream filters and encoders/decoders) simultaneously, with there being no clear rules for who can modify what and the different processes being typically delayed with respect to each other. - avformat_find_stream_info() making it necessary to support opening and closing a single codec context multiple times, thus complicating the semantics of freeing various allocated objects in the codec context. Those problems are resolved by replacing the AVStream embedded codec context with a newly added AVCodecParameters instance, which stores only the stream parameters exported by the demuxers or read by the muxers.
-
- 27 Jul, 2015 1 commit
-
-
Vittorio Giovara authored
Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
- 24 Feb, 2015 7 commits
-
-
Martin Storsjö authored
Many of these functions were named foo_free_context, and since the functions no longer should free the context itself, only allocated elements within it, the previous naming was slightly misleading. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This makes it more consistent with depacketizers that don't have any .free function at all, where the payload context is freed by the surrounding framework. Always free the context in the surrounding framework, having the individual depacketizers only free any data they've specifically allocated themselves. This is similar to how this works for demuxer/muxers/codecs - a component shouldn't free the priv_data that the framework has allocated for it. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This makes it clear that the individual parsing functions can't touch the parsed out value. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This avoids implementing a full function just to set this one field. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 21 Feb, 2015 3 commits
-
-
Gilles Chanteperdrix authored
Signed-off-by:
Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> Reviewed-by:
Thomas Volkert <silvo@gmx.net> Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
Gilles Chanteperdrix authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Gilles Chanteperdrix authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 14 Feb, 2015 1 commit
-
-
Diego Biurrun authored
-
- 24 Dec, 2014 1 commit
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 15 Dec, 2014 1 commit
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 09 Jul, 2014 1 commit
-
-
Anton Khirnov authored
Use it for logging, instead of NULL or the stream codec context.
-
- 13 Oct, 2013 1 commit
-
-
Paul B Mahol authored
Signed-off-by:
Paul B Mahol <onemda@gmail.com>
-
- 05 May, 2013 1 commit
-
-
Diego Biurrun authored
-
- 20 Jan, 2013 2 commits
-
-
Martin Storsjö authored
This gets rid of almost all the codec specific details from the generic rtpdec code. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This makes the returned data valid to stream copy into other containers as well, not only for decoding straight away. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 16 Jan, 2013 1 commit
-
-
Martin Storsjö authored
This fixes possible buffer overreads. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 15 Jan, 2013 1 commit
-
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 21 Dec, 2012 1 commit
-
-
Martin Storsjö authored
This allows depacketizers to figure out if packets have been lost. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 12 Dec, 2012 1 commit
-
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 09 Oct, 2012 1 commit
-
-
Janne Grunau authored
Fixes CID700204.
-
- 07 Aug, 2012 1 commit
-
-
Anton Khirnov authored
-
- 06 Jul, 2012 1 commit
-
-
Lou Logan authored
Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 08 Apr, 2012 1 commit
-
-
Martin Storsjö authored
This avoids exposing a dummy AVStream which won't get any data and which will make avformat_find_stream_info wait for info about this stream. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 06 Feb, 2012 1 commit
-
-
Diego Biurrun authored
-
- 28 Nov, 2011 1 commit
-
-
Diego Biurrun authored
-