Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old Today, 12:06   #16101  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 240
Quote:
Originally Posted by Atak_Snajpera View Post
I think that this time problem might be on your side. Before releasing I've tested new encoding server (1.12.1) on virtual machine (win10) using 16 running server (extreme stress test) many times. I have never experienced this kind of issues. Well to be honest I haven't noticed any problems at all. At this point I can only advise you to check what is happening under the hood. Open Process Hacker and check if ffmpeg.exe or/and x265_x65.exe is still in memory. I suspect that ffmpeg.exe just died and stopped serving frames to an encoder.
They are still in memory. I've had this happen on 3 different machines, of which 2 are Win7 and 1 Win10.
Would it be possible to add in a feature if ffmpeg hasn't responded in say 120s to kill it and restart the server?

Last edited by byteshare; Today at 12:09.
byteshare is offline   Reply With Quote
Old Today, 12:08   #16102  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 240
Quote:
Originally Posted by HehoChef View Post
Hey guys,
I'm new to the party, acquired a capable Drive and am know ripping, remuxing and partially compressing my BluRays and UHD's.

Thanks to RipBot and distributed encoding, x265 is now feasable for normal people as well.
I'm just baffled by the results im getting:

The resulting Bitrate while having an constant CQ vastly differentiates with the preset.

For example, i reencoded the first 20 Minutes of a 4K remux, @ 3840x1608, keeping 10bit and HDR, assuming that this should be x265 strongest disciplin, with the following results:
-cq 17, slower :20,2MBps
-cq 17, default: 14,5MBps
-cq 17 ultrafast: 4,6MBps

Of course they look very different.
I redid the same thing with Handbrake, yielding similar results.


Shouldn't cq encoding always keep the same visual quality, and the slower speeds allow for better compression, meaning that the tendency should be the other way around. At least thats the way it was with x264.

Maybe someone could give me a rundown of what I'm not understanding, or respectively what I'm dowing wrong.

Thanks a lot
The presents don't just affect compression, they also affect quality because they use different settings to either speed up or slow down things to make better predictions.
Very few things with encoding is linear.
byteshare is offline   Reply With Quote
Old Today, 12:08   #16103  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,054
Quote:
Originally Posted by HehoChef View Post
Shouldn't cq encoding always keep the same visual quality
As you found out it doesn't work that way. Simple as that.
sneaker_ger is offline   Reply With Quote
Old Today, 12:58   #16104  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 6,573
Quote:
Originally Posted by byteshare View Post
They are still in memory. I've had this happen on 3 different machines, of which 2 are Win7 and 1 Win10.
Would it be possible to add in a feature if ffmpeg hasn't responded in say 120s to kill it and restart the server?
So like I thought. ffmpeg.exe silently crashed or just stopped serving frames to an encoder. Since ffmpeg.exe is just a messenger I think that something wrong is happening on avisynth level (some filter is behaving badly)
Atak_Snajpera is offline   Reply With Quote
Old Today, 13:02   #16105  |  Link
burt123
Registered User
 
Join Date: Jun 2010
Posts: 326
Quote:
Originally Posted by byteshare View Post
They are still in memory. I've had this happen on 3 different machines, of which 2 are Win7 and 1 Win10.
Would it be possible to add in a feature if ffmpeg hasn't responded in say 120s to kill it and restart the server?
Atak,

I understand that you'd want to test, and test before release, which I commend, but because it can be so random, it could take days of testing to have a stall.

byteshare,

Your suggestion, (if possible), would be excellent, it would look after itself
burt123 is offline   Reply With Quote
Old Today, 13:05   #16106  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 6,573
It would be better if you could find some pattern. Does it happen on specific file source codec (MPEG-2,MPEG-4 ASP,MPEG-4 AVC,HEVC and so on). The same with avisynth filters.
Atak_Snajpera is offline   Reply With Quote
Old Today, 13:10   #16107  |  Link
burt123
Registered User
 
Join Date: Jun 2010
Posts: 326
Quote:
Originally Posted by Atak_Snajpera View Post
It would be better if you could find some pattern. Does it happen on specific file source codec (MPEG-2,MPEG-4 ASP,MPEG-4 AVC,HEVC and so on). The same with avisynth filters.
Atak,

98% of my encodes are x264 mkv's, and I don't use a lot of filters (other than default), occasionally, MDeGrain2, and HQD3D.

But when the stall is a Server, wouldn't that be something a little different (just asking).
burt123 is offline   Reply With Quote
Old Today, 13:58   #16108  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 240
Quote:
Originally Posted by Atak_Snajpera View Post
It would be better if you could find some pattern. Does it happen on specific file source codec (MPEG-2,MPEG-4 ASP,MPEG-4 AVC,HEVC and so on). The same with avisynth filters.
I don't know what the pattern is but I also don't know what was causing FFMPEG to crash before you changed the EncodingServer to restart on a crash.
Every time it crashes, it will work if I try it again, so I don't know how to reproduce the issue.
I haven't tried it, but I'm sure if I tried the same encode that had a crash it wouldn't have the same issue again.
I have been using the same avisynth filters on a lot of encodes recently and it is rare to have a crash/lockup but a pain when I'm not checking my encodes every few hours, since it could happen at any moment or it could also take days to encounter.

Last edited by byteshare; Today at 16:13. Reason: grammer
byteshare is offline   Reply With Quote
Reply

Tags
264, 265, appletv, avchd, bluray, gui, iphone, ipod, ps3, psp, ripbot264, x264 2-pass, x264 gui, x264_64, x265, xbox360

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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 +1. The time now is 17:24.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.