2006-01-13, 21:09 | Link #221 | |
Panda Herder
Join Date: Dec 2005
Location: A bombed out building in Beruit.
|
Yay the long posts are back. I think Zero1's the only person I've seen duoble post because he exceeded teh charector limit.
Quote:
http://www-user.tu-chemnitz.de/~noe/...omparison.html |
|
2006-01-13, 23:44 | Link #222 |
Aegisub dev
IT Support
Join Date: Dec 2004
Location: Florianópolis, Brazil, Pale Blue Dot
Age: 38
|
I've done a quick test, and remuxed a fansub mp4 into mkv:
[Arienai_-_Conclave]_Ginban_Kaleidoscope_-_07_[H264_-_AAC][4E67292C].mp4 144,508,229 bytes [Arienai_-_Conclave]_Ginban_Kaleidoscope_-_07_[H264_-_AAC][4E67292C].mkv 144,472,592 bytes Matroska is smaller in this case, but only 35 kB so... which is pretty irrelevant, if you ask me. I'd use those 35 kB with chapter information, though (even though I don't think it needs that much). |
2006-01-13, 23:58 | Link #223 |
Panda Herder
Join Date: Dec 2005
Location: A bombed out building in Beruit.
|
Personally I find mkv easier to use, and seeing as I can currently use more features with mkv then mp4, I see no reason to use mp4 atm.
Also has anyone used the new noise reduction filter in x264? |
2006-01-14, 00:10 | Link #224 |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Just to keep this thread "on the cutting edge", on the latest release of x264, they've added a built in noise reduction algorithm:
http://forum.doom9.org/showthread.php?t=105433 The specific algorithm is described in: Transform-Domain Wiener Filtering for H. 264/AVC Video Encoding and its Implementation http://ieeexplore.ieee.org/search/wr...number=1530445 which I haven't actually read yet (I'll see if I can download it from my campus computer)... but from the title we can assume it's some wavelet based dct filtering. To use it, add the --nr xxx parameter with xxx some integer which is the "baseline noise rate". I'm guessing that the higher the xxx, the noisier the source is assumed to be, therefore the stronger the filtering. I haven't experimented with this at all, so I have no idea if it works better than standard avisynth filters, although I'm pretty sure it'll be a lot FASTER than them (since the encoder has motion estimation vectors calculated already etc...) Edit: DryFire beat me to it! Although his post was highly uninformative
__________________
|
2006-01-14, 01:32 | Link #225 |
Member
Join Date: Feb 2004
|
MP4 supports chapters just fine; that's not an advantage of mkv afaik. MKV is of course nice and supports more stuff, but mp4 has a greater chance of 'out of the box' support in the future, so I prefer it since TV cap fansubs just don't need the extras of mkv.
|
2006-01-14, 03:07 | Link #226 | |||
Suki Suki Sia-chan ^Q^
Join Date: Dec 2005
|
Quote:
Quote:
Actually i didnt do much expreriment with chroma qp offset options, but according to my test, chroma qp off set increase global psnr alot from -12 to 12, but i havent compare them visually here is the quick test result and the option i used: start /belownormal /b /w x264 -b 3 -B 600 -o "%userprofile%\desktop\%~n1.264" %1 --progress --cqm jvt -8 -f -6:-6 -mixed-refs --bime --b-pyramid -w --frames 500 Chroma QP offset = -12 x264 [info]: PSNR Mean Y:38.048 U:46.866 V:47.540 Avg:39.475 Global:34.035 kb/s: 554.86 Chroma QP offset = -10 x264 [info]: PSNR Mean Y:38.370 U:46.627 V:47.319 Avg:39.766 Global:34.337 kb/s: 557.69 Chroma QP offset = -8 x264 [info]: PSNR Mean Y:38.716 U:46.328 V:47.072 Avg:40.070 Global:34.656 kb/s: 558.95 Chroma QP offset = -6 x264 [info]: PSNR Mean Y:39.023 U:46.082 V:46.861 Avg:40.337 Global:34.934 kb/s: 564.06 Chroma QP offset = -4 x264 [info]: PSNR Mean Y:39.309 U:45.809 V:46.594 Avg:40.576 Global:35.216 kb/s: 569.39 Chroma QP offset = -2 x264 [info]: PSNR Mean Y:39.470 U:45.386 V:46.239 Avg:40.681 Global:35.293 kb/s: 570.29 Chroma QP offset = 0 x264 [info]: PSNR Mean Y:39.612 U:44.994 V:45.917 Avg:40.767 Global:35.426 kb/s: 573.21 Chroma QP offset = 2 x264 [info]: PSNR Mean Y:39.847 U:44.728 V:45.614 Avg:40.937 Global:35.628 kb/s: 577.87 Chroma QP offset = 4 x264 [info]: PSNR Mean Y:39.949 U:44.455 V:45.311 Avg:40.982 Global:35.690 kb/s: 582.99 Chroma QP offset = 6 x264 [info]: PSNR Mean Y:40.106 U:44.238 V:45.167 Avg:41.085 Global:35.778 kb/s: 580.97 Chroma QP offset = 8 x264 [info]: PSNR Mean Y:40.109 U:44.010 V:44.809 Avg:41.034 Global:35.760 kb/s: 578.34 Chroma QP offset = 10 x264 [info]: PSNR Mean Y:40.173 U:43.782 V:44.635 Avg:41.048 Global:35.806 kb/s: 582.82 Chroma QP offset = 12 x264 [info]: PSNR Mean Y:40.226 U:43.643 V:44.540 Avg:41.063 Global:35.840 kb/s: 583.71 Quote:
IIRC(again...) x264 encoder appear to have this function after November 2005. And actually the x264 options is place inside the bitstream, not the container, my mistake |
|||
2006-01-14, 03:22 | Link #227 | |
Panda Herder
Join Date: Dec 2005
Location: A bombed out building in Beruit.
|
Quote:
What interests me more are built in filters that take advantage of calculations that were to be done anyway (maybe the inclusion of filter patches or some type of plugin system). I'll definately play around with it when I have the chance. Also a link to the doom9 thread: http://forum.doom9.org/showthread.php?t=105433 (I kinda assumed anyone who reads this read reads doom9) |
|
2006-01-14, 04:54 | Link #228 | |||||||||
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
Quote:
Quote:
Quote:
Yes, MKV v2 does have a lower overhead, I saw that test a while a ago and was impressed. Quote:
The so called MP4 of dewm was larger when muxed to MKV than MP4 also. Not that I'm splitting hairs, I quite agree that 35KB is negligable here Afterthought: I wonder if Arienai muxed multiple streams to get VFR. MKVmerge would probably see this as a single MP4 file and treat it that way. I guess if this was the case it would get out of sync if you watched it, what with it having no timecodes file. That might explain the filesize difference, but it's just a shot in the dark. Edit: Hmm, interesting. I just muxed my H.264 + AAC test to MP4 and MKV. MKV = 26.2 MB (27,501,181 bytes) MP4 = 26.2 MB (27,504,638 bytes) I can't explain it Quote:
As for the NR reduction filter, sounds like it will do a similar job to FFT3Dfilter? I don't know much about noise reduction algos though Also, good post Quarkboy Quote:
MKV was added in time, and since I had become used to using H.264 + AAC with MP4box, I wasn't inclined to change. Aside from not wanting to change out of lazyness, as you say although MKV has great features, my usage would only use the basic ones like H.264, AAC or Vorbis and chapters support, all of which MP4 already offer, bar true Vorbis support. You are supposed to be able to mux Vorbis (via private stream?) but that would create a non spec compliant file, and if you are going to do that anyway, you might as well use MKV because at least it will be supported in some way. There is also a slight hope of "out of the box playback" you mentioned too. Quote:
CBR is next to useless in my opinion other than web streaming, or situations where it is impossible to use 2 pass encoding. Quote:
Now this is funny. As you might have gathered I've been offline for about a month, so I've been trying stuff whilst offline. First it appears we found out about x264 storing settings in the bitstream by viewing with a hex editor at the same time, and now the chroma offset tests. Well a while back I did some tests, not as large a range as yours but I'll post the results. Code:
-------------------- Chroma QP offset = 0 -------------------- avis [info]: 704x480 @ 23.98 fps (1431 frames) x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow! x264 [info]: slice I:49 Avg QP:22.39 size: 17071 PSNR Mean Y:44.42 U:48.55 V:48.77 Avg:45.34 Global:44.72 x264 [info]: slice P:995 Avg QP:23.38 size: 9498 PSNR Mean Y:43.27 U:46.85 V:46.69 Avg:44.08 Global:43.52 x264 [info]: slice B:387 Avg QP:24.87 size: 3367 PSNR Mean Y:43.07 U:46.15 V:46.49 Avg:43.85 Global:43.40 x264 [info]: mb I I16..4: 28.5% 49.1% 22.3% x264 [info]: mb P I16..4: 8.1% 14.3% 6.1% P16..4: 33.6% 8.2% 3.9% 0.3% 0 .2% skip:25.3% x264 [info]: mb B I16..4: 2.4% 3.6% 1.0% B16..8: 35.6% 1.7% 2.1% direct: 2.8% skip:50.7% x264 [info]: final ratefactor: 20.89 x264 [info]: 8x8 transform intra:50.1% inter:46.0% x264 [info]: ref P 77.7% 12.4% 5.0% 2.1% 1.5% 1.4% x264 [info]: ref B 76.8% 12.5% 4.8% 2.3% 1.8% 1.7% x264 [info]: PSNR Mean Y:43.256 U:46.718 V:46.710 Avg:44.060 Global:43.523 kb/s: 1553.48 encoded 1431 frames, 3.22 fps, 1554.17 kb/s -------------------- Chroma QP offset = 2 -------------------- avis [info]: 704x480 @ 23.98 fps (1431 frames) x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow! x264 [info]: slice I:48 Avg QP:22.40 size: 16380 PSNR Mean Y:44.48 U:47.76 V:47.90 Avg:45.23 Global:44.60 x264 [info]: slice P:996 Avg QP:23.20 size: 9518 PSNR Mean Y:43.36 U:46.15 V:45.93 Avg:43.99 Global:43.47 x264 [info]: slice B:387 Avg QP:24.69 size: 3377 PSNR Mean Y:43.12 U:45.42 V:45.74 Avg:43.73 Global:43.32 x264 [info]: mb I I16..4: 28.5% 49.3% 22.2% x264 [info]: mb P I16..4: 8.1% 14.7% 6.3% P16..4: 32.4% 8.3% 4.0% 0.3% 0 .2% skip:25.7% x264 [info]: mb B I16..4: 2.3% 3.6% 1.0% B16..8: 35.1% 1.8% 2.2% direct: 2.4% skip:51.5% x264 [info]: final ratefactor: 20.69 x264 [info]: 8x8 transform intra:50.3% inter:46.2% x264 [info]: ref P 77.1% 12.9% 5.1% 2.1% 1.5% 1.4% x264 [info]: ref B 76.9% 12.6% 4.8% 2.2% 1.7% 1.8% x264 [info]: PSNR Mean Y:43.331 U:46.006 V:45.945 Avg:43.964 Global:43.466 kb/s: 1551.25 encoded 1431 frames, 3.25 fps, 1551.97 kb/s -------------------- Chroma QP offset = 4 -------------------- avis [info]: 704x480 @ 23.98 fps (1431 frames) x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow! x264 [info]: slice I:48 Avg QP:22.31 size: 16072 PSNR Mean Y:44.52 U:46.74 V:46.75 Avg:45.03 Global:44.45 x264 [info]: slice P:996 Avg QP:23.06 size: 9526 PSNR Mean Y:43.42 U:45.39 V:45.09 Avg:43.85 Global:43.38 x264 [info]: slice B:387 Avg QP:24.61 size: 3366 PSNR Mean Y:43.15 U:44.64 V:44.88 Avg:43.55 Global:43.18 x264 [info]: mb I I16..4: 28.8% 49.0% 22.3% x264 [info]: mb P I16..4: 8.0% 14.9% 6.4% P16..4: 31.7% 8.4% 4.1% 0.3% 0 .2% skip:26.1% x264 [info]: mb B I16..4: 2.3% 3.7% 1.0% B16..8: 35.0% 1.8% 2.2% direct: 2.1% skip:52.0% x264 [info]: final ratefactor: 20.53 x264 [info]: 8x8 transform intra:50.5% inter:46.4% x264 [info]: ref P 76.8% 13.0% 5.1% 2.2% 1.5% 1.4% x264 [info]: ref B 77.1% 12.2% 4.9% 2.3% 1.9% 1.8% x264 [info]: PSNR Mean Y:43.385 U:45.231 V:45.087 Avg:43.805 Global:43.359 kb/s: 1549.80 encoded 1431 frames, 3.59 fps, 1550.51 kb/s -------------------- Chroma QP offset = 6 -------------------- avis [info]: 704x480 @ 23.98 fps (1431 frames) x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow! x264 [info]: slice I:48 Avg QP:22.27 size: 15952 PSNR Mean Y:44.49 U:45.84 V:46.01 Avg:44.81 Global:44.23 x264 [info]: slice P:996 Avg QP:22.99 size: 9517 PSNR Mean Y:43.46 U:44.73 V:44.46 Avg:43.70 Global:43.26 x264 [info]: slice B:387 Avg QP:24.55 size: 3376 PSNR Mean Y:43.18 U:44.01 V:44.26 Avg:43.39 Global:43.05 x264 [info]: mb I I16..4: 28.4% 48.9% 22.6% x264 [info]: mb P I16..4: 8.1% 15.1% 6.5% P16..4: 31.1% 8.4% 4.2% 0.3% 0 .2% skip:26.1% x264 [info]: mb B I16..4: 2.2% 3.7% 1.1% B16..8: 34.9% 1.8% 2.3% direct: 2.0% skip:52.0% x264 [info]: final ratefactor: 20.44 x264 [info]: 8x8 transform intra:50.8% inter:46.3% x264 [info]: ref P 76.4% 13.3% 5.2% 2.2% 1.5% 1.4% x264 [info]: ref B 76.8% 12.5% 4.8% 2.2% 1.9% 1.7% x264 [info]: PSNR Mean Y:43.420 U:44.569 V:44.459 Avg:43.653 Global:43.233 kb/s: 1548.27 encoded 1431 frames, 3.33 fps, 1548.96 kb/s -------------------- Chroma QP offset = 8 -------------------- avis [info]: 704x480 @ 23.98 fps (1431 frames) x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow! x264 [info]: slice I:47 Avg QP:22.26 size: 15989 PSNR Mean Y:44.26 U:45.29 V:45.32 Avg:44.51 Global:44.04 x264 [info]: slice P:997 Avg QP:22.92 size: 9521 PSNR Mean Y:43.50 U:44.20 V:43.97 Avg:43.57 Global:43.15 x264 [info]: slice B:387 Avg QP:24.51 size: 3353 PSNR Mean Y:43.19 U:43.49 V:43.75 Avg:43.24 Global:42.92 x264 [info]: mb I I16..4: 28.3% 48.9% 22.9% x264 [info]: mb P I16..4: 8.0% 15.3% 6.5% P16..4: 30.8% 8.5% 4.3% 0.3% 0 .2% skip:26.2% x264 [info]: mb B I16..4: 2.2% 3.6% 1.0% B16..8: 34.8% 1.8% 2.3% direct: 1.9% skip:52.3% x264 [info]: final ratefactor: 20.37 x264 [info]: 8x8 transform intra:51.1% inter:46.4% x264 [info]: ref P 76.4% 13.2% 5.1% 2.2% 1.5% 1.4% x264 [info]: ref B 76.9% 12.5% 4.8% 2.3% 1.9% 1.7% x264 [info]: PSNR Mean Y:43.440 U:44.045 V:43.956 Avg:43.515 Global:43.111 kb/s: 1547.04 encoded 1431 frames, 3.76 fps, 1547.74 kb/s If we take the two extremes of an offset of 0 and 8 and check the results. CQ offset 0 = x264 [info]: PSNR Mean Y:43.256 U:46.718 V:46.710 CQ offset 8 = x264 [info]: PSNR Mean Y:43.440 U:44.045 V:43.956 Here you see that you have lowered the PSNR of the U plane by 2.673db and lowered the V plane by 2.754db, and it has only increased the Y plane by 0.184db In my opinion, that is not a worthwhile sacrifice, no matter how important the Y plane is. The quality of the video in this instance is fair, but it's more a case of pointing out the tradeoff rather than actual quality here. Standard disclaimer: Some people don't like PSNR as a measurement and don't trust it, but it's all I have, so don't complain Quote:
Last edited by Zero1; 2006-01-14 at 05:56. |
|||||||||
2006-01-14, 07:03 | Link #229 | |
*yawn*
Join Date: Jan 2003
Location: The sunny side of the Alps
Age: 41
|
Quote:
__________________
|
|
2006-01-14, 13:48 | Link #230 |
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
Hmm, just installed the CoreAAC filter and wow, I'm more than impressed. A notably lower CPU usage than FFDshow, and so I'm led to believe, Nero too.
Still can't play Nero's Greatest game trailer at full frame though, it's pretty hardcore. Though it's watchable now, it's not dropping frames, it just seems like a lower framerate in general. Did a bit of non scientific testing. This CPU usage includes background tasks so expect a 2% margin of error or there about. Test file was the standard Char's counter attack clip I used in my MP4 and MKV testfiles. H.264 was encoded with x264 CLI, muxed with MP4box. ASP was encoded with XviD 1.2 in Vdubmod with packed bit disabled. Muxed with MP4box. The originating AVI file was kept for the AVI/VfW test, so it's essentially the same encode. Resolution is 704x480 (was considering AR tagging but thought not to) No audio was encoded or muxed. MPC 6.4.8.7 was used with the overlay mode. I was surprised that the XviD VfW decoder used so much CPU, I tested a few times and the results were consistant. Something to note is that I have a Matrox Parhelia graphics card, which might have a bearing in H/W acceleration. If someone with a similar CPU could test but different graphics card and report the results, that would be great. Last edited by Zero1; 2006-01-14 at 14:12. |
2006-01-14, 15:40 | Link #231 |
Aegisub dev
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 39
|
Zero1, like you know, several people in this thread already commented on the Windows NT process accounting (CPU usage measuring etc.) being inaccurate measuring CPU usage, and as such, it being a completely useless statistic about a codec. I managed to reproduce LytHka's unrealistically low CPU usage on VLC a few times, and then I couldn't reproduce it again.
If you want to measure how effecient two codecs are, you need another measure, namely the "how fast can it decode this clip". Haali created this tool for testing DirectShow codecs: http://haali.cs.msu.ru/mkv/timeCodec.exe (TheFulff also linked it earlier.)
__________________
|
2006-01-14, 18:00 | Link #233 | ||
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
Warning: This post may contain traces of bullshit theory(!)
Well, it seems when I come up with something it's usually a bad or not fully thought through idea :/ Quote:
First, some results Code:
H.264 in MP4, decoded by CoreAAC = User: 11s, kernel: 0s, total: 11s, real: 12s, fps: 122.9, dfps: 115.8 User: 11s, kernel: 0s, total: 11s, real: 12s, fps: 121.9, dfps: 115.9 User: 11s, kernel: 0s, total: 11s, real: 12s, fps: 121.9, dfps: 115.8 H.264 in MP4, decoded by FFDShow = User: 16s, kernel: 0s, total: 16s, real: 17s, fps: 85.5, dfps: 80.8 User: 16s, kernel: 0s, total: 16s, real: 17s, fps: 85.9, dfps: 81.7 User: 16s, kernel: 0s, total: 16s, real: 17s, fps: 84.8, dfps: 81.8 ASP in MP4, decoded by FFDShow = User: 6s, kernel: 0s, total: 7s, real: 7s, fps: 199.0, dfps: 186.0 User: 6s, kernel: 0s, total: 7s, real: 7s, fps: 196.4, dfps: 186.4 User: 6s, kernel: 0s, total: 7s, real: 7s, fps: 195.6, dfps: 187.2 ASP in AVI, decoded by FFDShow = User: 6s, kernel: 0s, total: 7s, real: 7s, fps: 198.5, dfps: 187.1 User: 6s, kernel: 0s, total: 7s, real: 7s, fps: 199.0, dfps: 188.7 User: 6s, kernel: 0s, total: 7s, real: 7s, fps: 199.8, dfps: 188.3 ASP in AVI, decoded by XviD VfW = User: 10s, kernel: 1s, total: 11s, real: 12s, fps: 124.9, dfps: 118.4 User: 9s, kernel: 1s, total: 11s, real: 11s, fps: 125.2, dfps: 119.8 User: 10s, kernel: 1s, total: 11s, real: 12s, fps: 123.7, dfps: 116.7 It doesn't represent a realistic playback environment (well it most likely isn't meant to, but anyway). For instance you may have a source that plays back fine on a borderline CPU, but then you hit a really complex section that the CPU won't be able to decode in real time. The program doesn't tell me that or represent it in any way, it just decodes the complex scene (albeit not in real time) and adds it to the "score" of what has already been decoded faster than realtime. The end result may end up telling you the video was decoded in realtime or less as it will average the decoding times of all frames. And here's a real example. I just tested Nero's 1080p Greatest Game trailer. It's 153 seconds long, and according to this, it decoded in 128 seconds, which implies faster than realtime. User: 118s, kernel: 4s, total: 122s, real: 128s, fps: 29.9, dfps: 28.5 I can tell you first hand that this file does not play in realtime using CoreAVC. I get some frames at 90-95% and then others that hit 99/100% and then it lags. It's hard to explain (rather I fail at expressing myself). I'll put it into laymens terms for my own sanity, so don't think I'm being, hmm...fecetious? Lets say you have a video of 3 frames, frames 1 and 2 require 95% CPU power to decode, and frame 3 cannot be decoded in realtime, and requires the equivalent of 110%. This of course makes 300% over 3 frames = 100% per frame. The tool above would tell me that this video decoded in realtime (as with the example) since it forces all frames through at max CPU usage (for arguements sake say 100%, but due to processes etc. it will not be 100%). Basically it decodes all frames as fast as possible, but that doesn't happen in video playback, it decodes them on the fly with whatever amount of CPU power it requires and doesn't take into account that future frames may be too complex to decode (I'm not forgetting about B and reference frames here). If a decoder were to read ahead and decode the frames making full use of the CPU, and store them in a buffer of some sort, I guess that would reduce stuttering. I dunno if that's possible to decode future frames with spare CPU power, but if it was it might be a nice thing for AVC (or maybe an additional option in FFDShow? Heck, it's worth suggesting for nothing I guess), the downside would be max CPU usage for a bit, unless you were able to specify a max CPU %, so for instance if a frame is decoding at 60% CPU, and you set the max to 80%, it would use the other 20% to help decode and store the next frame. This way if the next frame would have required the equivalent of 110%, well 20% is already dealt with so it should theoretically decode without lag now. Also you would need to get it to ignore the limit in situations. Say after the 60% frames you hit a hard section requiring 90% CPU usage, the max CPU % would need to be ignored and told not to decode any future frames, or perhaps in this instance it would be wise to use 100% in case the next frame is even more complex? Who knows, it's just a crazy idea. Ideally I would like something like Haali's tool, but would produce a graph or something like I posted. That way you can see when it peaks, and how much it peaks by. Hmm, come to think of it, I wonder if Vprove had such a feature. The demo was crippled >.< Hmm, I know we say we can't trust WinNT, but when I was checking out that particular program, it seemed like it was telling a bit more of the story then Task Manager was, and seemed to update more often, but when did that ever stop us not trusting MS Hmm, let's pick out ASP in AVI decoded by XviD and H.264 in MP4 decoded by FFDShow. Both have a similar average, but as we see from the graph, and common sense can confirm this, the H.264 decoding peaks a lot higher than ASP. It could be this peak that makes a file unplayable (or simply just stutter and lose sync) for someone if they can play that ASP, but only borderline (say if playing the ASP was near on 90-100% CPU). The averages are similar though. Well I'll leave it at that, I'm having trouble expressing what I mean and now I'm repeating myself. Bah, I guess I'm just whining, running timecodec to get those results was the fastest and most convienient thing in the world, and it at least reflects the average CPU usage Quote:
Version: 0.0.0.2 Alpha (20060104) File name: CoreAVC20060104.zip And how did you come across that feature test? If it was the one from my site then it's quite old. I don't think there is any real TTXT formatting or positioning, and the SAR is wrong. It's 32:27, when it should have been 40:33. These are fixed in a slightly newer beta version, I believe nicholi has a copy, but it wasn't supposed to be used by anyone, he just wanted to test something there and then. I'll be looking more into TTXT formatting, I don't get why MPC displays the subs in a different position to OSMO, or which one is right (I suspect OSMO). Also I need to fix the 5.1 AAC when I get my connection back. Nero's encoder kept changing the samplerate to 22050/44100 no matter what bitrate it was (buggy release I guess). I think I'll do an all you can eat MPEG fest too, see how MP4 suffers with that (track changing is usually fun, especially with MKV hell, god damn, takes forever). |
||
2006-01-14, 18:02 | Link #234 | ||
翻訳家わなびぃ
Fansubber
|
Quote:
Quote:
|
||
2006-01-14, 18:22 | Link #235 |
Banned
Join Date: Jan 2004
|
@Zero1: What are you talking about? This wasn't a rant or anything. The thing I noticed is that if you have the System Default output turned on in MPC the coreAVC doesn't automatically tell the player to use the overlay renderer and just doesn't resize the video, so I wondered it needs an application like ffdshow (where you can use the overlay mixer for the output) to tell the player what renderer to use. So the only way to resize that video right is by using the overlay output option in MPC's settings. It's funny to see Winamp having the overlay output as the default though.
Oh, I'm using ver 0.0.0.3 of coreAVC. It *does* support anamorphic encodes, it just doesn't have an application like ffdshow to go along with it so that it could make it go through the renderer with overlay output selected as a default. Oh, that MP4 of doom might be a bit old, yes. I'm not sure. I got it off one site (it might've been yours). I think one of your encoding comrades linked it to me. |
2006-01-14, 18:30 | Link #236 | |
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
LytHka: There has been a misunderstanding, I didn't interpret it as a rant but what you say is interesting. AR should be stored in the bitstream, so shouldn't it be the splitter that tells a player to resize the image? Hmm. I guess it might come down to graphics cards and drivers too. If I set my MPC to system default, I get 2 video windows! Yay, fun! One is anamorphically resized, one isn't Hmm, I don't know though, that's a little out of my area, I'm an encoder, not a decoder (lol?)
Edit: Hmm, I just grabbed this, maybe it would work for you Version 0.0.0.4 Alpha (20060113) : Support for VSSH FOURCC Support for YUY2 output Force anamorphic flag on renderer Quote:
IIRC Nero stores it's chapters in the user data atom "udta", which is basically for attachments, there may also be some extensions in the actual chapters, I don't know. The standard and supported was is like this: Code:
00:00:00.000 Start of file 00:00:15.000 15 Seconds 00:00:30.000 30 Seconds 00:00:45.000 45 Seconds 00:00:60.000 End of file Last edited by Zero1; 2006-01-14 at 18:53. |
|
2006-01-14, 19:16 | Link #237 | ||||
Rozen Detective
Join Date: Dec 2005
Location: Germany
Age: 40
|
Quote:
Quote:
Quote:
Quote:
Last edited by Jekyll; 2006-01-14 at 22:27. |
||||
2006-01-14, 20:36 | Link #238 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
__________________
|
|
2006-01-14, 21:10 | Link #239 | ||
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
Quote:
Code:
<UserDataBox> <BoxInfo Size="200" Type="udta"/> <UDTARecord Type="chpl"> <ChapterListBox> <BoxInfo Size="172" Type="chpl"/> <FullBoxInfo Version="1" Flags="0"/> <Chapter name="Zero1's MP4 Feature Test" startTime="00:00:00.000" /> <Chapter name="15 Seconds" startTime="00:00:15.000" /> <Chapter name="30 Seconds" startTime="00:00:30.000" /> <Chapter name="45 Seconds" startTime="00:00:45.000" /> <Chapter name="End of file" startTime="00:00:59.685" /> </ChapterListBox> </UDTARecord> <UDTARecord Type="cprt"> <CopyrightBox LanguageCode="jpn" CopyrightNotice="Sunrise"> <BoxInfo Size="20" Type="cprt"/> <FullBoxInfo Version="0" Flags="0"/> </CopyrightBox> </UDTARecord> </UserDataBox> Quote:
I guess it's GPAC's user friendly way of letting people be able to format and manipulate a potential text stream. I suppose within reason they could have even made the TTXT format like SSA, eh? |
||
2006-01-15, 17:42 | Link #240 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
Actually, though, it's probably better for them to use the xml type format, as it's far easier to parse than ssa (which I've been told is notoriously annoying to parse). It'll be easier for people to write software that manipulates it.
__________________
|
|
Thread Tools | |
|
|