Hi,
Stas Oskin wrote:
> Hi Luca.
>
> Sorry for delay in getting back to you. I would like to continue this topic.
>
>
>> This actually is an almost-constant-frame-rate (I think it is constant
>> frame
>> rate with some rounding errors) at 5fps. Look at the timestamps...
>>
>
> What do you mean by timestamps?
I mean: read the frames in the file you posted, and look at the timestamps
associated to them. If you do not know how to do it, use something like this
patch:
Index: tools/pktdumper.c
===================================================================
--- tools/pktdumper.c (revision 15644)
+++ tools/pktdumper.c (working copy)
@@ -100,7 +100,8 @@
while ((err = av_read_frame(fctx, &pkt)) >= 0) {
int fd;
snprintf(pktfilename, PATH_MAX-1, fntemplate, pktnum,
pkt.stream_index, pkt.pts, pkt.size, (pkt.flags & PKT_FLAG_KEY)?'K':'_');
- printf(PKTFILESUFF"\n", pktnum, pkt.stream_index, pkt.pts, pkt.size,
(pkt.flags & PKT_FLAG_KEY)?'K':'_');
+// printf(PKTFILESUFF"\n", pktnum, pkt.stream_index, pkt.pts, pkt.size,
(pkt.flags & PKT_FLAG_KEY)?'K':'_');
+ if (pktnum) printf("%d %"PRId64" %"PRId64"\n", (int)pktnum, pkt.pts,
pkt.pts / pktnum);
//printf("open(\"%s\")\n", pktfilename);
if (!nowrite) {
fd = open(pktfilename, O_WRONLY|O_CREAT, 0644);
and then run "tools/pktdumper -n sample2.mp4". You will see something
like
1 200 200
2 400 200
3 600 200
4 800 200
5 1000 200
6 1200 200
7 1400 200
8 1600 200
9 1800 200
10 2000 200
[...]
5370 1074006 200
5371 1074206 200
5372 1074406 200
5373 1074606 200
5374 1074806 200
5375 1075006 200
showing that this is basically a constant frame rate file.
In your previous file, you had
1 80 80
2 160 80
3 200 66
4 280 70
[...]
12234 1178922 96
12235 1179122 96
12236 1179322 96
12237 1179522 96
12238 1179722 96
showing that the frame rate is almost monotonically decreasing.
> I do know
> that we get very inconsistent timestamps from the source, so they should be
> the same here.
I do not know what you mean by inconsistent, but the two files you
posted are quite different (in the first one, the difference between a
timestamp and the previous one is monotonically increasing, in the
second one such difference is constant).
Since you say that in both cases you used the input timestamps for
writing the output, this means that the source is not behaving in the
same way in the two cases...
>> The video encodes a still scene, so there is no way to see if movements are
>> more jumpy at the beginning or at the end. And it seems to be encoded at
>> 12.5kbps, so quality is pretty bad...
>>
>
> Well, this is the strangest part - the video is actually encoded in 250Kbps.
> Moreover, it's streamed in this quality (250Kbps) as well.
>
> I really can't get why it's written/played back in such format, do you have
> any ideas on your side?
I do not know. Maybe using wrong timestamps creates problems to the rate
control mechanism?
Luca
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
