Reuben Martin
Forum Replies Created
-
run “./configure –help” to get a listing of all the options you can set. You can disable building documentation by appending “–disable-doc”. From your config that you listed, you will probably want to disable x11grab as well. That functionality is kinda pointless on a Mac.
-
The jack audio library / include files you have are probably not the correct version. I seriously doubt you need jack support on a Mac anyway. Disable jack support when setting up your configure options.
-
No, ffmpeg will only mux MPEG2 video codec into MXF files. It can demux quite a few different codecs, but until now it has had quite a few bugs. For what it’s worth there has been a lot code commits to improve MXF support over the last few months, but that has not been released yet. Another resource is keep an eye on in libMXF, which has some very handy MXF tools. (https://ingex.sourceforge.net/libMXF/)
But what you probably would be most interested is OpenDCP. (https://code.google.com/p/opendcp/)
-
Several things:
– Place “-f image2” option in front of the “-i” option to make sure the image sequence is handled correctly.
– Avoid muxing codecs into AVI files that are not Intra-Frame only. Avi just does not have the proper mechanisms for dealing with it. Many players have work-arounds to make it work, but each of them implement that their own way so there is no guarantee of consistency. With x264, use something like mp4, mpeg-ts, mkv, etc…
– Another thing about non-Intra-Frame codecs: They are not going to work well with a “slide show” video like this. They encode across multiple frames looking for similarities between frames. Unless the gifs are a continuous video sequence, this will not work well and will smear badly. Try using something like MJPEG. (Which BTW, _does_ work well in an AVI file)
– Nit-pick: frame rates are best represented as numerator/denominator. So instead of “-r 0.667” use “-r 3/2”
– Most importantly: many players do not support low frame rates like this very well at all. ffplay generally shows them correctly, so does the window’s wmplayer oddly enough. But many players do not. Even ones based off of ffmpeg’s av libraries like VLC or mplayer. Make sure the playback problem isn’t just a problem with the player.
-
It should work. You might try specifying the input pix_fmt option in front of the -i option to ensure that 32bit mode is enforced.
You can also try the “qtrle” codec which is basically quicktime animation codec. It supports alpha.
-
Oh, and one more thing, AVI files are absolutely horrible with codecs employing I-P-B frames. If the device supports any other type of container format like MPEG-PS you would be better off trying to mux the streams into that type of container format. Another approach is to encode Intra-frame only. (No P or B frames)
-
If it’s just sync drift, there are async and vsync options that can help deal with that, as well as itsoffset to compensate for delay. However for what you are talking about, it would seem that ffmpeg is miscalculating what the original framerate for the input file is. Try manually specifying the input frame rate of the video by setting another -r options, _before_ the -i options to force the input framerate.
Of course, if the file plays ok with ffplay, it may just be something odd about the device.
-
The “SAR 65536:65535 DAR 16384:13107” is nothing more than bad math programming by whatever crappy framework encoded the file.
Your problem might be that the player does not recognize the fourcc code. Notice that the fourcc code from the sample is 0x44495658 while your encode is 0x64697678. Edit the fourcc to use upper case “XVID” rather than lower case “xvid” and see if that makes it happy.
-
ffmpeg -re -i mmsh://venetian.upx.net.br/00201 -acodec libmp3lame -aq 0 -f mp3 Output.mp3
-
I’m not implying that it’s necessarily better, just different. I don’t use the 0.7.x series any more, so you should take what I say with a grain of salt and understand that what may work for me may not work for you and vice-versa.
One thing of interest from what you posted is this:
[mp4 @ 0x86adc80] Frame rate very high for a muxer not effciciently supporting it.
Please consider specifiying a lower framerate, a different muxer or -vsync 2Your problem might be a sync issue. Try using the “vsync 2” option that it suggests.
It’s more likely though that the problem is with libfaac not supporting the format of the input (16000 Hz, mono, s16) but that your version of ffmpeg does not check for it and tries to force it. My version fails saying libfaac does not support that format. You can try resampling the audio to a format libfaac supports.