On Fr, 2008-03-14 at 14:26 +0100, Jaap A. Haitsma wrote: > On Thu, Mar 13, 2008 at 8:07 PM, Ioannis Nousias <s0238762 sms ed ac uk> wrote: > > > > > i wouldnt just add a gst element, just because it doesnt do anything. > > > this can have performance regressions and stuff of that kind. > > > > > > daniel > > > > > > > > Hi daniel, > > > > When the input is raw, 'decodebin' creates ghost pads (proxy), which do > > have some overhead (dereferencing?), but it's negligible. I've done a > > simple test with 30 or so cascaded 'decodebin's and there was no > > measurable CPU difference. It does affect the creation-time of the > > pipeline though, by adding type checks, but that's probably similar to > > adding custom checks for the input format. > > > > It's just more flexible this way. Currently, it ignores any format that > > isn't raw. Sure, a custom check and a conditional addition of a > > 'jpegdec' would do the trick in my case, but what about other cases > > (unforeseen)? Similarly to why you use ffmpegcolorspace rather than > > manually handling some types only. > > > > what do you think? > > > Daniel, > > I think it's a good idea to add the decodebin. We'll support more > cameras and it doesn't add much overhead jaap really knows whats up ;) ok, ioannis, could you try to prepare a patch and submit it to bugzilla? daniel > > Jaap -- this mail was sent using 100% recycled electrons ================================================ daniel g. siegel <dgsiegel gmail com> http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred
Attachment:
signature.asc
Description: This is a digitally signed message part