tor 2019-08-22 klockan 10:34 +0200 skrev Michael Niedermayer: > On Thu, Aug 22, 2019 at 10:23:40AM +0200, Paul B Mahol wrote: > > On Thu, Aug 22, 2019 at 10:16 AM Michael Niedermayer < > > mich...@niedermayer.cc> > > wrote: > > > > > On Thu, Aug 22, 2019 at 10:09:30AM +0200, Paul B Mahol wrote: > > > > Why not fix issues listed in decoder code instead of this hack?
I think there's better things we could have Michael do. That said: > > Also all this old game codecs never used very high resolutions. > > Max something vga, but not even that. > > limiting to 640x480 instead of 4096x4096 would give a factor of about > 55 > speedup, thats still a long way from 2000 so that solves also only > part of it > > anyway ill provide a patch that limits resolution so theres something > that can be discussed. The probing in lavf/idcin.c already limits the resolution to 1024x1024. The only sample we have is 320x240. The Quake 2 decoder (cl_cin.c) limits CIN frames to 128 KiB compressed, from which the 1024x1024 limit in idcinvideo.c likely derives (128 KiB == 1 Mib == 1 Mipx if always using the shortest Huffman code). Zero-byte packets are also not allowed. If we're looking over this anyway we could toss in all these limitations, and maybe limit audio to 11025, 22050 and 44100 Hz. I also notice that idcinvideo.c contains code copy-pasted from cl_cin.c in Quake 2 (SmallestNode1 -> huff_smallest_node). The copyright header should reflect this. /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
