summaryrefslogtreecommitdiff
path: root/fftools
Commit message (Collapse)AuthorAge
* fftools/ffprobe: Report initial and trailing paddingAndreas Rheinhardt2022-09-05
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fftools/ffmpeg_opt: Check creation of new programAndreas Rheinhardt2022-09-01
| | | | | | Fixes Coverity issue #1512413. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fftools: Use report_error_then_exit_program() for allocation failuresAndreas Rheinhardt2022-09-01
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fftools/cmdutils: Add function to report error before exitAndreas Rheinhardt2022-09-01
| | | | | | | | | | | | This is designed to improve and unify error handling for allocation failures for the many (often small) allocations that we have in the fftools. These typically either don't return an error message or an error message that is not really helpful to the user and can be replaced by a generic error message without loss of information. Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fftools/ffmpeg: use a separate counter for encoded packet data sizeAnton Khirnov2022-08-29
| | | | | | | | | | | | | | | | | update_video_stats() currently uses OutputStream.data_size to print the total size of the encoded stream so far and the average bitrate. However, that field is updated in the muxer thread, right before the packet is sent to the muxer. Not only is this racy, but the numbers may not match even if muxing was in the main thread due to bitstream filters, filesize limiting, etc. Introduce a new counter, data_size_enc, for total size of the packets received from the encoder and use that in update_video_stats(). Rename data_size to data_size_mux to indicate its semantics more clearly. No synchronization is needed for data_size_mux, because it is only read in the main thread in print_final_stats(), which runs after the muxer threads are terminated.
* fftools/ffmpeg: drop OutputStream.fps_modeAnton Khirnov2022-08-29
| | | | | It is only used within new_video_stream(), so make it a local variable there.
* fftools/ffmpeg: drop OutputStream.encAnton Khirnov2022-08-29
| | | | | | It is either equal to OutputStream.enc_ctx->codec, or NULL when enc_ctx is NULL. Replace the use of enc with enc_ctx->codec, or the equivalent enc_ctx->codec_* fields where more convenient.
* fftools/ffmpeg_filter: remove an always-true checkAnton Khirnov2022-08-29
| | | | | | | ost->enc is always non-NULL here, since - this code is never called for streamcopy - opening the output file will fail if an encoder cannot be found, so filters are never initialized
* fftools/ffmpeg_filter: remove an always-false checkAnton Khirnov2022-08-29
| | | | | | This code cannot be triggered, since after 90944ee3ab7 opening the output file will abort if an encoder cannot be found and streamcopy was not explicitly requested.
* fftools/ffmpeg: remove a stale extern declarationAnton Khirnov2022-08-29
| | | | Forgotten in 8cbf229c941b3c77a756bff05d0ceb5f4f2219c5
* fftools/ffmpeg: stop accessing av_stream_get_parser() from the main threadAnton Khirnov2022-08-29
| | | | | | | | | | | | | | | It races with the demuxing thread. Instead, send the information along with the demuxed packets. Ideally, the code should stop using the stream-internal parsing completely, but that requires considerably more effort. Fixes races, e.g. in: - fate-h264-brokensps-2580 - fate-h264-extradata-reload - fate-iv8-demux - fate-m4v-cfr - fate-m4v
* fftools/ffmpeg_opt: try to propagate the requested output channel layoutJames Almer2022-08-23
| | | | | | | | | Don't silently replace it with the default layout for the amount of channels from the requested layout. Should fix ticket #9869 Signed-off-by: James Almer <jamrial@gmail.com>
* fftools/ffmpeg: call av_guess_frame_rate() when opening the fileAnton Khirnov2022-08-22
| | | | | It is currently called when configuring the filter, which races with the demuxer thread.
* ffprobe: restore reporting error code for failed inputsGyan Doshi2022-08-17
| | | | | | c11fb46731 led to a regression whereby the return code for missing input or input probe is overridden by writer close return code and hence not conveyed in the exit code.
* fftools/ffmpeg: store a separate copy of input codec parametersAnton Khirnov2022-08-16
| | | | | | | | | | | Use it instead of AVStream.codecpar in the main thread. While AVStream.codecpar is documented to only be updated when the stream is added or avformat_find_stream_info(), it is actually updated during demuxing. Accessing it from a different thread then constitutes a race. Ideally, some mechanism should eventually be provided for signalling parameter updates to the user. Then the demuxing thread could pick up the changes and propagate them to the decoder.
* fftools: add DPI awareness manifestTimo Rothenpieler2022-08-13
| | | | | Some filters, like gdigrab, rely on this to be set to see and report proper dimensions.
* fftools/ffmpeg: move packet timestamp processing to demuxer threadAnton Khirnov2022-08-13
| | | | | | | | | Discontinuity detection/correction is left in the main thread, as it is entangled with InputStream.next_dts and related variables, which may be set by decoding code. Fixes races e.g. in fate-ffmpeg-streamloop after aae9de0cb2887e6e0bbfda6ffdf85ab77d3390f0.
* fftools/ffmpeg: use a separate variable for discontinuity offsetAnton Khirnov2022-08-13
| | | | | | This will allow to move normal offset handling to demuxer thread, since discontinuities currently have to be processed in the main thread, as the code uses some decoder-produced values.
* fftools/ffmpeg: simplify conditions in ts_discontinuity_processAnton Khirnov2022-08-13
|
* fftools/ffmpeg: move inter-stream ts discontinuity handling to ↵Anton Khirnov2022-08-13
| | | | ts_discontinuity_process()
* fftools/ffmpeg: move timestamp discontinuity correction out of process_input()Anton Khirnov2022-08-13
|
* fftools/ffmpeg: pre-compute the streamcopy start pts before transcoding startsAnton Khirnov2022-08-13
| | | | | | | InputFile.ts_offset can change during transcoding, due to discontinuity correction. This should not affect the streamcopy starting timestamp. Cf. bf2590aed3e64d44a5e2430fdbe89f91f5e55bfe
* fftools/ffmpeg: move stream-dependent starttime correction to transcode_init()Anton Khirnov2022-08-13
| | | | | Currently this code is located in the discontinuity handling block, where it does not belong.
* fftools/ffmpeg_mux: avoid leaking pkt on errorsAnton Khirnov2022-08-13
|
* fftools/ffmpeg: mark all encode sync queues as done before flushing encodersAnton Khirnov2022-08-13
|
* fftools/ffmpeg: move handling corrupt packets to the input threadAnton Khirnov2022-08-08
|
* fftools/ffmpeg_demux: do not store demux packet in the contextAnton Khirnov2022-08-08
| | | | Its use is local to input_thread().
* fftools/ffmpeg_demux: factorize signalling end of demuxingAnton Khirnov2022-08-08
|
* fftools/ffmpeg: move -stream_loop handling to the demuxer threadAnton Khirnov2022-08-08
| | | | | | | | | | | | | -stream_loop is currently handled by destroying the demuxer thread, seeking, then recreating it anew. This is very messy and conflicts with the future goal of moving each major ffmpeg component into its own thread. Handle -stream_loop directly in the demuxer thread. Looping requires the demuxer to know the duration of the file, which takes into account the duration of the last decoded audio frame (if any). Use a thread message queue to communicate this information from the main thread to the demuxer thread.
* fftools/ffmpeg: move seek_to_start() to ffmpeg_demux.cAnton Khirnov2022-08-08
| | | | Reduces the diff in the following commit.
* fftools/ffmpeg: move get_input_packet() to ffmpeg_demux.cAnton Khirnov2022-08-08
| | | | Also rename it to use the ifile_* namespace.
* fftools/ffmpeg: report new streams from the input threadAnton Khirnov2022-08-08
| | | | | | This avoids a potential race with the demuxer adding new streams. It is also more efficient, since we no longer do inter-thread transfers of packets that will be just discarded.
* fftools/ffmpeg: handle dumping input packets in input_thread()Anton Khirnov2022-08-08
| | | | This is a more appropriate place for this.
* fftools/ffmpeg: drop the 'h' key handlingAnton Khirnov2022-08-08
| | | | | | | | | This undocumented feature runtime-enables dumping input packets. I can think of no reasonable real-world use case that cannot also be accomplished in a different way. Keeping this functionality would interfere with the following commit moving it to the input thread (then setting the variable would require locking or atomics, which would be unnecessarily complicated for a feature that probably nobody uses).
* fftools/ffmpeg: move the input thread into its own fileAnton Khirnov2022-08-08
| | | | It will contain more demuxing-specific code in the future.
* fftools/ffmpeg: drop a write-only variableAnton Khirnov2022-08-08
|
* fftools/ffmpeg: always read input in a threadAnton Khirnov2022-08-08
| | | | This will be required by the following architecture changes.
* fftools/ffmpeg: store the input file index in InputFileAnton Khirnov2022-08-08
| | | | | | Use it to simplify some code and fix two off-by-one errors. Similar to what was previously done for OutputFile.
* fftools/ffmpeg: drop a superfluous stack variableAnton Khirnov2022-08-08
|
* fftools/ffmpeg: deprecate specifying a sync stream with -mapAnton Khirnov2022-08-08
| | | | It has not had any effect whatsoever for over 10 years.
* fftools/ffmpeg: remove OutputStream.sync_istAnton Khirnov2022-08-08
| | | | It is not actually used for anything.
* fftools/ffmpeg: remove OutputStream.encoding_neededAnton Khirnov2022-08-08
| | | | It is unnecessary, as it is always exactly equivalent to !!ost->enc_ctx
* fftools/ffmpeg: remove OutputStream.stream_copyAnton Khirnov2022-08-08
| | | | | | | | | | | | | | | There are currently three possible modes for an output stream: 1) The stream is produced by encoding output from some filtergraph. This is true when ost->enc_ctx != NULL, or equivalently when ost->encoding_needed != 0. 2) The stream is produced by copying some input stream's packets. This is true when ost->enc_ctx == NULL && ost->source_index >= 0. 3) The stream is produced by attaching some file directly. This is true when ost->enc_ctx == NULL && ost->source_index < 0. OutputStream.stream_copy is currently used to identify case 2), and sometimes to confusingly (or even incorrectly) identify case 1). Remove it, replacing its usage with checking enc_ctx/source_index values.
* fftools/ffmpeg_opt: drop redundant decoder selectionAnton Khirnov2022-08-08
| | | | A decoder is already selected above, in choose_decoder().
* fftools/ffmpeg: stop accessing the decoder context unnecessarilyAnton Khirnov2022-08-08
| | | | | | The same information is available from AVStream.codecpar. This will allow to stop allocating a decoder unless decoding is actually performed.
* fftools/ffmpeg_hw: stop logging to the decoder contextAnton Khirnov2022-08-08
| | | | | Only the decoder itself should do that. Use NULL as is done by all other logging code in ffmpeg.
* fftools/ffmpeg_opt: move adding metadata out of open_output_file()Anton Khirnov2022-08-08
|
* fftools/ffmpeg_opt: move adding programs out of open_output_file()Anton Khirnov2022-08-08
|
* fftools/ffmpeg_opt: move adding attachments out of open_output_file()Anton Khirnov2022-08-08
|
* ffmpeg_opt: consider HW acceleration method when selecting decoderHaihao Xiang2022-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Usually a HW decoder is expected when user specifies a HW acceleration method via -hwaccel option, however the current implementation doesn't take HW acceleration method into account, it is possible to select a SW decoder. For example: $ ffmpeg -hwaccel vaapi -i av1.mp4 -f null - $ ffmpeg -hwaccel nvdec -i av1.mp4 -f null - $ ffmpeg -hwaccel vdpau -i av1.mp4 -f null - [...] Stream #0:0 -> #0:0 (av1 (libdav1d) -> wrapped_avframe (native)) libdav1d is selected in this case even if vaapi, nvdec or vdpau is specified. After applying this patch, the native av1 decoder (with vaapi, nvdec or vdpau support) is selected for decoding(libdav1d is still used for probing format). $ ffmpeg -hwaccel vaapi -i av1.mp4 -f null - $ ffmpeg -hwaccel nvdec -i av1.mp4 -f null - $ ffmpeg -hwaccel vdpau -i av1.mp4 -f null - [...] Stream #0:0 -> #0:0 (av1 (native) -> wrapped_avframe (native)) Tested-by: Mario Roy <marioeroy@gmail.com> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com> Signed-off-by: Anton Khirnov <anton@khirnov.net>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-22 16:45:15 +0000