Add it to decoder options instead, to be processed when opening the
decoder. This way it won't be overridden by flags the user might be
setting otherwise.
Fixes "runtime error: member access within misaligned address 0xf00 for type
'struct bar', which requires # byte alignment" errors under GCC ubsan.
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes server compatibility issues with rtspclientsink GStreamer plugin.
>From specification:
RFC 7826 "Real-Time Streaming Protocol Version 2.0" (https://datatracker.ietf.org/doc/html/rfc7826), section 18.54:
mode: The mode parameter indicates the methods to be supported for
this session. The currently defined valid value is "PLAY". If
not provided, the default is "PLAY". The "RECORD" value was
defined in RFC 2326; in this specification, it is unspecified
but reserved. RECORD and other values may be specified in the
future.
RFC 2326 "Real Time Streaming Protocol (RTSP)" (https://datatracker.ietf.org/doc/html/rfc2326), section 12.39:
mode:
The mode parameter indicates the methods to be supported for
this session. Valid values are PLAY and RECORD. If not
provided, the default is PLAY.
mode=receive was always like this, from the initial commit 'a8ad6ffa rtsp: Add listen mode'.
For comparison, Wowza was used to push RTSP stream to. Both GStreamer and FFmpeg had no issues.
Here is the capture of Wowza responding to SETUP request:
200 OK
CSeq: 3
Server: Wowza Streaming Engine 4.8.26+4 build20231212155517
Cache-Control: no-cache
Expires: Mon, 15 Jan 2024 19:40:31 GMT
Transport: RTP/AVP/UDP;unicast;client_port=11640-11641;mode=record;source=172.17.0.2;server_port=6976-6977
Date: Mon, 15 Jan 2024 19:40:31 GMT
Session: 1401457689;timeout=60
Test setup:
Server: ffmpeg -loglevel trace -y -rtsp_flags listen -i rtsp://0.0.0.0:30800/live.stream t.mp4
FFmpeg client: ffmpeg -re -i "Big Buck Bunny - FULL HD 30FPS.mp4" -c:v libx264 -f rtsp rtsp://127.0.0.1:30800/live.stream
GStreamer client: gst-launch-1.0 videotestsrc is-live=true pattern=smpte ! queue ! videorate ! videoscale ! video/x-raw,width=640,height=360,framerate=60/1 ! timeoverlay font-desc="Sans, 84" halignment=center valignment=center ! queue ! videoconvert ! tee name=t t. ! x264enc bitrate=9000 pass=cbr speed-preset=ultrafast byte-stream=false key-int-max=15 threads=1 ! video/x-h264,profile=baseline ! queue ! rsink. audiotestsrc ! voaacenc ! queue ! rsink. t. ! queue ! autovideosink rtspclientsink name=rsink location=rtsp://localhost:30800/live.stream
Test results:
modified FFmpeg client -> stock server : ok
stock FFmpeg client -> modified server : ok
modified FFmpeg client -> modified server : ok
GStreamer client -> modified server : ok
Signed-off-by: Paul Orlyk <paul.orlyk@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes server compatibility issues with rtspclientsink GStreamer plugin
Signed-off-by: Paul Orlyk <paul.orlyk@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Previously AV_PIX_FMT_RGB8 was documented as "RGB 3:3:2,
(msb)2R 3G 3B(lsb)". While the RGB 3:3:2 part is correct, the latter
part should be: (msb)3R 3G 2B(lsb). This commit also updates the
format's pixdesc description to be (msb)3R 3G 2B(lsb).
Signed-off-by: Jeffrey Knockel <jeff@jeffreyknockel.com>
Reviewed-by: "Diederick C. Niehorster" <dcnieho@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is the 64bit version of Chris Doty-Humphreys SFC64
Compared to the LCGs these produce much better quality numbers.
Compared to LFGs this needs less state. (our LFG has 224 byte
state for its 32bit version) this has 32byte state
Also the initialization for our LFG is slower.
This is also much faster than KISS or PCG.
This commit replaces the broken LCG used before.
(broken as it had only a period ~200M due to being put in a double)
This changes the output from random() which is why libswresample.mak
is updated, update was done using the command in libswresample.mak
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
As I understand, support for .STR files is broken for almost 10 years now (since 161442ff2c it seems).
Currently, ffmpeg fails with tons of errors like this on version 1 STRs, e.g. Wipeout 1:
[mdec @ 00000000027c72c0] ac-tex damaged at 1 9
What happens is that only the audio is present in the video file.
Anyway, that one character patch fixes the problem, video is now rendered.
Signed-off-by: aybe <aybe@users.noreply.github.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The C library function double atan2(double y, double x) takes y as the first
parameter and x as the second parameter.
Signed-off-by: Haixia Shi <hshi@meta.com>
On some platforms (in particular, ARM/AArch64), the implementation
of AV_READ_TIME() may use a privileged instruction - in such
cases, benchmarking just fails with a SIGILL.
Instead of crashing, try executing AV_READ_TIME() once within
a region with the signal handler active, to allow gracefully
informing the user about the issue.
This matches the dav1d checkasm commit
95a192549a448b70d9542e840c4e34b60d09b093.
Signed-off-by: Martin Storsjö <martin@martin.st>
Parse iprp and iinf boxes and its child boxes to get the actual codec used
(AV1 for avif, HEVC for heic), and properly export extradata and other
properties in a generic way.
The avif tests reference files are updated as the extradata is now exported.
Based on a patch by Swaraj Hota
Co-authored-by: Swaraj Hota <swarajhota353@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Marth64 <marth64@proxyid.net>
Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
used open source tool for processing 608/708 closed caption (CC) sources.
It can be used to archive the original, raw CC bitstream and to produce
a source file file for later CC processing or conversion. As a result,
it also allows for interopability with ccextractor for processing CC data
extracted via ffmpeg. The format is simple to parse and can be used
to retain all lines and variants of CC.
A free specification of RCWT can be found here:
https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT
This muxer implements the specification as of 01/05/2024, which has
been stable and unchanged for 10 years as of this writing.
This muxer will have some nuances from the way that ccextractor muxes RCWT.
No compatibility issues when processing the output with ccextractor
have been observed as a result of this so far, but mileage may vary
and outputs will not be a bit-exact match.
Specifically, the differences are:
(1) This muxer will identify as "FF" as the writing program identifier, so
as to be honest about the output's origin.
(2) ffmpeg's MPEG-1/2, H264, HEVC, etc. decoders extract closed captioning
data differently than ccextractor from embedded SEI/user data.
For example, DVD captioning bytes will be translated to ATSC A53 format.
This allows ffmpeg to handle 608/708 in a consistant way downstream.
This is a lossless conversion and the meaningful data is retained.
(3) This muxer will not alter the extracted data except to remove invalid
packets in between valid CC blocks. On the other hand, ccextractor
will by default remove mid-stream padding, and add padding at the end
of the stream (in order to convey the end time of the source video).
tests/checkasm/checkasm:
C LSX LASX
hevc_idct_32x32_8_c: 1243.0 211.7 101.7
Speedup of decoding H265 4K 30FPS 30Mbps on
3A6000 with 8 threads is 1fps(56fps-->57fps).
Reviewed-by: yinshiyou-hf@loongson.cn
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Anton Khirnov
James Almer
sunyuechi
Nuo Mi
Paul Orlyk
Jeffrey Knockel
Michael Niedermayer
aybe aybe
Haixia Shi
Martin Storsjö
Rémi Denis-Courmont
Marth64
Stefano Sabatini
yuanhecai