no luck playing mp4 from an xcd

[Phobos]

Originally posted by calinb
Really? Was the 3ivx splitter fixed?

I have the "plus" version (paid-version)of 3ivx installed on my computer, but I downloaded the latest free 3ivx demo. Comparing the size and dates on the splitters (3ivxDSMediaSplitter.ax), they are both 284KB and 1/27/2004, which predates our problems.

you are right, lastest 3ivx version was released before our problems, or was there an un-announced change??

[bond]

3ivx is working behind the scenes on new versions of their tools of course
i assume they sent avih a fixed unofficial one for testing

[SeeMoreDigital]

bond,

Can you remind us how well the Philips DVP642 stand-alone player coped with .mp4 files burned as XCD?


Cheers

[bond]

i think it has been reported hat the video was "delayed", dunno what this means tough

[SeeMoreDigital]

Please forgive me for asking an stupid/newbie question!

Does XCD use similar standards to the old Philips CDi system?

On this thread (http://forum.doom9.org/showthread.php?s=&threadid=74009) Joe Fenton describe CDi as being: -
discs are one track in mode 2 form 2 with a variant of ISO-9660 specific to Philips. I don't do much burning so I don't understand all the different modes etc. But I am interested why it is some players (like the Philips) can read/see discs that other players can't!


Cheers

[avih]

Originally posted by bond
3ivx is working behind the scenes on new versions of their tools of course
i assume they sent avih a fixed unofficial one for testing

no, thay actually haven't. Shitowax told me they changed the implementation (which also caused the same symptoms while playing a clip from a network drive, due to the same incorrect assumptions: "the underlaying layer should handle cache, and therefore, we can treat the stram as fully random access, and don't worry about delays in reading it from the medium").

i wasn't following this issue closely since, as i don't personally use the 3ivx splitter.

perhaps shitowax could provide some more info here.

sorry for the misinformation guys, i hope we can sattle this issue soon.

avih.

[bond]

okidoki, i now had the time to test avih's 7f filter with the latest internal 3ivx version available atm (should include all the goodies shitowax promised in this thread :D )

here are my findings:
1) with 7f loading needs about 6-7 secs (with graphedit, winme) on my 866mhz pentium3
2) with the latest official 6b it takes forever (surely more than 30secs)
3) only registering the 7f is not enough (takes very long like 6b), adding the mentioned registry entries is still necessary (shitowax wrote that 3ivx will do this automatically)
4) there doesnt seem to be much seeking, as the cd drive is very quiet
5) the whole playback process seems to need pretty much cpu power, as at the beginning and on some highmo scenes i get choppy playback

all in all 7f is working much better than 6b, still for me the current situation is far from being perfect :(

/me blames shitowax!

[calinb]

Originally posted by bond
okidoki, i now had the time to test avih's 7f filter with the latest internal 3ivx version available atm (should include all the goodies shitowax promised in this thread :D )
Bond, Thanks!

Your latest result seems to be in line with what I found with 7f and the released 3ivx splitter. I made the registry edit too. Doesn't sound like the internal version provides any improvement. Are you sure shitowax gave you a new splitter (did you diff the files :))

[bond]

Originally posted by calinb
Doesn't sound like the internal version provides any improvement. Are you sure shitowax gave you a new splitter (did you diff the filesi am absolutely sure, as i have access to internal alpha releases which are done for testing previews

what i find annoying is the high cpu usage it needs during decoding :(

[shitowax]

It's a VERY BAD idea to put a .mp4 file on an XCD... and this whatever chaching system we add in our splitter.
Anyway, did you check that the same bitstream plays correctly from a .avi ? Maybe it's just your CDROM drive that cannot handle the high bitrate of those scenes ...

Originally posted by bond
okidoki, i now had the time to test avih's 7f filter with the latest internal 3ivx version available atm (should include all the goodies shitowax promised in this thread :D )

here are my findings:
1) with 7f loading needs about 6-7 secs (with graphedit, winme) on my 866mhz pentium3
2) with the latest official 6b it takes forever (surely more than 30secs)
3) only registering the 7f is not enough (takes very long like 6b), adding the mentioned registry entries is still necessary (shitowax wrote that 3ivx will do this automatically)
4) there doesnt seem to be much seeking, as the cd drive is very quiet
5) the whole playback process seems to need pretty much cpu power, as at the beginning and on some highmo scenes i get choppy playback

all in all 7f is working much better than 6b, still for me the current situation is far from being perfect :(

/me blames shitowax!

[bond]

Originally posted by shitowax
Maybe it's just your CDROM drive that cannot handle the high bitrate of those scenes ...hm i noticed that whenever there are highmo scenes, which show choppyness, it seems that there is some heavy reading from the cd, as the lights of my drives flash strongly (in quiet scenes the lights flashes very rarely).

i tested it with my two drives: philips cdd4801 burner (reading speed 32x) and the samsung sd-612s dvd drive (40x)

does anyone know whats causing this heavy reading in highmo scenes and what i can do about it?
does the caching discussed in this thread influence this somehow? shouldnt be 40x drives fast enough to handle 1cd highmo bitrates?


btw i also noticed that the samsung drive doesnt seem to like reading the beginning of mp4s on xcd as it takes very long, makes lots of noice, spins around a lot...
i assume this has something to do with the way the 3ivx splitter handles the mp4 playback starting?

[avih]

@bond:
the buferring/prefetching affects mainly 2 scenarios:

1. most important: the startup time. during the 'negotiations' phase, some splitters (i.e. the 3ivx one) reads the a LOT of data in very small chunks (think 2M in 2-4 bytes chunk) to identify the properties of the clip, and synchronize with the stream. in this case, the buferring (and prefetching) helps performance a lot (again, only if the splitter ignores the fact that it's reading from a relatively slow media).

2. during playback, where relatively larger chunks are read (think 2K-32K), the buferring has small to non-existent improvement to very-slightly deteriorating the performance, because the cache is searched on every read, but it never finds anything it needs in the cache (it always reads forward and nearly-never the same sector twice). the preformance hit should be neglectible imho though.

[bond]

thanks avih! :)

any idea why (too) the heavy reading from the cd in highmo scenes happens and what i can do about it? :(

[avih]

@bond.
no, i don't know. iirc, i did not see any obvious anomalities with the 3ivx splitter during normal playback. the only thing i can think of, is that for extremely high bitrate bursts, the cd just doesn't read fast enough.

my only suggestion (for the implementation of the splitter), is that the splitter is programmed to prefetch the data from the cd in a separate thread, in large enough chunks (i'd say few hundreds Kb to few Mb), and always 'stay ahead' enough such that there's no acute need to use the cd for reading very large chunks of data during very short periods of time. but this is only based on my logic, and not on any aquantance with the internal implementation of the splitter.

sorry i can't help better.

[bond]

:(