the list_devices option of dshow didn't indicate whether a specific
device provides audio or video output. This patch iterates through all
media formats of all pins exposed by the device to see what types it
provides for capture, and prints this to the console for each device.
Importantly, this now allows to find devices that provide both audio and
video, and devices that provide neither.
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
avdevice/dshow is a realtime device and as such does not support
seeking. Therefore, its demuxer format should define the
AVFMT_NOBINSEARCH, AVFMT_NOGENSEARCH and AVFMT_NO_BYTE_SEEK flags.
With these flags set, attempting to seek (with, e.g.,
avformat_seek_file()) correctly yields -1 (operation not permitted)
instead of -22 (invalid argument).
This actually seems to apply to many other devices, at least the
gdigrab, v4l2, vfwcap, x11grab, fbdev, kmsgrab and android_camera
devices, from reading the source.
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
GetTime may return an error indication that the sample has not
timestamps, or may return a NULL start time. In those cases, fall back
to graph time. Emit log when that happens.
Improve logging in the frame receive function: now logged against
correct avclass instead of NULL.
Better debug message in case sample dropped: could now be audio or
video frame.
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
No need to query twice, use value we've already unconditionally got.
Improve variable names
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
The dshow avdevice ignores timestamps for video frames provided by the
DirectShow device, instead using wallclock time, apparently because the
implementer of this code had a device that provided unreliable
timestamps. Me (and others) would like to use the device's timestamps.
The new use_video_device_timestamps option for dshow device enables them
to do so. Since the majority of video devices out there probably provide
fine timestamps, this patch sets the default to using the device
timestamps, which means best fidelity timestamps are used by default.
Using the new option, the user can switch this off and revert to the old
behavior, so a fall back remains available in case the device provides
broken timestamps.
add use_video_device_timestamps to docs.
Closes: #8620
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
list_options true would crash when both a video and an audio device were
specified as input. Crash would occur on line 784 because
ctx->device_unique_name[otherDevType] would be NULL
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
The earlier code did not account for the fact that
av_display_rotation_set() wants the angle in the anticlockwise
direction (despite what its documentation stated for a long time);
furthermore, the H.2645 spec wants the flips applied first,
whereas our code did it the other way around. This can be fixed
by negating the angle once for every flip.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The transpose filter has modes equivalent to "rotation by 90°/270°"
followed by horizontal flips.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In case of an orthogonal transformation av_display_rotation_get()
returns the (anticlockwise) degree that the unit vector in x-direction
gets rotated by; get_rotation in cmdutils.c makes a clockwise degree
out of this. So if one inserts a transpose filter corresponding to
this degree, then the x-vector gets mapped correctly and there are
two possibilities for image of the y-vector, namely the two unit
vectors orthogonal to the image of the x-vector.
E.g. if the x-vector gets rotated by 90° clockwise, then the two
possibilities for the y-vector are the unit vector in x direction
or its opposite. The latter case is a simple 90° rotation for both
vectors* whereas the former is a simple 90° clockwise rotation followed
by a horizontal flip. These two cases can be distinguished by looking
at the x-coordinate of the image of the y-vector, i.e. by looking
at displaymatrix[3]. Similarly for the case of a 270° clockwise
rotation.
These two cases were previously wrong (they were made to match
wrongly parsed exif rotation tag values).
*: For display matrices, the y-axis points downward.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The cases in which there was flipping together with a rotation
that is not a multiple of the identity were wrong.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
sets coded_width / coded_height too to keep them consistent with
width / height
Fixes: OOM
Fixes: 42263/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5653333619113984
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix#7830
When we upload a frame that is not padded as MSDK requires, we create a
new AVFrame to copy data. The frame's padding data is uninitialized so
it brings run to run problem. For example, If we run the following
command serveral times we will get different outputs.
ffmpeg -init_hw_device qsv=qsv:hw -qsv_device /dev/dri/renderD128 \
-filter_hw_device qsv -f rawvideo -s 192x200 -pix_fmt p010 \
-i 192x200_P010.yuv -vf "format=nv12,hwupload=extra_hw_frames=16" \
-c:v hevc_qsv output.265
According to https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#encoding-procedures
"Note: It is the application's responsibility to fill pixels outside
of crop window when it is smaller than frame to be encoded. Especially
in cases when crops are not aligned to minimum coding block size (16
for AVC, 8 for HEVC and VP9)"
I add a function to fill padding area with border pixel to fix this
run2run problem, and also move the new AVFrame to global structure
to reduce redundant allocation operation to increase preformance.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
It is more clear and easily to detect the issues similar to commit
3857ecbe70
Signed-off-by: Zhong Li <zhongli_dev@126.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
- Ensure the yadif .metal compiles when targeting any Metal runtime version
- Use some preprocessor awkwardness to ensure Core Video's Metal-specific
functionality is exposed regardless of our deployment target (this works
around what seems to be an SDK header bug, filed as FB9816002)
- Ensure all direct references to Metal functions and classes are gated
behind runtime version checks (this satisfies clang's deployment-target
violation warnings provided by -Wunguarded-availability).
Apparently Metal.framework is included with the command line tools
(and thus may be present without Xcode), but the Metal compiler is only
included as part of Xcode.
On some encoders, this defaults to true, which can result in encode speed
being _limited_ to only slightly above realtime (as a power-saving measure),
so we need a way to disable it.
VideoToolbox internally sets all the colorspace parameters to BT709,
regardless of what the bitstream actually indicates, so we need to
replace that with what we've parsed.
