Video encoding for playing on Smart TV

[VideoYak]

Hi all,

I am almost approaching the stage of encoding my restored Video8 captures (Huffyuv, PAL 720x576, DAR 5:4, 50 FPS - de-interlaced). I would like to put the videos on USB that family members can just stick into their TV and play.

The extended family has all sorts of different makes and models of TV, so looking for the best compatibility of codec.

I just wanted to check if what I have researched below is correct?

From my reading of the forums, encoding with X.264 and the slower preset should give me the best balance between compatibility:quality:compression. File size is my lowest concern, compatibility and quality being the most important. Am I wrong?


Next is I have read that some players will not respect the DAR flag of 4:3 on the video and a safer bet is to resize to square pixels. I would rather this approach, then risk it. So my understanding for getting the perfect square pixel is to crop my video 704x576 and then resize to 1440x1080 which gives me a perfect 4:3 square pixel. Is this the best approach?

[Sharc]

From my reading of the forums, encoding with X.264 and the slower preset should give me the best balance between compatibility:quality:compression. File size is my lowest concern, compatibility and quality being the most important. Am I wrong?

Given your criteria, you are not wrong. However, if file size does not matter but encoding speed matters you may be equally happy with x264 preset "slow". You have the choice.

Next is I have read that some players will not respect the DAR flag of 4:3 on the video and a safer bet is to resize to square pixels. I would rather this approach, then risk it. So my understanding for getting the perfect square pixel is to crop my video 704x576 and then resize to 1440x1080 which gives me a perfect 4:3 square pixel. Is this the best approach?

I am not aware of players and (smart) TVs which will not play 4:3 non-square pixels correctly, provided that the stream is flagged accordingly. However, peoply may have forced their TV to play everything as 16:9 (a setting option on most TVs). So resizing to saquare pixels 1440x1080 is fine if encoding time and file size do not matter, and provided that all the TV's you have in mind can play unpadded 1440x1080 4:3 progressive 50fps correctly. At the end, the "best" approach is a personal decision.

[VideoYak]

Thanks Sharc as always.

... provided that all the TV's you have in mind can play unpadded 1440x1080 4:3 progressive 50fps correctly. At the end, the "best" approach is a personal decision.

Hmmmm, this I would not have a clue about whether they could play unpadded 1440x1080. I guess I would prefer to take the conservative option that will have a higher chance of working across a broad range of devices. Would that be to keep it 720x576 and ensure it is flagged as 4:3? I also missed that 768x576 is 4:3, would that be better? I am confused by what is the safest option to get the best possible most compatible display option.

[Sharc]

Well, here is what I normally do with 720x576i25 (PAL) captures (apart from any other filtering):
- Crop as needed from all sides (i.e. remove the crud from all sides, interlaced compliant)
- Pad with black borders to 704x576 (i.e. masking the crud)
- encode x264 (slow, CRF15) as 704x576i25, SAR (Sample Aspect Ratio)=12:11 in .mp4 container

I don't even deinterlace (well, that's perhaps just me), but keep it interlaced and do the filtering interlaced.

(The problem I suspect with upscaled 1440x1080p50 is that some (smart) older TV's may not be compliant with the 50fps at 1440x1080, but only accept 25i means 50 interlaced filelds per second at 1440x1080).

[VideoYak]

Ok you just sent me down a rabbit warren, I had assumed that TV de-interlacing performance would be similar to what I am seeing on my LCD monitor (VLC and MPHC) when playing interlaced content. QTGMC performed much better than that. But I have now read that I am mistaken, so maybe for the optimum result I am better - leaving it interlaced. In general I assume TV de-interlacing would be comparable to or better than QTGMC?

I think I might follow your normal process and see what it looks like. Thank you for sharing! Do you just just the slow preset and nothing extra?

[Sharc]

Most people would probably deinterlace these days, using a high quality deinterlacer like QTGMC.
If you don't deinterlace, the player or (smart) TV will do the deinterlacing (unless your TV is an ancient CRT TV), and one depends on the quality of the TV's/players deinterlacer which is often considered inferior to QTGMC. Depends on the model and source as well. Therefore most people will follow the QTGMC route once they have it working properly. Also, filtering (like denoise) is easier (means more straightforward) for progressive footage than for interlaced material, because many of the filters are designed to work on progressive video.

QTGMC on the other hand will normally double the frame rate (like 25i -> 50p, unless you do baserate deinterlacing (25i->25p) loosing 50% of the motion fluidity). The TV must be compliant with the new resolution, framerate and bitrate. Buzzword is x264 "levels and profile" and the TV's compatibility. If it doesn't comply with your encode, it may reject to play the file, or play it with occasional stutter due bitrate peaks and buffering (VBV) issues.

Just some caveats. I don't want to discourage you from deinterlacing, resizing to square pixels and upscale.

P.S. If you watch interlaced sources with MPC-HC or VLC you have to switch ON their deinterlacer / bobber to do the deinterlacing for your LCD monitor. It's a setting option of the players. Otherwise you will see all the interlacing combes (jaggies). Again, one depends on the quality of the player's real-time deinterlacer/bobber.

PPS: There is of course also the posibility of using QTGMC (25i->50p) and re-interlacing (50p->25i) at the end, should the double framerate cause any compatibility problems at a certain (upscaled) frame size. For reinterlacing to 25i just add to your script

AssumeTFF()
SeparateFields().selectevery(4,0,3).weave()
ConvertToYV12(interlaced=true)

[VideoYak]

Thanks Sharc,

I guess I just have to try different things and see what works, there does not appear to be a perfect answer.

I think I will try your method and also cropping to 704x576 and set the Sampling Aspect Ratio / Pixel Aspect Ratio =10/11 and see what yields the best result.

[Sharc]

.... and set the Sampling Aspect Ratio / Pixel Aspect Ratio =10/11 and see what yields the best result.

SAR (aka PAR) = 12:11 for PAL 4:3, not 10:11.
(10:11 would be the SAR for NTSC 4:3).

[Alwyn]

Square pixels, double frame rate = KISS/way to go; makes V8 beautifully smooth and no confusion. This is 2023, everything will cope. If a particular TV can't, you'll soon hear about it.

And 1440x1080 does not automatically mean larger files. It all depends on the encoding bitrate.

[Sharc]

This is 2023, ....

Believe me, I know this. But the TV(s) may not all be from 2023 ....

[VideoYak]

.... and set the Sampling Aspect Ratio / Pixel Aspect Ratio =10/11 and see what yields the best result.

SAR (aka PAR) = 12:11 for PAL 4:3, not 10:11.
(10:11 would be the SAR for NTSC 4:3).

Whoops, yes understood.

Square pixels, double frame rate = KISS/way to go; makes V8 beautifully smooth and no confusion. This is 2023, everything will cope. If a particular TV can't, you'll soon hear about it.

And 1440x1080 does not automatically mean larger files. It all depends on the encoding bitrate.

Believe me, I know this. But the TV(s) may not all be from 2023 ....

Ok maybe the best approach for me is Crop my video 704x576 and then resize to 1440x1080 at 50 FPS. Then any negative feedback with TV's struggling, I'll resort to cropping or masking and setting the SAR/PAR = 12:11

[Sharc]

Ok maybe the best approach for me is Crop my video 704x576 and then resize to 1440x1080 at 50 FPS. Then any negative feedback with TV's struggling, I'll resort to cropping or masking and setting the SAR/PAR = 12:11

Sounds good to me, assuming the head switching crud at the bottom does not annoy you

[VideoYak]

Ok maybe the best approach for me is Crop my video 704x576 and then resize to 1440x1080 at 50 FPS. Then any negative feedback with TV's struggling, I'll resort to cropping or masking and setting the SAR/PAR = 12:11

Sounds good to me, assuming the head switching crud at the bottom does not annoy you

Might sound silly, but I feel it gives the footage a bit of character. I have played around with cropping and adding a border, but I am on the fence.

[Alwyn]

Crop that crud off as well! At least blank it. Hate that stuff... Every time I see it I think "the person that did that capture and left that ugly stuff there didn't know what they were doing".

[Sharc]

@VideoYak: Also think about the colorsace (601 vs 709) when blindly upscaling SD (704x576) to HD (1440x1080)

[VideoYak]

@VideoYak: Also think about the colorsace (601 vs 709) when blindly upscaling SD (704x576) to HD (1440x1080)

Trying not to go in blindly and to get my head around upscaling. I know jagabo used nnedi3_rpow2 in my other post on de-interlacing, so I need to look into that.

I dont understand the REC.601/709 comment, I looked at this post https://forum.videohelp.com/threads/404634-NTSC-VHS-summary-6-Hybrid-for-Conversions-D...scaling-to-MP4 and I can't find anything mentioned about colorspace.

I am also currently playing around with Video Enhancer 2.2 that uses super resolution resize, it was mentioned in a post I stumbled across.

However it will only accept my huffyuv video if I select the Uncompressed option. Does anyone use Video Enhancer?


[Attachment 73777 - Click to enlarge]

[Alwyn]

601 for SD, 709 for HD. I asked the question a while ago (no, I'm not going to suggest you "search the forum"!). We never came to a hard consensus on what "HD" was but anything at or larger than 720 was deemed "HD". My NLE automatically codes the colour correctly for the video size; Staxrip may also?

https://forum.videohelp.com/threads/410665-BT-709-is-for-HD-What-is-HD#post2700918

[VideoYak]

Thanks Alwyn, understood. So going from.my current SD video to HD convert the color matrix from rec.601 to rec.709. And make sure to flag the colour matrix correctly in the encoding process.

Now just need to get my head around what to use to upscale.

[Sharc]

Yes. And even though it is 2023 it is perhaps not quite as simple as suggested in the KISS concept of post #9

[VideoYak]

How does this code look as a starting point?

AviSource("Video.avi")
crop(8,0,-8,-0)
#Colormatrix("Rec.601->Rec.709")
nnedi3_rpow2(rfactor=2, nns=4, qual=2, cshift="Spline36Resize", fwidth=1440, fheight=1080)
aWarpSharp(depth=5)
Sharpen(0.2)

I must admit, I still dont fully understand the REC601/709. I have commented out the colormatrix for now, because I thought I could run the above in avisynth, save as lossless Huffyuv for the time being then manage the colormatrix when I am doing the encoding. Is that reasonable?

From what I understand it seems that as long as the VUI is set correctly to Rec.709 when encoding then it should play correctly, some people take the extra precaution of converting to be sure. Please correct me if I am wrong.

[Sharc]

How does this code look as a starting point?

AviSource("Video.avi")
crop(8,0,-8,-0)
#Colormatrix("Rec.601->Rec.709")
nnedi3_rpow2(rfactor=2, nns=4, qual=2, cshift="Spline36Resize", fwidth=1440, fheight=1080)
aWarpSharp(depth=5)
Sharpen(0.2)

I must admit, I still dont fully understand the REC601/709. I have commented out the colormatrix for now, because I thought I could run the above in avisynth, save as lossless Huffyuv for the time being then manage the colormatrix when I am doing the encoding. Is that reasonable?

From what I understand it seems that as long as the VUI is set correctly to Rec.709 when encoding then it should play correctly, some people take the extra precaution of converting to be sure. Please correct me if I am wrong.

Upload a sample of your source "Video.avi". I assume it is Rec. 601.
Read post #4 here to get an idea what can go wrong and what may get criss-crossed:
https://forum.videohelp.com/threads/410665-BT-709-is-for-HD-What-is-HD#post2700312
What does your player (decoder) do? Compare your source with your encode to check if there is a shift in the color tint, and if so, whether you consider it as being essential.

[VideoYak]

How does this code look as a starting point?

AviSource("Video.avi")
crop(8,0,-8,-0)
#Colormatrix("Rec.601->Rec.709")
nnedi3_rpow2(rfactor=2, nns=4, qual=2, cshift="Spline36Resize", fwidth=1440, fheight=1080)
aWarpSharp(depth=5)
Sharpen(0.2)

I must admit, I still dont fully understand the REC601/709. I have commented out the colormatrix for now, because I thought I could run the above in avisynth, save as lossless Huffyuv for the time being then manage the colormatrix when I am doing the encoding. Is that reasonable?

From what I understand it seems that as long as the VUI is set correctly to Rec.709 when encoding then it should play correctly, some people take the extra precaution of converting to be sure. Please correct me if I am wrong.

Upload a sample of your source "Video.avi". I assume it is Rec. 601.
Read post #4 here to get an idea what can go wrong and what may get criss-crossed:
https://forum.videohelp.com/threads/410665-BT-709-is-for-HD-What-is-HD#post2700312
What does your player (decoder) do? Compare your source with your encode to check if there is a shift in the color tint, and if so, whether you consider it as being essential.

Here is where I am getting confused, from what I understand it is not flagged as REC anything as it is still in the lossless huffyuv 4:2:2 format. I thought that the flagging happens in during the encoding process under VUI.

My workflow is Capture -> Lossless Huffyuv ->Deinterlace/filters -> Lossless Huffyuv -> Upscale Sharpen -> Lossless Huffyuv -> Encode -> H.264

I understand I could combine a lot of those steps into one script, but while I am learning I like to break the process out. The text in red is what I am trying to do now. Would it not be the next step that I make sure it is REC.709?

Apologies to be this annoying, I am just a bit confused. But if it is as simple as for this step Upscale Sharpen -> Lossless Huffyuv I need to include "Colormatrix("Rec.601->Rec.709")" in the script, then I will do that.

[Sharc]

Here is where I am getting confused, from what I understand it is not flagged as REC anything as it is still in the lossless huffyuv 4:2:2 format. I thought that the flagging happens in during the encoding process under VUI.

Yes. The .avi does not flag the colorspace explicitly. But as the capturing process follows Rec. 601 the colorspace will be accordingly (in good faith, but no proof).

So when you upscale without signalling the colorspace, the decoder may by default assume that it is 709 based on the new vertical resolution, hence introduce a tint shift.
If you signal it as 601, the decoder may read the flag and decode it accordingly. Colors are correct. When the decoder ignores the signalling it may by default apply 709 for decoding and shift the colors accordingly.

So for upscaling I would convert to 709. For "natural" (VHS-) videos the differences are fortunately subtle though. Most visible perhaps for the red-brown panels towards the end of the clip.

Added:
Below script visualizes the difference. Step through the frames to switch between 601<->709

v1=AviSource("Video.avi")   #your source
#v1=colorbars(pixel_type="YUY2") #alternate source for better visibility
v2=v1.Colormatrix("Rec.601->Rec.709")
interleave(v1,v2)

[VideoYak]

Thanks Sharc, playing around with the code you provided now.

So for upscaling I would convert to 709. For "natural" (VHS-) videos the differences are fortunately subtle though. Most visible perhaps for the red-brown panels towards the end of the clip.

A silly question, I will do this - but if I am exporting as Huffyuv avi, will this conversion still be retained?

AviSource("Video.avi")
crop(8,0,-8,-0)
Colormatrix("Rec.601->Rec.709")
nnedi3_rpow2(rfactor=2, nns=4, qual=2, cshift="Spline36Resize", fwidth=1440, fheight=1080)
aWarpSharp(depth=5)
Sharpen(0.2)

[Sharc]

A silly question, I will do this - but if I am exporting as Huffyuv avi, will this conversion still be retained?

Huffyuv (by default) shouldn't touch the colors AFAIK (unless you force it to output RGB). But you may want to check it out using the colorbars as a source.