Deprecate ffmpeg-powered Inspector in favor of mediainfo

[Seth Thomas Rasmussen]

Hey kids,

I pushed some code last week to support the audio_bit_rate and a
couple new time_base attributes in the Inspector. With the latter,
wrangling the video_match regex took some fortitude. While I am
pleased to have triumphed, the experience finally pushed me to
question whether or not one should rely on ffmpeg for this behavior.
For starters, one cannot easily rely on ffmpeg. ffmpeg does what
ffmpeg is gonna do, the world be damned.

So, I asked some of the kind folks in #ffmpeg on freenode for
alternatives and one of the ops quickly suggested a couple options:

- mediainfo
- mplayer (with certain options, similar to ffmpeg)

I think I prefer the mediainfo option at this point. For one, just
look at the name. It's output is pretty nicely structured and its
intended purpose seems pretty well suited to what the Inspector needs.

So, I suppose we would have to maintain ffmpeg support. Going forward,
I would like to work on an Inspector powered by mediainfo and relegate
any future ffmpeg support updates to those who for whatever reason
really need it(perhaps they cannot install mediainfo or something). As
much as I like crafting a fine regex, it's still a poor man's parser
and it hurts even more when what you're parsing is almost trying to
taunt you..

I'm not sure of the details of the interfaces around this new support.
I suppose ideally we'd keep the one Inspector class and add some way
to switch which implementation it uses. Thoughts?

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

[Seth Thomas Rasmussen]

On Sun, Mar 1, 2009 at 2:42 PM, Seth Thomas Rasmussen
<sethra...@gmail.com> wrote:
> I pushed some code last week to support the audio_bit_rate and a
> couple new time_base attributes in the Inspector. With the latter,
> wrangling the video_match regex took some fortitude. While I am
> pleased to have triumphed, the experience finally pushed me to
> question whether or not one should rely on ffmpeg for this behavior.
> For starters, one cannot easily rely on ffmpeg. ffmpeg does what
> ffmpeg is gonna do, the world be damned.

Here is the current state of that regex, by the way:

http://github.com/greatseth/rvideo/commit/db742719bfeeab92d96ae59b9d0afc7fcf7faaf5

[Jon Dahl]

I definitely agree that maintaining ffmpeg compatibility is a pain,
for both inspection and transcoding. I think it would be a great idea
to add mediainfo or mplayer as inspection options. If mediainfo works
well, we could maybe even make it the default. But we should also
leave ffmpeg inspection support in the tool as well, even if people
have to fine-tune it to their specific version of ffmpeg.

Looking briefly at mediainfo, it looks like the command-line version
is secondary to the Windows GUI version [1]. That might not be a
problem, but it's something to keep in mind.

Another option: we could bind each version of rvideo to a specific
ffmpeg checkout, to ensure compatibility. But that isn't ideal.

Cheers,
Jon

[1] http://mediainfo.sourceforge.net/en/Support/FAQ#Cmd_Options



On Mar 1, 2:42 pm, Seth Thomas Rasmussen <sethrasmus...@gmail.com>
wrote:

[Kyle Drake]

I find it a bit silly that they're changing ffmpeg that much at all.
It's been around forever, doesn't really need to keep getting changed
like it does.

The main caveat of course is lack of transcoding. So you would to
remove transcode support, have two dependancies, or split transcoding
and inspection into seperate gems. Another idea is to patch ffmpeg to
have a sort of programmers friendly interface with a -p flag or
something like that.

I do not envy your position here, there really isn't a good solution
to this unfortunately.

-Kyle

[Jon Dahl]

I think we're only talking about doing this for the Inspector class. We'd basically support a variety of tools for both inspection and transcoding. Transcoding has ffmpeg + mencoder + On2 Flix Engine (in development), so now Inspection would have ffmpeg + mediainfo + ?.

The RVideo gem could include both inspection and transcoding, or that could be split into separate gems. Either one is fine with me.

At least that's my suggestion. Seth?

[Seth Thomas Rasmussen]

On Tue, Mar 3, 2009 at 2:41 PM, Jon Dahl <jon...@gmail.com> wrote:
> I think we're only talking about doing this for the Inspector class. We'd
> basically support a variety of tools for both inspection and transcoding.
> Transcoding has ffmpeg + mencoder + On2 Flix Engine (in development), so now
> Inspection would have ffmpeg + mediainfo + ?.

Right. Nobody is suggesting dropping Transcoder support. That would
just be wacky!

> The RVideo gem could include both inspection and transcoding, or that could
> be split into separate gems. Either one is fine with me.
>
> At least that's my suggestion. Seth?

I think they should stay in the same package. It's actually a
requirement, for now anyway, as the Transcoder uses Inspector in a
spot or few.

Ideally I think we'd not expand Inspector implementations beyond
adding something more structured like mediainfo. Maintaining ffmpeg
next to that is just for ye olde backwards compat.

[Peter Boling]

On Tue, Mar 3, 2009 at 2:41 PM, Jon Dahl <jon...@gmail.com> wrote:
> We'd basically support a variety of tools for both inspection and transcoding.
> Transcoding has ffmpeg + mencoder + On2 Flix Engine (in development), so now
> Inspection would have ffmpeg + mediainfo + ?.

Been a long time since I've posted, but thought I'd weigh in. Think
attachment_fu. It has an abstracted layer between the file and the
file storage medium. A set of methods that can be called and return
the appropriate data depending on the storage medium, which can by any
of filesystem, database, amazon, etc.

I think the inspector should work essentially the same way. Granted
level of support for the different inspector engines would vary as
would their level of use. But the same goes for attachment_fu's
storage engines. I'd venture that database is not as well kempt as
amazon or filesystem, as those two are much better options for most
use cases.

For example each storage engine in attachment_fu has to respond to
public_filename. Similarly the inspector would have a 'plugin'
architecture, such that anyone who wanted to write an inspector that
responded to the inspector set of methods and piped those calls to an
appropriate system command and parsed the response, could write one.
That way those who need or want to use some other inspector can
leverage all of RVideo by just writing one little inspector for their
'mediainfo' of choice.

I wonder how many other silent listeners there are? :)

--
|7eter H. l3oling
-----------------------------------------------------------------
9thBit LLC | http://peterboling.com/
Sagebit LLC | http://sagebit.com
-----------------------------------------------------------------
blog: http://galtzo.blogspot.com/
lang: English, Spanish, Portuguese
-----------------------------------------------------------------
find events in your city at http://cartabuzz.com
find tickets for anything fast at http://monkeystub.com

[Kai Krakow]

On 3 Mrz., 22:22, Seth Thomas Rasmussen <sethrasmus...@gmail.com>
wrote:

> Ideally I think we'd not expand Inspector implementations beyond
> adding something more structured like mediainfo. Maintaining ffmpeg
> next to that is just for ye olde backwards compat.

There's also ffprobe which might be of interest as it was written as
an addon to ffmpeg to get around the parsing problem. It created
output easily parsable by machines - however I didn't check how well
it follows the redicilous changes the ffmpeg team is doing to ffmpeg's
output every new version.

Regards,
Kai

[spezam]

Sorry,
did anyone implemented a mediaInfo powered inspector?

I did some benchmarks on our transcoding platform, and I realized that
the "ffmpeg -i" approach is about three times slower than the
"mediainfo" one.

Regards,
Matteo

[Seth Thomas Rasmussen]

On Thu, May 28, 2009 at 2:58 PM, spezam<spe...@gmail.com> wrote:
>
> Sorry,
> did anyone implemented a mediaInfo powered inspector?

Sorry, I fell off the wagon on this thread.. was just browsing Gmail archives..

Anyway, yes! I started one: http://github.com/greatseth/mediainfo

:)