Re: Agenda for the Edinburgh mini-summit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/30/2013 03:21 PM, Oliver Schinagl wrote:
> On 30-08-13 15:01, Hans Verkuil wrote:
>> OK, I know, we don't even know yet when the mini-summit will be held but I thought
>> I'd just start this thread to collect input for the agenda.
>>
>> I have these topics (and I *know* that I am forgetting a few):
>>
>> - Discuss ideas/use-cases for a property-based API. An initial discussion
>>    appeared in this thread:
>>
>>    http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195
>>
>> - What is needed to share i2c video transmitters between drm and v4l? Hopefully
>>    we will know more after the upcoming LPC.
>>
>> - Decide on how v4l2 support libraries should be organized. There is code for
>>    handling raw-to-sliced VBI decoding, ALSA looping, finding associated
>>    video/alsa nodes and for TV frequency tables. We should decide how that should
>>    be organized into libraries and how they should be documented. The first two
>>    aren't libraries at the moment, but I think they should be. The last two are
>>    libraries but they aren't installed. Some work is also being done on an improved
>>    version of the 'associating nodes' library that uses the MC if available.
>>
>> - Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See
>>    this thread for all the nasty details:
>>
>>    http://www.spinics.net/lists/linux-media/msg65137.html
>>
>> Feel free to add suggestions to this list.
> What about a hardware accelerated decoding API/framework? Is there a 
> proper framework for this at all? I see the broadcom module is still in 
> staging and may never come out of it, but how are other video decoding 
> engines handled that don't have cameras or displays.
> 
> Reason for asking is that we from linux-sunxi have made some positive 
> progress in Reverse engineering the video decoder blob of the Allwinner 
> A10 and this knowledge will need a kernel side driver in some framework. 
> I looked at the exynos video decoders and googling for linux-media 
> hardware accelerated decoding doesn't yield much either.
> 
> Anyway, just a thought; if you think it's the wrong place for it to be 
> discussed, that's ok :)

No, this is the right place. See http://hverkuil.home.xs4all.nl/spec/media.html#codec
for more information.

For the longest time that section in the spec said that that interface was 'Suspended'.
That was only corrected in 3.10 or 3.11 even though actual codec support has been
around for much longer. There are many v4l2 drivers today that do this. Just grep
for V4L2_CAP_VIDEO_M2M in drivers/media.

Codec drivers are really just a video node that can capture and output at the same
time, and has a lot of codec controls (http://hverkuil.home.xs4all.nl/spec/media.html#mpeg-controls)
to tweak codec parameters.

Just post any questions you have regarding this to the linux-media mailinglist,
we're happy to help out.

Regards,

	Hans

> 
> oliver
>>
>> Note: my email availability will be limited in the next three weeks, especially
>> next week, as I am travelling a lot.
>>
>> Regards,
>>
>> 	Hans
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux