This patch is currently incomplete. In fixing the colour format for the H.264
encoder, the patch effectively prevents the MPEG4 encoder from supporting 422
This should be a more complete patch. There are now 2 stages in generating the
params for passing to the Venc1_create call. Firstly, the colorspace from the
caps is translated into XDM format and then any device/codec specific 'fixes'
are applied to the input and reconstruction chroma formats.
This means that alternative colorspace formats can be passed to encoders that
support them. Tested with h.264 (NV12) and mpeg4 (NV12 / UYVY).
This patch covers 2 elements:
In order to support yuv420sp output colour format for H.264 encoder, the resizer
device is chained with the capture device. This enforces 32 byte alignment, so
some output buffers will have a pitch larger than pixel width (i.e. 736 bytes
for 720 pixel images). Internal caps are adjusted for DM365 to compensate for
this, however negotiated caps stay the same (width=720).
This may be considered a bit hacky, but to allow for larger buffer pitch the
encoder checks the upstream buffer size and compares it to the expected buffer
size (only for yuv720sp format). If the upstream buffer size is larger, it
assumes padding and uses the circular buffer framecopy to remove the padding
bytes. This is only supported with contiguous input frames.
Note this patch also contains changes from the trunk made by tracker patches
#858, #867 and #871 from Brijesh Singh.
Thanks a bunch on getting video encoder support in action, some comments:
1) v4l2src changes looks okay to me, but i would suggest you creating separate
file (may dm365_resizer.c) and put all your resizer
gst_v4l2_setresize_continuous(), gst_v4l2_setpreview_continuous() functions in
that file. This will help rebasing when we are move to new version of
gst-plugin-good. And gives a clear picture to driver team on what changes they
need to make in driver to avoid all these hacks in v4l2src. We can't afford
patching these good known open-source tool to mitigate driver bug, they need to
fix it or provide much nicer interface.
2) Please add #if defined (DAVINCI_LSP_WORKAROUND) &&
defined(Platform_dm365) to your each function. This helps me keeping track on
how we are doing on GIT kernel. We need to make sure that all these workarounds
are addressed in upstream kernel. Just like above, don't want to carry the
3) I'm very familiar with DM365 encoder and trying to understand why we are
modifying circular buffer? Could you please explain what exactly you are trying
to do ?
4) You are using my old patch, please rebase your patch with newer one from
tracker. The old patch has a bug and i've fixed and update it.
oops 3) I meant to say i'm not very familiar ;(
No problem, appreciate the feedback. Agree with comments, should help to tidy
things up a bit.
As far as the circular buffer goes, this relates to the problem of receiving a
yuv420sp buffer from the upstream that may contain padding bytes (i.e. 736 wide
buffer for 720 pixel wide image). So, seeing as the encoder already makes use of
a framecopy (from within the circular buffer) it seemed sensible to use that to
remove the padding bytes. But this means I had to modify the circular buffer
code to allow the upstream buffer pitch to be specified.
Another option here would be to use the encoder features to remove the padding.
I experimented with this on the H.264 encoder (using captureWidth), but this
won't work on the MPEG4 encoder, so sub-windows would need to be used on that.
As there wasn't a consistent approach with the encoders I decided to use the
framecopy technique instead.
What do you think?
Anyway, I'll get another patch together with your other comments.
Note that framecopy is used in circular buffer only when you configure
"continguousInputFrame=TRUE" property (i.e v4l2src is also set
with always_copy=FALSE). If possible then we should try to find some other
alternative. Can you check how DVSDK DM365 encode demo handles these case? Not
sure if we need to force to use framecopy all the time?
Updated patch based on comments from Brijesh Singh (including rebase against
timestamp tracker patch), pending thoughts on best way to remove padding from
upstream capture buffer.
i've cleaned v4l2src patch  a bit to align with build system and makefile
changes. See if im not breaking anything here. Could u pls try this at your end
with TIDmaiVideoSink, something like
gst-launch v4l2src ! 'video/x-raw-yuv,format=(fourcc)NV12' ! TIDmaiVideoSink
P.S: i've tested only compilation and looks like its compiling okay.
Sorry I haven't got back to you before. That patch is great, combined with the
patch from tracker #871. Having said that, of course it only works properly in
NV12 format when combined with changes to the next step in the pipeline.
In terms of TIDmaiVideoSink, not quite right yet. In NV12 format, the output is
garbled in much the same way as I saw with the encoder, before the encoder
changes were made (i.e. not taking account of the 16 byte padding per line).
Interestingly though, in UYVY, it quits out complaining that 'Failed to
configure framecopy'. Also, it suggests the bytesperline in UYVY is 736, which
is incorrect if it refers to the upstream buffer.
Something strange going on here. I'm involved with some other work at the moment
but I'll try and take a look at it.
Had a chance to look at the problems with TIDmaiVideoSink. It needed a couple of
things sorting out to work with other updates.
1. The display format was fixed to NV12 if DM365, so it couldn't sink a UYVY
buffer as the framecopy quits out. I fixed this by allowing the display buffer
to be initialised with the same colour format as the input buffer.
2. As per TIVidenc1, when sinking a NV12 buffer on the DM365 the code needs to
check for upstream buffer alignment.
I've checked the changes with UYVY and NV12, from both videotestsrc and v4l2src
and things seem ok, patch attached [diff-trunk-gsttidmaivideosink.patch].
I have to admit, at the moment I'm having second thoughts on using the resizer
chained in with capture. It may well cause too many restrictions down the line,
like not being able to use the resizer in single-shot mode, which I guess means
no resizing? Anyway, just more to think about! :-)
Closing tracker. Encoder support in already in trunk.
|trackertype||To do||New feature