Thank you for your swift reply,
I examined the sample code you mentioned; apiexample.c. Missed that one!
However, I found it very interesting, specially the audio_decode_example() and
audio_encode_example() functions. I think these two combined more or less does
what I want to do. Instead of reading and writing to and from files I am
currently trying out reading and writing to and from buffers instead. Thanks
for the pointer!
Does the encoding take care of any headers and trailers defined by the format
in question?
Thanks again,
//Robert
P.S. The input stream will come from a Java class running in the same process.
As for a test I am reading audio data from a .flv file and is treated as a
stream (Java Inputstream). The code I am working on is implemented in C/C++,
seems simpler for the moment, so I am using JNI. There is a ffmpeg-java
project relying on JNA, but it did not have a workable init_put_byte() so I
started on this track. There will definitely be some refactoring!
Why stream? We do not want to use files and having to spawn a separate process
every time a conversion is to take place. Want (need) to do it in process ...
On 7/10/08 1:14 PM, "Luca Abeni" <[EMAIL PROTECTED]> wrote:
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
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
