I've been using OpenCV for quite some time now and I always ignored more or less an oddity that occurs while writing AVIs with OpenCV commands. But now I need it for another purpose and it has to be accurate.
When I read a XVID compressed AVI with cvCaptureFromFile (or FromAVI) and then write the frames with cvVideoWriter (choosing XVID compression from the W32 menu) the resulting AVI always lacks the last frame of the original vid. That frame is also ignored while reading unless the input vid is an uncompressed AVI but in that case when I choose uncompressed (or a codec) for saving the last frame makes trouble and the program aborts leaving no readable AVI file.
What can I do about it, anyone know?
Cheers
Stephan
1) Upgrade to the newest OpenCV available and try again.
2) If that doesn't work, you'll have to choose another multimedia framework to read the frames: ffmpeg or gstreamer.
That's all I can think right now.
Related
I have a series of jpegs,I would like to pack and compress them to a Video.
I use tool mpeg streamclip, but it double the whole play time.
If I have 300 jpegs, set fixed fps 30, I expect to get a video of 10s length . but using stream clip I get a 20s long video.
One answer is to get someone who understands programming. The programming APIs (application interfaces, the way client programs call libraries) to the lig libraries like ffmeg have ways in which frame rate can be controlled, and it's usually quite a simple matter to modify a program to produce fewer intermediate frames if you are creating a video from a list of JPEGs.
But the best answer is probably to find a tool that supports what you want to do. That's not a question to ask a programmer especially. Ask someone who knows about video editing. (It would take me about two days to write such a tool from scratch on top of my own JPEG codec and ffmpeg, so obviously I can't do it in response to this question, but that's roughly the level of work you're looking at).
I have an H264 stream (IIS - smooth streaming) that I would like to play with SilverLight. Apparently SilverLight can do it, but how?
Note: the VC-1 stream can be played by the SilverLight, but H264 not.Also, I can provide a stream and any additional information required. H264 encoder is the one in Media Foundation (MFT). Same goes for the VC-1 that works (although is it impossible to create equal chunks for smooth streaming because forcing key-frame insertion makes video jerky.EDIT: MPEG2VIDEOINFO values for H264:
Just a guess. Based on your question 18009152. I am guessing you are encoding h.264 using the annexb bitstream format. According to comments, you can not tell the encoder to use AVCC format. Therefore, you must perform this conversion manually (Annex B WILL NOT work in an ISO container). You can do this by looking for start codes in your AVC stream. A start code is 3 or 4 bytes (0x000001, 0x00000001). You get the length of the NALU by locating the next start code, or the end of the stream. Strip the start code (throw it away) and in its place write the size of the NALU in a 32bit integer big endian. Then write this data to the container. Just to be clear, this is performed on the video frames that come out of the encoder. The extra data is a separate step that appears you have mostly figure out (except for the NALUSizeLength). Because we uses a 4 byte integer to write the NALU sizes, you MUST set NALUSizeLength to 4.
Silverlight 3 can play H264 files. Use MediaStreamSource for this.
Here is the interface description: http://msdn.microsoft.com/en-us/library/system.windows.media.mediastreamsource(v=vs.95).aspx
Also, this blog entry is related to H264 playing sing Silverlight 3: http://nonsenseinbasic.blogspot.ru/2011/05/silverlights-mediastreamsource-some.html
It will help you with other issues that may arise.
Short Version:
I am looking for a library or sample code in either C or Actionscript which allows me to find the byte offset in a FLV file for each keyframe. I am aware that the spec is published at http://download.macromedia.com/f4v/video_file_format_spec_v10_1.pdf but wading through it and writing reliable code would, hopefully, be reinventing the wheel ;)
Longer version:
In Actionscript- I am successfully using netStream.appendBytes() to play a flv file. However, now I want to enable seeking.
It seems that I must change the stream offset to the beginning of a keyframe in the file, simply seeking to any position in the file does not work (neither when using NetStreamAppendBytesAction.RESET_SEEK nor NetStreamAppendBytesAction.RESET_BEGIN)
However, I'm not sure how to determine where that is. Even if the file were encoded with CBR and I knew the timecode for a keyframe, it would still need to be after the header which could be any length.
So I am looking for a library or solution in either C or Actionscript which allows me to find the byte offset in the file of each keyframe- that way I'll have the precise value and can even use VBR
(C will be used either to find this information beforehand, or possibly at runtime via alchemy)
Use netStream onSeekPoint event :
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/NetStream.html#event:onSeekPoint
What I wish to do is to "split" an .mp3 into two separate files, taking duration as an argument to specify how long the first file should be.
However, I'm not entirely sure how to achieve this in C. Is there a particular library that could help with this? Thanks in advance.
I think you should use the gstreamer framework for this purpose. So you can write an application where you can use existing plugins to do this job. I am not sure of this but you can give it a try. Check out http://gstreamer.freedesktop.org/
For queries related to gstreamer: http://gstreamer-devel.966125.n4.nabble.com/
If you don't find any library in the end, then understand the header of a mp3 file and divide the original file into any number of parts and add individual headers to them. Its not gonna be easy but its possible.
It can be as simple as cutting the file at a position determined by the mp3 bitrate and duration requested. But:
your file should be CBR - that method won't work on ABR or VBR files, because they have different densityes
your player should be robust enough not to break if it gets partial mp3 frame at a start. Most of the playback libraries will handle mp3s split that way very gracefully.
If you need more info, just ask, I am on the mobile and can get you more info later.
If you want to be extra precise when cutting, you can use some library to parse mp3 frame headers, and then write frames that you need. That way, and the way mentioned before, you'll get only frame alignment as a minimum, and you have to live with thaty and that's 40ms.
If that isn't enough, you must decode mp3 to PCM, split at sample boundary, then recompress to mp3 again.
Good luck
P.s.
When you say split, I hope you don't expect them to play one after another with no audible 'artifacts'. Mp3 frames aren't self-sufficient, as they carry information from the frame before.
I'm writing some physics simulations in c for university, and now I output a series of hundreds of png that I then watch in fast sequence... is there a way to merge them to a video in c with some simple lossless codec library?
P.S. I'm using cairo graphics and have very little experience in graphics programming in general
If you want to avoid using an external program, libavcodec is probably the best way to generate video. It's in C, and quite well documented (see the above link).
More documentation on Jonas' solution using mencoder is here.
Not exactly what you are asking for but I wouldn't roll my own, I would use mencoder:
mencoder mf://*.png -mf w=800:h=600:fps=25:type=png -ovc raw -oac copy -o output.avi
PS. mencoder is part of MPlayer and is Open Source. DS.
You just want to watch some PNGs as a video? You don't need to merge them:
mplayer -fps 2 mf://*.png
There are fast lossless codecs in ffmpeg's libavcodec, if you want to do that instead of write PNGs. e.g. ffvhuff, or huffyuv.
Or if you don't want to use libavcodec, you could write y4m raw output and pipe it to something. yuv4mpeg is a header with the frame rate and frame size, and then the uncompressed pixels for each frame just raw.