AnimeSuki Forums

Register Forum Rules FAQ Members List Social Groups Search Today's Posts Mark Forums Read

Go Back   AnimeSuki Forum > Anime Related Topics > Fansub Groups

Notices

Reply
 
Thread Tools
Old 2006-01-13, 21:09   Link #221
DryFire
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:
Originally Posted by Zero1
Well assuming it's hardsubbed and nothing fancy, then it doesn't really matter whether it's MKV or MP4, the only thing is that you are limited to AAC rather than Vorbis, and MP4 has lower overheads. Losing Vorbis would be the clincher for many people though. AAC encoders just aren't good enough yet, better than MP3 yes, but has a long way to go before it's comparable with the mighty AoTuV Vorbis (from a coding point of view, is it even possible without breaking specs?)
I believe mkv v2 has a lower overhead then mp4 and mkv v1. I can't find the thread i was looking for exactly so you'll have to settle for this:

http://www-user.tu-chemnitz.de/~noe/...omparison.html
DryFire is offline   Reply With Quote
Old 2006-01-13, 23:44   Link #222
ArchMageZeratuL
Aegisub dev
*IT Support
 
 
Join Date: Dec 2004
Location: Florianópolis, Brazil, Pale Blue Dot
Age: 29
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).
__________________
Aegisub developer [ Forum | Wiki | Bugtracker | IRC ]
ArchMageZeratuL is offline   Reply With Quote
Old 2006-01-13, 23:58   Link #223
DryFire
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?
DryFire is offline   Reply With Quote
Old 2006-01-14, 00:10   Link #224
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
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
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2006-01-14, 01:32   Link #225
iluid
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.
iluid is offline   Reply With Quote
Old 2006-01-14, 03:07   Link #226
SSS
Suki Suki Sia-chan ^Q^
 
Join Date: Dec 2005
Quote:
Originally Posted by Zero1
I think it was the one pass bitrate mode that used to be CBR by default (multipass was always ABR). If you want one pass CBR now you need to set the VBV maxrate (IIRC).
Hmm, i never use CBR, so i have no experience how to tweak VBV maxrate or other options, and AFAIK CRB only useful when streaming(?).

Quote:
Also I wouldn't set the chroma-qp-offset unless you have to. It's true that the human eye takes less notice of chroma than luma, but remember because chroma is subsampled, you need to sacrifice a lot of quality from the chroma plane to make a noticable improvement to the luma.
You looks pro with video processing area
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:
I noticed this the other day, but I don't recall it being on the change log. Also my old encodes don't appear to have it (unless I just missed it).
x264 dev didnt write it to change log IIRC
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
SSS is offline   Reply With Quote
Old 2006-01-14, 03:22   Link #227
DryFire
Panda Herder
 
Join Date: Dec 2005
Location: A bombed out building in Beruit.
Quote:
Originally Posted by Quarkboy
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
Yes, well.. I can't seem do delete my own threads. To make up for this I'll add that akupenguin (akupenguin = pengvado right?) suggested values from 100 to 1000.

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)
DryFire is offline   Reply With Quote
Old 2006-01-14, 04:54   Link #228
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 30
Quote:
Originally Posted by TheFluff
Indeed... Nice to have you back, Zero1!
Likewise, hope everyone had a good holiday. I know I did, being away from work and having some time to yourself is great, just a shame I was offline, I was planning to get so much work done.


Quote:
Originally Posted by LytHka
In any case, you're a week late for this discussion so I think we should just drop it.
Oh I see, so it's like that is it? I don't care, it's still relevant because it's something that happens all the time, but whatever. No point bitching over the internets.


Quote:
Originally Posted by DryFire
Yay the long posts are back. I think Zero1's the only person I've seen duoble post because he exceeded teh charector limit.



I believe mkv v2 has a lower overhead then mp4 and mkv v1. I can't find the thread i was looking for exactly so you'll have to settle for this:

http://www-user.tu-chemnitz.de/~noe/...omparison.html
Yep, and I was lucky, I think the old limit was 20,000 or 25,000 characters, which would have meant a triple or quad post

Yes, MKV v2 does have a lower overhead, I saw that test a while a ago and was impressed.


Quote:
Originally Posted by ArchMageZeratuL
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).
Hmm, that's odd. I wonder if they muxed it with something other than MP4box (unlikely) or added meta info after. MP4box creates nice optimised files, but sometimes when I have tried to add some meta data like the name of the show or the year it was released the file gets bloated.
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:
Originally Posted by DryFire
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?
Yes, MKVmerge is stupidly easy to use, but I still don't mind mp4box, It's quite easy too.
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:
Originally Posted by iluid
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.
That's fair comment, although at the time I started using x264 (something like rev 200) there wasn't an option for MKV, it was MP4 or AVI, so I chose the lesser of two evils which was MP4 which of course meant I avoided VFW limitations and at the same time all the other associated hacks.
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:
Originally Posted by SSS
Hmm, i never use CBR, so i have no experience how to tweak VBV maxrate or other options, and AFAIK CRB only useful when streaming(?).
Yes, CBR is useless in most situations bar streaming and live capture. Even so for live capture you could just use --crf or --qp I guess and get a more consistant result.
CBR is next to useless in my opinion other than web streaming, or situations where it is impossible to use 2 pass encoding.


Quote:
Originally Posted by SSS
You looks pro with video processing area
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
Lol, thanks for the compliment, but I have to be modest because there are much better encoders than myself out there
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:
Originally Posted by DryFire
Yes, well.. I can't seem do delete my own threads. To make up for this I'll add that akupenguin (akupenguin = pengvado right?) suggested values from 100 to 1000.
Yep, as you guessed, akupenguin is pengvado. And yeah, it's a pretty safe assumption that people here are Doom9 goers, though I should really go there more often.

Last edited by Zero1; 2006-01-14 at 05:56.
Zero1 is offline   Reply With Quote
Old 2006-01-14, 07:03   Link #229
ender
*yawn*
 
 
Join Date: Jan 2003
Location: The sunny side of the Alps
Age: 31
Quote:
Originally Posted by Zero1
I don't know if Blu-ray is backward compatible with CD and DVD, it would be a damn stupid move if it wasn't. Well I'd need to look into that, but something amusing is that Pre-recorded Blu-ray discs are likely to use MPEG-2. Yes you have a larger capacity on the Blu-ray discs, but with the increased effeciency of H.264 it would be very easy to store more H.264 on HD-DVD than MPEG-2 on Blu-ray. Add to that HD-DVDs are cheaper to produce, and you see where this is going.
I've read somewhere that (at least some) Blu-ray players (or was it computer drives, I'm not too sure) will support DVDs, but not CDs...
__________________
Because 10 billion years' time is so fragile, so ephemeral... it arouses such a bittersweet, almost heartbreaking fondness.
ender is offline   Reply With Quote
Old 2006-01-14, 13:48   Link #230
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 30
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.
Zero1 is offline   Reply With Quote
Old 2006-01-14, 15:40   Link #231
jfs
Aegisub dev
 
 
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 30
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.)
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs is offline   Reply With Quote
Old 2006-01-14, 16:42   Link #232
LytHka
Banned
 
Join Date: Jan 2004
Is there any option in coreAVC anywhere to use an overlay renderer? I've tested Zero1's MP4 of Doom with it which is an anamorphic encode so the only way I got it to resize properly was by using MPC's Overlay control. =/
LytHka is offline   Reply With Quote
Old 2006-01-14, 18:00   Link #233
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 30
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:
Originally Posted by jfs
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.)
I hear you on the Task Manager thing, more on that in a bit.

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
With all due respect, this program doesn't tell me what I am wanting to know, but yes, as you implied it does show the raw efficiency if you can call it that. It decodes all frames as fast as possible and then gives a report at the end. I'm not saying Haali's tool has no use, it's probably that I'm using it for the wrong purpose :P. I guess it was made to quickly check the decoding speeds of different FFDShow builds etc, rather than to nosy at what sort of minimal requirements you might be able to speculate, or simply just see how AVC decoding compares to ASP complexity wise.

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:
Originally Posted by LytHka
Is there any option in coreAVC anywhere to use an overlay renderer? I've tested Zero1's MP4 of Doom with it which is an anamorphic encode so the only way I got it to resize properly was by using MPC's Overlay control. =/
Bizzare? I don't seem to have any problems with anamorphic or CQM.

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).
Zero1 is offline   Reply With Quote
Old 2006-01-14, 18:02   Link #234
Sylf
翻訳家わなびぃ
*Fansubber
 
 
Join Date: Nov 2003
Age: 40
Send a message via MSN to Sylf Send a message via Yahoo to Sylf
Quote:
Originally Posted by iluid
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.
Quote:
Originally Posted by http://gpac.sourceforge.net/auth_mp4box.php
Chapter extensions have been introduced by Nero and are NOT standard extensions of IsoMedia file format, don't be surprised if some players don't understand them.
I wish I could say something more nice about mp4 chapter support, but nope. This is the hard cold truth
Sylf is offline   Reply With Quote
Old 2006-01-14, 18:22   Link #235
LytHka
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.
LytHka is offline   Reply With Quote
Old 2006-01-14, 18:30   Link #236
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 30
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:
Originally Posted by Sylf
I wish I could say something more nice about mp4 chapter support, but nope. This is the hard cold truth
Don't worry about it, that particular statement is referring to Nero's chapters. Like their subtitles, Nero do it in what one might describe as a "not strictly supported" way. In other word a hack, like with Nero storing DVD subpictures in MP4, I believe this to be unsupported and the official subtitle format should be 3GPP timed text (aka TTXT).

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
and use -chap chapterfile.chp when muxing with MP4box. This is fully spec compliant, unlike using Nero's software that stores the chapters in somewhere other than they should be.

Last edited by Zero1; 2006-01-14 at 18:53.
Zero1 is offline   Reply With Quote
Old 2006-01-14, 19:16   Link #237
Jekyll
Rozen Detective
 
 
Join Date: Dec 2005
Location: Germany
Age: 30
Quote:
Originally Posted by Zero1
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.
That sounds like a pretty good idea, to me. It might be easier to implement a maximum predecoded-frame-buffer-limit than a maximum-CPU-usage-limit, though.

Quote:
Originally Posted by Zero1
This is fully spec compliant, unlike using Nero's software that stores the chapters in somewhere other than they should be.
It's not, as far as is see. :/

Quote:
Originally Posted by MP4Box manual
-chap chap_file
adds chapter information contained in chap_file to movie. For more details on chapter file syntax, cf http://gpac.sourceforge.net/auth_mp4box.php.
Whereas the the URL contains the following (Sylf quoted it before):
Quote:
Originally Posted by auth_mp4box.php
-chap chap_file : adds chapter information located in chap_file to the destination file. Chapter extensions have been introduced by Nero and are NOT standard extensions of IsoMedia file format, don't be surprised if some players don't understand them.
Alas, it seems like there is no standardised chapter support in MP4, as I did not find anything about "extensions" that Nero might have made to MP4 chapters, thus one has to assume that the mere existence of chapters is the "extension".
__________________

Last edited by Jekyll; 2006-01-14 at 22:27.
Jekyll is offline   Reply With Quote
Old 2006-01-14, 20:36   Link #238
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Quote:
Originally Posted by Zero1
Don't worry about it, that particular statement is referring to Nero's chapters. Like their subtitles, Nero do it in what one might describe as a "not strictly supported" way. In other word a hack, like with Nero storing DVD subpictures in MP4, I believe this to be unsupported and the official subtitle format should be 3GPP timed text (aka TTXT).
Oops, don't get careless now. 3gpp and ttxt are NOT the same thing. 3gpp is the standardized format for mp4 text based subtitle streams. ttxt is an xml format which gpac developed to DESCRIBE 3gpp streams. I.e. ttxt is something only mp4box can parse right now.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2006-01-14, 21:10   Link #239
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 30
Quote:
Originally Posted by Jekyll
Alas, it seems like there is no standardised chapter support in MP4, as I did not find anything about "extensions" that Nero might have made to MP4 chapters, thus one has to assume that the mere existence of chapters is the "extension".
Actually I don't think it's looking good now.

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>
This is something I dumped from one of my feature tests, it looks like the chapters are stored in the user data atom. I was convinced it was stored in BIFS and part of MPEG-4 Systems. It seems stupid to think MP4 has menus, 2D + 3D rendering, Flash, and some other funky stuff, yet no official word on chapters. Maybe there's something I've overlooked or misunderstood. Bond might know.


Quote:
Originally Posted by Quarkboy
Oops, don't get careless now. 3gpp and ttxt are NOT the same thing. 3gpp is the standardized format for mp4 text based subtitle streams. ttxt is an xml format which gpac developed to DESCRIBE 3gpp streams. I.e. ttxt is something only mp4box can parse right now.
Well I've shown my ignorance on that one (or my generally sloppy writing ), I haven't really looked into 3GPP subtitles a great deal, I would be more inclined to if Haali's splitter would deal with them properly.

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?
Zero1 is offline   Reply With Quote
Old 2006-01-15, 17:42   Link #240
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Quote:
Originally Posted by Zero1
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?
Yeah, but SSA doesn't have a "BLINK" environment.... Did I mention 3gpp has a "BLINK" environment? HASN'T ANYONE LEARNED ANYTHING?! There's a reason blink was banned from the web... and I can just imaging the abuses for subtitle streams........ the horror!

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.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 05:50.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
We use Silk.