New mediainfo-powered inspector on the way: Siskel

3 views
Skip to first unread message

Jon Dahl

unread,
Jul 17, 2009, 7:28:49 PM7/17/09
to RVideo
There was some discussion recently about using mediainfo to inspect
videos instead of ffmpeg. Main reason: each ffmpeg version prints out
video info differently, which breaks the RVideo::Inspector class every
few months. The theory is that MediaInfo won't do the same thing.

I'm going to implement this as a new library, separate from RVideo
core. One group of users needs a full Ruby transcoding library (like
RVideo), and another group just needs video inspection. No need to
make the latter deal with a transcoding library.

Introducing Siskel, coming very soon.

# results = Siskel.review(:file => 'path/to/myfile.mov')
# results[:format] # => 'MPEG-4'
# results[:video][:frame_rate] # => '29.970 fps'

Thoughts? Good approach? Bad approach?

Cheers,
Jon Dahl

Seth Thomas Rasmussen

unread,
Jul 20, 2009, 1:17:45 PM7/20/09
to rvi...@googlegroups.com

Naming's a little corny. ;)

Not sure about the hash-style access.. might be good, though.

I started a Mediainfo gem a little while ago. I didn't put a ton of
thought into the API yet other than to try to be compatible with
RVideo::Inspector in some spots(although I haven't yet moved my app
off RVideo::Inspector). Most of the methods are derived from
Mediainfo's output.

http://github.com/greatseth/mediainfo

--
Seth Thomas Rasmussen
http://greatseth.com

Seth Thomas Rasmussen

unread,
Jul 20, 2009, 8:36:47 PM7/20/09
to rvi...@googlegroups.com
On Fri, Jul 17, 2009 at 7:28 PM, Jon Dahl<jon...@gmail.com> wrote:
>

Some more thoughts:

- The hash approach seems useful if you need to handle groups of
attributes in isolation and be able to compare, iterate, etc. I'm not
sure how useful that is. I was thinking I could add that behavior as
an option to my library though. The underlying structure is a big
hash, and with some fancy programming.. hmm..

- You gave FPS as an example.. with attributes like that, it seems
most useful to provide an API like this for each attribute: fps,
fps_units, fps_with_units. The main win is getting at the 'raw'
numbers in a standard way. On the other hand, some attributes could
very well imply units and do with a single accessor which returns a
number.

Reply all
Reply to author
Forward
0 new messages