decoding this file causes audio glitches in mplayer -demuxer 35, -ac ffmp3, -dumpaudio, nothing helps user reports it playing fine in xine. http://home.twmi.rr.com/compn/mp3audioproblem.mp4 2.1mb -compn
compn wrote:
decoding this file causes audio glitches in mplayer -demuxer 35, -ac ffmp3, -dumpaudio, nothing helps user reports it playing fine in xine.
I have the what is almost certainly the same file (~233MB in total), and have experienced a number of different problems with it which I hadn't quite gotten around to reporting (there's a somewhat incoherent draft saved). I'll note that the vast majority of the audio problems, including all of the most severe ones, don't appear till after the apparent end of that sample; I can provide a larger sample if need be (given somewhere to upload it to, anyway). The most unusual problem I've observed with the file is that, on my system, it plays back too fast (as compared to other files I have which open with the same sequence); the reported framerate is 23.976, but when I specify -fps 22.45 (the number comes from my own observations while transcoding in an attempt to work around the problems) the file plays back at the correct speed. This doesn't fix any of the other problems, but it might be worth looking at on its own; my best guess as to the cause would be the change which I believe was committed from using the codec framerate to using the container framerate, in cases where they are different. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
The Wanderer wrote:
compn wrote:
decoding this file causes audio glitches in mplayer -demuxer 35, -ac ffmp3, -dumpaudio, nothing helps user reports it playing fine in xine.
I have the what is almost certainly the same file (~233MB in total), and have experienced a number of different problems with it
I'll note that there are now two of these files that I know of, from the same source, both exhibiting very similar problems (although, from my limited examination, the second less so than the first). For the time being, there are also working XviD/AVI versions being released in parallel to the problematic x264/MP4 versions, but that will not be the case for much longer. I'll note that unless I'm much mistaken, the people creating these files have claimed to be doing so using either MEncoder or FFmpeg; if that is true, then the cause of the problems may well be there (on the encoding/muxing end) rather than in MPlayer (on the playback end). I very much want this problem fixed, whatever its cause may be; I'd be more than willing to do the work myself, if I had any idea of what *to* do. Even though I don't, I'd be glad to provide whatever assistance I can at any point. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
The Wanderer wrote:
The Wanderer wrote:
compn wrote:
decoding this file causes audio glitches in mplayer -demuxer 35, -ac ffmp3, -dumpaudio, nothing helps user reports it playing fine in xine.
Having now tested the original video: it does not play in xine for me (aborts immediately with "error, NO frame"), and while vlc does play it with perfectly fine audio, it also gives me severely hashed video (to the point that the subtitles are quite thoroughly illegible). (These are stock xine and vlc from current Debian unstable.)
I have the what is almost certainly the same file (~233MB in total), and have experienced a number of different problems with it
I'll note that there are now two of these files that I know of, from the same source, both exhibiting very similar problems (although, from my limited examination, the second less so than the first). For the time being, there are also working XviD/AVI versions being released in parallel to the problematic x264/MP4 versions, but that will not be the case for much longer.
They're up to four files now. There has been a fair amount of discussion of these problems (or what I think are the same ones) on the forums associated with the source of the files, and some people there may be willing to help; if being able to ask questions of the people responsible for creating the files would be useful, then I can see if they would be willing to cooperate. As noted above, vlc can play the audio of any of these source files just fine. However, if I extract the audio with -dumpaudio and play that with anything - MPlayer, ffplay, mpg321, vlc - it exhibits the same popping and scratchiness that are present when playing the source file with MPlayer. Since the audio itself is not damaged (else vlc would not be able to play it correctly), and -dumpaudio is (according to my understanding) supposed to be a byte-for-byte copy of the audio stream, the fact that the dumped audio *is* damaged presumably means that MPlayer is misunderstanding what exactly constitutes the audio stream; that in turn would mean that the problem lies in the demuxer. If no one else is interested in trying to figure out what the problem here is, I'm quite willing to do the work myself - if someone can clue me in on how to go about figuring out what part of the relevant code might be responsible. I know how to track down the cause of a crash (in general, anyway), and I have some experience with tracking down non-crashing bugs in code I know in detail from having written it myself - but I have next to *no* understanding of the MPlayer code, and so no idea of where to get started. (I've never even been able to follow the flow of execution from program start, which is the only place I can think of to start trying to *gain* such an understanding.) The only thing I could really do to try to fix things, without some help, would be to essentially rewrite random parts of demux_mov.c and see what happens; that would probably fix the problem eventually, through the mechanics of any evolutionary process, but it would probably have fried my brain well before that point. I'd also like to note, for the record, that if this post - like my last two on the subject - gets no attention at all, I shall begin to get somewhat angry. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Tue, Nov 08, 2005 at 03:12:41AM -0500, The Wanderer wrote:
I'd also like to note, for the record, that if this post - like my last two on the subject - gets no attention at all, I shall begin to get somewhat angry.
Nevertheless, I'm afraid getting angry will not accomplish much. The MOV demuxer is a hairy beast that nobody really wants to touch. You could try your luck in #mplayerdev and see if you can get people there interested in your problem. Diego
Diego Biurrun wrote:
On Tue, Nov 08, 2005 at 03:12:41AM -0500, The Wanderer wrote:
I'd also like to note, for the record, that if this post - like my last two on the subject - gets no attention at all, I shall begin to get somewhat angry.
Nevertheless, I'm afraid getting angry will not accomplish much.
Well, no. It's what I might do *after* getting angry that might. ^_^ (I didn't say I'd start to rant and rave and fling feces around; that's very rarely productive. There are, however, other possible lines of attack which I'd ordinarily be reluctant to take for fear of giving offense... but when I'm offended enough myself, I don't necessarily care. Fortunately for all concerned, including me, that rarely happens.)
The MOV demuxer is a hairy beast that nobody really wants to touch. You could try your luck in #mplayerdev and see if you can get people there interested in your problem.
I suppose this may be what finally motivates me to figure out which server that's on and go there for a while... ...but my main objection is not so much to "no one is willing to do the work" as "no one pays the slightest bit of attention". It had reached the point that until I looked back and re-noticed all of the different names which have posted here in the not-too-distant past,, I was beginning to wonder if most of the devs were no longer members of this list. Even an acknowledgement that I'd posted in the first place would have helped somewhat. I don't mind so much "no one can help" or even "people might be able to help, but no one is willing to put in the effort"; what I *do* mind is having something which I consider important be entirely ignored. As I noted in both of my last two posts in this thread, I'm quite willing to help, and/or do as much as possible of the work myself - but I do not have the understanding of video handling, audio handling, or container formats in general (much less MOV in particular) necessary to figure out where to begin. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Tue, Nov 08, 2005 at 12:34:12PM -0500, The Wanderer wrote:
The MOV demuxer is a hairy beast that nobody really wants to touch. You could try your luck in #mplayerdev and see if you can get people there interested in your problem.
I suppose this may be what finally motivates me to figure out which server that's on and go there for a while...
freenode
Even an acknowledgement that I'd posted in the first place would have helped somewhat. I don't mind so much "no one can help" or even "people might be able to help, but no one is willing to put in the effort"; what I *do* mind is having something which I consider important be entirely ignored.
It would maybe help if you put the bug in Bugzilla, it's a better means for archiving bugs than this mailing list. Diego
Diego Biurrun wrote:
On Tue, Nov 08, 2005 at 12:34:12PM -0500, The Wanderer wrote:
The MOV demuxer is a hairy beast that nobody really wants to touch. You could try your luck in #mplayerdev and see if you can get people there interested in your problem.
I suppose this may be what finally motivates me to figure out which server that's on and go there for a while...
freenode
Noted.
Even an acknowledgement that I'd posted in the first place would have helped somewhat. I don't mind so much "no one can help" or even "people might be able to help, but no one is willing to put in the effort"; what I *do* mind is having something which I consider important be entirely ignored.
It would maybe help if you put the bug in Bugzilla, it's a better means for archiving bugs than this mailing list.
I keep forgetting we even have a Bugzilla. I'm there now, trying to figure out once again what actually *is* important information. (I have in the past written literally pages on this, not all of which got sent and most of which was probably entirely irrelevant to the specific problem at hand. Some of it may perhaps be relevant to an unrelated bug or three in FFmpeg, but that's another issue.) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Wed, 26 Oct 2005 14:51:14 -0400 The Wanderer <inverseparadox@comcast.net> wrote:
The Wanderer wrote:
compn wrote:
decoding this file causes audio glitches in mplayer -demuxer 35, -ac ffmp3, -dumpaudio, nothing helps user reports it playing fine in xine.
this is incorrect, i found if you combine such commandlines, you can play the audio correctly in mplayer, i figured this out by studying how vlc would do it mplayer 163.mp4 -demuxer 35 -ac +ffmp3 but i'm told that the video speeds up/plays incorrectly at least this gives you correct audio. altho i'm at a loss at why ffmp3 is not handling mp3 audio when demuxed with lavf... old codecs.conf or missing entry?
I have the what is almost certainly the same file (~233MB in total), and have experienced a number of different problems with it
I'll note that there are now two of these files that I know of, from the same source, both exhibiting very similar problems (although, from my limited examination, the second less so than the first). For the time being, there are also working XviD/AVI versions being released in parallel to the problematic x264/MP4 versions, but that will not be the case for much longer.
if you would talk to the guys encoding this, find out what program they use, etc, it would be useful, can we claim broken encoder yet? hehe i've had a 3-4 users come in #mplayer and ask about this problem...
The Wanderer
anyways, i do appreciate your help, i've also removed the sample as i needed the space. i dont think this list gets a lot of eyeballs, but i've seen most of the main developers writing to it (michaelni, rxt, dalias, rc, reimar, sascha , deigo, etc) so i think at least someone might check it out. -compn
On Tue, 22 Nov 2005 18:08:57 -0500 compn <tempn@twmi.rr.com> wrote:
altho i'm at a loss at why ffmp3 is not handling mp3 audio when demuxed with lavf...
Why would it? Codec order isn't format/demuxer-specific.
compn wrote:
On Wed, 26 Oct 2005 14:51:14 -0400 The Wanderer <inverseparadox@comcast.net> wrote:
The Wanderer wrote:
compn wrote:
decoding this file causes audio glitches in mplayer -demuxer 35, -ac ffmp3, -dumpaudio, nothing helps user reports it playing fine in xine.
this is incorrect, i found if you combine such commandlines, you can play the audio correctly in mplayer, i figured this out by studying how vlc would do it
mplayer 163.mp4 -demuxer 35 -ac +ffmp3
but i'm told that the video speeds up/plays incorrectly
It does; if you also specify '-fps 24000/1001' it will play back perfectly. I've seen this discussed on the forums of the people who released the files, and hadn't reached the point of thinking to post it here.
at least this gives you correct audio. altho i'm at a loss at why ffmp3 is not handling mp3 audio when demuxed with lavf... old codecs.conf or missing entry?
For one thing, the audio in the file is misdetected by FFmpeg - it thinks that it's AAC for some reason. (Probably to do with the fact that the audio ID tag in that file - the same data you set with '-fafmttag' - is some eight to sixteen hex digits long, rather than what the MPlayer man page claims is the MP3 standard of '0x55'.) There is an MPlayer bug, in the demuxer; there is also an FFmpeg bug, in the audio-format detection; there may also be a bug in whatever program created the files, in the audio-format tag writing. Stack the two (or three) of them together and you get a metaphorical perfect storm. (It doesn't help that there doesn't appear to be any way to force FFmpeg to use a particular codec when decoding, unlike with MPlayer... at least, none of the things I've tried have worked right.)
I have the what is almost certainly the same file (~233MB in total), and have experienced a number of different problems with it
I'll note that there are now two of these files that I know of, from the same source, both exhibiting very similar problems (although, from my limited examination, the second less so than the first). For the time being, there are also working XviD/AVI versions being released in parallel to the problematic x264/MP4 versions, but that will not be the case for much longer.
if you would talk to the guys encoding this, find out what program they use, etc, it would be useful, can we claim broken encoder yet? hehe
I've tried to contact them, with no real luck so far (although there are avenues still available - f'rinstance, no big-name people were there in their IRC channel last time I tried). I vaguely seem to remember a report, quite some time back when they were still using AVI, that they were doing their encoding and muxing with either MEncoder or FFmpeg... but that does not seem likely at this juncture.
i've had a 3-4 users come in #mplayer and ask about this problem...
I've seen at least one of them on the forums I mentioned, so yes, I'm aware of that. ...I think there was something else I wanted to say in here, but I don't remember offhand what it was. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Tue, 22 Nov 2005 22:56:01 -0500 The Wanderer <inverseparadox@comcast.net> wrote:
compn wrote:
On Wed, 26 Oct 2005 14:51:14 -0400 The Wanderer <inverseparadox@comcast.net> wrote:
The Wanderer wrote:
compn wrote:
decoding this file causes audio glitches in mplayer -demuxer 35, -ac ffmp3, -dumpaudio, nothing helps user reports it playing fine in xine.
this is incorrect, i found if you combine such commandlines, you can play the audio correctly in mplayer, i figured this out by studying how vlc would do it
mplayer 163.mp4 -demuxer 35 -ac +ffmp3
but i'm told that the video speeds up/plays incorrectly
It does; if you also specify '-fps 24000/1001' it will play back perfectly. I've seen this discussed on the forums of the people who released the files, and hadn't reached the point of thinking to post it here.
at least this gives you correct audio. altho i'm at a loss at why ffmp3 is not handling mp3 audio when demuxed with lavf... old codecs.conf or missing entry?
For one thing, the audio in the file is misdetected by FFmpeg - it thinks that it's AAC for some reason. (Probably to do with the fact that
i think i've narrowed down the bugs, maybe they are correct, maybe i'm 100% wrong :) bug #1 in mp3 in mp4 with -demuxer 35 is libavformat using fourcc instead of the mpeg4 elementary stream descriptor atom to pick which audio codec to use. does mplayer use the elementary stream descriptor atom? i think yes? does ffmpeg need to use this instead of fourcc? AAC: MOV track #0: 105 chunks, 948 samples Audio bits: 16 chans: 2 rate: 44100 MOV: Found MPEG4 audio Elementary Stream Descriptor atom (51)! Fourcc: mp4a MP3: MOV track #1: 2886 chunks, 0 samples Audio bits: 16 chans: 2 rate: 48000 MOV: Found MPEG4 audio Elementary Stream Descriptor atom (35)! Fourcc: mp4a bug #2 is mplayer's mp4 demuxer is not demuxing the mp3 audio like libavformat. bug #3 is libavformat demuxing the framerate improperly can someone verify this using ffplay on the same sample? are there more bugs? is my bug list wrong? -compn
compn wrote:
On Tue, 22 Nov 2005 22:56:01 -0500 The Wanderer <inverseparadox@comcast.net> wrote:
compn wrote:
this is incorrect, i found if you combine such commandlines, you can play the audio correctly in mplayer, i figured this out by studying how vlc would do it
mplayer 163.mp4 -demuxer 35 -ac +ffmp3
but i'm told that the video speeds up/plays incorrectly
It does; if you also specify '-fps 24000/1001' it will play back perfectly. I've seen this discussed on the forums of the people who released the files, and hadn't reached the point of thinking to post it here.
at least this gives you correct audio. altho i'm at a loss at why ffmp3 is not handling mp3 audio when demuxed with lavf... old codecs.conf or missing entry?
For one thing, the audio in the file is misdetected by FFmpeg - it thinks that it's AAC for some reason. (Probably to do with the fact that
i think i've narrowed down the bugs, maybe they are correct, maybe i'm 100% wrong :)
bug #1 in mp3 in mp4 with -demuxer 35 is libavformat using fourcc instead of the mpeg4 elementary stream descriptor atom to pick which audio codec to use.
does mplayer use the elementary stream descriptor atom? i think yes? does ffmpeg need to use this instead of fourcc?
AAC: MOV track #0: 105 chunks, 948 samples Audio bits: 16 chans: 2 rate: 44100 MOV: Found MPEG4 audio Elementary Stream Descriptor atom (51)! Fourcc: mp4a
MP3: MOV track #1: 2886 chunks, 0 samples Audio bits: 16 chans: 2 rate: 48000 MOV: Found MPEG4 audio Elementary Stream Descriptor atom (35)! Fourcc: mp4a
bug #2 is mplayer's mp4 demuxer is not demuxing the mp3 audio like libavformat.
If by "like" you mean "in the same way that libavformat does", then yes. By some means MPlayer appears to be using an incorrect idea of what data is and is not part of the audio stream, so it passes either too little data (chopping off in the middle of a frame, or something) or too much data (appending unrelated data after the end of the correct data) to the audio codec.
bug #3 is libavformat demuxing the framerate improperly
It may not just be libavformat, actually. The file plays back too fast (albeit not as much so) in MPlayer as well, when not specifying -demuxer 35. I've gotten it to play back at what appears, subjectively, to be the correct rate by specifying '-fps 22.5' (I got the number from dividing the number of frames by the number of seconds in one of my early transcoding-with-MEncoder test runs, although I haven't been able to reproduce that since), but the default framerate even without libavformat's demuxer appears to have some hiccups in it. (More likely, given that the default framerate with MPlayer's demuxer is 24000/1001, this is another effect of the bug you've labeled as #2.) (I wasn't entirely certain of the above, so I went back and tested just now, and it appears to be the case - judging by the fact that the audio and video do not get out of sync, and the audio is definitely playing too fast. I'll note that although the audio plays at the correct speed with -fps 22.5, it *does* then get out of sync with the video.)
can someone verify this using ffplay on the same sample?
Unfortunately no, because currently if I pass one of the MP4 files as input to either the ffmpeg or ffplay binary I get system-overloading floods of "[aac @ 0x8410e70]faac: frame decoding failed: Channel coupling not yet implemented" errors (I think it's literally hundreds if not thousands per second). In the case of ffplay, the display window does open, but I get neither video nor audio output. This is a result of the same bug you've labeled as #1, above. If I could figure out how to force ffplay to use a given audio codec - in the same way that you can in MPlayer with the plus sign in '-ac +ffmp3' - then I'd be able to test it, but from everything I've seen there doesn't appear to be a way to do that. I have, in the past, been able to get *some* output from ffplay on what I seem to remember were the same files (it's a little blurry in my memory, because I've done so many tests with remuxed/transcoded versions), but current CVS behaves as I've described above. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Tue, 22 Nov 2005 22:56:01 -0500 The Wanderer <inverseparadox@comcast.net> wrote:
I've tried to contact them, with no real luck so far (although there are
anime-destiny now has similar files, altho the sync is ok, the audio still needs -demuxer 35 (for both aac and mp3 audio) and -ac +ffmp3 for mp3 [A-Destiny]_Konjiki_no_Gash_Bell_-_65_[71EE362C].mp4 is one of the problem files, torrents are availible at: http://anime-destiny.org maybe it will be easier to contact a-destiny than KF? also i added this to http://bugzilla.mplayerhq.hu/show_bug.cgi?id=403 -compn
participants (4)
-
compn -
Diego Biurrun -
RC -
The Wanderer