Hello guys, I am using Avidemux to deinterlace 240p video content from old video game consoles. I capture them using an El gato game capture. The resulting .TS file is very sharp, colorful and interlaced 720x480 at 29.970 fps. In order to use these files in Adobe Premiere I must deinterlace them in Avidemux.
What I do is, in filters, I select in this order:
1.- Separate fields. To obtain 2 fields of 240p.
2.- Resample FPS, from 119.89 to NTSC 59.93.
3.- Resize to 720x480, Lanzcos3, since it does not offer the Nearest Neighbour option, which is the best for pixel art.
The result is a great looking progressive 480p video at 59.941 FPS that lasts the exact same amount of time, and it's way better than what the Elgato software and Adobe can do to an interlaced file. Unfortunatley, the audio loses sync. I have attempted to do this process to two different video clips, and both lost sync.
What would be the best way to avoid losing the audio sync?
Thank you in advance.
Please provide a sample file
(unedited)
I have uploaded the TS file I am using for this test. (48 seconds long).
You can download it from here: http://www.modoversus.com/sample_interlaced_240p_TS.rar
Please let me know if I should upload any other file.
Thanks.
Is that one ok for you ?
http://fixounet.free.fr/deinterlaced.mkv
Thanks for the video and quick response!
The thing about 240p videogames is that they frequently used flickering graphics to create the illusion of transparency. This video I am using for test is using this effect in the rainbow in the back, and in the shadows of the characters whenever they are under the sun, on the left of the level.
In the video you have kindly provided me, the shadows and the ranibow spend various seconds either completly solid or completly gone. Most deinterlacing methods tend to either blend the frames to create the transparency effect, which leads to a less sharp image and darker colors, or to loose the flickering effects for many frames at a time by either making the graphics completly solid or removing them. The rainbow is solid for most of the video, and the shadows on the ground for the characters are missing. (I even bought a scaler device that takes the RGB 240i video and escalates it to 720p, and had the exact same result for the flickering effects, which is why I am trying with software to preserve them.)
Using separate fields, the result of the test is this: http://modoversus.com/separated_fields.rar
It does not look as sharp compared to the video you uploaded, but the flickering effects look very close to the interlaced video and how it looks on the game console.
ok, but in term of sync ?
I tried to mimick what you do :
* separate field
* Resample FPS to 59.94 (not 59.84)
* Encode audio to mp3
* Save as mkv
It looks fine
I suspect the mp4 container to introduce a delay. Could you try with mkv ?
BTW, just dropping one field will have the same result with better speed
Interesting issue.
Each frame in the .ts seems to be, 2 progressive frames from the 240P with each P frame converted to an up-sampled field, and weaved together.
Is the capture done that way on purpose, so as to preserve the mechanics behind the transparent rainbow (viz, on in one frame then off in the next frame)?
Can't help with the out of sync issue.
But just as a thought - maybe the capture has dropped frames and any explicit AV-sync timing is "lost" in the ADM separate field filter process.
Mean would know if that is probable (since his approach has slightly adjusted FPS!).
Quote from: mean on February 23, 2016, 05:42:52 PM
I tried to mimick what you do :
* separate field
* Resample FPS to 59.94 (not 59.84)
* Encode audio to mp3
* Save as mkv
It looks fine
I suspect the mp4 container to introduce a delay. Could you try with mkv ?
BTW, just dropping one field will have the same result with better speed
Mean, I tried it as you recommended, (without dropping one field). I'm happy to report that this obtained the desaired result! Kept the effects and the sound in sync. Thank you so much for the advice!
Quote from: AQUAR on February 24, 2016, 01:14:15 AM
Interesting issue.
Each frame in the .ts seems to be, 2 progressive frames from the 240P with each P frame converted to an up-sampled field, and weaved together.
Is the capture done that way on purpose, so as to preserve the mechanics behind the transparent rainbow (viz, on in one frame then off in the next frame)?
Can't help with the out of sync issue.
But just as a thought - maybe the capture has dropped frames and any explicit AV-sync timing is "lost" in the ADM separate field filter process.
Mean would know if that is probable (since his approach has slightly adjusted FPS!).
Probably yes. Old videogame consoles had limited ability to provide semi-transparent colors, so to achieve this they would flicker the graphic elements to fake the transparency, or would use a mesh of pixels. Old video game consoles (and computers that connect to TVs) from the late 70s up to maybe the year 1999 actually display 240p video, which is then somehow displayed as 480i on standard definition sets and arcade monitors. According to Wikipedia (https://en.wikipedia.org/wiki/Low-definition_television#Resolutions):
Quote
Older video game consoles and home computers generated a nonstandard NTSC or PAL signal which sent a single field type which prevented fields from interlacing. This is equivalent to 240p and 288p respectively, and was used due to requiring less resources and producing a progressive and stable signal.
Some video capture devices and HD TVs do not recognize 240p or treat it as 480i, which creates issues. I used the El Gato Game Capture HD device to capture it, as it can recognize 240p /288p trough Composite and S-Video cables (the sample video used S-Video), tough sadly not trough component. Other capture devices are not able to recognize the 240p signal and do not capture the video.
The whole thing about de-interlacing, upscaling old video games is a bit complicated and expensive proposition. The best solution I had found was a device called the Framemeister RGB, a 350 USD device specially designed to upscale 240p video to HD standards with a lag of about 1 frame or less. Since I could not afford one, and was only interested in recording video, I was looking for a solution on software that could create a similar look, which Demux has provided.
Thanks for the info, it has satisfied my curiosity.
I'll add this practical use for the separate field filter to my bag of tricks.
Just for interest have you tried using dgbob mode=1 order=1 threshold=0
I think that will extract each field in the .ts and fills in the "black scan lines" by basic nearest neighbour interpolation.
You end up with 720 * 480 frames that are upsampled versions of their corresponding progressive frames from the 240P source.
This condenses the multi filter workflow into a single filter work flow.
That will also preserve the transparency (flicker trick!) seen in the source video (rainbow and shadows on the animated figures!).
Also the captured data is for non square pixels and so you need to adjust for the square pixel PAR of computer monitors.
In other words --- the .TS specifies a DAR of 4:3 but the ADM recode specifies a DAR 0f 3:2 (and so needs a PAR adjustment!).
Curious question - what is the frame rate of the 240P source material.
Quote from: AQUAR on February 25, 2016, 03:50:11 AM
>8 >8 Curious question - what is the frame rate of the 240P source material. >8 >8
Quote from: modoversus on February 23, 2016, 05:05:16 AM>8 >8 I capture them using an El gato game capture. The resulting .TS file is very sharp, colorful and interlaced 720x480 at 29.970 fps. >8 >8
Quote1.- Separate fields. To obtain 2 fields of 240p.
2.- Resample FPS, from 119.89 to NTSC 59.93.
;)
@ Jan
Something maths doesn't quite seem to stack up to me - thats why I asked the question.
The .ts frame rate is 30 fps (60 fields per second as its interlaced!).
Each .ts frame is in fact 2 frames from the 240P source.
So the frame rate of the 240P source must be 60 fps (twice the .ts frame rate!).
At the end of these processes we are getting progressive frames equal to the "up-sampled" 240P frames and displayed at a frame rate of 60 fps.
All good so far (I think!) and none of the frames are duplicated.
But, are those games consoles really outputting 240P @ 60 fps?
I thought it was more like 30 fps (frames per second!).
PS:
Its so hot here (38 celcius at the moment) that I am probably missing something fundamental.
The game is outputting probably interlaced 30 fps.
The recording is 240P (progressive: fullframe = 2 half interlaced together)
splitting 240p back to 2 half interlaced frames
frame rate is staying the same: one gives full frame the other 2 half frames
Add to that going from analogue to digital.
...
just guessing, never used 60Hz devices, lucky me.
@ Jan it was to hot (temperature wise!) for me to finish my thought so here is part 2.
First though, when you play back the .ts in ADM you will see that there is combing, because the two fields are coming from 2 progressive frames that of course have a different instance in time. Thus the recording/capturing is interlaced and the source is progressive (being computer generated graphics?).
This is different than splitting a progressive frame into 2 fields for interlaced storage, here playback in ADM will simply weave the fields back together for full recovery of the progressive frames (no combing). Doesn't matter if the console outputs 30 progressive frames per second interlaced format or 30 progressive frames per second progressive format (in this case!).
There doesn't seem to be other processes taking place like field shifting or telecining to suit NTSC transmission but not sure about that.
Hence I was curious as to what does this game console actually output.
I think you are right in saying that its some analogue NTSC transmission but is it standard?
Anyway if the game outputs 30 progressive frames per second (interlaced or not) my maths is out by a factor of 2 (since we get 60 fps).
Using dgbob mode=1 order=1 threshold=0 gives 60 frames per second, as it should (given what is contained in the .ts).
The steps in the process of the OP are essentially the same as the steps used by dgbob, but it results in a frame rate of 120 fps and gets resampled back to 60 fps. Again the maths is out by a factor of 2 given what is taking place.
Question is - what am I missing? (update I'll try and answer myself!!)
- ADM writing the wrong meta data because it confuses field rates with frame rates for interlaced material!
Does the frame resampling actually take place or is it a do nothing other than to change fps meta data?
- What is the game console creating in terms of the 240P specification.
I think its progressive frames with a SAR of 360 x 240 @ 60 fps that are packaged as NTSC interlaced @ 30 fps.
Its non standard NTSC in terms of extra wide "analogue pixels" . These are sampled twice by the capture device
to give a digital frame with a SAR of 720 x 480i @ 30 fps. That just leaves scaling for a 4:3 DAR on pc monitors.
I should really compare the dgbob product with the OP product and see if there is a difference with and without the fps resampling.
Anyway it kind of makes sense to me now and I learned a new thing "transparency by flickering".
I hope this does not confuse things further, but in theory, all older game consoles output 240p at 60 fps progressive. My TS file shows in property as 29 FPS, but when recording, there is a setting in El Gato Gamecapture HD that I select labeled "Enable 60 fps recording". This video was recorded from a NTSC Sega Saturn console, if that helps somehow.
Also the screen resolution that the game console is working on should be 720x240p at 60fps, but when shown on a standard definition TV or monitor, it fills the screen by alternating between drawing a line of the game display and then an empty black line. By alternating black lines and lines of the game display image, it achieves complete 480 lines of resolution.
I assume that by separating fields, we obtain the real progressive frame as it was created by the game console. Then it is necessary to scale it to 480 as we do not have scanlines to fill the other half of the screen resolution.
@ modoversus
Thanks for that.
Part of that is entirely consistent with what I deduced from the video stream in the transport file.
The theory thus seems to fit the reality.
Something for you to consider:
TV's from the analogue era only work with interlaced signals (NTSC or PAL).
The screen pixels on these displays are defined as a section of a scan line (kind of virtual pixels shaped by scan line frequency and number).
The composite video output of the game console is an NTSC signal with a Display Aspect Ratio (DAR) of 4:3.
The capture process actually records that the DAR is 4:3 in the meta data of the .ts.
As you said - the content of those virtual pixels comes from "weaving" together 2 progressive digital frames (if you like the second frame fills in the black scan lines left after painting with the first frame!).
These digital frames have a Stored Aspect Ratio (SAR) of 360:240 (note SAR not DAR).
The conversion from digital to analogue translates that to 720x480 virtual pixels and because virtual pixels (TV pixels) aren't square pixels that in turn translates to a DAR of 4:3.
Straight up, the 720x480 capture (analogue to digital) is not a DAR match for digital PC monitors, as these have square pixels.
You have to take note of that DAR meta data if DAR is to be preserved on a digital PC monitor.
That requires resampling the "new" progressive frames to suit (eg to 640X480).
If you don't the final picture will have a DAR of 3:2 (round things no longer look round!).
You should only resample after deinterlacing (or on the separated fields!) else it will be a mess.
The transparency effect on the PC monitor is also not entirely to same as when using a TV as display (TV = smoother).
Hope that helps explain a bit how I perceive the 640 from 720 from 360 (its crazy!).
These are just my thoughts and as I am no expert I may well have it all wrong.
Do try the Dgbob filter and see if it works.
Aquar, I tried Dgbob as you suggested, and while the image looks very colorful and sharp (better than what I end with the method I am using), there are interlacing effects (see attached screenshot), and the motion feels less smooth. What would you suggest be a good setting to us with Dgbob?
Quote
Straight up, the 720x480 capture (analogue to digital) is not a DAR match for digital PC monitors, as these have square pixels.
You have to take note of that DAR meta data if DAR is to be preserved on a digital PC monitor.
That requires resampling the "new" progressive frames to suit (eg to 640X480).
If you don't the final picture will have a DAR of 3:2 (round things no longer look round!).
You should only resample after deinterlacing (or on the separated fields!) else it will be a mess.
This certainly matches what I have heard about anologue to digital video. Can you please suggest me a way to achieve this in Avidemux?
Its like that because you're combining 2 "progressive" fields to try and create a single progressive frame (wrong approach for your objective).
Is this combing in moving parts throughout? If so, then you are just weaving these two fields together.
You have to treat that 240P capture as true interlaced video (as opposed to telecined film for example).
Meaning you are required to de-interlace and Dgbob has various settings to taylor the process of deinterlacing.
Some interlaced video has 2 fields holding one progressive frame (eg film to video @ 24 fps).
Weaving works great for that type of interlaced video.
The console output isn't like that, it holds 2 progressive frames (not standard but allowed for consumer grade devices, I believe).
I tried the .TS sample you provided with dgbob mode=1 order=1 threshold=0.
That way you get "360 x 240 game pixels" (from a field) plus "360 x240" black pixels that are filled in by interpolation.
The interpolation with these settings are constrained by only looking at the nearest "game pixels" in that field.
And each field is treated that way as opposed to only half the fields (hence the doubling of frame rate from 30 to 60 fps).
If you use smarter de-interlacing then you may loose the transparency effect because of blending the rainbow present in one field and rainbow not present in the next (not verified if that happens!).
Try Dgbob with:
tick in in top field first
mode: double nb of frames and fps
threshold set to 0
no tick in extra
Downscale to 640x480 by using the swscale resizer filter.
(use after the Dgbob filter)
Something else - the 720 pixels wide may well include overscan (unseen "pixels" on the TV / black vertical borders in the capture).
Might want to investigate cropping any vertical black borders before rescaling.