>> Even if that were true (which I have no idea to be honest) are you sure >> you’re not assuming a raw uncompressed source and no compression afterwards >> either? > > Frames 3, 8, 13, 18, etc. are combed. The rest of the frames are progressive. > The progressive frames display the effects of decombing. > > The source is a 24fps progressive H.264 AVC video. I'm transcoding it to, > among other test transcodes, 5-5-5-5 pull-down @ 60fps progressive, H.264 > AVC. I'm not sure what you mean by "assuming a raw uncompressed source and no > compression afterwards", but I hope I've responded appropriately.
I mean I know what combing artifacts look like, but I wouldn’t know how to produce combing artifacts in an encode deliberately if asked if I knew how so take this with a grain of salt but I think the general “every encode reduces information” caveat applies, especially as you’re doing some image processing in between. You might say that technically, it is a reversible process, but multiple iterations of de/compression with an efficiency-focused codec such as H.264 will quickly show diminishing returns despite any novel techniques to enhance perceived quality that you use in between decompression and compression. I liken it to one of those pitch-shifting or retiming plugins/effects in audio apps; you can use those to maintain pitch while you stretch the duration of the recording but if you make edits and “freeze” it as part of a submix, it’s not going to sound the same when you shrink it back down to its original time. I don’t know if there would be other limitations if you kept the raw yuv video throughout, but then as efficient as H.264 is, you’d be talking something like ~100,000kbps in that case :/ Regards, Ted Park _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
