Hi all,
we're using libav* binded to custom IO, so it's possible to use our http
client instead of libav* one. I've noticed that application is not even
trying to decrypt HLS + AES* chunks and fails with exception "Error when
loading first segment". The loop:
1. Bind io_open, io_close, seek, read
Hello Mark,
It works. Thanks a lot.
Regards,
Jinbo Li
- Message original -
De: "Mark Thompson"
À: "libav-user"
Envoyé: Lundi 19 Novembre 2018 14:59:09
Objet: Re: [Libav-user] hardware encoding on Raspberry Pi using Openmax has
issue of time stamp
On 19/11/18 18:14, Jinbo Li wrote:
>
On 19/11/18 18:14, Jinbo Li wrote:
> Hello,
>
> Hello, I have an issue on implementing hardware encoding on raspberry pi by
> using openmax. The problem is that I always get wrong time stamp in my
> AVpacket even right after it gets initialized, the time stamp was always
> assigned to be 634 (s
Hello,
Hello, I have an issue on implementing hardware encoding on raspberry pi by
using openmax. The problem is that I always get wrong time stamp in my AVpacket
even right after it gets initialized, the time stamp was always assigned to be
634 (seems to be the numerator of time base) and it d
So the way I am decoding should be correct, if I am not mistaken.
Is there a way to get around my avcodec_send_packet() performance issues?
Can you pre-send packets or use an option to increase buffer size?
El lun., 19 nov. 2018 a las 15:37, Carl Eugen Hoyos ()
escribió:
> 2018-11-15 13:30 GMT+0
2018-11-15 13:30 GMT+01:00, Omar Álvarez :
> I am trying to decode a h264 3Kx3K video file using NVDEC and ffmpeg 4.0.
>
> I am having a problem when avcodec_receive_frame() returns AVERROR(EAGAIN),
> and I try to get the next packet with avcodec_send_packet(). It sometimes
> takes 40-60 ms to retu
First of all, thanks for the response.
I just tested git head and current drivers, and the problem persists.
My hardware:
Intel i5-6400
Nvidia GTX 1050
Right now, I am decoding more or less like this:
while
{
avcodec_send_packet()
while (more_frames)
{
avcodec_receive_fram
