Code: Select all
................... MAKEME(pfmt, OMX_VIDEO_PARAM_PORTFORMATTYPE); pfmt->nPortIndex = encportidx+1; pfmt->nIndex = 0; pfmt->eCompressionFormat = OMX_VIDEO_CodingAVC; pfmt->eColorFormat = OMX_COLOR_FormatYUV420PackedPlanar; pfmt->xFramerate = viddef->xFramerate; MAKEME(scaletype, OMX_CONFIG_SCALEFACTORTYPE); scaletype->nPortIndex = encportidx+1; scaletype->xWidth = 0x8000; scaletype->xHeight = 0x8000; OERR(OMX_SetConfig(m4, OMX_IndexConfigCommonScale, scaletype)); pixaspect->nPortIndex = encportidx+1; pixaspect->nX = 64; pixaspect->nY = 45; // OERR(OMX_SetParameter(m2, OMX_IndexParamBrcmPixelAspectRatio, pixaspect)); .................
Code: Select all
You need a resize component in between the decoder and encoder.Beach wrote:I am trying to implement the scaling bit. However, it seems that scaling is not supported by the Rpi
Code: Select all
OERR(OMX_SetupTunnel(m2, decportidx+1, m4, encportidx));
Yup. You'll need to instantiate the resizer at some point. I'd do it near the start -- there's no point doing something vaguely complex some seconds of runtime later only to find it's wrong so you've got to do it all over again, wasting time -- then when the decoder has changed state, set the parameters of the output port to the input port of the resizer, and setup the tunnel between them. The bit I'm hazy on is when you should then plumb the output of the resizer to the input of the encoder; I'll leave that in your clearly capable hands.Beach wrote:It seems that indeed a resize port exists:
http://home.nouwen.name/RaspberryPi/doc ... esize.html
port 60/61. So the decoder output must be tunneled to the resizer and then to the encoder.
I'm not surprised. I didn't bother setting it to the closest value as aspect is one of those things that if it's wrong it's just wrong. There's really no almost-right; it'll need fixing up in the container anyway.Beach wrote:Well the openmax definition is hard to chew, it's fudge. Lot's of things are pretty unclear.
As for your code I managed the aspect ratio bit. The values are restricted to
1:1, 10:11, 16:11, 40:33, 59:54, and 118:81. The closest to 16:9 being the latter. I did'nt actually had a chance to see the output, but at runtime I am getting no errors .
UPDATE: It does work! (BTW I am using VLC)
Because it doesn't query the codecs from the decoder, which is what the licence you have bought enables. I wanted to see if it could encode to anything else, and it can: 3GP is in there, from memory.Beach wrote: The program queries the codecs from the encoder (as a dump). I have a MPEG2 license, yet that particular codec is not outputted by this dump. Why not?
Profiles and levels are codec settings, which constrain the encoder in certain ways: how many key frames may be present; the maximum / average bit rate; things like that. The details for H.264 are in Annex A of ISO 14496 part 10.Beach wrote: At some point you query and set the profile and level of the encoder. I did not grasp what that does? What is the definition of profile and level? Looks like it has something todo with the encoder used, but that's already set in the eCompressionFormat is it not? The necessity eludes me.
As Dom said, you need to read the OpenMAX specs from Khronos. The answers to your questions are in there, although not terribly well explained.Beach wrote: I need some buffers to set up. However. What buffers do I need? Do I need buffers between the tunneled components? Do i need an input buffer and an output buffer? Very unclear for now.
And finally (well for now) What is the exact sequence of events I have to do to setup the tunneling. I read that you set them up in IDle state, There seems to be a required sequence to put them in enabled state (something to do with the buffers) and then again in the execution state.
Anyone who knows the answers: you cannot be elaborate enough :D
3GP is just a subset of MPEG4. IIRC it consists of Baseline profile AVC (might be Constrained Baseline, I can't remember for sure atm), AAC-LC and a subset of the MP4 container.dickon wrote:Because it doesn't query the codecs from the decoder, which is what the licence you have bought enables. I wanted to see if it could encode to anything else, and it can: 3GP is in there, from memory.Beach wrote: The program queries the codecs from the encoder (as a dump). I have a MPEG2 license, yet that particular codec is not outputted by this dump. Why not?
Apologies; I found I had a spare few hours this evening, so have attacked the code and beaten it into a nicer shape. It's on GitHub either at the above URL or https://github.com/dickontoo/omxtx, which will probably become the new master branch.Beach wrote:Before you plan to tidy things up, pls contact me, I used your code as a template and have added a fair bit already.
Your code probably mostly slotted between the two loops. This should be moved to the new configure() function, which does all the stuff between the two loops that should have been in its own function and called as appropriate and now is. It's mostly untouched.Beach wrote: Although not working at the moment -As said I have to understand the tunneling and buffer sequences- but it would be a waist not to use that.
That Sounds great. To let other people see this, you should create your own github account and sign in. Go to:Beach wrote: I am not familiar with the github. And I also do not know the difference between a fork and a branch. What would this be? And where in the github could I upload my (dirty) code? Or is this a new program to be put under a separate github handle?