Robert Krüger krueger@... writes:
In case of the files I am talking about here, there are no recovery
point SEIs after the first frame so libavformat/avcodec is probably
doing everything correctly, too. Since I think I know that these
streams in fact do have random access points, I will
Hi,
thanks for your help.
Your function above, if i understood correctly, read from raw file, put
data into video_buf and at the end returned the number of bytes read. Now i
want to encode, so i must to pass raw data to avcodec_encode_video2
function, that takes input raw video data from frame.
Robert Krüger krueger@... writes:
If my debug output is correct, both contain no
B-slices/frames (I just noticed that) but they
do contain I-slices/frames. If I am not missing
something, those I-Frames should be valid random
access points then.
Do you mean you debugged the sample (with
On Mon, Oct 21, 2013 at 4:21 PM, Carl Eugen Hoyos ceho...@ag.or.at wrote:
Robert Krüger krueger@... writes:
If my debug output is correct, both contain no
B-slices/frames (I just noticed that) but they
do contain I-slices/frames. If I am not missing
something, those I-Frames should be valid
Robert Krüger krueger@... writes:
Since only P- and I-slices are parsed (I can see that
in the debug output), I would indeed expect every
I-frame (meaning any frame only consisting of one
I-slice in the stream) to be a valid access point
So you mean a P-frame after an I-frame is not
Robert Krüger krueger@... writes:
Even better. Which commit are you talking about?
Iirc, fixed ticket with keyword h264.
You mean 2738?
I believe this is the one I meant.
Carl Eugen
___
Libav-user mailing list
Libav-user@ffmpeg.org
On Mon, Oct 21, 2013 at 6:38 PM, Carl Eugen Hoyos ceho...@ag.or.at wrote:
Robert Krüger krueger@... writes:
Btw, is it intentional that you don't answer questions
I ask in my emails?
Please understand that you know much more than I do about
H.264 so I simply cannot answer most of your
Hello all,
I am writing a an application that encodes incoming video in H.264 using
libavcodec and libx264. However, I noticed that the output data was much
larger than I expected. When I examined the output, I discovered that the
encoder was only producing I- and P-frames and never
Robert Krüger krueger@... writes:
I was interested to know how you found out that
ffmpeg thinks the 28th frame is a random access
point
I concatenated the second until the 29th frame of the
input sample and tested decoding with current FFmpeg.
I also wanted to test with the reference
