Dear Stephan, hello everyone,

Thank you Stephan for your detailed explainations. I understood it. Now I come 
to the conclusion, that the support for 1080i h.264 coded streams in libav is 
not very well (Sorry I don't want to cry or to be unpolite!!! libav is a good 
library!!!).

At now I want to know, when does av_read_frame support reading interleaced 
h.264 frames corectly? Is it planned? 

regards,
Sven

Am Tuesday 04 August 2009 17:40:57 schrieb Stephan Assmus:
> Hi,
>
> On 2009-08-04 at 17:06:33 [+0200], Sven Alisch <[email protected]> wrote:
> > > This is wrong, you need to open the stream like this, by passing your
> > > IO context to av_open_input_stream():
> > >
> > >     ByteIOContext ByteIOCtx;
> > >     init_put_byte(&ByteIOCtx, pDataBuffer, lSize, 0, this, &my_read,
> > >     NULL,
> > >         NULL); ...
> > >
> > >     av_open_input_stream(&YourAVFormatContext, &ByteIOCtx, "",
> > >         TheAVInputFormat, TheAVFormatParametersOrNULL);
> >
> > Ok too. Then I have further questions:
> >
> > 1) pDataBuffer and lSize are variables that you declare yourself? And how
> > big should pDataBuffer be?
>
> That is a very valid question. In the example I read, I saw "BUFSIZ" (some
> POSIX define) being used. But I found that 64K was a good buffer size, for
> the initial probing. 4K would probably have been sufficient. What I just
> wrote actually makes only sense, because I was using the same buffer and
> read function to read the initial probing data. This may not even apply to
> you.
>
> What happens, and that is important for your next question as well, is that
> this is a very simple, low-level, raw data reading function. libavformat
> will buffer the data your returned internally as it needs. If your buffer
> is smaller, than there will be more calls to your read() hook, if it is
> larger, there will be less. So it depends a bit on what you need. If you
> read larger chunks at once by supplying a bigger buffer, it may be a bit
> faster (more buffering), there will be a sweet spot.
>
> > 2) What is my influence to av_read_frame if I use such a callback
> > function
> > my_read? Is it right that I can make av_read_frame to deliver a complete
> > frame consists of several NAL-Packets?
>
> I can see where this is going, but I guess it heavily depends on the
> demuxer that you are using. If it expects packtes at certain offsets, then
> you can't just filter the data as you like and shuffle packets around
> inside the buffer you return. I guess with a non-seekable streaming format,
> you should have more freedom to do this, since the demuxer cannot know in
> advance what kind of packet will come next (?) so as long as you assemble
> valid stream chunks, it should be fine.
>
> > 3) My Callbackfunction my_read looks like:
> >
> > int my_read(void* opaq, uint8_t* buf, int size)
> > {
> >   ...
> >
> >   return size;
> > }
> >
> > Depends the content of an AVPacket readed by av_read_frame by the size I
> > return in my_read?
>
> Ahm, no, your read() hook is used before AVPackets even enter the picture.
> Unless you are piping two AVFormatContext instances, which would be weird.
>
> Maybe an example is due. Suppse I am reading an AVI file via my own read()
> hook. Maybe I supplied a 4K buffer. libavformat will probably read all of
> 4K, even if this has nothing to do with the chunk data inside those 4K.
> Suppose there is a 3500 byte video chunk inside the data I returned, and a
> 200 byte audio data chunk. When I later call av_read_frame(), it may return
> the video chunk encapsulated in an AVPacket. A second call to
> av_read_frame() will return the audio chunk. Then the AVI demuxer knows the
> next video chunk is 3000 bytes. Then it will assemble the remaining 300
> bytes from the previes read() invokation, and invoke the next read() to
> fetch another 4K, which will contain the remaining 2700 bytes of the video
> chunk. Do you see how this works? Providing your own read() hook is at the
> lowest level of feeding data into libavformat. AVPackets and demuxing comes
> at the next level, read() has little to do with it.
>
> > My goal is to cut an transportstream consisting of h.264-content and
> > audiocontent. The only obstacle is that av_read_frame give me corrupted
> > h.264 frames. MPEG2 is much easier. :-( Therefore I need a correct
> > working av_read_frame in connection with h.264-bitstream.
>
> If you need to filter out some packets from the stream, so that libavformat
> never sees them, then you would have to demux the stream yourself and skip
> unwanted packets. I suppose you could even do this using another
> AVFormatContext, but are you sure that this is the cause for your problems?
> At this point, I am afraid that I know too little of what you are doing,
> combined with my relative incompetence with regards to the FFmpeg libs,
> that I cannot help you with good advice. I did have to write my own
> read()/seek()/write() hooks and am using a ByteIOContext, so I can tell you
> my findings with that. An alternative for using a ByteIOContext is writing
> your own URLProtocol, but so far it seemed to me like it is more code for
> the same thing.
>
> Best regards,
> -Stephan
> _______________________________________________
> 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

Reply via email to