mbox series

[FFmpeg-devel,00/35] avdevice (mostly dshow) enhancements

Message ID 20210607230414.612-1-dcnieho@gmail.com
Headers show
Series avdevice (mostly dshow) enhancements | expand

Message

Diederick C. Niehorster June 7, 2021, 11:03 p.m. UTC 
This patch series implements a series of features, mostly enhancing the
dshow avdevice, but also adding new functionality to avformat and
avutil. This whole patchset enabled users of the FFmpeg API to fully
query and control a dshow device, making FFmpeg a nice backend for any
program that needs access to, e.g., a webcam.

[PATCH 29/35] avdevice/dshow: implement capabilities API
and
[PATCH 32/35] examples: adding device_get_capabilities example
have incorporated all of Andreas Rheinhardt's review comments.

Querying the capabilities of a dshow device is now also possible on a
device that is already opened. I expect/guess however that it may not be
possible to achieve that for all of the avdevices, so in principle it is
important that this patchset adds the ability to create an allocated but
unopened AVFormatContext+AVInputFormat with the new function
avformat_alloc_input_context().

Diederick Niehorster (35):
  avdevice/dshow: implement option to use device video timestamps
  avdevice/dshow: add use_video_device_timestamps to docs
  avdevice/dshow: query graph and sample time only once
  avdevice/dshow: handle unknown sample time
  avdevice/dshow: set no-seek flags
  avdevice/dshow: implement get_device_list
  avdevice/dshow: list_devices: show media type(s) per device
  avdevice: add info about media types(s) to AVDeviceInfo
  avdevice/dshow: add media type info to get_device_list
  fftools: provide media type info for devices
  avformat: add control_message function to AVInputFormat
  avdevice/dshow: implement control_message interface
  avdevice: adding control message requesting to show config dialog
  avdevice/dshow: accept show config dialog control message
  avdevice/dshow: tv_tuner_audio_dialog cleanup missing
  avdevice/dshow: add config dialog command for crossbar and tv tuner
  avdevice/dshow: discover source color range/space/etc
  avdevice/dshow: select format with extended color info
  avdevice/avdevice: Revert "Deprecate AVDevice Capabilities API"
  avdevice/avdevice: clean up avdevice_capabilities_create
  avdevice: capabilities API details no longer public
  avformat: avdevice capabilities API details no longer public
  avformat: cosmetics
  avutil/opt: AVOptionRange gains is_set field.
  avutil/opt: add av_opt_to_string
  avdevice: Add internal helpers for querying device capabilities
  avdevice/dshow: move audio format helpers
  avdevice/dshow: when closing, set context fields back to zero
  avdevice/dshow: implement capabilities API
  avdevice/dshow: cosmetics
  avformat: add avformat_alloc_input_context()
  examples: adding device_get_capabilities example
  Makefile/examples: cosmetics
  avdevice/dshow: prevent NULL access
  avdevice/dshow: capabilities query also works on opened device

 configure                              |    2 +
 doc/examples/.gitignore                |    1 +
 doc/examples/Makefile                  |   47 +-
 doc/examples/Makefile.example          |    1 +
 doc/examples/device_get_capabilities.c |  192 ++++
 doc/indevs.texi                        |    6 +
 fftools/cmdutils.c                     |   41 +-
 libavdevice/avdevice.c                 |   94 +-
 libavdevice/avdevice.h                 |   59 +-
 libavdevice/dshow.c                    | 1372 +++++++++++++++++++++---
 libavdevice/dshow_capture.h            |   12 +
 libavdevice/dshow_crossbar.c           |   95 +-
 libavdevice/dshow_pin.c                |   46 +-
 libavdevice/internal.h                 |   64 ++
 libavdevice/utils.c                    |   48 +
 libavdevice/version.h                  |    4 +-
 libavformat/avformat.h                 |   57 +-
 libavformat/utils.c                    |   66 +-
 libavformat/version.h                  |    4 +-
 libavutil/opt.c                        |   94 +-
 libavutil/opt.h                        |   17 +-
 libavutil/version.h                    |    2 +-
 22 files changed, 2021 insertions(+), 303 deletions(-)
 create mode 100644 doc/examples/device_get_capabilities.c

Comments

Valerii Zapodovnikov June 8, 2021, 12:13 a.m. UTC | #1 
Actually I do not know how well will this work. Did you ever play any
stream? Even if you play it without forcing seeking you are allowed to
search forth due to how latency works. That problem with latency was only
fixed in CMAF. ONE must to accelerate decoding forward in time to get low
latency.

Now hardware devices are different. But still, what about pause? What about
seeking in the end which was BTW broken: see in
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210604062818.2099-1-val.zapod.vz@gmail.com/

I mean, I agree this should be the default.
Diederick C. Niehorster June 8, 2021, 6:47 a.m. UTC | #2 
On Tue, Jun 8, 2021 at 2:13 AM Valerii Zapodovnikov <val.zapod.vz@gmail.com>
wrote:

> Actually I do not know how well will this work. Did you ever play any
> stream? Even if you play it without forcing seeking you are allowed to
> search forth due to how latency works. That problem with latency was only
> fixed in CMAF. ONE must to accelerate decoding forward in time to get low
> latency.
>
> Now hardware devices are different. But still, what about pause? What about
> seeking in the end which was BTW broken: see in
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210604062818.2099-1-val.zapod.vz@gmail.com/
>
> I mean, I agree this should be the default.
>

In its current state, dshow (and from a quick look) many other devices do
not support any seeking in either direction. So i think they should be
properly flagged as such, at least to get a meaningful error when
attempting to seek.

By the way, despite using git send-email to send the whole series at once,
it seems that they didn't end up in a nice thread (even though headers with
in-reply-to were correct), nor did patchworks pick up all the patches (it
missed 2/35 [and 5/35], so only attempted to build the first....). What
could be the issue here, should i throttle send-email somehow for instance?
Valerii Zapodovnikov June 8, 2021, 9:34 a.m. UTC | #3 
Just resend them (without any -v2).
Diederick C. Niehorster June 8, 2021, 10:52 a.m. UTC | #4 
didn't have the patchst anymore and already processed comments in later
patches, so 02/35 and 05/35 became out of 33. Noticed that too late. Hope
that doesn't confuse anything. Else we'll get it on -v2 of this series
(which there will certainly be), where i think i'll throttle sending a bit
(somehow).

On Tue, Jun 8, 2021 at 11:34 AM Valerii Zapodovnikov <val.zapod.vz@gmail.com>
wrote:

> Just resend them (without any -v2).
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>