Hi,
I finally found some time to play with ffh264 again, and I found out
that it sets avctx->coded_frame to NULL.
Since ffmpeg.c contains code for supporting this situation, I assume
that avctx->coded_frame == NULL is valid. But this makes impossible to
know the frame quality, the frame type, and to recognize key frames.
So, I tried to add support for coded_frame... I came up with the
attached patch, but I do not know if it is correct (in particular, is it
ok to set coded_frame = &t->po?).
After applying this patch ffmpeg shows a reasonable "q=" value while
encoding (I hope it is correct). I am not setting coded_frame->pts yet,
but I expect that something like avctx->coded_frame->pts = ((AVFrame
*)data)->pts should work...
Finally, when preparing this patch I had some doubts about t->po: if I
understand it correctly, t->po contains the encoded frame... Is this
right? If yes, why is it allocated with
"avpicture_alloc(&t->po, avctx->pix_fmt, width, height);", implying that
it contains non-compressed video? Also, why not directly allocating
t->po_data0 instead of allocating t->po and doing t->po_data0 =
(uint8_t *)t->po.data[0];?
Sorry for the dumb question; I'm just trying to get acquited with the
code...
Thanks,
Luca
--
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
N O W A R ! ! !
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coded_frame.diff
Type: text/x-patch
Size: 927 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070125/6d82a415/attachment.bin>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4