Gstreamer V4l2 Codec elements for video encoders/decoders.

[Amit Pandya]

Hi,

Since Gstreamer-1.13.x gst-v4l2 codec(H263/H264/Mpeg4/VP8/VP9) elements for
video encode/decode are introduced with gst-plugins-good(sys/v4l2).
Where to find the details regarding on which all platforms above mentioned
gst-v4l2 encode/decode plugins are verified ? (at least while sources
acceptance)

Already part of gst-plugins-good, believe mentioned v4l2 encode elements
must have complied to specific acceptance criterion with respect to
functional verification on specific platforms.
Where can get the information regarding the testing/verification status?
(may be from the sources submitters)  

PS: Latest seems support recently announced for nxp's IMX.6 Application
Processors platforms
(https://twitter.com/ndufresne/status/1020315527393300481)

-Thanks
   



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mercredi 22 août 2018 à 10:27 -0500, Amit Pandya a écrit :
> Hi,
>
> Since Gstreamer-1.13.x gst-v4l2 codec(H263/H264/Mpeg4/VP8/VP9) elements for
> video encode/decode are introduced with gst-plugins-good(sys/v4l2).
> Where to find the details regarding on which all platforms above mentioned
> gst-v4l2 encode/decode plugins are verified ? (at least while sources
> acceptance)

All current implementation have little oops or rough edges, but
currently the most tested paltforms (non scientific) would be:

 - IMX.6/8 CODA driver
 - Qualcomn Venus driver (dynamic resolution is broken)
 - Exynos (some stability issue, which seems to be in IOMMU driver)

Other platforms may works, or may work with a minimal amount of code
changes. There is some upcoming work on Amlogic S905x too. We don't
maintain a list of supported hardware at this stage. The long term plan
will be to integrate these platform into some CI which will be
generating reports.

>
> Already part of gst-plugins-good, believe mentioned v4l2 encode elements
> must have complied to specific acceptance criterion with respect to
> functional verification on specific platforms.
> Where can get the information regarding the testing/verification status?
> (may be from the sources submitters)  

Best is to write a test plan for your needs and execute that on each
platform. You may ask specific question for specific cases and I may be
able to comment if this is supported or not.

>
> PS: Latest seems support recently announced for nxp's IMX.6 Application
> Processors platforms
> (https://twitter.com/ndufresne/status/1020315527393300481)

The code in GStreamer is fully generic, though my last round of testing
have all been done on a IMX.6 Sabre Lite. Some of the rough edges
specific to this board has been addressed in this cycle.

>
> -Thanks
>    
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Amit Pandya]

Hi Nicolas,

Thanks for the response.

Can you provide inputs if decode pipeline verified to be working with
Non-blocking (or Blocking) I/O with 'queue' in-place after decoder?
gst-v4l2 decode element ! queue ! gst-render element

Any issues encountered using queues in pipeline in your testing with various
streaming I/O modes in case.

If possible, can you provide gst-v4l2 decoders pipelines(gst-launch-1.0)
used in your verification test-plan just for the reference.

Also, any inputs/guidance regarding where can procure these development
platform (specifically Exynos) in case wish to have verified reference v4l2
model.
 - IMX.6/8 CODA driver
 - Qualcomn Venus driver (dynamic resolution is broken)
 - Exynos (some stability issue, which seems to be in IOMMU driver)

-Thanks



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le jeudi 30 août 2018 à 08:56 -0500, Amit Pandya a écrit :
> Hi Nicolas,
>
> Thanks for the response.
>
> Can you provide inputs if decode pipeline verified to be working with
> Non-blocking (or Blocking) I/O with 'queue' in-place after decoder?
> gst-v4l2 decode element ! queue ! gst-render element

The GStreamer CODEC implementation uses poll() in order to avoid
blocking operation in the kernel. Then input/output is seperated in the
elements using a thread. Using queues before or after the
encoder/decoder will introduce another thread, but won't increase the
allocation. It's a known limitation of the queues. There is another
limitation cause by the base class, which still need to be addressed.
It's not specific to V4L2, OMX decoders are also affected. You can
track it here:

https://bugzilla.gnome.org/show_bug.cgi?id=715192

>
> Any issues encountered using queues in pipeline in your testing with various
> streaming I/O modes in case.

mmap and dmabuf are the well supported one. For the importation path,
usrptr and dmabuf-import, there are not widely supported by CODEC
drivers. There is also some work ongoing to make the importation path
more robust.

>
> If possible, can you provide gst-v4l2 decoders pipelines(gst-launch-1.0)
> used in your verification test-plan just for the reference.

It's not yet fully integrated, but currently the focus has been put on
playback using playbin, and encoding using manual pipeline / RTSP,
e.g.:

  v4l2src ! v4l2h264enc ! h264parse ! rtph264pay name=pay0

>
> Also, any inputs/guidance regarding where can procure these development
> platform (specifically Exynos) in case wish to have verified reference v4l2
> model.
>  - IMX.6/8 CODA driver

I use devices from Boundary Device:
https://boundarydevices.com/

>  - Qualcomn Venus driver (dynamic resolution is broken)

For that I use DragonBoards, from 96boards:

https://www.96boards.org/product/dragonboard410c/
https://www.96boards.org/product/dragonboard820c/

>  - Exynos (some stability issue, which seems to be in IOMMU driver)

For exynos, I use Hardkernel board Odroid XU4:
https://www.hardkernel.com/main/products/prdt_info.php

For all of my boards, I use a ARM or AARCH64 Fedora 28 base system,
combined with a manually built Linux Kernel, and if needed u-boot. The
DragonBoard are setup so that the Android booloader (LK) will start u-
boot, but UEFI isn't enabled in my setup.

regards,
Nicolas
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-deve

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Amit Pandya]

Hi Nicolas,

Do DRC (Dynamic Resolution Change) verified to be supported using gst-v4l2
decoder plugins on any of the supported platforms?

If the input stream contains two concatenated SPS/PPS sequence, does the
gst-v4l2 decoder handle newstreamformat event by doing all the
STREAM-OFF/REQBUF(0)/G_FMT/REQBUF(x)/STREAM-ON sequence ?

-Regards
Amit Pandya



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mardi 09 avril 2019 à 01:30 -0500, Amit Pandya a écrit :
> Hi Nicolas,
>
> Do DRC (Dynamic Resolution Change) verified to be supported using gst-v4l2
> decoder plugins on any of the supported platforms?

Never seen such an acronyme, makes things looks less organic. Yes,
resolution changes work on some platform (notably IMX.6 CODA), but very
few of them. The implementation is not optimal, it consist of a full
decoder reset. With the new specification being worked on, and the
validation test that will come with it, we should start having proper
support for the new, and more optimal mechanism (SOURCE_CHANGE events).
There is patches attached on an issue (yes some people don't yet
understand merge request) that implements SOURCE_CHANGE event handling,
and the implementation seems to be in the right direction.

https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/587

>
> If the input stream contains two concatenated SPS/PPS sequence, does the
> gst-v4l2 decoder handle newstreamformat event by doing all the
> STREAM-OFF/REQBUF(0)/G_FMT/REQBUF(x)/STREAM-ON sequence ?

You'll need h264parse in front of your decoder for the current
implementation to work with pre-announced SPS/PPS. The h264parse
element should detect SPS/PPS activation and update the caps
accordingly. The SOURCE_CHANGE event would not depend on this directly,
since it's the decoder that triggers this event on SPS/PPS activation,
and it will only do that is needed. Note that none of the driver have
implemented support for reusing larger buffers for smaller resolution
yet, but it's a well known technique that will likely happen in the
future (or could be contributed of course).

All this is in the expert hands of the kernel maintainers.

>
> -Regards
> Amit Pandya
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Amit Pandya]

Hi Nicolas,

1) As per earlier communication on this thread you informed that all current
implementation of gst-v4l2 decode/encode have little oops or rough edges,
but currently the most tested paltforms (non scientific) would be:
 - IMX.6/8 CODA driver
 - Qualcomn Venus driver (dynamic resolution is broken)
 - Exynos (some stability issue, which seems to be in IOMMU driver)
 
Do gst-v4l2 decode/encode implementation now been verified on any other hw
platforms(specifically for 64-bit) other than the listed above?


2) Do reverse playback seek is supported with gst-v4l2 decoders and ever
verified on any of the supported hw platforms.

NOTE: We tried to check reverse playback with gst-v4l2 decoder on Exynos but
found not working.    

If currently reverse playback is not supported with gst-v4l2 decoders then
let us know if you have any plans to support it with gst-v4l2 decoders?

-Thanks  



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel