ateme
21st June 2005, 17:15
This sticky contains information gathered from the Bugs & Issues and the Quality threads. It summarizes various bugs and issues encountered by the beta testers, and will inform you of the state of the bugs that were reported to us. It also contains information on the encoder that may be of interest to you.
Ateme's staff will try to keep this sticky as much up to date as possible.
This sticky is only informative and users should continue to post their issues / remarks into the dedicated threads.
Bug list
Interlaced / PAFF - crash
Description : the encoder may crash when paff / interlaced are used alone.
Status : solved in our internal version
Lossless - huge bug
Description : some video encoded in lossless are obviously not lossless
Status : solved in our internal version
Lossless
Description : lossless can be used in two passes, and gives a lower quality than in one
Status : solved in our internal version
Fix : lossless in two passes is useless, since the quantizer is fixed to 0
Rate control with interlacing
Description : the effective bitrate when encoding with -setef interlaced is two third of the requested bitrate. With -setef paff it is five sixth.
Status : solved in our internal version
Temporary fix : use 1.5 times the wanted bitrate if you use -setef interlaced, and 1.2 times the bitrate if you use -setef paff
Psnr computation bug
Description : psnr results reported by encavc aren't accurate in two passes
Status : solved in our internal version
MP4 parser - x264
Description : Unable to playback some files generated by x264.exe
Status : solved in our internal version
MP4 parser - big files
Description : Unable to playback 4GB+ files
Status : solved in our internal version
Multithreaded strange behavior
Description : Some users don't seem to be able to use several threads to encode. It may happen on the second pass only
Status : not yet reproduced on our computers
Adaptive deblocking
Description : adaptive deblocking seems not to have any effects
Status : solved in our internal version
Conflict with Nero
Description : Nero's decoder takes priority over Ateme's.
Status : not yet solved
Long encoding
Description : encoding over 1 day makes the time counter of encavc to loop
Status : solved in our internal version
Opengop
Description : the hidden feature 'opengop' leads sometimes to broken frames on the first gops of the video
Status : solved in our internal version
BSPlayer
Description : the decoder doesn't work with BSplayer
Status : not yet solved
PSNR values aren't displayed when using -denoiser or -fgm
Description : When using -denoiser or -fgm options and -psnr, the PSNR results aren't displayed at the end of the encoding.
Status : This behaviour is normal. When using the denoiser or the film grain modeler, the source is altered before being sent to the encoder. Therefore, measuring the PSNR between the filtered source and the reconstructed frame would not be revelant. That's why the PSNR isn't computed in this case.
MBaff efficiency
Description : MBaff doesn't seem to bring the quality gain expected over Paff or progressive.
Status : solved in our internal version
Custom quantization matrices
Description : Chroma seems to be shifted when using custom matrices.
Status : the issue appears to come from nero decoder since it's ok with JM and ateme decoder.
Various remarks
Interlacing
When playing back interlaced content, the default decoder configuration flags the video as interlaced. If a video renderer which can deinterlace is used, it will automatically deinterlace the result, which might not be wanted. To avoid that behavior, in the decoder configuration, uncheck 'Interlaced content'.
Interlaced content cannot be decoded by FFDShow / FFMpeg, but only by our decoder or nero's
When interlaced content is played back deinterlaced with some jerkyness, it means that the bff / tff is wrongly set ( you didn't specified the correct one when encoding ). You can fix that at decoding time by changing the tff / bff settings.
Interlaced flags are the following : interlaced, paff, mbaff.
Interlaced makes the encoder consider the whole video as interlaced. It will encodes all the frames as two fields. Even on highly interlaced materials, it will give worse results than if it was disabled.
Paff makes the encoder decide for each frame whether to encode it as a frame or as two fields. It is more than often on par with a progressive encoding, but sometimes it gives worse results too.
MBaff makes the encoder decide for each macroblocks whether to encode it progressive or interlaced. It will give better results than paff and interlaced, and also better results than a progressive encoding.
MBaff + Paff theorically, the encoder can decide for each frame whether to encode it as two fields or as a frame, in which case for each macroblock it can choose between fields or progressive. Theorically only, because our encoder doesn't do Paff decision in this case.
References
Using a lot of references in the highest quality level creates huge slow downs, and often leads to a small quality gain, not necessarily worthing the pain.
'ref' defines the max number of references in the L0 list. 'bref' defines the number of references in the L0 list that will be used for bframes ( so the documentation is wrong on that point ). They are separated because reference frames slows the codec down, and are not necessarily as helpful for bframes than for pframes. Our codec only allows for one backward reference.
Decoder
The decoder only outputs in YV12, which causes some trouble with some video cards. We're still wondering whether or not to add YUY2 output to it.
Jerkiness of the encoding process
Sometimes, the encoding process seems to freeze. It is due to the behavior of the cmd.exe 'window'. When you select a text in that window, it'll stop the encoding process. To resume it, right click on the window. A big thanks to sysKin for pointing that out.
Fast first pass
The progression percentage of the first pass on long encoding will seem to jump. It's normal. The very fast first pass is enabled on clips longer than 10000 frames. On shorter clip, the first pass is done at a quality level of min(good, requested level).
Psychovisual
There are 4 psychovisual levels, which are independant from the other settings.
psy 0 -> no psychovisual heuristics
psy 1 -> psychovisual heuristics on a frame level
psy 2 -> psychovisual heuristics on a macroblock level
psy 3 -> enhanced psychovisual heuristics on a macroblock level. Some people prefer it over psy 2, others don't.
CBR
The bitrate in CBR mode isn't fixed for each frame. Instead, it follows the CPB / VBV logic : the encoder has a Coded Picture Buffer which must never be empty nor full during the encoding process. Hence, encoding in CBR, you can remark that the bitrate varies. It is normal, expected and even wanted.
File size accuracy
The effective filesize in CBR mode should be reached, minus the CPB size inaccuracy ( which is by default 224 KB ). The ABR mode was designed for allowing an accuracy beneath 1 MB. The 2pass mode should be really close to the targetted bitrate.
DirectShowSource and mp4
When using DirectShowSource in avisynth, you must not seek into the file, or else you won't be able to insure that the frame you're on is indeed the correct frame. That is not necessarily a bug from our parser / decoder, nor from avisynth, but it's definitely an issue when the two are involved.
However, when doing psnr tests, as soon as you don't trim the DirectShowSourced clip, you shouldn't have any issue.
Meanwhile, we'll try to find if an easy fix can be found.
Ateme's staff will try to keep this sticky as much up to date as possible.
This sticky is only informative and users should continue to post their issues / remarks into the dedicated threads.
Bug list
Interlaced / PAFF - crash
Description : the encoder may crash when paff / interlaced are used alone.
Status : solved in our internal version
Lossless - huge bug
Description : some video encoded in lossless are obviously not lossless
Status : solved in our internal version
Lossless
Description : lossless can be used in two passes, and gives a lower quality than in one
Status : solved in our internal version
Fix : lossless in two passes is useless, since the quantizer is fixed to 0
Rate control with interlacing
Description : the effective bitrate when encoding with -setef interlaced is two third of the requested bitrate. With -setef paff it is five sixth.
Status : solved in our internal version
Temporary fix : use 1.5 times the wanted bitrate if you use -setef interlaced, and 1.2 times the bitrate if you use -setef paff
Psnr computation bug
Description : psnr results reported by encavc aren't accurate in two passes
Status : solved in our internal version
MP4 parser - x264
Description : Unable to playback some files generated by x264.exe
Status : solved in our internal version
MP4 parser - big files
Description : Unable to playback 4GB+ files
Status : solved in our internal version
Multithreaded strange behavior
Description : Some users don't seem to be able to use several threads to encode. It may happen on the second pass only
Status : not yet reproduced on our computers
Adaptive deblocking
Description : adaptive deblocking seems not to have any effects
Status : solved in our internal version
Conflict with Nero
Description : Nero's decoder takes priority over Ateme's.
Status : not yet solved
Long encoding
Description : encoding over 1 day makes the time counter of encavc to loop
Status : solved in our internal version
Opengop
Description : the hidden feature 'opengop' leads sometimes to broken frames on the first gops of the video
Status : solved in our internal version
BSPlayer
Description : the decoder doesn't work with BSplayer
Status : not yet solved
PSNR values aren't displayed when using -denoiser or -fgm
Description : When using -denoiser or -fgm options and -psnr, the PSNR results aren't displayed at the end of the encoding.
Status : This behaviour is normal. When using the denoiser or the film grain modeler, the source is altered before being sent to the encoder. Therefore, measuring the PSNR between the filtered source and the reconstructed frame would not be revelant. That's why the PSNR isn't computed in this case.
MBaff efficiency
Description : MBaff doesn't seem to bring the quality gain expected over Paff or progressive.
Status : solved in our internal version
Custom quantization matrices
Description : Chroma seems to be shifted when using custom matrices.
Status : the issue appears to come from nero decoder since it's ok with JM and ateme decoder.
Various remarks
Interlacing
When playing back interlaced content, the default decoder configuration flags the video as interlaced. If a video renderer which can deinterlace is used, it will automatically deinterlace the result, which might not be wanted. To avoid that behavior, in the decoder configuration, uncheck 'Interlaced content'.
Interlaced content cannot be decoded by FFDShow / FFMpeg, but only by our decoder or nero's
When interlaced content is played back deinterlaced with some jerkyness, it means that the bff / tff is wrongly set ( you didn't specified the correct one when encoding ). You can fix that at decoding time by changing the tff / bff settings.
Interlaced flags are the following : interlaced, paff, mbaff.
Interlaced makes the encoder consider the whole video as interlaced. It will encodes all the frames as two fields. Even on highly interlaced materials, it will give worse results than if it was disabled.
Paff makes the encoder decide for each frame whether to encode it as a frame or as two fields. It is more than often on par with a progressive encoding, but sometimes it gives worse results too.
MBaff makes the encoder decide for each macroblocks whether to encode it progressive or interlaced. It will give better results than paff and interlaced, and also better results than a progressive encoding.
MBaff + Paff theorically, the encoder can decide for each frame whether to encode it as two fields or as a frame, in which case for each macroblock it can choose between fields or progressive. Theorically only, because our encoder doesn't do Paff decision in this case.
References
Using a lot of references in the highest quality level creates huge slow downs, and often leads to a small quality gain, not necessarily worthing the pain.
'ref' defines the max number of references in the L0 list. 'bref' defines the number of references in the L0 list that will be used for bframes ( so the documentation is wrong on that point ). They are separated because reference frames slows the codec down, and are not necessarily as helpful for bframes than for pframes. Our codec only allows for one backward reference.
Decoder
The decoder only outputs in YV12, which causes some trouble with some video cards. We're still wondering whether or not to add YUY2 output to it.
Jerkiness of the encoding process
Sometimes, the encoding process seems to freeze. It is due to the behavior of the cmd.exe 'window'. When you select a text in that window, it'll stop the encoding process. To resume it, right click on the window. A big thanks to sysKin for pointing that out.
Fast first pass
The progression percentage of the first pass on long encoding will seem to jump. It's normal. The very fast first pass is enabled on clips longer than 10000 frames. On shorter clip, the first pass is done at a quality level of min(good, requested level).
Psychovisual
There are 4 psychovisual levels, which are independant from the other settings.
psy 0 -> no psychovisual heuristics
psy 1 -> psychovisual heuristics on a frame level
psy 2 -> psychovisual heuristics on a macroblock level
psy 3 -> enhanced psychovisual heuristics on a macroblock level. Some people prefer it over psy 2, others don't.
CBR
The bitrate in CBR mode isn't fixed for each frame. Instead, it follows the CPB / VBV logic : the encoder has a Coded Picture Buffer which must never be empty nor full during the encoding process. Hence, encoding in CBR, you can remark that the bitrate varies. It is normal, expected and even wanted.
File size accuracy
The effective filesize in CBR mode should be reached, minus the CPB size inaccuracy ( which is by default 224 KB ). The ABR mode was designed for allowing an accuracy beneath 1 MB. The 2pass mode should be really close to the targetted bitrate.
DirectShowSource and mp4
When using DirectShowSource in avisynth, you must not seek into the file, or else you won't be able to insure that the frame you're on is indeed the correct frame. That is not necessarily a bug from our parser / decoder, nor from avisynth, but it's definitely an issue when the two are involved.
However, when doing psnr tests, as soon as you don't trim the DirectShowSourced clip, you shouldn't have any issue.
Meanwhile, we'll try to find if an easy fix can be found.