Discussion: Generating encodes suitable for HDTV media players

OK, here is a copy of my last reply to the other thread:


Some interesting facts about the jerky playback of the 720p version of the copper video sample:


I was puzzled by this progressive movie looking odd on interlaced display. I was unsure if the 30fps was really at play with my mind here... So I expanded each fields of the interlaced video (bob() function in avisynth)obtaining a 60fps video at half the original resolution.


I then resized it to 720p frame size, encoded and played on linkplayed.


Guess what, the video look perfect.


I guess the problem is really the interlaced nature of the source material. Does this mean that all progressive video played back on an interlaced display exibit this behavior... probably yes at varying severity levels... but this piece of video seem to be an extreme example of what can go bad.


You know what? Thinking of it some more I just realized what is the source of the problem here! The lack of Motion Blur! This explains why if I "bob" the source to get 60fps it play smooth! With all 60 fps the spacing of each frames makes for a smooth motion. Now remove each second frame things get too crisp... not enough bluriness to link each image. This is why the video look like garbage... because it it too sharp!


I encoded the video again with a blend deinterlace filter + motion blur + resize and it now look watchable. Certainly not as good as the 60fps 720 version but better than the straight deinterlaced version.


Have a look at:

720p 60fps


and

720p with motion blur


This short clip is certainly a keeper for demo/testing purpose.

I do not think that you will ever have a nice looking 720p 29.97 version of the 1080i source material due to the fact that there is not enough motion blur in each frames. If the camera used to film the train had used a slower shutter speed motion blur would have been captured in each frame and the resulting train move would have looked a lot more natural once deinterlaced.


The best I can do to get a more natural look to the 720p version it to apply artificial motion blur to the encoded version. Maybe if I had a better motion blur filter the result would look more pleasing to the eye but right now I have not found anything more suitable.


I also tried to produce a properly encoded interlaced version (sort of a 720i version) without luck. The player always choke on it. The closest approximation of it is to "BOB" the source material to encode a 720p version at twice the frame rate (roughly 60fps). This version play rather nicelly on the linkplayer and certainly look very similar to the original interlaced version. The downside is that the resulting file size is a lot larger that the trully deinterlaced version.


You can find an example of the 60fps and 720p with artificial motion blur in the post above.

Hmm.. I don't really follow the "motion blur" argument. The 720p 29.97 version should have the same number of complete "frames" as the original. There are 60 FIELDS per second in the 1080i, but only 30 FRAMES... The 720p30 should capture ALL the frames. The problem we all seem to be having, is reassembling the fields into their proper frames.


I looked at your last two encodes in the old thread. The 720p 60 looks great. The motion-blur looks, well, blurry.


Here's what I tried:

1) Deinterlace by throwing away the even fields. (This results in 1920x540p30)

2) Rescale to 960x540.


This effectively reduces the size by 1/2 in each dimension, while preserving the frame rate.


When I previewed this in VirtualDub, it looked great (yeah, I know, it's no longer HD, but my "true" HD display is only 32", so I won't be able to see much difference, and my projector is only ED).


HOWEVER, when I played this back on the LinkPlayer, the interlace problem was back! I am completely mystified! Anyone know what the heck is going on?


PS: cyburn: I looked at the 720p60 encode again, and while it does look great, it stutters a little towards the end of the clip when I play it on the LinkPlayer.. Do you have this same problem? (I think maybe 720p60 is approaching the limits of the LinkPlayer.. It is actually a lot MORE resolution than 1080i30)


PPS... Oops... strike that dumb comment about "720p60 approaching the limts" etc... I _think_ 720p60 is standard HDTV encoding, and has roughly the same bandwidth as 1080i30.... But it DID stutter when I played it, honest!

I've started the same discussion over on the Doom9 forum: -

http://forum.doom9.org/showthread.php?s=&threadid=90896


And... a forum member called CruNcher, used VirtualDubMod and SmartDeInterlacer to generate the following, Mpeg4 1280x720 progressive encode (with Qpel and B-VOP): -

http://cruncher.mufflastig.com/XviD/samples/720p.avi


How well does this fair on the I-O DATA player?



Cheers

Just to clarify the source of that clip:


- Original .ts capture (actually, .tp capture) from OTA broadcast WTTW (Chicago DTV channel 47) via MyHD PC capture card. WTTW broadcasts in 1080i.

- File cut and converted to mpeg via HDTVtoMPEG2 (removed other SD program streams at same time)

- Further cut of small clip from large .mpeg file via some other MPEG splitter tool, which I can't recall at the moment. (A demo version which I have since un-installed...)


NOTE: original "raw" capture file from MyHD is no longer available. All I have is the .mpeg output from HDTVtoMPEG2. (and the short clip...)

I too noticed the strutter toward the end when the train reach the right cornet of the display. Could be a limitation of the linkplayer2. I will try to encode it in DIVX and see if it play any better.


Now, as far as motion blur goes I am pretty sure that it is actually the problem.


At 30 interlaced frames per second you essentially display 60 half frames per second. Those frames are stretched to fill the full height of the screen. So you really get something like 1920x540 at 60 fps. Because interlaced display will blend the frames 1 line up or down from the previously frame your brain see the image has having more resolution than it really has... especially in area without motion.


If you look at each half frames of the interlaced video you will notice the absence of motion blur on the train numbers. This is probably related to the fact that the camera was using a high speed shutter that "snapped" motion less pictures 60 times per seconds. If you try to blend those 2 images you get a picture with two sharp 2003 number in them slightly off blended together. This look bad.


If the source material was shot at shutter speed of let say 30fps the individual frames would contain nicelly blurred numbers. Our brain like to see blurr when there is movement. This is why computer graphic animation user motion blur to make movement realistic. Combining those frames would render a nicelly blurred 2003 number that would be interpreted well by our brain.


The issue here is that we try to see blurriness in the video where there is not. Our brain just show us a flickering 2003 number because this is the best it can do with the motion blur less picture sequence.


Hope this help explain my theory.

I still don't buy the "motion blur" theory. It is based on the assumption that each "field" in the 60-fields-per second is captured independently, at different times (every 1/60th of a second). I don't think this is the case. It is really "frames" that are captured every 1/30th of a second. They are then split into interlaced fields and encoded as 60-interlaced-fields per second. It should theoretically be possible to re-combine these fields into the frames...


"motion blur" is entirely governed by the shutter-speed of the camera. It should be apparent (or not, depending on the original acquisition) regardless of how it is encoded.


The "motion blur" you are adding is an entirely artificial effect meant to simulate slow shutter speed. It has done this, which consequently masks the combing, but this is not really a very good solution. The results are, sorry to say, aweful.


But.. by all means keep on trying stuff! You have produced the BEST encode so far!! Better than any I have, that's for sure...


I am wondering what the problem is with just settling for cyburn's 1080i encode.... Is the compression rate not so good? Does it take forever to encode? I can live with that encoding.. It looked pretty good to me... why do we need 720p?

Quote:
This is very odd, because a still from CruNcher's encode looks like this: -

http://img233.exs.cx/img233/8888/cruncher3ft.jpg


Which is nowhere near as bad as the stills taken from previous 720p encoding attempts!


Personally speaking, I would not worry about the stuttering frames too much at this stage. As I'm sure this is more to do with the Mpeg2 source rather than the encoding!


I also feel future encoding attempts should be generated without including the AC3 audio stream, just in case it's not been interleaved correctly!


pontus, are you able to swap your Mpeg2/AC3 source for an Mpeg2 "video only" one?



Cheers

Yeah, some of this stuff just doesn't make sense. I have lots of encodes that look fine on PC when paused. Even some that look fine on Linkplayer when paused. But STILL show the doubled images when played.. The one that REALLY surprised me is the one where I stripped out all the even fields. It STILL had the doubled images when played on Linkplayer! Maybe I screwed up the encoding on that... I'll have to double-check it


I have extremly limited space on my ISPs server. I can't fit another clip. I would rather leave the present one there, if you don't mind. If you want to strip out the AC3, be my guest, but ultimate solution will have to have it retained... This will also ensure a "constant starting point" for the purposes of this discussion. I'd really like to limit the variables if at all possible...


- Frank

Quote:
It been compressed using 7-zip.

But here it is again as a good ol' .Zip file



Cheers

Quote:
Have a look at: http://videosystems.com/e-newsletter...Work_12_13_04/


This is an exerpt from it that goes along the motion blur + strobing effect we have noticed:

The table below shows how this could be done. Blue text indicates fields that are created from even fields—likely by “interpolating†odd-lines from even-lines. Interpolation generates a frame that has less “motion blur†than does a frame obtained by progressive scanning. Lack of motion blur creates the slight strobing look to objects in motion that has been widely reported


Also, this clip 29.97 frames are made up from to seperate interlaced fields captures at different interval of time. If it was just 1080p source encoded as 2 interlaced frames, deinterlacing them would produce a perfect frame without motion artifact.


I am 99% sure that the issues with strutering video is linked to lack of motion blur in the deinterlaced frames. Nothing we can do about it. It has nothing to do with the compression codec.

Ok.. I agree. "Way too many numbers"....


Actually, I am not all that worried about any "stuttering" that may occur. The real issue is the double-up and/or combing. This is absent in playing the original, and really should be absent in any encoded version. Even progressive encodes, don't you think? OK, so maybe converting to progressive at 1/2 the "field" rate (720p30, for example) will result in a little stuttering, but it shouldn't result in this obvious display of doubled images and/or combing.... should it?


I think the motion-blur "stuttering" would be acceptable. It is probably a pretty subtle effect. The double-image/combing effect we are seeing is NOT subtle. At least for me it isn't...


If it turns out to be just plain impossible to convert to progressive, maybe the best approach is to just stick with interlaced...


cyburn, would you mind re-posting your "solved" post to this thread? (The one that tells how you created the 1080i version with NO combing/doubled images? ) Thanks...


PS. I really just want to reduce the size of the video, mainly for storage considerations. I don't care if it's interlaced or progressive. As long as I can play it on the LinkPlayer, and have it look pretty close to the original, I will be happy... Well, actually, I will ALSO want the whole conversion process to be simple, fast, and cheap, of course, but that goes without saying!