On 7/28/2010 9:37 PM, Nhat Huy wrote:
On Thu, Jul 29, 2010 at 3:03 AM, Michael Chisholm<[email protected]>wrote:
On 7/27/2010 9:24 PM, Nhat Huy wrote:
On Wed, Jul 28, 2010 at 2:53 AM, Michael Chisholm<[email protected]
wrote:
On 7/27/2010 2:35 AM, Nhat Huy wrote:
On Tue, Jul 27, 2010 at 3:04 PM, avcoder<[email protected]> wrote:
On Tue, Jul 27, 2010 at 1:43 PM, Nhat Huy<[email protected]>
wrote:
Hi,
According to your suggestion, I have to write a new av_read_frame
which
points to my bit-stream buffer.
No! you do not need it, just tell ffmpeg your buffer and length ,
FFmpeg will do everything for you
But how can I determine the AVPacket.size which contains each frame in
H.264
bit-stream ?
I will share some pieces of code.
you should grasp my idea based on the code!
Note: my code was based on older FFmpeg APIs.
Thank you very much.
_______________________________________________
That's fine if you're getting only the raw video packets. Not so fine if
you are getting a video stream in some container format and need to go
through all the stream processing. I thought it was the latter.
Andy
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Hi Andy,
I'm dealing with raw H.264 bit-stream, not video format file such as: mkv,
avi thus avcodec_decode_video is what I need. Now I'm thinking how to
determine the size of each frame in bit-stream buffer. I have to pass size
and data of each coded frame in buffer to avcodec_decode_video.
I see that av_read_frame can calculate size, but I do not know how it can
do
that.
Huy.
Ok. I think "av_read_frame" is an unfortunate name for that function. It
reads a packet, not a frame. Packets are the unit of muxing into container
formats, and may not even contain a complete frame. So if you don't have to
deal with that, that function is not relevant.
avcodec_decode_video() (which is deprecated, actually you should use
avcodec_decode_video2()) is built to operate in a "streaming" fashion
(different meaning here than I used before). I mean to say that it's
written to take data a little bit at a time, and once it's received enough
to decode a complete frame, it will let you know (got_picture_ptr will
receive a non-zero value). So you might try just feeding it data directly,
in whatever size chunks make sense for you, and see if you get decoded
frames out.
Andy
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
In H.264 a frame can contain many slices, thus each time I feed
avcodec_decode_video, I have to pass a buffer with complete frame into
avcodec_decode_video. I tried to feed avcodec_decode_video with a slice
bitstream (this frame has 4 slices), and I got a frame with many error
concealment. avcodec_decode_video always outputs a decoded frame without the
knowledge of the buffer contains a complete frame or not, in case H.264.
This is the result if a slice (unfinish frame) feeding into
avcodec_decode_video:
http://img97.imageshack.us/img97/4097/55244522.jpg
Thus I have to calculate exactly the buffer size of a coded frame in buffer
before feeding it. I will borrow these codes from JM
http://iphome.hhi.de/suehring/tml/
Thanks for your help.
Huy.
I don't know how the h.264 decoder works, I just use it ;) So explaining that
behavior is beyond my knowledge. Someone else will have to describe whether
that's expected, libav's bug, your bug, or something else. I have decoded h.264
and other formats (although never from raw encoded data directly, always from
packets I get from libavformat), and I get lots of those error/warning messages,
but I just ignore them and keep going anyway and so far it seems to work well
enough.
Andy
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
