Thanks to Mathieu Malaterre <malat@debian.org> for reporting the
Que/Queue typo. (https://bugs.debian.org/839542)
Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
* commit '398f015f077c6a2406deffd9e37ff34b9c7bb3bc':
avconv: buffer the packets written while the muxer is not initialized
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '1c169782cae6c5c430ff62e7d7272dc9d0e8d527':
avconv: explicitly postpone writing the header until all streams are initialized
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Decoders have previously not used AVFrame.pts, and with the upcoming
deprecation of pkt_pts (in favor of pts), this would lead to an errorneous
interpration of timestamps.
This is a bit messy, mainly due to timestamp handling.
decode_video() relied on the fact that it could set dts on a flush/drain
packet. This is not possible with the old API, and won't be. (I think
doing this was very questionable with the old API. Flush packets should
not contain any information; they just cause a FIFO to be emptied.) This
is replaced with checking the best_effort_timestamp for AV_NOPTS_VALUE,
and using the suggested DTS in the drain case.
The modified tests (fate-cavs and others) still fails due to dropping
the last frame. This happens because the timestamp of the last frame
goes backwards (ffprobe -show_frames shows the same thing). I suspect
that this "worked" due to the best effort timestamp logic picking the
DTS over the decreasing PTS. Since this logic is in libavcodec (where
it probably shouldn't be), this can't be easily fixed. The timestamps
of the cavs samples are weird anyway, so I chose not to fix it.
Another strange thing is the timestamp handling in the video path of
process_input_packet (after the decode_video() call). It looks like
the code to increase next_dts and next_pts should be run every time
a frame is decoded - but it's needed even if output is skipped.
With the new decode API, doing this in ffmpeg.c is impractical. There
was resistance against removing the warning, so put it into libavcodec.
Not bothering with reducing the warning to verbose log level for
subsequent wanrings. The warning should be rare, and only happen when
developing new codecs for the old API.
Includes a change suggested by Michael Niedermayer.
This commit is based on commit 35c8580 from Anton Khirnov <anton@khirnov.net>
which was skipped in b8945c4.
The avcodec_copy_context() call in the encode path is left in place for now
as AVStream.codec is apparently still required even after porting ffmpeg to
the new bsf API.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This commit is initially largely based on commit 4426540 from Anton
Khirnov <anton@khirnov.net> and two following fixes (80fb19b and
fe7b21c) which were previously skipped respectively in 98e3153, c9ee36e,
and 7fe7cdc.
mpeg4-bsf-unpack-bframes FATE reference is updated because the bsf
filter now actually fixes the extradata (mpeg4_unpack_bframes_init()
changing one byte is now honored on the output extradata).
The FATE references for remove_extra change because the packet flags
were wrong and the keyframes weren't marked, causing the bsf relying on
these proprieties to not actually work as intended.
The following was fixed by James Almer:
The filter option arguments are now also parsed correctly.
A hack to propagate extradata changed by bitstream filters after the
first av_bsf_receive_packet() call is added to maintain the current
behavior. This was previously done by av_bitstream_filter_filter() and
is needed for the aac_adtstoasc bsf.
The exit_on_error was not being checked anymore, and led to an exit
error in the last frame of h264_mp4toannexb test. Restoring this
behaviour prevents erroring out. The test is still changed as a result
due to the badly filtered frame now not being written after the failure.
Signed-off-by: Clément Bœsch <u@pkh.me>
Signed-off-by: James Almer <jamrial@gmail.com>
This commit is largely based on commit 15e84ed3 from Anton Khirnov
<anton@khirnov.net> which was previously skipped in bbf5ef9d.
There are still a bunch of things raising codecpar related warnings that
need fixing, such as:
- the use of codec->debug in the interactive debug mode
- read_ffserver_streams(): it's probably broken now but there is no test
- lowres stuff
- codec copy apparently required by bitstream filters
The matroska references are updated because they now properly forward
the field_order (previously unknown, now progressive).
Thanks to James Almer for fixing a bunch of FATE issues in this commit.
Signed-off-by: Clément Bœsch <clement@stupeflix.com>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '5e1840622ce6e41c57d9c407604863d3f3dcc3ae':
avconv: fix handling attachments in init_output_stream
Conflicts:
avconv.c
This is functionally a no-op, as we don't have the bug this is trying to
fix. See 843be56ee1.
Merged-by: Timothy Gu <timothygu99@gmail.com>
* commit '49670e4218d34899a1c37abb7a11615efc16f757':
avconv: add a function for determining whether a filtergraph is simple
Conflicts:
avconv.c
Merged-by: Timothy Gu <timothygu99@gmail.com>
Avoids unexpected occurance and dependency on NaN behavior and divisions by 0
Testcase: fate-lavf-fate-avi_cram
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I have no idea why the first hunk uses ost->enc_ctx, because as far as
I understand, that is never used in case of -c:v copy, but this code
block is only entered if encoding_needed=0, which means stream_copy=1.
My point being: review from someone that knows this really well would
be appreciated.
* commit 'c15f6098b1b25689dd5e86aeb5ce69bc12efe1e1':
avconv: pass the hw context from filters to the encoder
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Codec options of streams detected during avformat_find_stream_info are not set
therefore without this patch we initialize the encoders with decoder info
based on decoders without options.
This cause problems for probed DVB teletext streams where
avctx->subtitle_header depend on the txt_format setting.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
In the spirit of commit a956840cbc. Simple method to reproduce:
pass -vstats_file /dev/full to ffmpeg.
All raw fclose usages in ffmpeg.c taken care of here.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
avio_closep is not guaranteed to succeed, and its return value can
contain information regarding failure of preceding writes and silent
loss of data (man 2 close, man fclose). Users should know when the
progress was not successfully logged, and so a diagnostic is printed
here.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
* commit 'e63e3797a1ed9346f529848e6ba3d27fd2d2cc8d':
avconv: pass the global codec side data to the muxer
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This adds a computation of the progress speed versus realtime ("Nx")
to the status line and to the report log. It uses the progress time
as already calculated for total output time as a base.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-hex and -dump command line options do nothing unless -loglevel debug is set.
-dump by itself is useful for monitoring live streams (to get the current PTS for example) however when it is used with -loglevel debug for an RTMP stream, librtmp also dumps the packet data which makes the output too noisy.
do_pkt_dump is only set in check_keyboard_interaction or by the -dump command line option so this change should have no effect on any other parts of the code..
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Using -ss as an input option shifts timestamps down by the seek, so it
doesn't have to be added to the recording time when checking whether to
stop.
Fixes#977
Signed-off-by: Simon Thelen <ffmpeg-dev@c-14.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Small refactor of fps code for improved readability. In particular
the "cor" variable was unnecessary and misleading because it would
always be set to -delta0.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I didnt find any case that triggers this but if it gets triggered it needs to be
investigated
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
a set ost->frame_rate does not imply CFR in ffmpeg
The changed fate tests had all wrong packet durations
(like 1/1000 or 1/90000)
There might be more cases in which is_cfr could be set
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '3efd71b4d0b4a73ccbbbdc092e6bbd54d92633f4':
avconv: set packet duration for CFR video streams
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Fixes a segfault when trying to write nonexistent rtp information.
Signed-off-by: Simon Thelen <ffmpeg-dev@c-14.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
FFDIFFSIGN was created explicitly for this purpose, since the common
return a - b idiom is unsafe regarding overflow on signed integers. It
optimizes to branchless code on common compilers.
FFDIFFSIGN also has the subjective benefit of being easier to read due
to lack of ternary operators.
Tested with FATE.
Things not covered by this are unsigned integers, for which overflows
are well defined, and also places where overflow is clearly impossible,
e.g an instance where the a - b was being done on 24 bit values.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This is more concise and conveys the intent better.
Furthermore, it is likely more precise as well due to lack of floating
point division.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
* commit 'cd0e08813a0484002b5defbf557c859f123953ae':
avconv: support infinite loop for the loop option
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'fb472e1a11a4e0caed2c3c91da01ea8e35d9e3f8':
avconv: add support for Intel QSV-accelerated transcoding
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
On lines 1633,1634 FFABS(pts) is performed. However, if av_stream_get_end_pts
returns AV_NOPTS_VALUE always, pts remains stuck at INT64_MIN, leading
to undefined behavior on FFABS.
One could conceive of a solution using FFNABS. However, such a solution
has to deal with the implementation defined rounding of integer division
with at least one negative operand in ANSI C89. C99 forces truncation to
zero, but I am not sure that all of our platforms compile with full C99
support, and in particular whether we can safely assume a fixed
rounding behavior across all platforms.
This solution is simple, and I doubt changing INT64_MIN to INT64_MIN + 1
has any practical loss - if it is stuck at its initial value, the stream
is messed up anyway.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
stream copy always has a input stream, it cannot use complex video/audio filters with unambigous input
Fixes CID1322348
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This prevents breaking existing command lines in case the "ab" default is removed from libavcodec
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The null muxer has AVFMT_RAWPICTURE set but can be fed with non-raw material
related to Ticket4778
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
