Elgato questions

Edit history:

TheThrillness: 2013-03-29 01:11:57 am

2013-03-29 01:11:36 am

thethrillness.blogspot.com

https://forum.speeddemosarchive.com/post/reencoding_with_anrichan_from_elgatorecorded_mp4_files.html

Yes the solution seems to be that line imported into VDub. You can also use FFmpegSource2("D:\filename.mp4",atrack=-1)

If I had time I would test this myself. You might also need the VirtualDub AAC codec: http://gral.y0.pl/~fcchandler/AACACM/index.html

2013-03-29 06:38:31 am

Are you sure the color shift isn't caused by the splitter to remove HDCP? Does it look the same if you skip the Elgato and plug it directly into your TV? Or are you using the component cable? I only tried component from a PSP, but the result was good.

ballofsnow

2013-03-29 09:47:56 am

Quote from Molotov:

The problem is, I'm not completely sure how I'm supposed to get the results into something that Anri will accept. The original recordings are .ts files,

You can try Anri 3.3 with the AAC mod I made. It's listed under changes to 3.4:

https://forum.speeddemosarchive.com/post/anrichan_3.3__june_5_2011.html

In Anri, choose AVCHD as source.

2013-03-29 10:08:11 am

thethrillness.blogspot.com

Will 3.4 work with Elgato though? Elgato is mts and the changes list it is for m2ts.

ballofsnow

Edit history:

ballofsnow: 2013-03-29 10:55:12 am

ballofsnow: 2013-03-29 10:53:53 am

2013-03-29 10:53:14 am

m2ts, ts, mts, they seem to be more or less the same thing. Or, at least, dgavcdec is able to process them anyway if they're different. Should work specifically with Elgato, since I tested with a clip that blizzz made in this thread. Note that we identified a chroma issue, so be on the watchout..

Oh, and don't hold out for 3.4, I don't think it'll see the light of day. I just made the mods/patches because I was getting fed up. I'm looking at nate's Yua these days to take over.

2013-03-29 03:13:17 pm

Quote from blizzz:

Are you sure the color shift isn't caused by the splitter to remove HDCP? Does it look the same if you skip the Elgato and plug it directly into your TV? Or are you using the component cable? I only tried component from a PSP, but the result was good.

Since the game is on the Playstation 3, I have no choice but to use component cables. The shifting isn't there when I plug the cables in directly. There's still a shadow behind the letters, but that much I'm sure is intentional. The Elgato just overkills it for some reason and I messed with the component/TV compatibility options to see if that would help (it didn't).

Quote from ballofsnow:

Note that we identified a chroma issue, so be on the watchout..

When I read that topic, I assumed the chroma issue was only for old consoles using the A/V adapter. It's been known to do the same thing to newer consoles as well?

Edit history:

blizzz: 2013-03-29 04:08:13 pm

2013-03-29 03:49:25 pm

The chroma issue is caused by recording 240p as 480i with bad compression. Recording progressive sources is fine.

I don't have Valkyria Chronicles, so I can't test it myself. Do you have some other games that show this that I might have? In general it wouldn't be bad to record using HDMI (even though the later PS3 models have a lossy HDMI encoder). The View HD mini splitter will remove HDCP, check the sticky thread for more info.

Edit: Just tried PS3 with component cables. Couldn't see any problem in the menu or some games I started.

2013-03-29 04:56:31 pm

I'm going to attach a few screenshots to save on upload time (if you need videos, just let me know). Out of the games I tested, it was most obvious for Metal Gear Solid 3 and Final Fantasy XIII-2. The shadow on the text is way too big, but maybe it doesn't matter much? I can't really notice any problems in motion, at least. It's just irritating because I know it's there. :/

Also, I tested out the Anri mod and I've got a new problem. The high quality encode comes out perfectly, but the insane and extreme quality both sound like they are underwater. I'll have to try the manual Avisynth method later and see if that still happens.

Attachment:

Screenshots.rar

2013-03-29 05:55:00 pm

FF XIII-2 (Asia) on PS3 with the Elgato component cable.

2013-03-29 08:24:47 pm

Yeah, I'm thinking it's the component cable's fault at this point. I'll try to pick one up within a few days and see if that solves the ghosting. If it does, I'm going to have the great combo of relief and that feeling of incredible stupidity. Tongue

Also, I tested the Avisynth method that TheThrillness mentioned and it works well. The audio starts a second or two late, but it's totally in sync and doesn't sound like its underwater, so I don't care.

2013-03-30 06:53:37 am

If blizzz used different component cables than what Elgato bundled then the conclusion could be that the Elgato cable is the cause of the issue.

2013-03-30 07:18:20 am

Quote from TheThrillness:

If blizzz used different component cables than what Elgato bundled then the conclusion could be that the Elgato cable is the cause of the issue.

Quote from blizzz:

with the Elgato component cable.

Component quality is good with any cable I tried. Not the same level as with the SC-500N1, but rather close.

Edit history:

TheThrillness: 2013-03-30 10:32:50 am

2013-03-30 10:31:25 am

thethrillness.blogspot.com

I swear I read that post as if it was from Molotov (I think I got confused because you have no avatar and I had just woken up :P). Now this issue really is interesting.

2013-03-30 05:11:45 pm

Ok, I just (re)learned that I'm a complete freaking moron. Long story short, I didn't know that one cable that I never opened from the package was the component cable. I just saw what looked like an A/V In and assumed it was the "retro adapter" or something. It didn't help that it came along with an HDMI cable, which I knew for a fact that I didn't need. Turns out the other one was the component cable and it solved the ghosting entirely. So yeah, I'm a giant idiot and all the issues are resolved now. o\

Thanks for the help everyone.

Super Mario World Test.mp4

2013-05-21 03:13:08 pm

TheThrillness asked me to record a Super Mario World sample using the latest Elgato firmware and upload it for someone else to look at. I've attached what I think is an ok recording, but I'm not entirely sure how I'm supposed to record standard definition stuff. These are the settings I used:

Input: Composite
Profile: Standard
Quality: Best
Preserve Source Format

I left the overscan and stretch options alone, since those are probably not good. The result is an interlaced 720 x 480 video at 59.94 frames per second. If I disable "preserve source format," the output becomes a progressive 640 x 480 video at 29.97, but the deinterlacing doesn't seem very good.

Do these options sound correct? I can't do anything about the input frame rate at all, so I'm guessing this is the best I can do. I'm also wondering about encoding this stuff, because when I tried it with this sample, the most correct looking option in Yua had some weird issues with part of the grass bobbing even though nothing else did. I'd love to get this stuff sorted out properly, because I'd rather not record with an EZ Cap in composite for standard definition.

TheThrillness asked me to record a Super Mario World sample using the latest Elgato firmware and upload it for someone else to look at. I've attached what I think is an ok recording, but I'm not entirely sure how I'm supposed to record standard definition stuff. These are the settings I used:

Input: Composite
Profile: Standard
Quality: Best
Preserve Source Format

I left the overscan and stretch options alone, since those are probably not good. The result is an interlaced 720 x 480 video at 59.94 frames per second. If I disable "preserve source format," the output becomes a progressive 640 x 480 video at 29.97, but the deinterlacing doesn't seem very good.

Do these options sound correct? I can't do anything about the input frame rate at all, so I'm guessing this is the best I can do. I'm also wondering about encoding this stuff, because when I tried it with this sample, the most correct looking option in Yua had some weird issues with part of the grass bobbing even though nothing else did. I'd love to get this stuff sorted out properly, because I'd rather not record with an EZ Cap in composite for standard definition.

Attachment:

Edit history:

TheThrillness: 2013-05-21 06:48:01 pm

TheThrillness: 2013-05-21 06:47:39 pm

TheThrillness: 2013-05-21 06:38:27 pm

2013-05-21 06:36:01 pm

thethrillness.blogspot.com

Thanks for that Mol. It might be worth attaching that 640x480 29.97 video just incase that can be fixed (29.97 might have the separate fields) that Yua can fix out.

This is the best I could encode in Yua from the above sample using 1 pixel shift. Attached it to this post. Hopefully nate or bos see this.

It might just be my setup/player (CCCP package) but in the original video from blizzz (https://dl.dropbox.com/u/3459629/videos/Recording_2013-03-07_19-56-26_0002.ts) every frame makes progress but in Molotov's video when you frame advance, Mario like goes "back" every other frame. Hard to explain. Have a look yourself. Elgato look to have altered the recording way (not sure if properly though).

Attachment:

yua_HQ 2.mp4

Screen Shot 2013-05-21 at 9.12.25 PM.png

2013-05-21 08:14:07 pm

there is definitely something going on with the chroma. it's probably because it's interlaced yv12 (almost never seen without chroma ghosting). yua also apparently can't seek reliably in the video. the result seems fine though since there's no chroma ghosting and the chroma bobbing isn't really noticeable played back at f1.

Attachments:

smw_HQ.mp4

Edit history:

TheThrillness: 2013-05-21 09:18:17 pm

2013-05-21 09:17:18 pm

thethrillness.blogspot.com

Seeking on the Windows version of yua seems fine to me using the clip Molotov posted. Maybe issue with Mac version?

I'm no expert with all this but would S-Video clear this chroma issue up? Elgato do sell S-Video adapters for this device. If F1 passes SDA standards, would this be true for F2 and F3 material to?

Last question. 1-pixel shift is the only thing that gives good results?

2013-05-21 09:40:53 pm

there's no mac or windows version of yua. there's only yua. theoretically at least. to see it you have to go frame by frame for a while, maybe 50-100 frames. then it will suddenly go back a few dozen frames. normally i would be interested in fixing it, but seeking with ffmpeg is such a fuckfest that i'd rather pretend i didn't see it. at least for now.

s-video won't make any difference. the problem probably arises from a different chroma layout used in the video from the elgato than the one yua assumes is in use (which avisynth also uses and the code for which i copied from avisynth 3.0).

The classic pitfall of YV12 to YUY2 colorspace conversions
is to forget to take into account where chroma pixels lie
spatially, relatively to the luma pixels.

Neither is that position isn't exactly defined. You can find
YV12 colorspaces that differ only by the position of their
chroma pixels.

That implies that several converters must be implemented.
Ideally, one converter for each possible pair of
( input colorspace, output colorspace ).

Note also that we don't care about the horizontal position
of the chroma pixel, which we'll assume fixed and the same
in both colorspace.

Note the following convention : X will be a luma pixel, O a
chroma one.

Luckily, the chroma pixel, in YUY2 progressive, can only be on
the luma pixel, so that case is easily solved

yuy2 progressive :

X O X O X O X O X

X O X O X O X O X

X O X O X O X O X

X O X O X O X O X

Let's see now YV12 progressive : we have three possible positions :

yv12 progressive 1 ( most classic one ) :

X X X X X

O O O O

X X X X X

X X X X X

O O O O

X X X X X

yv12 progressive 2 :

X O X O X O X O X

X X X X X

X O X O X O X O X

X X X X X

yv12 progressive 3 :

X X X X X

X O X O X O X O X

X X X X X

X O X O X O X O X

Now, when we want to make a conversion from yuy2 to yv12, we
must use the proper interpolation according to the final
yv12 colorspace.

In YUY2 ---> YV12 1, the bilinear kernel used will be (1, 3, 3, 1)
In YUY2 ---> YV12 2, the bilinear kernel used will be (1, 2, 1, 0)
In YUY2 ---> YV12 3, the bilinear kernel used will be (0, 1, 2, 1)

Now, lets think a little about how interlace is stored in YV12.
It's not as abvious as it seems. One would first think that chroma
pixels lies in their respective field as if the field was itself
progressive. But what happens most is actually chroma pixels been
where they should be on the whole progressive frame.

That implies that if we consider a field alone, chroma pixels are
even more weirdly placed.

Let's examined each YV12 colorspace successively :

YV12 interlaced 1, top field :

X X X X X
O O O O

X X X X X

X X X X X
O O O O

X X X X X

YV12 interlaced 1, bottom field :

X X X X X

O O O O
X X X X X

X X X X X

O O O O
X X X X X

YV12 interlaced 2, top field :

X O X O X O X O X

X X X X X

X O X O X O X O X

X X X X X

YV12 interlaced 2, bottom field, and YV12 interlaced 3, top field :

X X X X X

O O O O

X X X X X

X X X X X

O O O O

X X X X X

YV12 interlaced 3, bottom field :

X X X X X

X O X O X O X O X

X X X X X

X O X O X O X O X

That implies the following kernels :

YV12 interlaced 1, top ---> (3, 7, 5, 1)
YV12 interlaced 1, bottom ---> (1, 5, 7, 3)
YV12 interlaced 2, top ---> (1, 2, 1, 0)
YV12 interlaced 2, bottom ---> (1, 3, 3, 1)
YV12 interlaced 3, top ---> (1, 3, 3, 1)
YV12 interlaced 3, bottom ---> (0, 1, 2, 1)

i briefly considered including support for switching to the other kernels provided by manao's library into yua, but i'd really need to see proof that the less common standards are used in more than one device to introduce that complexity. it would probably end up like switching the statid image - not obvious to the user how to do it - in any case.

yes, 1-pixel shift seems required for this material.

there's no mac or windows version of yua. there's only yua. theoretically at least. to see it you have to go frame by frame for a while, maybe 50-100 frames. then it will suddenly go back a few dozen frames. normally i would be interested in fixing it, but seeking with ffmpeg is such a fuckfest that i'd rather pretend i didn't see it. at least for now.

s-video won't make any difference. the problem probably arises from a different chroma layout used in the video from the elgato than the one yua assumes is in use (which avisynth also uses and the code for which i copied from avisynth 3.0). [hidden="more info, complements of manao"]   The classic pitfall of YV12 to YUY2 colorspace conversions
   is to forget to take into account where chroma pixels lie
   spatially, relatively to the luma pixels.

Neither is that position isn't exactly defined. You can find 
   YV12 colorspaces that differ only by the position of their
   chroma pixels.

That implies that several converters must be implemented. 
   Ideally, one converter for each possible pair of 
   ( input colorspace, output colorspace ).

Note also that we don't care about the horizontal position 
   of the chroma pixel, which we'll assume fixed and the same
   in both colorspace.

Note the following convention : X will be a luma pixel, O a
   chroma one.

Luckily, the chroma pixel, in YUY2 progressive, can only be on
   the luma pixel, so that case is easily solved

yuy2 progressive :

X   O   X   O   X   O   X   O   X

Let's see now YV12 progressive : we have three possible positions :

yv12 progressive 1 ( most classic one ) :

X       X       X       X       X

O       O       O       O

X       X       X       X       X

O       O       O       O

X       X       X       X       X

yv12 progressive 2 :

X   O   X   O   X   O   X   O   X

X       X       X       X       X

X   O   X   O   X   O   X   O   X

X       X       X       X       X

yv12 progressive 3 :

X       X       X       X       X

X   O   X   O   X   O   X   O   X

X       X       X       X       X

X   O   X   O   X   O   X   O   X

Now, when we want to make a conversion from yuy2 to yv12, we
   must use the proper interpolation according to the final
   yv12 colorspace.

In YUY2 ---> YV12 1, the bilinear kernel used will be (1, 3, 3, 1)
   In YUY2 ---> YV12 2, the bilinear kernel used will be (1, 2, 1, 0)
   In YUY2 ---> YV12 3, the bilinear kernel used will be (0, 1, 2, 1)

Now, lets think a little about how interlace is stored in YV12.
   It's not as abvious as it seems. One would first think that chroma
   pixels lies in their respective field as if the field was itself
   progressive. But what happens most is actually chroma pixels been
   where they should be on the whole progressive frame.

That implies that if we consider a field alone, chroma pixels are
   even more weirdly placed.

Let's examined each YV12 colorspace successively :

YV12 interlaced 1, top field :

X       X       X       X       X 
       O       O       O       O

X       X       X       X       X

X       X       X       X       X 
       O       O       O       O

X       X       X       X       X

YV12 interlaced 1, bottom field :

X       X       X       X       X

O       O       O       O     
   X       X       X       X       X

X       X       X       X       X

O       O       O       O     
   X       X       X       X       X

YV12 interlaced 2, top field :

X   O   X   O   X   O   X   O   X

X       X       X       X       X

X   O   X   O   X   O   X   O   X

X       X       X       X       X

YV12 interlaced 2, bottom field, and YV12 interlaced 3, top field :

X       X       X       X       X

O       O       O       O

X       X       X       X       X

O       O       O       O

X       X       X       X       X

YV12 interlaced 3, bottom field :

X       X       X       X       X

X   O   X   O   X   O   X   O   X

X       X       X       X       X

X   O   X   O   X   O   X   O   X

That implies the following kernels :

YV12 interlaced 1, top     ---> (3, 7, 5, 1)
   YV12 interlaced 1, bottom  ---> (1, 5, 7, 3)
   YV12 interlaced 2, top     ---> (1, 2, 1, 0)
   YV12 interlaced 2, bottom  ---> (1, 3, 3, 1)
   YV12 interlaced 3, top     ---> (1, 3, 3, 1)
   YV12 interlaced 3, bottom  ---> (0, 1, 2, 1)
[/hidden]
i briefly considered including support for switching to the other kernels provided by manao's library into yua, but i'd really need to see proof that the less common standards are used in more than one device to introduce that complexity. it would probably end up like switching the statid image - not obvious to the user how to do it - in any case.

yes, 1-pixel shift seems required for this material.

Edit history:

TheThrillness: 2013-05-21 10:02:05 pm

TheThrillness: 2013-05-21 10:01:42 pm

2013-05-21 10:01:12 pm

thethrillness.blogspot.com

Silly me. I only briefly used the slider and when frame advancing I do get the seek error.

Maybe just to see if switching kernels work, do some tests to see if it is that?

If it does happen to fix the issue, maybe just release one special build of yua for Elgato and then keep it separate from the main program. I see no reason as to why the Elgato could not become an SDA standard device that everyone uses. You would have every console covered along with HDMI video pass through so nobody has to buy amplifiers.

2013-05-22 07:01:26 pm

or, even better, autodetect the yv12 chroma layout with the same method i'm planning on using to autodetect the d4 bob reduction method and f.

Super Robot Wars Z Test 2.mp4

2013-05-22 10:35:37 pm

While I'm at it, I'd like to ask about 480i Playstation 2 recordings. I've attached two different samples. The first one is the preserve source format version and the second is with Elgato's attempt at deinterlacing. It seems like no matter what deinterlacing method I try (Yua or Elgato), the portraits end up getting somewhat screwed. This isn't meant to be a quality test, but would that sort of thing be SDA acceptable? I'm guessing it is, but can't hurt to ask.

Attachments:

Super Robot Wars Z Test.mp4

2013-05-23 08:37:16 am

so which one is which? the f1 one has field blending so that is obviously out. the f2 one looks fine but i wonder whether half the frames are missing. the jaggies on the portraits are probably due to interpolation-based deinterlacing. anri's deinterlacing is not like that and would probably produce better results in this case.