After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 581379 - ffenc_alac not working
ffenc_alac not working
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-05-04 22:24 UTC by Thiago Sousa Santos
Modified: 2009-09-10 08:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Thiago Sousa Santos 2009-05-04 22:24:19 UTC 
Please describe the problem:
TItle is self-explicative

Steps to reproduce:
1. gst-launch audiotestsrc ! ffenc_alac ! fakesink -v


Actual results:
Errors, a series of:

0:00:01.462853587 13665       0xe666a0 ERROR               ffmpeg :0:: buffer size is too small
0:00:01.462886542 13665       0xe666a0 ERROR               ffmpeg gstffmpegenc.c:772:gst_ffmpegenc_chain_audio:<ffenc_alac0> Failed to encode buffer
0:00:01.463406258 13665       0xe666a0 ERROR               ffmpeg :0:: alac: expected 36 extradata bytes



Expected results:
ffenc_alac to work properly.

Does this happen every time?
Yes

Other information:
Comment 1 Sebastian Dröge (slomo) 2009-05-07 13:54:46 UTC 
Seems that the alac encoder requires the input buffer size to be in some interval... not sure if we want to fix this in gst-ffmpeg. IMHO this should better be fixed in ffmpeg. Edward, what do you think?

Relevant part of code from alacenc.c:

    if(avctx->frame_size > DEFAULT_FRAME_SIZE) {
        av_log(avctx, AV_LOG_ERROR, "input frame size exceeded\n");
        return -1;
    }

    if(buf_size < 2*s->max_coded_frame_size) {
        av_log(avctx, AV_LOG_ERROR, "buffer size is too small\n");
        return -1;
    }
Comment 2 Sebastian Dröge (slomo) 2009-09-10 08:47:22 UTC 
Closing this, this should be fixed in ffmpeg: https://roundup.ffmpeg.org/roundup/ffmpeg/issue1371