I used a small GStreamer application to play MPEG2 video elementary streams. The
application is using the following elements and properties:
filesrc location=
TIViddec2 engineName=&quot;decode&quot;
codecName=&quot;mpeg2dec&quot; frameRate=30
TIDmaiVideoSink displayDevice=/dev/video2 displayStd=v4l2

Playing a single file and exiting the player afterwards is working fine.

But when I
- open the player application and init the pipeline
- play movie A
gst_element_set_state (pipeline, GST_STATE_NULL);
g_object_set (G_OBJECT (source), &quot;location&quot;, MOVIE_A,
NULL);
gst_element_set_state (pipeline, GST_STATE_PLAYING);
- at EOS of movie A
gst_element_set_state (pipeline, GST_STATE_NULL);
is called and
g_main_loop_quit (loop);
is NOT called
- play movie B
gst_element_set_state (pipeline, GST_STATE_NULL);
g_object_set (G_OBJECT (source), &quot;location&quot;, MOVIE_B,
NULL);
gst_element_set_state (pipeline, GST_STATE_PLAYING);

=&gt; playing movie B is not working
- display stays black
- get EOS immediately
- after some tries of playing different movies I get these errors
DavinciDisplay DavinciDisplay.1: not IO user
CMEMK Error: Failed to find a pool which fits 829440
CMEM Error: getPool: Failed to get a pool fitting a size 829440
Failed to allocate memory.

As mentioned above, g_main_loop_quit (loop) is NOT called in the app between
playback of movie A and movie B.
When I restart the player app, movie A is working again, all consecutively
movies are not working again.

The same behaviour can also be reproduced by toggleing a pipeline between the
states GST_STATE_NULL and GST_STATE_PLAYING.

Doing the same with e.g. audio elementary streams on DaVinci (TIAuddec1) or
video elementary streams on the PC is working fine.

Is the state transition to GST_STATE_NULL not working properly in TIViddec2 or
TIDmaiVideoSink ?

I also attached a small prototype test application to reproduce the behaviour
mentioned above. The pathes to the movie files are hard coded and toggeling
between the movies can be done by pressing 'a' or 'b' on the keyboard.

I used a small GStreamer application to play MPEG2 video elementary streams. The
application is using the following elements and properties:
filesrc location=
TIViddec2 engineName=&quot;decode&quot;
codecName=&quot;mpeg2dec&quot; frameRate=30
TIDmaiVideoSink displayDevice=/dev/video2 displayStd=v4l2

Playing a single file and exiting the player afterwards is working fine.

But when I
- open the player application and init the pipeline
- play movie A
gst_element_set_state (pipeline, GST_STATE_NULL);
g_object_set (G_OBJECT (source), &quot;location&quot;, MOVIE_A,
NULL);
gst_element_set_state (pipeline, GST_STATE_PLAYING);
- at EOS of movie A
gst_element_set_state (pipeline, GST_STATE_NULL);
is called and
g_main_loop_quit (loop);
is NOT called
- play movie B
gst_element_set_state (pipeline, GST_STATE_NULL);
g_object_set (G_OBJECT (source), &quot;location&quot;, MOVIE_B,
NULL);
gst_element_set_state (pipeline, GST_STATE_PLAYING);

=&gt; playing movie B is not working
- display stays black
- get EOS immediately
- after some tries of playing different movies I get these errors
DavinciDisplay DavinciDisplay.1: not IO user
CMEMK Error: Failed to find a pool which fits 829440
CMEM Error: getPool: Failed to get a pool fitting a size 829440
Failed to allocate memory.

As mentioned above, g_main_loop_quit (loop) is NOT called in the app between
playback of movie A and movie B.
When I restart the player app, movie A is working again, all consecutively
movies are not working again.

The same behaviour can also be reproduced by toggleing a pipeline between the
states GST_STATE_NULL and GST_STATE_PLAYING.

Doing the same with e.g. audio elementary streams on DaVinci (TIAuddec1) or
video elementary streams on the PC is working fine.

Is the state transition to GST_STATE_NULL not working properly in TIViddec2 or
TIDmaiVideoSink ?

I also attached a small prototype test application to reproduce the behaviour
mentioned above. The pathes to the movie files are hard coded and toggeling
between the movies can be done by pressing 'a' or 'b' on the keyboard.

I am able to reproduce this behavior, and I think there may be two issues
here:

1) Regarding &quot;CMEMK Error: Failed to find a pool which fits
829440&quot;. This problem seems to be specific to TIViddec2 as it does not
occur when using TIViddec with xDM 0.9 codecs on DVSDK 1.30.

My suspicion here is that calls to BufTab_chunk and BufTab_expand (which are
specific to TIViddec2) are somehow changing the viddec2-&gt;hOutBufTab in a
way that causes problems when deallocating the BufTab. If the BufTab fails to
deallocate, that memory will not be available for re-allocation when switching
clips. That would cause a CMEM failure like the one above.

2) When using xDM 0.9 codecs, the CMEM failure doesn't occur, but the
application still gets &quot;stuck&quot; after switching clips. It
appears that it switches to the second clip correctly and decodes the first
frame, but hangs when pushing the first frame to the display. The pipeline
state changes may be affecting the TIDmaiVideoSink in a way that leaves it in a
bad state after changing clips.

My next task will be to try to instrument the code to see if I can detect
viddec2-&gt;hOutBufTab not being deallocated correctly.

Analysis of the &quot;video_decode_io2&quot; DMAI sample app shows that
DMAI is deallocating buffers correctly even for VIDDEC2. Next, I instrumented
the plugin itself to see what is going on with the CMEM pools. The attached
&quot;cmem.log&quot; dumps the contents of /proc/cmem before and after
every call to BufTab_create() and BufTab_delete() for
viddec2-&gt;hOutBufTab.

Here is a summary of what the log is saying:

After the first call to BufTab_create(), we are allocating these pools:

New test:
Toggleing between NULL and PLAYING is also not working for TIDmaiVideoSink.

Attached below is a small test app (am-player_testtivideosink.tar.gz) which uses
just 'videotestsrc' and 'TIDmaiVideoSink' to show test patterns on the
display.

This app toggles the pipeline state between GST_STATE_NULL and GST_STATE_PLAYING
or GST_STATE_PLAYING and GST_STATE_PAUSED.

Toggleing between GST_STATE_PLAYING and GST_STATE_PAUSED is working fine.

Toggleing between GST_STATE_NULL and GST_STATE_PLAYING is not working after the
first iteration any more.

With debug level 3 I get the messages stored in TIDmaiVideoSink_l3.log below.

To control the test app &quot;am-player_testtivideosink&quot; you can
press
- 'a' or 'b' to select between 2 test patterns
- 's' to toggle between NULL and PLAYING
- space bar to toggle between PAUSE and PlAYING
- 'q' to exit the test app

I looked more into the CMEM issue. It turns out we are not hitting a CMEM bug
or limitation here. I've uncovered two issues related to the CMEM failure --
one in the GStreamer's Viddec2 support, and one in DMAI.

I've attached the patch file
&quot;0001-Do-not-update-numOutputBufs-after-resizing-the-BufTa.patch&quot;
as a fix for the plugin issue.

The DMAI issue has been filed with major severity. The internal TI defect ID
for this DMAI issue is SDOCM00054576. The DMAI issue uncovered was the calls to
BufTab_expand() can allocate additional buffers that will be leaked by
BufTab_delete(). BufTab_expand() is only needed when playing clips that use
Viddec2 (xDM 1.x) codecs, which is why it doesn't appear on previous
releases.

I installed Don's patches and did a new test with my test app
&quot;am-player_testtividdec2&quot; (attached below).
This GStreamer app just uses filesrc + TIViddec2 + fakesink to isolate issues
coming from TIViddec2.

To control the test app you can press
- 'a' or 'b' to select between 2 hard-coded m2v elementary streams (adjust this
for your needs)
- 's' to toggle between NULL and PLAYING
- space bar to toggle between PAUSE and PlAYING
- 'q' to exit the test app

New test with TIAuddec1:
Verified the behavior of TIAuddec1 if the pipeline is toggled between
GST_STATE_NULL and GST_STATE_PLAYING.
The test app 'am-player_testtiauddec1' is attached below.
This app just uses the elements filesrc + TIAuddec1 + fakesink.
Problem: After 90 .. 100 toggles between NULL and PLAYING, I get an OOM.
TIAuddec1 seems to leak memory somewhere in this use case.
Same behavior as TIViddec2 (here it happens after about 50 toggles), see my
description above.
I currently don't know, if the error message 'push to source pad failed' has
something to do with this malfunction.

To control the test app you can press
- 'a' or 'b' to select between 2 hard-coded mp2 elementary streams (adjust this
for your needs)
- 's' to toggle between NULL and PLAYING
- space bar to toggle between PAUSE and PlAYING
- 'q' to exit the test app

The issue with the TIDmaiVideoSink has been root caused to a failure to properly
munmap the driver buffers created in the DMAI Display_create function in the
DMAI Display_delete function. I have attached a patch made against DMAI version
1.20.00.05 which fixes this issue. The patch does the following:

1. sets the size value for munmap to be the same size as was used during the
mmap operation.
2. Moves the close of the file to after the munmap call. This is a
safety/niceness issue.

Please see the patch dmai_1_20_display_delete_munmap_fix.patch

Steps to verify:
1. In the DVSDK directory apply the patch and rebuild the DMAI package.
2. Rebuild the TI GStreamer plugin and install on the target file system.
3. Run the testtivideosink package and verify that pipeline can now be
transitioned between states.