Hi Jesse,
Jeff, to your notes: I spent a little more time experimenting. I find
that for low-res video (e.g. 240x160) I'll just get a single IDR slice
at any time, and then decoding works as well as VLC (I think). At
higher res (e.g. 320x240) I start getting multiple IDR slices in a
row, and then it's artifact-city. If I buffer all IDR slices before
passing to avcodec_decode_video2(), then I finally get clear-looking
frames. The sequence looks something like: [7,8,5,5], [1], [1], [1],
[1], [7,8,5,5], [1], [1]...
So even if I solve the keyframe issue as above, the intervening
P-frames seem to be pushing pixels more than they should. Basically
at each keyframe, I now get a clear image, and in-between, the whole
scene kind of bulges and gets more and more distorted until the next
keyframe. BTW my test example is this one:
rtsp://media1.law.harvard.edu/Media/policy_a/2012/02/02_unger.mov
<http://media1.law.harvard.edu/Media/policy_a/2012/02/02_unger.mov>
(UDP blocked, as Ross pointed out).
So two question:
A) Is it really necessary to collect all, successive I-frames to send
all at once to avcodec_decode_video2(), or might this indicate some
other, larger issue? If I don't collect them all, only one fraction
of the image is clear at a time, with the rest of it totally blurred.
Do you set the context->flags2=CODEC_FLAG2_CHUNKS for the context passed
to avcodec_decode_video2()?
I think this is necessary in order for avcodec_decode_video2() to
properly decode H.264 frames that span multiple calls to it.
--
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
