VERO VS ATV Anyone like to share there real world exsperiance

Help and Support Vero
41

Because you are not streaming HD audio. The 23.976Hz only really presents issues when you are trying to passthrough audio. Even then, it depends on the receiver…

TVs should handle 23.976Hz (24/1.001) and 24.000Hz (24/1.000) just fine. The most common thing people will get is an audio dropout, which in the worst case scenario, can present every 41 seconds.

When playing back video, you can either synchronise playback with the video clock or the audio clock. Vero uses the video clock. With a video clock, you adjust the audio to synchronise with the video (drop packets); with an audio clock you adjust the video to synchronise with the audio (drop frames).

If you are not bitstreaming audio, then the video clock can easily be used for synchronising and the audio can be adjusted. If you are bitstreaming audio, you cannot modify the audio, one because we need to keep it intact, and two, because we do not know what’s in each packet. In theory…

Vero can theoretically, output a 23.976Hz signal, but the kernel does not support it. The trick (early testing) is to set it at the PLL directly. This gives us 23.976Hz output. But, as far as the kernel, and Kodi are concerned, they think that they are outputting at 24Hz, so you will have a synchronisation issue. The solution here would be to software decode the formats. This can be done for DTS, AC3, and in Isengard, with the libdcadec library, DTS-HD should be decodable in software too. We then decode into LPCM and as we do now know what is in each packet, we can effectively synchronise the clocks. Some amps are more susceptible to timing issues than others. You get HD audio – the only difference is that your amp won’t show that fancy HD audio passthrough light.

23.976 is still being tested on the Vero.

S

42

Sorry, the Vero / cubox does not have a Video Reference Clock at all or do you see one here: https://github.com/xbmc/xbmc/tree/master/xbmc/video/videosync

@mk01 of xbian is working on one - and we are pretty far.

Without this video clock which “basically” ticks to eglSwapBuffers in order to really know a frame has been presented, there currently is a cpu timer fallback, which does not guarantee at all that I frame has been presented.

And something concerning the 3:2 which was mentioned. This works also only in that case by speeding up to 24.0 and then using 60 hz for display. All of this will kill passthrough audio heavily. With a 59.94 mode passthrough would have been at least usable.

But - the same guy working on the Reference Clock also has implemented fractional modelines and support for it in kodi - so there finally is some hope for vero / imx users.

Something else: the ATV had an nvidia gpu, which was perfectly able to sync to a 23.976 fps clock, but sadly you need a special xorg.conf - which you btw. still need on every nvidia hardware on linux until today (kodi’s wiki has more information about that).

In short: If 3:2 is not possible and direct fps adjustment is not possible, passthrough audio will become a nightmare, cause the problem with “drops” and “dupes” is, that you will hear them with a nice psssst noise.

43

Yes you are correct :stuck_out_tongue:

Sam

44

Yes confirmed. The ATV uses xorg.conf so the NVIDIA X driver can validate Modelines based on the EDID presented by the connected display. This includes 23.976 if your TV supports it. VESA modes are not used.

[quote=“Soli, post:40, topic:5096”]
As for your next question, I fail to see the relevance. Most users don’t even see a difference when playing 23,976fps over 60hz. (A so called “jittery” 3:2 pulldown). That doesn’t mean the playback is “perfect”.[/quote]
I guarantee if you blind tested users by showing video on a media player platform supporting 23.976fps output on a 24p TV with some sort of Cinema Mode activated, and then showed them the same video again this time playing 23.976fps at 60Hz (using a 3:2 pulldown technique), they would go for the former every time.

Using this example, the former is far more “perfect” to the viewer than the latter with its horrible 3:2 pulldown camera pan judder.

Interestingly it looks that way when you have newer Hardware to compare it to. Just did a back to back comparison with the ATV1+CHD (23.976) compared to an AMlogic S805 SoC with 23.976Hz output running Android + Kodi Isengard RC. I agree the ATV1 camera pans during video playback are a little bit “jittery” compared to the buttery smooth output of the far newer AMlogic Hardware.
(Opening scenes in Tron Legacy are good for testing this.)

45

Something I said technically wrong: We are very proud, that IMX/vero does not have to do eglSwapBuffers anymore, cause of the two fbs, this was very bad bus performance wise. Currently we just enable doublebuffer and print the fb1.

@mk01s code hooks into the kernel and measures these ticks. From there they are used in a handle to get the information. Btw. such a Reference Clock also only is helpful when you don’t passthrough audio - out of the known issues. It makes no sense to sync video to a display while you can only throw audio frames away.

Other than that - I am really thankful to @mk01 that studied 3000 pages of freescale manual and did that stuff on his on during his freetime while having a 60 hours / week job. Hopefully we will see some prebuild images by him very soon. This would be a “good” final feature for imx hw and I’d push it to kodi upstream.

46

Wrxtasy, stop it:)

The ATV can use a special xorg.conf but you have to add it yourself. So no, ootb 23.976hz is not supported based on EDID. (And by it’s very nature, a custom xorg.conf will override the EDID info)

I’m not talking about a direct comparison, my point is that you don’t judge if something is “right” based on what the general population thinks is right. My friends use their Samsung and LG TV’s with their default values, oversaturated colors, “super” brightness, frame interpolation, mpeg denoiser, “super” blacklevel, contrast and whatnot, with jittery 3:2 pulldown. To them it looks fantastic, whereas I’m getting suicide tendencies… Still, they would be able to discern 23.976hz compared to 60hz if it was presented to them.

And by the looks of it, you yourself just confirmed my point by comparing the ATV to a true 23.976hz source. So much for the “perfect” playback of ATV eh?

I’m sorry for the lack of quoting. This forum is a absolute nightmare on an iPad.

47

I don’t see your point at all. The purpose of a distribution is to ship “the best quality possible” out of the box. So after unpacking everything possible will work. And as this nvidia driver flaw is known since >= 6 years, it’s so simple to ship that config. And then you have an out of the box experience like you want it.

And what you also confuse is, that the nvidia driver(!) has this bug when parsing the EDID information. xorg.conf does not overwrite EDID at all, it just adds modes, nvidia is not able to parse - this won’t change even if you change the complete EDID.

This is btw. a linux only bug. On windows systems it finds 24.0 and 23.976 modes.

Also what obviously no one understands is how “Sync Playback to Display” works. If you leave audio aside (or assume no passthrough audio), it does absolutely not matter if you sync to 23.976 fps or to 24.0 - cause the ReferenceClock does not nothing else besides: tick, tick, tick, tick … if you display 24 frames a second on a 24.0 hz monitor or if you display 23.976 fps on a 23.976 monitor does not make a single difference and you won’t see a single issue with that.

The problem starts when audio, that you cannot touch comes into play, as this speedup can only be achieved with resampling (if refclock is constant - what a display clock should be → harmless), if you need drop / dupe → big issue.

Edit: Perhaps to be more clear here: If your Reference Clock runs with 24 fps and you watch a 23.976 fps movie, the movies is speed up, cause 24 fps are displayed per second(!), nothing will happen to the image content, no stutter, nothing - just the time one frame is displayed is a bit less than before. This is no issue at all and nothing you will see at all, if you resample the audio to match this new speed, you guessed it - if the “other clock”, which is audio’s clock (sync and so on) needs to be adjusted and you cannot - cause it is packetwize passthrough only, you start to get issues.

For the vero here, we have the problem that there is no ReferenceClock, just a computed one. This uses the fps value and “guesses” when next swap should happen. That this goes fully wrong as the speed of the swapping is not known at all - is also clear.

Summarize:

  • If you have a working Video Reference Clock and if you don’t need passthrough audio, everything will most likely be fine for you (if you have issues with 3:2 - you need a 24.0 hz mode)
  • If you need passthrough, you need a display speed that matches the audio clock. So if your movies is 23.976 fps and you don’t get a 59.94 hz mode and your output is only 24 or 60hz - you have a big, big issue that is not solvable without either video stutter or audio drops.

(Based on current kodi techniques - empty audio frames, one could produce with matching headers not taken into account).

48

I’m talking about the Crystalbuntu 2 “distro”. ootb means “cb2 ootb”, not my view of what ootb is supposed to be. If you add a 23.976hz mode to cb2, then that mode is read from xorg.conf and not EDID, so yeah we agree.

Don’t think anyone misunderstands what “sync playback to display” is. It’s an elegant way of getting smooth framerates and to get rid of the framedoubling each 41second, but as you say it’s not quite compatible with passthrough audio. I just feel that hardware in 2015 should be able to output 23.976hz and one shouldn’t have to resolve to workarounds.

49

Fully +1 to what you said!

50

@ Soli, Don’t go getting all dark and stormy on us now while class is in progress :wink:
(I suggest Beer to easy the pain I may have caused !)

I’m happy to stand corrected and learn something about what looks like a long standing NVIDIA EDID driver parsing bug in the process. One I knew nothing about.

As was Kindly and patiently pointed out by Fritsch this EDID parsing error is not going to work for 23.976fps output on the ATV due to this:

<mode id="0x1c0" name="1920x1080" w="1920" h="1080" hz="23.97091" current="true" preferred="false"/>

To fix its xorg.conf Modeline edit time…
EDIT: This is better after xorg.conf tweaking …

<mode id="0x1c0" name="1920x1080" w="1920" h="1080" hz="23.97576" current="false" preferred="false"/>

And yes completely agree Hardware released in the last few years has to support 23.976Hz out of the box by whatever means possible. Users are demanding it. :slight_smile:

51

Btw. obviously those modes are only used if you have “Adjust Refreshrate to match video” (On Start / Stop) enabled under Video -> Playback.

When watching such a movie, you can verify with the kodi-xrandr command to see if those are used. From the logfile you sent me via email, you seem to still miss the 24.0 mode.

52

Yes I always run Kodi with this mode - Adjust Refreshrate to match video" (On Start / Stop)
Fixed 24Hz too :smile:

For those reading the Modeline for 23.97576Hz worked when using NVIDIA drivers v.304.125 and also v.304.84 I’ve downgraded to v.295.40 to test and the Modeline is then overridden by nvidia-auto-select again.

Fritsch, is this EDID parsing bug still in the newest NVIDIA drivers or just the old stuff ?

53

Yes … all of them. Was never fixed. And you need > 300 for these modes to work. For older version, it was more hard to accomplish the same.

Btw. Now make a test for me:

Use kodi-xrandr to force your refreshrate to 24.0 hz(!) (triple verify). Then disable Adjust Refreshrate to match video completely.

Now instead turn on “Sync Playback to Display” (if v14: Method Video -> Clock and Resample Audio).

Turn off Passthrough audio and play a 23.976 fps movie.

What happens? (Just try to see what happens, no thinking involved).

Edit: Forcing is done by: DISPLAY=:0 /usr/lib/kodi/kodi-xrandr --output HDMI-0 --modex 0xASDF (replace the ASDF to the matching mode)

54

DISPLAY=:0 /usr/xbmc/lib/kodi/kodi-xrandr --output HDMI-0 --mode 0x1be
DISPLAY=:0 /usr/xbmc/lib/kodi/kodi-xrandr

<mode id="0x1be" name="1920x1080" w="1920" h="1080" hz="24.00000" current="true" preferred="false"/>

Kodi Isengard Alpha2…
Plus the above config… (no refresh rate switching occurring)

Visually I see no difference compared to a 23.976fps movie played with the 23.98Hz video output mode selected. No Frame duplicates or drops, No Audio issues with 5.1 sound either, its still in sync after 10 mins of video playback.

Now if I’ve been paying attention, video is sped up to 24fps and Audio Resampled due to the ATV1 having a video reference clock. Yes ?

55

Exactly. This will be a solution for the vero / cubox if the 23.976 modes that we try to force (out of spec) into it are not usable. But this solution needs a video clock (in your case now GLX clock).

Oki, if you don’t use passthrough, keep the Sync Playback to display enabled and enable Adjust Refreshrate to match video on start / stop additionally.

If you use passthrough, disable Sync Playback to Display again.

Btw. I personally use: Adjust Refreshrate + Sync Playback to Display + Passthrough off. Perfect video and I don’t care about what my AVR displays.

56

I’m sure a lot of IMX/Vero owners will be very grateful when that happens. :smiley:
Talk about gettin down and dirty into the Freescale code !

I will test the Amlogic S805 SoC I have here next to see if they have a video reference clock or are using some sort of workaround at the driver/Kernel level.

23.976fps video camera panning and playback is still smoother on the AMlogic S805 than the corrected 23.97576Hz playback on the ATV1.

Good info in this thread here Fritsch !

57

If you don’t have skips or drops and the refreshrate is matching :slight_smile: then this is not really possible, besides perhaps your TV is “interacting” … turn off all these “TV Smoothers” or 800 hz features :-).

And something else; With the “Sync Playback to Display” it’s not possible that it could tear at all, if hw decodes correctly (e.g. no drops) and render is fast enough (no skips) and driver is not buggy as hell (Missing in codec info) - it can’t get smoother on any platform. So much about smoothness.

If you don’t like the picture on ATV, see the xorg.conf concering the RGB Mode, try to set that on Limited, perhaps that is an issue which influences your mind :slight_smile:

58

No the atv isn’t as smooth as can be. It’s a little jittery, believe it or not.

59

It has nothing to do with the ATV at all and it also has nothing to do with religion. If the swapBuffers the glx method uses is doing it’s job, it can’t be non smooth.

If I would like to believe something I would be a member of the church. Measure the GLX clock and print calculate the error vs. a hpet and see yourself.

60

I see the same minor jitter as Soli, with all smoothing modes off on the TV as well. I never noticed it at all before until doing a back to back comparison with the AMlogic S805.
Funny how the brain get used to seeing something until an improved version comes along.

I do know my jitters from my judders now and I don’t even go to Church :slight_smile: Maybe we’ve both become sensitised from testing stuff a wee bit.