Integrating our jpeg2000 hardware codec inside gstreamer.
Locked
 
|
Hello all, We are developing a PCI-express board for accelerating
JPEG2000 encoding and decoding. We also provide a lot of software applications with our
board (streaming server/client, ingest software, players, transcoders,
archiving software…). A lot of features we plan to create (or have already
created) in our software do already exist in gstreamer. We do not like the idea
of reinventing the wheel and we are now thinking about designing a gstreamer
plugin for our HW codecs to be able to use all the wonderful gstreamer plugins. Since I am new to gstreamer (just read the general doc and
plugin writing guide), before making that switch I would like to ask your
advices about complexity of what we would like to develop: The product we would like to build is a player GUI for
jpeg2000 media (using our hardware jpeg2000 decoder pciexpress board): The media types we would like to support: - 1 Sequence of jpeg2000 (RGB or YCbCr) files
(multifilesrc), with a wav audio track (filesrc) - 2 sequences of jpeg2000 files (2 x multifilesrc)
for 3D movies, with a wav audio track (filesrc) - Two Mxfs files (one for video with embedded
Jpeg2000 frames, and another one with audio) The type of “pipelines” we would need: - Audio played on autoaudiosink in sync with video
played on autovideosink - Audio played on autoaudiosink in sync with video
played on external video interface of our board (SDI) - Audio and Video played on external audio/video
interface of our board The features the gui will have: - Playing/pausing/stopping/seeking the content (and unrelated to gstreamer: - Browsing filesystem for content - Manage/save playlists) Our “clock concern”: - Our board do have an SDI interface. We would
like to be able for the board to be a “clock provider” when used with
this video interface. - If we use alsasink and our board with video
output interface, we would still like alsasink to be chosen as clock and have a
mechanism in our board library to drop/repeat frames to compensate drift
between alsa clock and our board’s clock. My questions: - Since our board can act as a
“decoder-only” and as a “decoder+sdi video sink”, I
guess I should have two elements in my plugin: “myjpeg2000decoder and
myjpeg2000sdisink” ? "myjpeg2000sdisink" would need to support
up to two input pads (for playing 3D content). Is this the right way to do it? - Is this easy for gstreamer to keep my
audio/video in sync when using “unrelated” sources (multifilesrc
+wav filesrc , audiomxf+videomxf, … instead of the a typical source with
one avi file containing audio and video)? What could happen to this sync if a
“seek” is applied on the pipeline? - Since the movie player TOTEM uses GStreamer and
it has the basic features we need (seek, playlist), is there a way to make it
run our pipelines? I guess it would be possible if playbin was aware of how to
play our content ? - About performances of
“autovideosink”: do I have a chance of being able to play in
realtime 1920x1080 @ 30 fps (RGB24 or YUYV) on any of the videosink provided
with gstreamer (a quick test gst-launch videotestsrc ! autovideosink in
1920x1080 is not realtime on my i7 with 6gigs RAM on Ubuntu10.04)? - Any idea, suggestion or other thing you think I
should take into account? - What about the complexity of the whole work ? Many thanks in advance for paying attention to this rather
big email. I would be glad to start using gstreamer :-). Best regards, Charles Buysschaert IntoPIX S.A _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Integrating our jpeg2000 hardware codec inside gstreamer.
|
Administrator
|
Hi,
On Wed, 2011-08-03 at 17:54 +0200, CBU wrote: [...] > My questions: > > - Since our board can act as a “decoder-only” and as a > “decoder+sdi video sink”, I guess I should have two elements in my > plugin: “myjpeg2000decoder and myjpeg2000sdisink” ? > "myjpeg2000sdisink" would need to support up to two input pads (for > playing 3D content). Is this the right way to do it? You should create separate elements for the decoder and for the sdi sink. Doing a decoder+sink combo has only brought problems in the past. Note: * There are some SDI elements already in bad, might be worth looking at them and maybe extending those. * As long as your sink can recognize the decoded memory is already "on-board" you won't need to do card<=>mainmemory back and forth. > > > > - Is this easy for gstreamer to keep my audio/video in sync > when using “unrelated” sources (multifilesrc +wav filesrc , audiomxf > +videomxf, … instead of the a typical source with one avi file > containing audio and video)? Yes > What could happen to this sync if a “seek” is applied on the > pipeline? The seek will be sent to all sinks present in the pipeline, and therefore through all sub-graphs of the pipeline. > > > > - Since the movie player TOTEM uses GStreamer and it has the > basic features we need (seek, playlist), is there a way to make it run > our pipelines? I guess it would be possible if playbin was aware of > how to play our content ? If you have separate decoder and sink elements it should just-work with playbin2. Note: * Test whether your plugins work by not only using hand-crafted pipelines, but also decodebin2 and playbin2. > > > > - About performances of “autovideosink”: do I have a chance > of being able to play in realtime 1920x1080 @ 30 fps (RGB24 or YUYV) > on any of the videosink provided with gstreamer (a quick test > gst-launch videotestsrc ! autovideosink in 1920x1080 is not realtime > on my i7 with 6gigs RAM on Ubuntu10.04)? I'm pretty sure that if you profile it ... you'll see 99% of the cpu is taken by videotestsrc :) Plenty of people watch (and even edit!) full HD videos with GStreamer. > > > > - Any idea, suggestion or other thing you think I should > take into account? > > > > - What about the complexity of the whole work ? There are already plenty of examples of video decoders and video sinks you can base your work on. As for complexity ... some people find writing a "hello world" example hard, and some others find writing a multimedia framework easy. Can't really answer that. > > > > Many thanks in advance for paying attention to this rather big email. > I would be glad to start using gstreamer :-). > > > > Best regards, > > > > > > Charles Buysschaert > > IntoPIX S.A > > > > > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
| Free forum by Nabble | Edit this page |