Created attachment 117102 [details] [review]
cp codec_data in caps in the first buf and send it with the first frame

in this file, I copied the codec_data in the caps into the first buffer, and send it with the first frame, so that the decoder can use it

Created attachment 117103 [details] [review]
add a pointer for codec_data

in this file, I copied the codec_data in the caps into the first buffer, and send it with the first frame, so that the decoder can use it

Created attachment 117104 [details] [review]
add a pointer for codec_data

Created attachment 117105 [details] [review]
reserve codec_data when recieved caps

reserve codec_data when recieved caps, it is same with the version 0.10.0.4,
but my other change need test with it.

Created attachment 117106 [details] [review]
reserve codec_data when recieved caps

reserve codec_data when recieved caps, it is same with the version 0.10.0.4,
but my other change need test with it.

Ok, so #117106 and #1171065 are the same patch, that is not required for 0.10.0.4, right?

#117102 and #117103 are the same patch too. For this patch I would say you should remove the "enable-codecdata" property. If you get codecdata from the container you should always pass it somehow.

So #117104 is not required, and #117102, #117103 (which are the same) can be minimized.

Thanks for the contribution. Can you mention if you are using Bellagio or some other OpenMAX IL implementation?

sorry, this is the first time that I used this tool, I don't know how to delete the patch and edit the description again, so I can only add comments now.

1. I build version gst-omx 0.10.0.4 failed, so I worked on 0.10.0.3. I used Bellagio OpenMAX IL implementation for libomxil-B-0.3.3 (0.3.9 build failed)

2. I try to use qtdemux and gst-omx dec to play an mp4 failed
   gst-launch-0.10 filesrc location=./1m=.mp4 ! qtdemux ! omx_mpeg4dec ! ffmpegcolorspace ! videoscale ! ximagesink
   it report picture size failed (0, 0, (nil))
   found the resean is qtdemux add codec_data in caps, but omx_mpeg4dec did not sent it to decoder, so I add the codec data in the first buffer and sent it with the first frame, it can play now.

3. I'am not from the gst-omx team, so I don't know if there is better methods to resolve this problem, and I don't know if how it works on TI hardware, so I add this property to maintain the old behaviors.

4. Changed files:
   gstomx_base_filter.c
   gstomx_base_filter.h
   gstomx_base_videodec.c (this files change is same with 0.10.0.4)

Motorola would like to contribute Gstreamer patch to the Gstreamer open source
community project. Please find attached the patch applicable for Gstreamer. For
any questions, please feel free to contact ("Zhao Liang "e3423c@motorola.com",
Shi Ling "w20230@motorola.com",Ye Haomiao "e5969c@motorola.com).
 
  

(In reply to comment #6)
> Ok, so #117106 and #1171065 are the same patch, that is not required for
> 0.10.0.4, right?
> #117102 and #117103 are the same patch too. For this patch I would say you
> should remove the "enable-codecdata" property. If you get codecdata from the
> container you should always pass it somehow.
> So #117104 is not required, and #117102, #117103 (which are the same) can be
> minimized.
> Thanks for the contribution. Can you mention if you are using Bellagio or some
> other OpenMAX IL implementation?

It's ok, I was just wondering if my assumptions where correct.

You can change the 'status' of the patches, I'll do it this time.

Why is 0.10.0.4 failing? That should be fixed.

So I'm going to integrate the patch #117103 for now. There's a new official way of sending the codec data to omx, but the new version of the standard hasn't been released yet.

hi, Fekipe Contreras, 

now the most latest bellagio open max code is version 0.9.0,
but the gst-omx recommanded one is 0.3.3? why?
do you know if 0.9.0 still have bugs? 
does gst-omx team and all of you work on 0.9.0 or 0.3.3?
 



(In reply to comment #8)
> It's ok, I was just wondering if my assumptions where correct.
> You can change the 'status' of the patches, I'll do it this time.
> Why is 0.10.0.4 failing? That should be fixed.
> So I'm going to integrate the patch #117103 [edit] for now. There's a new official way
> of sending the codec data to omx, but the new version of the standard hasn't
> been released yet.

Ah, nope, I just forgot to update the Wiki.

I think gst-openmax should work fine with anything after 0.3.2.

Created attachment 117786 [details] [review]
Send initial codec_data buffer

I'm attaching a new patch on top of the latest head that should do the same thing. Can you please try it out?

I updated the wiki to mention 0.9.0 instead of 0.3.3.

I also merged the patch so it should be in the next version of gst-openmax.