Review Request: Remove FFmpeg dependencies from the new MusicBrainz fingerprinting by using Phonon::AudioDataOutput instead of FFmpeg directly

Mark Kretschmann kretschmann at kde.org
Sat Oct 16 17:38:29 CEST 2010



> On 2010-10-04 13:30:31, Daniel Dewald wrote:
> >
> 
> Daniel Dewald wrote:
>     This is far from being complete. It something of a beginning. I just basically removes the ffmpeg stuff but puts nothing into place to replace it. A slot for the audioDataReady signal is created but not implemented anywhere let alone being connected somehow to some audioDataOutput. This has to go a long way before it could work. Also remember that the audioDataOutput was originally invented for visualizing stuff.. so the data wont come in at once.. you'd have to build some kind of buffer (as I did) before this could work. otherwise musicbrainz will either hang or starve.
> 
> Kevin Kofler wrote:
>     > I just basically removes the ffmpeg stuff but puts nothing into place to replace it.
>     
>     Uh yes, it puts a Phonon::AudioDataOutput in place.
>     
>     > A slot for the audioDataReady signal is created but not implemented anywhere
>     
>     line 160:
>     void MusicDNSAudioDecoder::handleFrame(const QMap<Phonon::AudioDataOutput::Channel, QVector<qint16> > &data)
>     
>     > let alone being connected somehow to some audioDataOutput.
>     
>     lines 130-131:
>         connect(&dataout, SIGNAL(dataReady(const QMap<Phonon::AudioDataOutput::Channel, QVector<qint16> >&)),
>                 this,  SLOT(handleFrame(const QMap<Phonon::AudioDataOutput::Channel,    QVector<qint16> >&)));
>     
>     > you'd have to build some kind of buffer (as I did) before this could work.
>     
>     The DecodedAudioData class in the original FFmpeg-based code is already such a buffer. FFmpeg doesn't deliver all the data at once either, the code used a loop. Due to how Phonon::AudioDataOutput works, I replaced the loop with a QThread event loop.
> 
> Daniel Dewald wrote:
>     > line 160:
>     > void MusicDNSAudioDecoder::handleFrame(const QMap<Phonon::AudioDataOutput::Channel, QVector<qint16> > &data)
>     
>     Sorry overlooked that because of strange coloring (still dont get this reviewboard stuff). Looking through that stuff now things look better ;o).
>     
>     > lines 130-131:
>     >     connect(&dataout, SIGNAL(dataReady(const QMap<Phonon::AudioDataOutput::Channel, QVector<qint16> >&)),
>     >             this,  SLOT(handleFrame(const QMap<Phonon::AudioDataOutput::Channel,    QVector<qint16> >&)));
>     
>     I also overlooked that because of the color ;o).
>     
>     > The DecodedAudioData class in the original FFmpeg-based code is already such a buffer. FFmpeg doesn't deliver all the data at once either, the code used a loop. Due to how Phonon::AudioDataOutput works, I replaced the >loop with a QThread event loop.
>     
>     I've no clue about ffmpeg of how its internal stuff works. May work or may not.. I'd say it won't because I know phonon. If it does I'd be surprised. Some other comments:
>     
>     - Dont try to get the samplerate via dataout.sampleRate(). I know the docu says it should work but most times and with most backends it wont. I had / have the same problem.
>     - With most (if not all) backends you wont get ANY data at all (for example VLC or gstreamer). With other it will crash (xine). Your theoretical approach might work (haven't checked all of it) but as for my experience it wont because of phonon and the backends.
>     - As Leo mentioned before phonon wont give you the data any faster as if you'd play the song in real.. so this will be FUCKING slow ;o).
>     
>     So my conclusion: 
>     
>     Good approach (I dont know if it could / would work ) and maybe even a smarter solution then what I implemented. But as for now this will have to sit and wait for the phonon stuff to work out I guess. I didn't try any of this though. This is just my brain speaking.

I can't really see this working well. Also, we depend on FFmpeg anyway (for Teo's Transcoding). And FFmpeg is proven and well maintained.

IMHO we should reject this one, sorry. Thanks for the effort, though.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100021/#review69
-----------------------------------------------------------


On 2010-10-03 23:07:03, Kevin Kofler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100021/
> -----------------------------------------------------------
> 
> (Updated 2010-10-03 23:07:03)
> 
> 
> Review request for Amarok.
> 
> 
> Summary
> -------
> 
> This patch removes FFmpeg dependencies from the new MusicBrainz fingerprinting by using Phonon::AudioDataOutput instead of FFmpeg directly.
> 
> WARNING: This version of the patch is completely untested and may not even build.
> In addition, Phonon::AudioDataOutput may not be ready for production use yet (crashes, decoding speed issues).
> You have been warned.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt baacef5 
>   src/musicbrainz/MusicDNSAudioDecoder.h 97976f6 
>   src/musicbrainz/MusicDNSAudioDecoder.cpp eef459a 
> 
> Diff: http://git.reviewboard.kde.org/r/100021/diff
> 
> 
> Testing
> -------
> 
> None yet.
> 
> 
> Thanks,
> 
> Kevin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20101016/2f8db379/attachment-0001.htm 


More information about the Amarok-devel mailing list