Opened 10 years ago

Closed 10 years ago

#3644 closed defect (fixed)

caf muxer sets incorrect codec id 'lpcm' in desc chunk for a-law and mu-law

Reported by: nu774 Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: caf
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

How to reproduce:

% ffmpeg -i foo.wav -c:a pcm_alaw bar.caf

Nothing can ever play it correctly, since it looks like nothing but an ordinary 8bit linear PCM, but it actually is a-law / mu-law.

Change History (4)

comment:1 by Carl Eugen Hoyos, 10 years ago

Keywords: caf added
Priority: criticalnormal

Please provide the command line together with the complete, uncut console output to make this a valid ticket.

comment:2 by nu774, 10 years ago

Sorry, but I don't give a damn to that kind of bureaucracy.
Command line is already provided. Can you explain why console output is usefull in this specific case, and you want to push needless efforts to the bug reporter?
If ffmpeg prints some error messages, or crashes or something it might be useful.
However, this is not the case. It just successfully (without any error) creates INCORRECT file.
ALWAYS.
I think I already have made it clear that in what condition it occurs, and HOW and WHY it is incorrect.
I don't think any information beyond this is necessary.

in reply to:  2 comment:3 by Carl Eugen Hoyos, 10 years ago

Replying to nu774:

Sorry, but I don't give a damn to that kind of bureaucracy.

Then why didn't you send a mail to the user mailing list (or to me directly) instead of opening an incomplete ticket here?

Command line is already provided. Can you explain why console output is usefull in this specific case, and you want to push needless efforts to the bug reporter?

At least one of your other reports is completely incomprehensible.

There is a hug number of tickets that were originally opened incomplete (similar to this one), a developer tried to guess what the ticket is about, spend a lot of time on it, and finally it turned out that the OP meant something else than what was guessed and the time was completely wasted.

I don't deny that this is not exactly true for this specific ticket but as said, taken all your tickets from yesterday together I believe it makes a lot of sense to paste your console output (that afaict you already saw when you tested the issue or am I wrong?) here to reduce the possibly wasted time on tickets.

Or - assuming we both agree that time is the only limiting factor in FFmpeg development (which is not necessarily true for open-source development in general) - would you say that it is unexpected that developers work on tickets that are reported with all necessary information instead of incomplete tickets?

comment:4 by Carl Eugen Hoyos, 10 years ago

Reproduced by developer: set
Resolution: fixed
Status: newclosed

Fixed in 4c49d082

Note: See TracTickets for help on using tickets.