View Full Version : Ateme H.264 Beta - Bug, Issues and Getting Started
Pages :
1
2
3
4
5
6
[
7]
8
9
Soulhunter
7th September 2004, 12:16
Originally posted by bobololo
@SoulHunter: The problem (blocks) you reported at high bitrate should be fixed now, we have found some bugs that only occur at very low Qp (< 12) which should be your case.
Nice, waiting for the new build... :)
Btw, some info about this other "bug" yet ???
Bye
plonk420
7th September 2004, 19:03
Originally posted by bobololo
Here is a little contribution from plonk420 :
http://nero.ateme.com/beta_encodes/cathedral-beta2-400extra-crop-avc.mp4
No you're not dreaming, it's only 400 kb/s :)
there was a bug (prolly the fault of the user :o ) where the incorrect framerate was used... should be 25ish... i'll reencode when the next beta comes out and hopefully we can replace this slightly embarassing file with the fixed one :eek:
CruNcher
7th September 2004, 20:30
@bobololo yes i apologize i was too fast with my asumption i rechecked and indeed it's allready in the source sorry for this :(
bobololo
7th September 2004, 22:07
After a week of intensive testing, we're happy to announce the release of the third beta package which is currently being uploaded to our public server. Testers' should receive the notification mail soon.
The changelog for this new version is the following :
- AviSynth DirectShowSource() issue fixed (adf_dech264.ax)
- Can't save graph in graphedit with source filter issue
fixed (adf_srcmp4.ax)
- Overwrite file issue fixed (mp4muxer.exe)
- New "-priority" option (encavc.exe)
- New "-maxqp" and "-minqp" options (encavc.exe)
- The extraction function could produce invalid mp4
(wrong config), it's fixed (mp4tb.exe)
- xmlparse.dll and xmltok.dll now compiled in release
- Misc bugfixes in the core encoder (encavc.exe)
- Improved bframes support (encavc.exe)
- Add AR support in the decoder filter (adf_dech264.ax)
As you can see, a bunch of bugs were fixed again thanks to your helpful reports and now the encoder is more stable than ever :)
Beside, with more than 300 posts and 12000 views in only 7 days, this feedback thread has completely exploded :) We couldn't imagine how popular this test could be ! In order to avoid your feedback to be completely overflooded, I created a new thread (http://forum.doom9.org/showthread.php?s=&threadid=82036) dedicated to quality feedback only while this one will be dedicated to bug, issues and help for starters. If a moderator is reading this, it would be really appreciated if he could rename this thread into something like "Ateme H.264 Beta - Bug, Issues and Getting Started" :)
This will hopefuly make the progress of this beta test more convenient for all !
Thanks again to all testers, your contribution is greatly welcomed.
-- bobololo.
LostMP4
7th September 2004, 22:49
Can I have details on the -priority option, please?
Which values are available?
bobololo
7th September 2004, 22:57
Originally posted by LostMP4
Can I have details on the -priority option, please?
Which values are available?
*Damned* I missed this option in the doc ...
-priority <below|above|high|idle|realtime|normal>
LostMP4
7th September 2004, 23:10
Originally posted by bobololo
*Damned* I missed this option in the doc ...
-priority <below|above|high|idle|realtime|normal>
You must be bugged ;)
Ok, for beta-3 this useful option is available, too:
-priority <idle|below|normal|above|high|realtime>
virus
8th September 2004, 00:33
ok, I've given the devs one more chance installing and testing the beta-3 filters, which don't work as always.
Now, I just want to let you know that I'm quitting the test.
I'm tired of asking (and offering help to fix the bugs) and be ignored, tired of fighting against the windmills alone, and I sincerely regret all the time I've wasted overnight to prepare some material, take PSNR figures, and so on even if I'm in a very busy period. My spare time, used for free, think about it dear Ateme devs, when you'll receive your salary at the end of the month...
I think I deserved something a bit different for my efforts, but hey, when it comes down to business you know how it's going to be... well, not a problem, 29 or 30 testers doesn't make any difference. I will continue read on your feedback guys, so please continue outputting numbers and opinions, I'm still interested in them.
have fun :)
virus
bond
8th September 2004, 00:54
Originally posted by bobololo
If a moderator is reading this, it would be really appreciated if he could rename this thread into something like "Ateme H.264 Beta - Bug, Issues and Getting Started"you wish we play, btw you can change the thread title by yourself too if you simply edit the title of your first post in this thread :)
bobololo
8th September 2004, 01:10
Originally posted by virus
ok, I've given the devs one more chance installing and testing the beta-3 filters, which don't work as always.
Now, I just want to let you know that I'm quitting the test.
I'm tired of asking (and offering help to fix the bugs) and be ignored, tired of fighting against the windmills alone, and I sincerely regret all the time I've wasted overnight to prepare some material, take PSNR figures, and so on even if I'm in a very busy period. My spare time, used for free, think about it dear Ateme devs, when you'll receive your salary at the end of the month...
I think I deserved something a bit different for my efforts, but hey, when it comes down to business you know how it's going to be... well, not a problem, 29 or 30 testers doesn't make any difference. I will continue read on your feedback guys, so please continue outputting numbers and opinions, I'm still interested in them.
have fun :)
virus
Well, I understand your disapointment and I'm sorry about it, but also consider what you were asking to us. Win9x support would involve our staff to setup a new PC, install the OS & drivers, all the development environment (just figure out how huge it is ...). And only then start investigating the issue. And all this for only 1 tester. Now imagine each tester has similar request, then I think we'd never be able to get our focus on the main topic of this test and the encoder would never be released ;)
Please keep in mind that we're not Microsoft nor Ahead. We're just compression codecs designers. Our expertise is to squeeze video data as much as possible and even we're learning and trying to do so, it is not to write software that works on every platform/os existing on this world (imagine one moment, that a single tester requests for BeOS support, what should we do then ?) ;)
BTW what's wrong with ShowTime filters ? Couldn't you continue to use them ?
virus
8th September 2004, 01:40
Originally posted by bobololo
BTW what's wrong with ShowTime filters ? Couldn't you continue to use them ? I can't seek nor use AVISynth. Ever tried to do an in-motion clip comparison without seeking capabilities? Or maybe compare two frames from two different encavc encodes side by side? Try without using seeking nor StackVertical() and then you can see.
Anyway, I can understand your point. But I also want to remind you that you never specified "Win2k/XP only" in your call for testers. Nor you said that 2k/XP was required at any point of this thread. Why fool me?
BTW I've already offered (4 days ago) to check the register and all the stuff you need on my own PC. And you didn't ever care to answer, as you do for the other stuff (the issue with the deblocker - thank God Sagittaire posted an answer to that some hours ago)
You know, when someone is unwanted it's better to ignore him. This I find disrespectful. Anyway, I don't care. One less tester, one less bug to resolve. Easy and simple, uh?
(ah, and even the XviD team is made up of "just compression codecs designers" who work on their spare time but their filters work flawlessly here... so I don't think I'm making such a huge request)
virus
JohnV
8th September 2004, 01:59
Originally posted by virus
I can't seek nor use AVISynth. Ever tried to do an in-motion clip comparison without seeking capabilities? Or maybe compare two frames from two different encavc encodes side by side? Try without using seeking nor StackVertical() and then you can see.
Anyway, I can understand your point. But I also want to remind you that you never specified "Win2k/XP only" in your call for testers. Nor you said that 2k/XP was required at any point of this thread. Why fool me?
BTW I've already offered (4 days ago) to check the register and all the stuff you need on my own PC. And you didn't ever care to answer, as you do for the other stuff (the issue with the deblocker - thank God Sagittaire posted an answer to that some hours ago)
You know, when someone is unwanted it's better to ignore him. This I find disrespectful. Anyway, I don't care. One less tester, one less bug to resolve. Easy and simple, uh?
(ah, and even the XviD team is made up of "just compression codecs designers" who work on their spare time but their filters work flawlessly here... so I don't think I'm making such a huge request)
virus For Pete's sake... At this stage it's much more important to optimize the quality than start spending lots of beta tuning time to fix some Win9x compatibility issues which affect 0.00001% of users.
I'm sure Win9X compatibility comes when it's the time, but considering how small minority this user group is, I totally understand that quality issue feedback/tuning gets much higher priority from Ateme at this point of the beta-test.
acidsex
8th September 2004, 02:07
For some odd reason, I never received the Beta-3 email. Dont know if it had to do with the hurricane we went through this past weekend but if bobololo could please send it to me, it would be greatly appreciated.
virus
8th September 2004, 02:16
Originally posted by JohnV
At this stage it's much more important to optimize the quality than start spending lots of beta tuning time to fix some Win9x compatibility issues which affect 0.00001% of users.
It's 10%, not 0.00001% :)
(I gave a link to an article about that in this very thread)
I want to remind you that Ahead (as Micro$oft) still supports Win98, 98SE, ME. And I also want to remind you that without my help, Ateme would have sold to Ahead a codec that wouldn't work at all on half of their supported platforms, since encavc-beta1 was b0rked on Win9x. I think that I deserved a different treatment for doing that... just make things clear, without making me waste time on this stuff, would have been much appreciated ;)
Anyway, it's all the same story. Why support that exotic Linux OS if everyone on Earth uses Windows? Why care about compatibility with Firefox if everyone uses IE? Why support that strange XviD-thingie when everybody in the world is happy with DivX? It's all the same. Business and software diversity are such different concepts... ;)
(and it's easy to make comments like yours when you're on the winning side. much less when you're in the minority)
virus
EDIT:
I'm sure Win9X compatibility comes when it's the time
please read again bobololo's statements... win9x compatibility will never come.
JohnV
8th September 2004, 02:43
Originally posted by virus
EDIT:
please read again bobololo's statements... win9x compatibility will never come. Eh.. Nero Digital uses Ahead's inhouse h.264 decoder anyway, not Ateme's decoder. So maybe complete win9x support won't come for this Ateme beta-test, but ShowTime works with Win9x, doesn't it? Furthermore according to my knowledge at least the h.264 seeking issue should be fixed in the next NVE update package.
virus
8th September 2004, 02:51
Originally posted by JohnV
Furthermore according to my knowledge at least the h.264 seeking issue should be fixed in the next NVE update package.
Good. (not that I need it anymore :D)
Anyway I'm not asking Ateme to support anything. But they should have simply said "dear virus, you cannot partecipate in this test with your OS, sorry, please don't waste time on it". Instead, they choose not to talk and ignore me. Had I not spoken out tonight, no more words would have been spent on the whole issue. That's disrespectful. (and I even offered to debug everything on my machine! :rolleyes: )
Ateme is free to do what they want. I'm just asking for a bit of respect for my (free) efforts ;)
virus
everwicked
8th September 2004, 02:54
Hi,
I don't speak for bobololo, nor I am trying to defend him but I have experienced similar problems since I have started developing for windows so I might be able to explain a few things.
Originally posted by virus
I can't seek nor use AVISynth. Ever tried to do an in-motion clip comparison without seeking capabilities? Or maybe compare two frames from two different encavc encodes side by side? Try without using seeking nor StackVertical() and then you can see.
Quite a few people like StackVertical(). I myself feel that is not used as it should. What i mean is, that you shouldn't be looking for differences, frame by frame. If you let the video play and get a generic impression then go ahead.
There are also two more things you can do:
1) Use VQStudio
2) Use GraphEdit to export the mp4 file to another, lossless or uncompressed AVI. You can then do whatever you need with it, including seeking.
Anyway, I can understand your point. But I also want to remind you that you never specified "Win2k/XP only" in your call for testers. Nor you said that 2k/XP was required at any point of this thread. Why fool me?
I am quite certain they did not know it wouldn't work on win9x. Noone was trying to fool you. That is clear, to me at least. You were just unlucky to find out in practice.
BTW I've already offered (4 days ago) to check the register and all the stuff you need on my own PC. And you didn't ever care to answer, as you do for the other stuff (the issue with the deblocker - thank God Sagittaire posted an answer to that some hours ago)
Unfortunately, it doesn't have to do with your PC at all. The state of your installation is unrelated to these issues which are clearly related to advancements not evident in Win9x. I don't know what it is, but it can be anything, varying from Unicode to threading. If you don't believe me, you can browse through msdn.microsoft.com. Check at the bottom and see that a lot of functions are not supported by Win9x.
(ah, and even the XviD team is made up of "just compression codecs designers" who work on their spare time but their filters work flawlessly here... so I don't think I'm making such a huge request)
The XviD team has quite a few people and it has some basic differences with ateme:
1) they "ship" a complete product
2) because of 1, they also have mechanisms to ensure portability.
Something that noone has pointed out is that Ateme does NOT sell a standalone encoder but rather an encoding library.
I want to remind you that Ahead (as Micro$oft) still supports Win98, 98SE, ME. And I also want to remind you that without my help, Ateme would have sold to Ahead a codec that wouldn't work at all on half of their supported platforms, since encavc-beta1 was b0rked on Win9x. I think that I deserved a different treatment for doing that... just make things clear, without making me waste time on this stuff, would have been much appreciated
As I said above, they only sell the library to ahead, not the interface. And as bobololo himself said, the core is cross-platform.
Anyway, it's all the same story. Why support that exotic Linux OS if everyone on Earth uses Windows? Why care about compatibility with Firefox if everyone uses IE? Why support that strange XviD-thingie when everybody in the world is happy with DivX? It's all the same. Business and software diversity are such different concepts...
Aside from the ateme issue, my personal opinion is that if you want to support multiple platforms then you're limited to Java or .NET if only linux/windows is target. Then you lose speed assuming it's video processing we're talking about. Let alone how many people moan about the required runtime.
If you keep the speed and work with C/C++, then let's face it. Developers will spend more time testing and adding work-arounds for broken stuff in obsolete OS's. Time that they could have used to introduce new features. In that way, the minority is hurting the majority, not themselves.
please read again bobololo's statements... win9x compatibility will never come.
It will come. Just not with Ateme's encoder/filters. Once again, someone from Ateme pointed out that they are used for in-house development. Too bad it didnt work for win9x users for this test. However, when Ahead gets it and the new Nero is out, it will support your beloved OS.
Just my 0.02 €
superdump
8th September 2004, 02:55
virus: The AVC binary doesn't work on your Win9x machine, right? Waaaay back when you first mentioned this bobololo stated that that's an issue with their tools (i.e. encavc) NOT WITH THE CODEC ITSELF. So just sit back and wait until it's released in Nero then try it again. If it's a quick fix they'd have done it already and as you're the only tester complaining about Windows 9x incompatibility I assume everyone else running the test executable is doing fine. As far as I'm concerned that's not bad going at all really. It's not viable to spend a lot of time fixing Win9x compatibility for a couple of week long beta test. Quality development, as stated, is more important as the other 49/50 beta testers are concerned with this, as are the codec developers. Ahead can fix Win9x compatibility as that will be part of their goal, not necessarily Ateme's.
Have a nice day.
virus
8th September 2004, 03:07
Originally posted by superdump
virus: The AVC binary doesn't work on your Win9x machine, right? Waaaay back when you first mentioned this bobololo stated that that's an issue with their tools (i.e. encavc) NOT WITH THE CODEC ITSELF. the codec (encavc.exe, not the filters) was b0rked in beta-1 under Win9x. I resolved the issue with bobololo by email so you probably don't know about it. And again: saying "sorry you cannot test with your OS" at *that* time (and not now) would have been better. The point is that nobody ever cared to say that.
BTW It's also not viable to spend a lot of time to prepare a lot of stuff for a beta-test and not having someone warn you "hey, you're doing useless work, we're not going to support your OS right now". Can you see my point?
plonk420
8th September 2004, 03:12
*groans*
just update your os already, if just for the codec test...! >:| after it's done, go back to your favored 98 or whatever... i upgraded XP (from 2000) just for a LAN party and haven't been (or looked) back since
virus
8th September 2004, 03:48
Originally posted by everwicked
2) Use GraphEdit to export the mp4 file to another, lossless or uncompressed AVI. You can then do whatever you need with it, including seeking.As I already pointed out a couple of times before, GraphEdit won't render the graph, nor let me build it manually... ;)
I am quite certain they did not know it wouldn't work on win9x. Noone was trying to fool you. That is clear, to me at least. I disagree. bobololo stopped talking to me right after he was sure that encavc worked under my OS, because Ateme needed that (encavc is meant to be cross-platform). You can re-read the thread if you want. He answered all the questions except mines, and commented all the results except mines. He didn't ever care to state *clearly* something like "sorry, we're not going to support your OS". That would have been sufficient for me. Instead, he chose to ignore me.
Is this a correct, polite behaviour? Especially considering that I've tried to be helpful?
JohnV
8th September 2004, 05:03
For Pete's sake stop the crying already. :rolleyes:
Lets all praise virus from the behalf of all the two Doom9 members using Win9x and behalf of the other Win9x users out there. It's time for this thread to go back on topic instead of whining about what someone should or shouldn't have said.
Bulletproof
8th September 2004, 05:21
I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:
encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000
It freezes up in WMP.
bobololo
8th September 2004, 09:11
Originally posted by Bulletproof
I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:
encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000
It freezes up in WMP.
Can you upload the file ? Thanks.
edit:
Originally posted by virus
I disagree. bobololo stopped talking to me right after he was sure that encavc worked under my OS, because Ateme needed that (encavc is meant to be cross-platform). You can re-read the thread if you want. He answered all the questions except mines, and commented all the results except mines. He didn't ever care to state *clearly* something like "sorry, we're not going to support your OS". That would have been sufficient for me. Instead, he chose to ignore me.
Is this a correct, polite behaviour? Especially considering that I've tried to be helpful?
Ok this will be my last post here about this subject, if you can't understand my point, it's useless to continue this low discussion.
1. The fix we did with encavc.exe was related to the system call CreateThread() which has a different behaviour between win9x and win2k/xp. This function is use to create the thread that read the input source and has nothing to do with the core encoder. We didn't change even 1 line of code in the core encoder to fix this issue.
2. You reported that changing the deblocking filter settings, there were few changes in your clip. I didn't answer you because if you read all the posts before, it clearly appeared that changing deblocking filters settings does something. Plus you didn't tell which bitrate you were using, it was obvious that if you encoded at high bitrate the deblocking doesn't do anything since there is no blocks !
3. I didn't either reply to some questions posted when I considered my answer wouldn't have much interest.
I now hope you can stand back and see the reality of the facts which is quite different from your whacky interpretation. In no way we tried to exploit you in order to make our codec works with win9x (once again the core encoder is completely OS independant) and ignored you just after. I simply can't believe how you can imagine such things, this is hallucinating !
This discussion is closed for me, I won't reply anymore on this topic.
-- bobololo.
708145
8th September 2004, 09:59
Originally posted by plonk420
*groans*
just update your os already, if just for the codec test...! >:| after it's done, go back to your favored 98 or whatever... i upgraded XP (from 2000) just for a LAN party and haven't been (or looked) back since
XPpro is 180€! I wouldn't do that just for a codec test. Don't know about prices in italy, though.
But now let's stop this allright?
/me on Win2kpro
bis besser,
Tobias
plonk420
8th September 2004, 10:22
now if only i could figure out why my video is dropping frames even tho it looks perfect in Vdub... :(
edit: FINALLY figured out where the problem is..! when i frame by frame my AVISynth script in vdub all is well. however, when VDub saves the AVI (or when EncAVC encodes from the AVS script) something gets skewed and the duplicated frame gets kept and some other frame gets dropped...! :angry: w...t...f...?!?
MPEG2Source("cathedral.d2v").BiCubicResize(640,480).crop(0,64,0,-64).SelectEvery(6,0,1,2,3,4).AssumeFPS(25)
(it makes no difference if the AssumeFPS is there or not)
Manao
8th September 2004, 10:33
What dll are you using for decoding mpeg2 ? MPEG2DEC3 ? dgdecode ?
With DVD2AVi / MPEG2DEC3, there was sometimes some frames missing. With DGdecode ( and DGindex ), you shouldn't have this issue anymore. Perhaps it will solve your problem.
Also, perhaps the frame you need to drop isn't always the 6th of each sycle of 6 frames. You should try decimate ( from the decomb package ), it may solve your issue.
Finally, if nothing works, try to cut a small part of your vob and make it available, some gurus on the avisynth forum will surely find what is wrong with it.
avih
8th September 2004, 10:46
Originally posted by JohnV
For Pete's sake stop the crying already. :rolleyes:
Lets all praise virus from the behalf of all the two Doom9 members using Win9x and behalf of the other Win9x users out there. It's time for this thread to go back on topic instead of whining about what someone should or shouldn't have said.
Take it easy JohnV, and please try to stay polite.
avih.
Sagittaire
8th September 2004, 10:51
I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:
encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000
It freezes up in WMP.
1)For me don't work with WMP10 or QTP but work perfectly with MPC: after test only default renderer works with MPC. WMR7 and WMR9 with windowed or renderless doesn't work ...
2) this avs script works
video=DirectShowSource("G:\H264-500.mp4",fps=25)
video=trim(video,0,35237)
return video
but not this script (VD or VDM bug)
video=DirectShowSource("G:\H264-500.mp4",fps=25)
return video
3) Directshow with H264 consumes RAM enormously. The RAM is not reloaded when I open several avs consecutively: I must open and close VD to avoid depassement of virtual memory.
but it isn't important for me: it's beta test on quality. These problem are decodeur problem exclusively and will be solved later.
virus
8th September 2004, 10:55
Originally posted by bobololo
... and ignored you just after. I simply can't believe how you can imagine such things, this is hallucinating !
Yeah, how can I imagine such things? Well...
Originally posted by bobololo on 4th September 2004 00:17
We're doing our best to try to make them work on your plateform as it was previously done following your report on encavc.
These were the last words you've addressed to me (before I spoke out a few hours ago). You didn't even care to answer "we cannot make it to work, sorry". You didn't even care to say a single word, either accepting or rejecting my offer to debug your filters on my PC.
You can be one of the best coders in the world but still I don't think you have the right to jerk me around.
This is my point. Sorry for any further incomprehension, anyway.
Discussion closed for me, too
cheers :)
virus
avih
8th September 2004, 10:57
Originally posted by virus
.....
Discussion closed for me, too
cheers :)
virus
thank you :)
plonk420
8th September 2004, 11:26
Originally posted by Manao
What dll are you using for decoding mpeg2 ? MPEG2DEC3 ? dgdecode ?
With DVD2AVi / MPEG2DEC3, there was sometimes some frames missing. With DGdecode ( and DGindex ), you shouldn't have this issue anymore. Perhaps it will solve your problem.
Also, perhaps the frame you need to drop isn't always the 6th of each sycle of 6 frames. You should try decimate ( from the decomb package ), it may solve your issue.
yep, using DVD2AVI / MPEG2DEC3; however, it displays 100% correctly when i advance frame-by-frame in VDub. when i Save As AVI or run the AVS file thru the encoder, THAT is when it messes up... :(
LostMP4
8th September 2004, 13:11
H.264 quantizer question..
If I remember correctly, increasing the quantizer by 6 should half the filesize... right :confused:
If that's right increasing the quantizer by 12 should reduce the filesize to a quarter
I made two test vbr encodes, with 21 (min and max) and 33 (min and max) quantizer but the first file it's about 6 times larger than second (1015 MB and 170 MB)
So, something is wrong (my memory, something related to my setting or maybe the codec?)
Core encoder version 1.0.1.19
Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Process Priority : Below
Rate Control : Vbr
Quality : Extra
Init Quantiser : 21 [21 - 21]
Max Consecutive BFrames : 3
Deblocking Strength : 0 (adaptive)
Num Reference : 5
Psychovisual : 2
Cartoon mode : On
Features : ipred ppred bpred cabac deblock hpel qpel part
-- Start processing pass 1 / 1
* 72839: encoding @ 12.20 fps - bitrate 352.48 kb/s - 100.00% completed
* 72840 frames encoded @ 2.66 fps - average bitrate 2919.37 kb/s
Encoding complete
Core encoder version 1.0.1.19
Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Process Priority : Below
Rate Control : Vbr
Quality : Extra
Init Quantiser : 33 [33 - 33]
Max Consecutive BFrames : 3
Deblocking Strength : 0 (adaptive)
Num Reference : 5
Psychovisual : 2
Cartoon mode : On
Features : ipred ppred bpred cabac deblock hpel qpel part
-- Start processing pass 1 / 1
* 72839: encoding @ 11.20 fps - bitrate 29.63 kb/s - 100.00% completed
* 72840 frames encoded @ 4.48 fps - average bitrate 488.87 kb/s
Encoding complete
superdump
8th September 2004, 13:17
Originally posted by LostMP4
H.264 quantizer question..
If I remember correctly, increasing the quantizer by 6 should half the filesize... right :confused:
If that's right increasing the quantizer by 12 should reduce the filesize to a quarter
I made two test vbr encodes, with 21 (min and max) and 33 (min and max) quantizer but the first file it's about 6 times larger than second (1015 MB and 170 MB)
So, something is wrong (my memory, something related to my setting or maybe the codec?)I think bobololo said that the filesize is 'nervous' using constant quantiser mode. I don't know if increasing qp by 6 is intended to halve the filesize but even if it is it won't do that in every case, depends on the source.
bobololo
8th September 2004, 13:32
Originally posted by LostMP4
H.264 quantizer question..
If I remember correctly, increasing the quantizer by 6 should half the filesize... right :confused:
If that's right increasing the quantizer by 12 should reduce the filesize to a quarter
I made two test vbr encodes, with 21 (min and max) and 33 (min and max) quantizer but the first file it's about 6 times larger than second (1015 MB and 170 MB)
So, something is wrong (my memory, something related to my setting or maybe the codec?)
The bitrate variation versus quantizer is absolutely not linear. If it was the case, the RC would be quite easier ;)
LigH
8th September 2004, 16:03
You might be interested in calculating the "bits per pixel and frame" value, as GordianKnot is calculating, for example. For DivX 5 or XviD-H.263, we usually recommend 0.25-0.30 bppf; for XviD-MPEG, we recommend 0.30-0.35 bppf. I wonder which minimum you would recommend for Ateme H.264?!
At first I'll try to upload a zipped Excel sheet here (I wonder if I'm allowed to upload - if so, it may appear soon here). Also I made a Windows EXE, but it is a but huge (due to using Delphi): ~185 KB.
Soulhunter
8th September 2004, 17:10
Nice, all problems with the T3 trailer are gone with the new beta... :)
Bye
ac-chan123
8th September 2004, 18:18
I have testet the mp4 files from this treat with the new IIS Frauenhofer mp4 Player (http://www.iis.fraunhofer.de/pub_rel/presse/2004/mpeg4/index.html). None of them are played. The Player says profile unkow.
SeeMoreDigital
8th September 2004, 18:33
Originally posted by ac-chan123
I have testet the mp4 files from this treat with the new IIS Frauenhofer mp4 Player (http://www.iis.fraunhofer.de/pub_rel/presse/2004/mpeg4/index.html). None of them are played. The Player says profile unkow. Can you upload a short sample?
Cheers
LostMP4
8th September 2004, 18:42
Originally posted by ac-chan123
I have testet the mp4 files from this treat with the new IIS Frauenhofer mp4 Player (http://www.iis.fraunhofer.de/pub_rel/presse/2004/mpeg4/index.html). None of them are played. The Player says profile unkow.
Tested my encodes, same error (AVC profile unknow)
maybe profiles aren't implemented yet...
Bulletproof
8th September 2004, 18:52
Originally posted by bobololo
Can you upload the file ? Thanks.
I have uploaded the file on the ftp in the incoming dir.
bond
8th September 2004, 20:30
Originally posted by LostMP4
maybe profiles aren't implemented yet...hm maybe the ateme encoder doesnt indicate the used profile in the .mp4 file, but the frauenhofer player needs it (might only play baseline profile streams and not main profile ones), but thats only speculation
bobololo
8th September 2004, 20:49
Originally posted by bond
hm maybe the ateme encoder doesnt indicate the used profile in the .mp4 file, but the frauenhofer player needs it (might only play baseline profile streams and not main profile ones), but thats only speculation
It seems that fraunhofer doesn't support main profile...
edit: FYI, streams encoded with our beta use main profile (77) and level 4.0 (40).
bobololo
9th September 2004, 01:45
Originally posted by Bulletproof
I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:
encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000
It freezes up in WMP.
Ok I got your file and tried to play it with mpc and wmp9 and both worked fine. Only I couldn't seek in wmp9. Which version of wmp do you use ? Does is work with other player ? Have you updated your filters with those provided in beta 3 ?
I'll try tomorrow on other PCs with different version of wmp if possible.
Bulletproof
9th September 2004, 02:10
I think my decoding filters were screwed up, I used unreg and reg again and it's playing fine now in WMP 6.4, thanks.
LostMP4
9th September 2004, 09:06
Originally posted by bobololo
streams encoded with our beta use main profile (77) and level 4.0 (40).
Will you support extended profile?
bobololo
9th September 2004, 13:09
Originally posted by LostMP4
Will you support extended profile?
Hum I don't think so, however FRExt tools are much more interesting :)
Tommy Carrot
9th September 2004, 14:18
Originally posted by bobololo
Hum I don't think so, however FRExt tools are much more interesting :)
Could anyone tell me what tools does FRExt/high profile have other than the additional colorspaces? I did a search, but everything i could find was a bunch of japanese pages, and press releases.
bobololo
9th September 2004, 14:35
Originally posted by Tommy Carrot
Could anyone tell me what tools does FRExt/high profile have other than the additional colorspaces? I did a search, but everything i could find was a bunch of japanese pages, and press releases.
The draft amendement is available on the jvt public ftp directory (ftp.imtc-files.org/jvt-experts). Check in the 2004/07 event at Redmond. If i remember correct, the draft is JVT-L049.doc. I'd like to check but it seems their ftp server is down now.
Tommy Carrot
9th September 2004, 14:42
Thx, i'll check later when the ftp is back. :)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.