On 7/23/2022 5:05 AM, Jethro_uk wrote:
> Just as a wee follow up:
>
> Moved the memory stick to play via my DVD player, and it was 100% perfect.
>
> Working theory is that the TV was decoding *and* displaying using the
> same circuitry. Splitting the task "solves" the issue.
>
> Annoyingly I used to have a network media player - a Cyclone - that did
> the job. But when it packed up and a replacement looked hard (and now
> even harder) to source, I fell back on letting the TV do the work.
>
> Not a biggie in the grand scale of things - generally I want my TV to
> just show what it's told. And the DVD player can act as a network media
> player, it's just a question of dealing with the interface. Which is
> gawdawful (Panasonic !).
>
On computers, video can be completely decoded by a video encode/decode
block in the GPU. The GPU could be inside the processor (Intel QuickSync,
AMD UVD), or in the video card GPU (NVidia Purevideo).
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
https://en.wikipedia.org/wiki/Unified_Video_Decoder
https://en.wikipedia.org/wiki/Nvidia_PureVideo
ARM processors should have some sort of acceleration as well,
to make it easier for a phone to play a video.
At one time, video decode acceleration consisted of IDCT support.
Which is almost no help at all. It helped at the macroblock level,
the blocks of pixels being manipulated in the frequency domain,
to trade off file size and detail (softness).
Today, speed tradeoffs mean that using IDCT is useless, as
the CPU can do discrete cosine transform without that kind of help.
But the above decoders do the whole job. You just DMA packets of
video into the video SIP, and out comes raw pixmaps.
Similarly, the above can have video encoding, and can do single-pass
H264 for example (at 330 FPS). Whereas on your desktop CPU, you can do two-pass
encoding for best results (first pass is a bandwidth estimator pass,
second pass does the encoding, using bandwidth estimates to estimate
when it can make "even better looking" stretches of video).
Like most of the junk in the house, a TV could be from an older
generation with CPU-only solution. Or it could be an ARM with a GPU
block with some of those functions in it. If you can discover
the "secret format" which causes low overhead on the TV CPU, then
the playback could be smoother. But this might also cause
a higher USB2 transfer rate to be needed, and larger files on
the stick.
How you encode, can affect "controls flexibility". A video can be
made more seek-able with bidirectional encoding, but that encoding
might be less common. Some CODECs just aren't good for seeking
at all, and attempts at going backwards can result in the video
playing from zero again.
Your TV is an experimenters paradise, wasting hours to solve problems
like this.
On the decoder table here, MPEG2 and H.264 might be examples of ones
you would want accelerated. And part of the reason, is the number of
sources in your house, that might use those formats. Like, the signal
that comes down the TV antenna, can be converted directly into packets
suited to one of these decoder-things. The only thing the hardware
needs help with, is being told which stream number is the video and
which stream number is the audio (as that can vary with broadcast material).
https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new
This is incoming from my TV tuner card, giving some idea what a
TV might be tuned for from a decoding perspective. I might have to tell
my computer which streams (marked with arrows) to play.
[mpeg2video @ 0000000004901000] interlaced frame in progressive sequence, ignoring
Duration: 01:04:56.91, start: 1.447051, bitrate: 16153 kb/s
==> Stream #0:0[0xc](eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:1[0xd](enm): Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s (hearing impaired)
==> Stream #0:2[0xe]: Video: mpeg2video, yuv420p(tv), 704x480, max. 24000 kb/s, 29.97 fps, 29.97 tbr, 10000k tbn, 59.94 tbc
Stream #0:3[0xffffffff]: Video: mjpeg, yuvj420p(pc, bt470bg/unknown/unknown), 200x113 [SAR 96:96 DAR 200:113], 90k tbr, 90k tbn, 90k tbc
Metadata: title : TV Thumbnail
Stream #0:4[0xf]: Subtitle: eia_608
Unsupported codec with id 1664495672 for input stream 4
If you transcoded your selection to MPEG2, maybe your TV would like that better.
The video card on my PC, can process an hour of TV content, in six minutes
(to make MPEG2).
If your transcode, happens to not match some automation the TV has,
it might have to switch to CPU decoding. Like some CODECs have multiple
"profiles", and the TV will hate some profiles enough, not to touch them.
Try and find an honest TV manual, with that level of detail...
Sometimes, the manufacturer provides a "list" of supported formats on
some web page, but it might be devoid of preferred profile info.
Making for an incomplete specification. It might include useless
things like DIVX and XVID square aspect, then handle them improperly
and circles are ellipses and so on.
Paul