https://bugs.kde.org/show_bug.cgi?id=386105
Leslie Zhai changed:
What|Removed |Added
Latest Commit||https://commits.kde.org/k3b
|
https://bugs.kde.org/show_bug.cgi?id=386105
--- Comment #12 from bl...@vivaldi.net ---
After accepting the latest revision of https://phabricator.kde.org/D11634 this
bug can be considered as fixed in the upstream for future releases.
--
You are receiving this mail because:
You are watching all b
https://bugs.kde.org/show_bug.cgi?id=386105
--- Comment #11 from bl...@vivaldi.net ---
So here's my code which converts float audio to 16bit (for WMA and AAC):
>for(int sample=0; samplefor(int ch=0; chfloat smpl = *(reinterpret_cast(
>d->fra
https://bugs.kde.org/show_bug.cgi?id=386105
--- Comment #10 from bl...@vivaldi.net ---
Created a phabricator diff here https://phabricator.kde.org/D11634
It fixes decoding for some lossless formats.
Compressed formats like WMA and AAC still have to be attended (probably need
flushing).
--
You ar
https://bugs.kde.org/show_bug.cgi?id=386105
--- Comment #9 from bl...@vivaldi.net ---
And one more: this plugin does not decode wma1, wma2 and aac at all, produces
total garbage. And these formats supposed to be "tested", lol, according to the
source comments.
--
You are receiving this mail beca
https://bugs.kde.org/show_bug.cgi?id=386105
--- Comment #8 from bl...@vivaldi.net ---
One more important addition: I think that the second half of every frame is
just some memory garbage as I found in previous step. But you not supposed to
divide the frame size by two. The actual string where thin
https://bugs.kde.org/show_bug.cgi?id=386105
--- Comment #7 from bl...@vivaldi.net ---
Experimenting further I found that if the calculated buffer size returned by
av_samples_get_buffer_size() is divided by two then the resulting waveform
looks normal (no noise), but the sound is twice faster than
https://bugs.kde.org/show_bug.cgi?id=386105
--- Comment #6 from bl...@vivaldi.net ---
I found that every frame produced by fillOutputBuffer() contains (some patch
of) corrupted data just right after the middle.
Also citing the FFMPEG docs:
>Some decoders (those marked with AV_CODEC_CAP_DELAY) ha
https://bugs.kde.org/show_bug.cgi?id=386105
Simon Andric changed:
What|Removed |Added
CC||simonandr...@gmail.com
--
You are receiving thi
https://bugs.kde.org/show_bug.cgi?id=386105
--- Comment #5 from bl...@vivaldi.net ---
> You can test to comment the SWAP code, then rebuild K3B to verify whether or
> not produce the noise
Did it but with that it's even worse. So it's not the case. I'm worriyng
however about the "if needed" part
https://bugs.kde.org/show_bug.cgi?id=386105
Leslie Zhai changed:
What|Removed |Added
CC||lesliez...@llvm.org.cn
--- Comment #4 from Leslie
https://bugs.kde.org/show_bug.cgi?id=386105
--- Comment #3 from bl...@vivaldi.net ---
plugins/decoder/ffmpeg/k3bffmpegwrapper.cpp:
int K3bFFMpegFile::read( char* buf, int bufLen )
{
// ...
// TODO: only swap if needed
for( int i = 0; i < len-1; i+=2 ) {
char a = buf[i];
https://bugs.kde.org/show_bug.cgi?id=386105
--- Comment #2 from bl...@vivaldi.net ---
Another very characteristic screenshot:
https://i.imgur.com/l9wpxYG.png
comparison between corrupted file produced by k3b ffmpeg plugin (above) and
normal (below)
--
You are receiving this mail because:
You are
https://bugs.kde.org/show_bug.cgi?id=386105
Dr. Chapatin changed:
What|Removed |Added
CC||bugsefor...@gmx.com
--
You are receiving this m
https://bugs.kde.org/show_bug.cgi?id=386105
--- Comment #1 from bl...@vivaldi.net ---
This is example FFmpeg decoding code
https://www.ffmpeg.org/doxygen/trunk/demuxing_decoding_8c-example.html
It has some differences from what is present in k3b ffmpeg plugin.
--
You are receiving this mail bec
15 matches
Mail list logo
