Hi I am new to x264 and know some basics. The encoding API routine used in x264 cli (x264.c) is summarized as:
call x264_encoder_open and set up parameters.
fetch a frame from input video and encode it with x264_encoder_encode.
iterate 2. until input EOF or the given frame limit is reached.
flush delayed frames.
My problem is: other than flush x264 encoder only once at the end of encoding process, is it possible or not to flush the delayed frames within step 2? For example, I want to flush the encoder manually every 20 frames (or a GOP frames) fed into x264_encoder_encode and resume the normal process when all delayed frames are encoded. Thus as a result the video will have several flush procedures.
Regards
No, it is not possible. As once you send your first NULL-frame to x264_encoder_encode to flush frames it will stop all working threads for encoding so you will need to call x264_encoder_close/x264_encoder_open to start new encoding instance. Btw why you need to flush frames every 20 frames? Because I can't understand such use case.
Related
I have a media server serving several cameras.
I'd like for the server to downsample the data from, say, 20 fps to 1 fps.
Obviously I could do this by decoding and recoding the video frames - however, the server is a little resource constrained. I notice that if I simply drop RTP UDP packets, the output is not so good - I see both tearing and junk in the images (at least with a opencv/ffmpeg client).
Is it possible to downsample within an RTP stream by dropping more carefully chosen frames/packets, to avoid junk and tearing in the output? (Currently I'm able to extract RTP|H264 raw data chunks on the server, but am not running them through a full codec).
An H.264 stream consists of different frame types: I (or IDR), P and B.
I (or IDR) frames are a full pictures and can be decoded without any other frames.
So you could filter out P and B frames and only pass on I frames.
Your resulting frame rates depends on the I (or IDR) frame frequency of the original stream. I am guessing you get somewhere between 0.1 to 2 fps.
We have an application that allows a user to pass an arbitrary Tcl code block (as a callback) to a custom API that invokes it on individual elements of a large data tree. For performance, this is done using a thread pool, so things can get ripping.
The problem is, we have no control over user code, and in one case they are doing a puts that causes memory to explode and the app to crash. I can prevent the this by redirecting stdout to /dev/null which leads me to believe that Tcl's internal buffers can't be emptied fast enough, so it keeps buffering. Heap analysis seems to confirm this.
What I don't understand is that I haven't messed with any of stdout's options, so it should be line buffered, blocking, 4k. So, my first question would be: why is this happening? Shouldn't there already be backpressure applied to prevent this?
My second question would be: how do I prevent this? If the user wants to to something stupid, I'm more than willing to throttle their performance, but I don't want the app to crash. I suppose one solution would be to redefine puts to write to a file (or simply do nothing) before the callback is invoked, but I'd be interested if there was a way to ensure backpressure on the channel to prevent it from continuing to buffer.
Thanks for any thoughts!
It depends on the channel type and how you've configured it. However, the normal model is that writes to a synchronous channel (-blocking true) will either buffer or write immediately (according to the -buffering option) and writes to an asynchronous channel (-blocking false) will, if not processed immediately, be queued to be carried out later by an internal event handler. For most applications, that does the right thing; it sounds like you've passed an asynchronous channel to code that doesn't call into the event loop (or at least not frequently). Try chan configureing the channel to be synchronous before starting the user code; you're in a separate thread so the blocking behaviour shouldn't be a problem for the rest of the application.
Some channels are more tricky. The one that people most normally encounter is the console channel in Tk on platforms such as Windows, where the channel ends up writing into a widget that doesn't have a maximum number of retained lines.
I'm experiencing an issue with a 20 video Flash project. We're calling the videos from a local source, and FLVPlayback is opening netstreams and generating this huge Uncategorized chunk of memory. Upon further inspection, it turns out that it's a large amount of netstream buffers. How do I empty these buffers?
I've found this NetStream.Buffer.Empty but I'm not sure how to properly use it.
Instead of using close(); I used dispose(); to stop, close, and flush the NetStream buffer. Many thanks to #batman
netStream.dispose()
This TIP confused me. It seems to be saying that -buffering line makes the input buffer infinitely large, when I thought line buffering only affected flushing of output? Can't I use -buffersize 5000 together with -buffering line to protect me from people sending long lines? If I can, then what good is chan pending? To discover when the buffer is full without a line break in it?
Or are there two different buffers? One that's just for pre-reading data to save time, and one internal that commands like gets and read use?
EDIT: Or is the problem created only when you use gets because it doesn't return partial lines? Does gets put the stream into an infinite large buffer mode because otherwise if the buffer filled up without a line break, gets could never return it? Is this the "line buffer mode" that the TIP talks about?
First off, the -buffersize option is for output, not input. I've never needed to set it in the past few years; Tcl's buffer management is pretty good.
Secondly, the -buffering option is also for output.
Thirdly, you're vulnerable to someone sending you a vastly long line if you're using blocking channels. You just have no opportunity to do anything other than wait for the end of the line (or the end of the file) to come.
But in non-blocking mode, things are more subtle. You get a readable fileevent for the channel (not relevant for files, but you can check their size is sane more easily, and they're not normally a problem in any case) and do a gets $theChannel line, which returns a -1. (If 0 or more, you've got a complete line.)
So what does the -1 mean? Well, it means that either the line is incomplete or you've got to the end of the stream. You can distinguish the cases with fblocked/chan blocked (or eof to detect the reverse case) and you find that the line isn't there yet. What now? Check to see how much data has been buffered with chan pending input; if there's a silly amount (where “silly” is tunable) then it's time to give up on the channel as the other side isn't being nice (i.e., just close it).
I've yet to see a real use for chan pending output that isn't happier with writable fileevents, but it's not usually a big problem: just using fcopy/chan copy to spool data from large sources to the (slow) output channel works fine without bloating buffers a lot.
I am developing an AIR application for desktop that simulate a drum set. Pressing the keyboard will result in a corresponding drum sound played in the application. I have placed music notes in the application so the user will try to play a particular song.
Now I want to record the whole performance and export it to a video file, say flv. I have already succeed in recording the video using this encoder:
http://www.zeropointnine.com/blog/updated-flv-encoder-alchem/
However, this encoder does not have the ability to record sound automatically. I need to find a way to get the sound in ByteArray at that particular frame, and pass it to the encoder. Each frame may have different Sound objects playing at the same time, so I need to get the bytes of the final sound.
I am aware that SoundMixer.computeSpectrum() can return the current sound in bytes. However, the ByteArray returned has a fixed length of 512, which does not fit in the requirement of the encoder. After a bit of testing, with a sample rate 44khz 8 bit stero, the encoder expects the audio byte data array to have a length of 5880. The data returned by SoundMixer.computeSpectrum() is much much shorter than the encoder required.
My application is running at 60FPS, and recording at 15FPS.
So my question is: Is there any way I can obtain the audio bytes in the current frame, which is mixed by more than one Sound objects, and has the data length enough for the encoder to work? If there is no API to do that, I will have to mix the audio and get the result bytes by myself, how can that be done?