I'm trying to decode the H.264 trailer for Serenity: http://www.apple.com/quicktime/hdgallery/serenity.html (it's a .mov in a 136 MiB .zip; I can put up short excerpts of the .mov if that would be useful to low-bw people) It plays mostly fine (excepting the fact that my Athlon XP 1466 is nowhere fast enough); I get no errors out of mplayer or ffmpeg on it, but I get corruption in the bottom 1/2 of the image, as shown in this screenshot (was playing this time with mplayer -xy .5 to cram it on my puny 1152x864, so the file's res is actually twice as high and wide): http://kuoi.asui.uidaho.edu/~wes/images/serenity-corrupt.jpg The file resolution is ginormous--1920x816--and the corruption is always in the lower part of the image, so I'm wondering if a counter is overflowing somewhere in the decoder. Or does Apple's encoder just suck? What I've tried: * initially was trying using a copy of mplayer built with sources updated from CVS on April 26 (same for libavcodec) * then just now I updated ffmpeg again, to make sure I'm using the absolute latest, and converted the file to mpeg4 with it, to take mplayer out of the H.264 decoding part, even though it's just using libavcodec anyway. Command was "ffmpeg -i serenity_1080p.mov -acodec copy -vcodec mpeg4 -b 16000 ser.avi". No improvement. * Just in case it was mplayer having problems with any video of large dimensions, I then tried scaling it down while converting: "ffmpeg -i serenity_1080p.mov -acodec copy -vcodec mpeg4 -b 16000 -s 480x204 ser-small.avi". Still no joy. I'm running Fedora Rawhide (the devel tree) so there's no guarantee it's not something else on my system. Neither ffmpeg nor mplayer will build with gcc4 (it seems to be stricter with inline asm), so I've been using gcc32. ffmpeg says: "built on Mar 27 2005 20:34:29, gcc: 3.2.3 20030502 (Red Hat Linux 3.2.3-47.fc4)" Anyone else see this problem with this file? Any ideas for other things I should try? --wes
Hi On Tuesday 03 May 2005 08:16, Wes Shull wrote:
I'm trying to decode the H.264 trailer for Serenity:
http://www.apple.com/quicktime/hdgallery/serenity.html
(it's a .mov in a 136 MiB .zip; I can put up short excerpts of the .mov if that would be useful to low-bw people)
It plays mostly fine (excepting the fact that my Athlon XP 1466 is nowhere fast enough); I get no errors out of mplayer or ffmpeg on it, but I get corruption in the bottom 1/2 of the image, as shown in this screenshot (was playing this time with mplayer -xy .5 to cram it on my puny 1152x864, so the file's res is actually twice as high and wide):
http://kuoi.asui.uidaho.edu/~wes/images/serenity-corrupt.jpg
The file resolution is ginormous--1920x816--and the corruption is always in the lower part of the image, so I'm wondering if a counter is overflowing somewhere in the decoder. Or does Apple's encoder just suck?
What I've tried: * initially was trying using a copy of mplayer built with sources updated from CVS on April 26 (same for libavcodec) * then just now I updated ffmpeg again, to make sure I'm using the absolute latest, and converted the file to mpeg4 with it, to take mplayer out of the H.264 decoding part, even though it's just using libavcodec anyway. Command was "ffmpeg -i serenity_1080p.mov -acodec copy -vcodec mpeg4 -b 16000 ser.avi". No improvement. * Just in case it was mplayer having problems with any video of large dimensions, I then tried scaling it down while converting: "ffmpeg -i serenity_1080p.mov -acodec copy -vcodec mpeg4 -b 16000 -s 480x204 ser-small.avi". Still no joy.
I'm running Fedora Rawhide (the devel tree) so there's no guarantee it's not something else on my system. Neither ffmpeg nor mplayer will build with gcc4 (it seems to be stricter with inline asm), so I've been using gcc32. ffmpeg says: "built on Mar 27 2005 20:34:29, gcc: 3.2.3 20030502 (Red Hat Linux 3.2.3-47.fc4)"
Anyone else see this problem with this file? Any ideas for other things I should try?
retry with latest cvs, loren merritt did check in some fix a few days ago which might have fixed this -- Michael "nothing is evil in the beginning. Even Sauron was not so." -- Elrond
On 5/5/05, Michael Niedermayer <michaelni at gmx.at> wrote:
retry with latest cvs, loren merritt did check in some fix a few days ago which might have fixed this
Ok, cvsuped and rebuilt both ffmpeg and mplayer. Strangely, mplayer is now working correctly, but ffmpeg was still behaving the same. Then I noticed: # which ffmpeg /usr/local/bin/ffmpeg # ldd /usr/local/bin/ffmpeg [...] libavformat.so => /usr/lib/libavformat.so (0x009a3000) libavcodec.so => /usr/lib/libavcodec.so (0x039eb000) D'oh. It was picking up old libraries that I hadn't uninstalled. Mplayer was ok because I always build it with a static copy of libavcodec copied over from my cvs dir. Anyway, I took care of that mess, and now ld.so is grabbing the right libraries for ffmpeg. But: $ ffmpeg -i serenity_1080p.mov -acodec copy -vcodec mpeg4 -b 16000 ser.avi ffmpeg version 0.4.9-pre1, build 4754, Copyright (c) 2000-2004 Fabrice Bellard configuration: --enable-gpl --enable-pthreads --enable-shared --enable-mp3lame --enable-libogg --enable-vorbis --enable-faad --enable-faadbin --enable-faac --enable-xvid --enable-pp --enable-shared-pp --cc=/usr/bin/gcc32 built on May 6 2005 12:36:04, gcc: 3.2.3 20030502 (Red Hat Linux 3.2.3-47.fc4) track[1].ctts.entries = 3299 Input #0, mov,mp4,m4a,3gp,3g2, from 'serenity_1080p.mov': Duration: 00:26:14.6, start: 0.000000, bitrate: 737 kb/s Stream #0.0: Audio: aac, 48000 Hz, stereo Stream #0.1: Video: h264, yuv420p, 1920x816, 23.98 fps File 'ser.avi' already exists. Overwrite ? [y/N] y Output #0, avi, to 'ser.avi': Stream #0.0: Video: mpeg4, yuv420p, 1920x816, 23.98 fps, q=2-31, 16000 kb/s Stream #0.1: Audio: aac, 48000 Hz, stereo Stream mapping: Stream #0.1 -> #0.0 Stream #0.0 -> #0.1 [mpeg4 @ 0x756280]timebase not supported by mpeg 4 standard Error while opening codec for output stream #0.0 - maybe incorrect parameters such as bit_rate, rate, width or height If I add "-r 23.976" ("ffmpeg -i serenity_1080p.mov -acodec copy -vcodec mpeg4 -b 16000 -r 23.976 ser.avi") it at least does the encode, but says "[mpeg4 @ 0x7e0280]removing common factors from framerate", and the resultant file does not have proper a-v sync. Is it accidentally rounding the framerate, or does the .mov really have 23.98? Lessons so far: * ffmpeg rocks * ffmpeg team rocks * I suck --wes
On Fri, 2005-05-06 at 13:03 -0700, Wes Shull wrote:
Lessons so far: * ffmpeg rocks * ffmpeg team rocks * I suck
A thought: if you don't want to have files lying around everywhere on your filesystem, consider making packages (ok, your system must have some sort of package format and you will have to dig into it, but then this problem is gone for good).
participants (3)
-
erik＠slagter.name -
michaelni＠gmx.at -
wes.shull＠gmail.com