FFMmpeg::open() has 'media type' bug with MP3s (image metadata)

[twmbx]

Q	A
Bug?	yes
New Feature?	no
Version Used	ecd50cd
FFmpeg Version	FFmpeg 2.8.10-0ubuntu0.16.04.1
OS	ElementaryOS Loki (Ubuntu 16.04)

Actual Behavior

calling $ffmpeg->open('audio.mp3'); returns an instance of FFMpeg\Media\Video instead of FFMpeg\Media\Audio when the mp3 file has an embedded image as part of it's metadata (id3 tag "cover image")

Expected Behavior

calling $ffmpeg->open('audio.mp3'); should return an instance of FFMpeg\Media\Audio object.

Steps to Reproduce

call $ffmpeg->open('audio.mp3'); using an audio file which has an id3 tag image aka "cover image" as part of its metadata

Possible Solutions

Not certain...
Better checks need to be made to differentiate video from mp3

[jens1o]

can reproduce it.

[twmbx]

Would the solution be to introduce an optional flag to allow forcing of the object type one wants returned?
Or would it be better to try detect audio more accurately?

[Romain]

I think it would be better to autodetect it based on the extension of the file. However, if the user is not rigorous about this, it may generate errors.
@jens1o, what do you think about auto-detection?

[jens1o]

It's a orientation, but we shouldn't rely on it. May I create a pr with some checking?

[Romain]

If you can, please do, thanks a lot!

[jens1o]

I'll do it as soon as the others are merged. Otherwise, the sums of pr aren't controllable anymore. Can you assign me to this issue in any way?

[Romain]

Unfortunately no, I tried but Github doesn't allow me to add assignees who are not admins.

[phylaxis]

Is there any fix for this yet?

[jens1o]

I'm happy to see a pr, I didn't had the time to invest it, and I also think it would mean a major break, so it is considered for 1.x for now.

[jens1o]

There is a fix for this problem, I'd happy to see that more people would test this to see if there is any regression(while I couldn't find one).

See #402 (comment) for the patch.

[Orrison]

Any possibility of movement on this one? It is a pretty significant bug that completely breaks working with audio files that have cover art meta data.

Is see @vibhavsinha proposed a fix that has not been touched in 2 years.

I would be willing to help with the issue if needed.

[fpolli]

Any possibility of movement on this one? It is a pretty significant bug that completely breaks working with audio files that have cover art meta data.

Is see @vibhavsinha proposed a fix that has not been touched in 2 years.

I would be willing to help with the issue if needed.

I used his fix in a site and it worked. I did have to add a missing end brace per my comment on the pull request, but once I did that, it worked. I am back here because almost a year later, I ran into the same issue on a new site and had forgotten about the problem.

[vibhavsinha]

I have rebased my PR with the latest of master branch.

It is passing the test cases. Although ideally, we should have a test case to cover this scenario, but I am not sure how mocking works here.

[sgloe]

I would appreciate this fix as well.