A caveat in using ‘ffmpeg’ to produce consumer-ready streams, from individual frame-files.

It recently happened to me, that I had used ‘Blender’ to create a very short animation, with 144 frames, but where I had instructed Blender to output this animation as a series of numbered .PNG-Files, which I would next use an ‘ffmpeg’ command, to compile into a compressed stream, the latter being an .MP4-File, using H.264 video compression. ( :1 )

But unexpectedly, I had obtained an .MP4-File, which would play on some of my player applications, but not on others. And when I investigated this problem, I found that player-applications which used a feature under Linux named ‘VDPAU‘, were Not able to play the stream, while player-applications which used software to decompress the stream, were able to play it.

The very first assumption that some people could make in such a situation would be, that they do not have their graphics drivers set up correctly, and that VDPAU may not be working correctly on their Linux-based computers. But, when I looked at my NVidia settings panel, it indicated that VDPAU support included support for H.264 -encoded streams specifically:

screenshot_20180720_154326

BTW, It’s not necessary for the computer to have an NVidia graphics-card, with the associated NVidia GUI, to possess graphics-acceleration. It’s just that NVidia makes it particularly easy, for users who are used to Windows, to obtain information about their graphics card.

Rather than to believe next, that VDPAU is broken due to the graphics driver, I began to look for my problem elsewhere. And I was able to find the true cause for the playback-problem. Ultimately, if we want to compress a stream into an .MP4-File, and if we want the recipient of that stream to be able to play it back, using hardware-acceleration, which is the norm for high-definition streams, then an ‘ffmpeg’ command similar to the one below would be the correct command:

 


ffmpeg -framerate 24 -i infile_%4d.png -an -vcodec libx264 -pix_fmt yuv420p -crf 20 outfile.mp4

 

But I feel that I should explain, how my first attempt to compress this stream, failed. It did not contain the parameter shown above, namely ‘-pix_fmt yuv420p‘. There are two WiKiPedia articles, which explain the subject of what ‘YUV’ means, and that may explain the subject better than I can, and that I recommend my reader read:

https://en.wikipedia.org/wiki/YUV

https://en.wikipedia.org/wiki/Chroma_subsampling

I am now going to paraphrase, what the above articles explain in detail.

Continue reading A caveat in using ‘ffmpeg’ to produce consumer-ready streams, from individual frame-files.

Rotation Reversal, by Inverting Only One Axis.

I could engage in some more speculative thinking.

I could be trying to design a hypothetical analog scheme for modulating color information, that belongs to the Y’UV system for representing colors. But I’d like my system to have as advantage over NTSC, that if the chroma sub-carrier gets phase-shifted, due to inaccuracies with the analog circuits, the result should be a shift in hue, which reverses itself from one TV scan-line to the next, as well as from one frame to the next. Just as viewers don’t normally see dot-crawl when they watch an NTSC-modulated signal on a monochrome receiver, they should also not be able to see the hue-shift, due to analog-circuit issues, with my hypothetical modulation scheme.

Consequently, the receivers for this type of signal should not have a Hue potentiometer.

But I discover a problem in my scheme. The U and V components are to be modulated onto a chroma sub-carrier, using quadrature-modulation, just like NTSC was. And yet, I’ll discover that I can only get the clockwise versus counter-clockwise reversal to take place, if I invert either the U or the V signal-component, but not if I invert both, nor if I just invert the sub-carrier, thereby inverting both U and V:

rot-rev_1-svg

The problem follows, because every signal which gets modulated onto a sub-carrier, using quadrature-modulation, throws sidebands. Hence, if I was to place the sub-carrier frequency just-beyond the frequencies already being used to encode luminance, I would also need to invert both U and V, by default, to eliminate all the dot-crawl. What can I do?

Continue reading Rotation Reversal, by Inverting Only One Axis.