Fixes a decoding regression introduced by e9a2a87773, and as a side effect also
fixes bogus values set to certain audio frames that had some samples discarded,
where the offsets added to pts, pkt_dts and pkt_duration were not reflected in
best_effort_timestamp.
Signed-off-by: James Almer <jamrial@gmail.com>
SMVJPEG stores frames as slices of a big JPEG image. The decoder is
implemented as a wrapper that instantiates a full internal MJPEG
decoder, then forwards the decoded frames with offset data pointers.
This is unnecessarily complex and fragile, not supporting useful decoder
capabilities like direct rendering.
Re-implement the decoder inside the MJPEG decoder, which is accomplished
by returning each decoded frame multiple times, setting cropping
information appropriately on each instance.
One peculiar aspect of the previous design is that since
- the smvjpeg decoder returns one frame per input packet
- there are multiple frames in each packets (the aformentioned slices)
the demuxer needs to return each packet multiple times.
This is now also eliminated - the demuxer now returns each packet
exactly once, with the duration set to the number of frames it decodes
to.
This also removes one of the last remaining internal uses of the old
video decoding API.
It depends on the muxer generating the timestamps, which is deprecated
and scheduled for removal on next bump.
A bunch of tests change timestamps, because of ffmpeg.c is not
generating them correctly. This should be fixed later.
Factor out the code into a separate muxing-specific function.
Stop accessing the deprecated AVStream-embedded codec context, use the
average framerate (if specified) instead.
While the FATE suite contains a sample file for Musepack 8, it did not
use it to test the decoder; it is only used in the mpc8-demux test that
tests the demuxer via streamcopy. Therefore this commit adds an actual
encoder test.
The test uses the framecrc output, because Musepack SV8 is an encoder
that returns multiple frames for a single packet, so that timing
information in the test output is valueable. Output seeking has been
used in order to limit the size of the ref file as well as to test this
codepath for the first time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
We now have the possibility of getting AVFrames here, and we should
not touch the muxer's codecpar after writing the header.
Results of FATE tests change as the MXF and Matroska muxers actually
write down the field/frame coding type of a stream in their
respective headers. Before this change, these values in codecpar
would only be set after the muxer was initialized. Now, the
information is also available for encoder and muxer initialization.
This disallows the usage of ? and # in libavformat specific scheme options
(e.g. subfile,,start,32815239,end,0,,:video.ts) but this change was considered
acceptable.
Signed-off-by: ruiquan.crq <caihaoning83@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
These conversion appears to be exhibiting the same rounding error as the rgbf32 formats where.
I seperated the rounding value from the 16 and 128 offsets, I think it makes it a little more clear.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
changes since v1:
- made into fate test
- fixed c90 warnings
- tests more intermediate formats
- tested on BE mips too
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is utilized by various media ingests to figure out the bit
rate of the content you are pushing towards it, so write it for
video, audio and subtitle tracks in case at least one nonzero value
is available. It is only mentioned for timed metadata sample
descriptions in QTFF, so limit it only to ISOBMFF (MODE_MP4) mode.
Updates the FATE tests which have their results changed due to the
20 extra bytes being written per track.
This AV1 decoder is currently only used for hardware accelerated decoding.
It can be extended into a native decoder in the future, so set its name to
"av1" and temporarily give it the lowest priority in the codec list.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Allow to set the EOF timestamp.
Also: doc/filters/testsrc*: specify the rounding of the duration option.
The changes in the ref files are right.
For filter-fps-down, the graph is testsrc2=r=7:d=3.5,fps=3.
3.5=24.5/7, so the EOF of testsrc2 will have PTS 25/7.
25/7=(10+5/7)/3, so the EOF PTS for fps should be 11/7,
and the output should contain a frame at PTS 10.
For filter-fps-up, the graph is testsrc2=r=3:d=2,fps=7,
for filter-fps-up-round-down and filter-fps-up-round-up
it is the same with explicit rounding options.
But there is no rounding: testsrc2 produces exactly 6 frames
and 2 seconds, fps converts it into exactly 14 frames.
The tests should probably be adjusted to restore them to
a useful coverage.
The dvbsubtest_filter.ts sample is a filtered version of the Videolan
sample database (samples/sub/dvbsub/dvbsubtest.ts) using Project X. It
originates from ticket #8844.
The write_colr flag has been marked as experimental for over 5 years.
It should be safe to enable its behavior by default as follows:
- Write the colr atom by default for mp4/mov if any of the following:
- The primaries/trc/matrix are all specified, OR
- There is an ICC profile, OR
- The user specified +write_colr
- Keep the write_colr flag for situations where the user wants to
write the colr atom even if the color info is unspecified (e.g.,
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259334.html)
This fixes https://trac.ffmpeg.org/ticket/7961
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
The new code is analog to how it's done in our mpegaudio parser.
Acked-by: Jun Zhao <barryjzhao@tencent.com>
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Also add and update some tests.
Change the semantic a little, because for filesytem paths
symlinks complicate things.
See the comments in the code for detail.
Fix trac tickets #8813 and 8814.
Reads color_primaries, color_trc and color_space from mxf
headers. ULs are from https://registry.smpte-ra.org/ site.
Signed-off-by: Harry Mallon <harry.mallon@codex.online>
add probeaudiostream for get audio stream's codec_name,codec_time_base,
sample_fmt,channels and channel_layout.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Important part of this algorithm is the double threshold step: pixels
above "high" threshold being kept, pixels below "low" threshold dropped,
pixels in between (weak edges) are kept if they are neighboring "high"
pixels.
The weak edge check uses a neighboring context and should not be applied
on the plane's border. The condition was incorrect and has been fixed in
the commit.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
floating point precision will cause rgb*max generate different value on
x86_32 and x86_64. have pass fate test on x86_32 and x86_64 by using
lrintf to get the nearest integral value for rgb * max before av_clip.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Now we just use one ADTS raw frame to calculate the bit rate, it's
lead to a larger error when get the duration from bit rate, the
improvement cumulate Nth ADTS frames to get the average bit rate.
e,g used the command get the duration like:
ffprobe -show_entries format=duration -i fate-suite/aac/foo.aac
before this improvement dump the duration=2.173935
after this improvement dump the duration=1.979267
in fact, the real duration can be get by command like:
ffmpeg -i fate-suite/aac/foo.aac -f null /dev/null with time=00:00:01.97
Also update the fate-adtstoasc_ticket3715.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
