This should be a few nano seconds faster (not measureable)
But Collectively the whole humankind watching hls will safe a minute
Found-by: Leo Izen
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The demuxer exports rawvideo, so there's no reason for the muxer to only
work with wrapped_avframe.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
For encoding, this field is entirely redundant with
AVCodecContext.framerate.
For decoding, this field is entirely redundant with
AV_CODEC_PROP_FIELDS.
H.264 and mpeg12 parsers need to be adjusted at the same time to stop
using the value of AVCodecContext.ticks_per_frame, because it is not set
correctly unless the codec has been opened. Previously this would result
in both the parser and lavf seeing the same incorrect value, which would
cancel out.
Updating lavf and not the parsers would result in correct value in lavf,
but the wrong one in parsers, which would break some tests.
This should fix the regression since 6b1f68ccb04d791f0250e05687c346a99ff47ea1
Should fix Ticket10353 (please test and report cases that still fail)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch simply recognizes the AAC audio track during
decode -- it does not add functionality to encode AAC in
MXF.
Signed-off-by: Ammon Riley <ammon.riley@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Its unexpected that a .avi or other "standard" file turns into a playlist.
The goal of this patch is to avoid this unexpected behavior and possible
privacy or security differences.
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
One that is fine enough to represent all DV audio sample rates. Audio
packet durations are now sample-accurate.
This largely undoes commit 76fbb0052df471075858c1cb82b04c8be7adba8d. To
avoid breaking the issue fixed by that commit, resync audio timestamps
against video if they get more than one frame apart. The sample from
issue #8762 still works correctly after this commit.
Slightly changes the results of the lavf-dv seektest, due to the audio
timebase being more granular.
Current code will call avpriv_set_pts_info() for each video frame,
possibly setting a different timebase if the stream framerate changes.
This violates API conventions, as the timebase is supposed to stay
constant after stream creation.
Change the demuxer to set a single timebase that is fine enough to
handle all supported DV framerates.
The seek tests change slightly because the new timebase is more
granular.
This was a bug/mistake in dae3679a9bfa421829ef9049ae2167089a2fdef7.
use_mfra_for by defintion only has an effect on fragmented MP4 files,
making the check not only redundant, but also broken if a user used
the option globally (i.e. set on non-fragmented MP4s).
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Also make duration check for mvhd more consistent with the others, write
version 1 of mvhd if duration is at least INT32_MAX instead of UINT32_MAX.
Signed-off-by: Marton Balint <cus@passwd.hu>
Commit 23eeffcd48a15e73fb2649b712870b6d101c5471 added a hack to support invalid
files where the creation date was encoded as a classic unix timestamp. Let's
reduce the scope of the hack by only applying it to version 0 mdhd/mvhd atoms.
Also warn the user of such possibly broken files.
Signed-off-by: Marton Balint <cus@passwd.hu>
When write multi-trun box, the MOV_TRUN_FIRST_SAMPLE_FLAGS flag
need judge by first param, not 0.
If the original video contains consecutive I frames,
this will cause the packets of fmp4 have error sample_flags ,
and then incorrect keyframes were generated,
and then error packet will be seeked.
Signed-off-by: Wang Yaqiang <wangyaqiang03@kuaishou.com>
Signed-off-by: Steven Liu <liuqi05@chinaffmpeg.org>
Changes the result of the h264_redundant_pps-mov test, where the output
timebase is now 1001/24000 instead of 1/24. This is more correct, as the
source file actually is 23.98fps.
Timestamps in two FATE H.264 conformance tests now start at 1 instead
of 0, which also happens in some other H.264 tests before this commit
and so is not a big issue.
Conversely, timestamps in some HEVC conformance tests start from a
smaller value now.
Ideally this should be addressed later in a more general way.
h264-conformance-frext-frext2_panasonic_b no longer requires -vsync
passthrough.
Partially reverts a change from 88de01d878167cbff9af32c0b7366e0aae3db2bd, and
2133cadfcf9a613cf2c0060f9896bba49dabfba4.
Signed-off-by: James Almer <jamrial@gmail.com>
