Hi Robert,
Robert Varttinen wrote:
[...]
> I've been looking at the examples and I think I have the big picture.
> Probably missing some though, so please feel free to point me in the right
> direction. Any hints and suggestions are greatly appreciated.
I suspect apiexample.c might contain some example code that can be
useful to you.
> My first realization was to make use use of the 'init_put_byte'
I do not think you need to play with init_put_byte() in your program.
If you want to demux some kind of multimedia container from a memory buffer,
then you need to implement an URLProtocol reading from a memory buffer
(instead of a file). If, instead, you already have a demuxed elementary
stream, then you do not need libavformat and you can directly use something
similar to apiexample.c.
Where is your input stream coming from, BTW?
> and ' av_open_input_stream' functions in ffmpeg.
I am not sure if directly calling av_open_input_stream is a good idea.
If you want to use libavformat, you should probably use av_open_input_file()
(using a special url protocol, as said above).
> Well, so far, so good. I do now realize that I will have to deal with threads
No. You _can_ use threads if they make things simpler for you, but you
are not forced to use threads (so, using threads or not is your design
choice).
> So, to my question: could you please give some advice on how correctly
> structure the code? I.e. what do I need to do codewise for a minimal
> implementation? I have looked at the examples bundled with ffmpeg and
> ffmpeg-java, and I think I've got the big picture as mentioned above, in
> which order to makes calls to the ffmpeg libs, etc. Unfortunately they all
> take files as input... and produces either a file output or displaying a
> videos in a window frame ...
For the input, I think you can either avoid using libavformat (if you
already have the demuxed ESs) or implementing an URLProtocol which reads
from a memory buffer instead of a file (as mentioned above). In the
second case, you can use libavformat for reading the input stream (look
at pktdumper.c for some example code).
For the output, you can use url_open_dyn_buf() & friends (as done, for
example, in ffserver.c) for obtaining the output stream in a buffer instead
of writing it to a file.
> I realize, despite my lack of proficiency in C/C++ and threads, that I need a
> separate thread to read bytes (or chunks of bytes) from the input stream.
No, you do not _need_ separate threads. You _can_ use separate threads if
this helps you. But if separate threads confuse you instead of simplifying
your work, then you can use a single-threaded application (such as ffmpeg.c).
Is there anything to be considered when writing to a stream, instead of a file?
As said above, look at ffserver.c, and at how it uses the url_*_dyn_buf()
functions.
Luca
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
