[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BAE73C66-D2B7-44A5-8CD9-72D0430BEED7@getmailspring.com>
Date: Wed, 16 Sep 2020 10:43:42 -0300
From: "Daniel W. S. Almeida" <dwlsalmeida@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
"r.verdejo@...sung.com" <r.verdejo@...sung.com>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
"nicolas@...fresne.ca" <nicolas@...fresne.ca>,
Shuah Khan <skhan@...uxfoundation.org>,
"linux-kernel-mentees@...ts.linuxfoundation.org"
<linux-kernel-mentees@...ts.linuxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH] media: vidtv: fix build on 32bit architectures
Hi Mauro, Geert,
> That doesn't seem to be the right thing to do here.
>
> Assuming that sampling rate is 48 kHz, you'll
> have duration = 1.875, which would be rounded to 1.
>
> In other words, the above is identical to:
>
> au->pts = count
>
> Now, I don't know from where that CLOCK_UNIT_90KHZ came from.
>
Mauro, here's my current understanding:
The values for PTS have to be defined in terms of a 90khz clock.
So for 30fps video, the values for PTS per frame would be:
frame_num/30 * 90000
so 0, 3000, 6000, 9000...etc
The same math is being used here for audio, but instead we have the
total audio sample count and a 48000 samples/sec
I did miss this rounding error though, I'm sorry.
Powered by blists - more mailing lists