News:

--

Main Menu

libx264 GIT builds

Started by LoRd_MuldeR, January 30, 2009, 12:39:23 AM

Previous topic - Next topic
Print
Go Down Pages 1 ... 8 9 10 11 12 ... 16
User actions

LoRd_MuldeR

#135
January 31, 2010, 05:49:51 PM
Quote from: FaiakesSomething is wrong with the 1414 mediafire links.

What is \"wrong\" with those links? Download seems to work for me...
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

Faiakes

#136
January 31, 2010, 05:58:47 PM
It takes forever to load and in the end it the download doesn\'t actually start.

Is this only happening to me?

LoRd_MuldeR

#137
January 31, 2010, 06:00:39 PM
Quote from: FaiakesIt takes forever to load and in the end it the download doesn\'t actually start.

Is this only happening to me?

Maybe the MediaFire sever is under heavy load at the moment.

However I successfully downloaded the file from MediaFire only 3 minutes ago. Please try again...
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

popper

#138
January 31, 2010, 08:09:48 PM
Quote from: LoRd_MuldeR
Quote from: FaiakesWhat\'s the difference?

The difference, as the name implies, is Periodic Intra Refresh ;)

Quote from: FaiakesWhy not only provide the libx264 SVN-r1414 with Periodic Intra Refresh?

Because not everybody wants to use Periodic Intra Refresh ???

Of course it would be desirable to have PIR as a runtime option, but currently Avidemux doesn\'t expose that option...

\"Because not everybody wants to use Periodic Intra Refresh ???\"
ohh but who couldnt WANT PIR its so sweet and even the 360 likes to play it.... :)

â€"intra-refresh â€"fps 25 â€"vbv-maxrate 5000 â€"vbv-bufsize 200 â€"slice-max-size 1500 -o whatever.mp4

now the only question is how to get a good default setting included inside avidemux for processing and producing generic 720P at 512kbit/s suitable for the average users upload ISP rate using the above options.

 and also how can avidemux take advantage of interactive x264 videos/720p50_mobcal_ter.y4m â€"preset veryfast â€"tune zerolatency realtime feedback for on the fly variable output in the future?

to make avidemux take 2 OR More input AVC files as future round robin interleaved input switching perhaps ?, then processed, and stuffed inside a Transport stream output, or whatever other things you might like to add later! for example, easy and simple scaled PIP (Picture In Picture) production TS perhaps.!

Faiakes

#139
January 31, 2010, 08:13:26 PM
Mediafire links working now.

LoRd_MuldeR

#140
January 31, 2010, 08:33:57 PM
Quote from: popper
Quote from: LoRd_MuldeR
Quote from: FaiakesWhat\'s the difference?

The difference, as the name implies, is Periodic Intra Refresh ;)

Quote from: FaiakesWhy not only provide the libx264 SVN-r1414 with Periodic Intra Refresh?

Because not everybody wants to use Periodic Intra Refresh ???

Of course it would be desirable to have PIR as a runtime option, but currently Avidemux doesn\'t expose that option...

\"Because not everybody wants to use Periodic Intra Refresh ???\"
ohh but who couldnt WANT PIR its so sweet and even the 360 likes to play it.... :)

I usually don\'t want PIR, because compression is LESS efficient with PIR enabled :o

The loss in efficiency that PIR causes isn\'t that large, when compared to a \"short\" I-Frame interval (like 35). But compared to a \"normal\" I-Frame interval (like 250+) there certainly is a much bigger loss in efficiency!

Furthermore not every player seeks properly in a stream that doesn\'t contain any I-Frames ;)
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

Faiakes

#141
January 31, 2010, 08:41:07 PM
Quote from: LoRd_MuldeRFurthermore not every player seeks properly in a stream that doesn\'t contain any I-Frames ;)
Would the latest MPC-HC be able to seek properly such files?

LoRd_MuldeR

#142
January 31, 2010, 09:03:29 PM
Quote from: Faiakes
Quote from: LoRd_MuldeRFurthermore not every player seeks properly in a stream that doesn\'t contain any I-Frames ;)
Would the latest MPC-HC be able to seek properly such files?

As MPC-HC is a DirectShow-based player, it totally depends on the DirectShow filters (splitter & decoder) that you use ;)
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

popper

#143
January 31, 2010, 09:08:52 PM
yeah. MPC-HC ,VLC,internal xbox360,PS3 and many others work fine with it, you can offset any compression being LESS efficient for a given content OC by upping your CRF to the next higher digit OC if compression filesize is more important than the quality of the final output to you and your viewers OC, but thats not really a concern for generic streaming of your content on things like http://www.veetle.com/frameworked/index.php/listing/index/10/popular/grid/0 or your LAN for instance...

and OC everyone knows the \"not every player\" is sh$t :) and you should be using a better one.

what, you dont use veetle etc to run your â€"intra-refresh â€"fps 25 â€"vbv-maxrate 1000 â€"vbv-bufsize 200 â€"slice-max-size 1500 -o whatever.mp4 encoding tests samples for others to link to on the fly, thats crazy ;)

LoRd_MuldeR

#144
January 31, 2010, 09:32:47 PM
Sure, we can compensate for less efficient compression by using a higher bitrate. But that\'s not the Point. The point is: Why should I spend a higher bitrate for PIR? The only benefits that PIR delivers are: You can start decoding at any random position, the stream is more robust against packet loss (up to 25% loss) and all frames have roughly the same size (as there are no \"big\" I-Frames\" anymore). That is great for low-latency streaming, such as VoIP applications -- the kind of applications PIR was developed for. But it\'s pretty much useless for encoding content for local playback! So again: If PIR has zero benefit for local playback but requires a higher bitrate for the same quality, why should I use it ???

Yes, there is no reason to use PIR for encoding content that is intended for local playback. Except for testing ;)
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

popper

#145
January 31, 2010, 10:04:51 PM
why use PIR, you said it yourself \"benefits that PIR delivers are: You can seek to any random position, the stream is more robust against packet loss (up to 25% loss) and all frames have roughly the same size (as there are no \"big\" I-Frames\" anymore....)\"

you simply tune your â€"vbv-maxrate 1000 â€"vbv-bufsize 200 â€"slice-max-size 1500 options to fit your local/remote LAN settings, just one of the biggest benefits... all those people using 11g and lower grade 11N wireless connections to interconnect their LAN kit for one, get a Direct Long Term benefit from the up to 25% loss protection for virtually No effort.

and OC theres other new inter-related x264 options coming down the line soon that also benefit low-latency and yet will/may increase compression and quality for many generic situations in the right combinations even more, but im just an old optimist hopeing OSS people start creating and using their ISP uploads to create new interesting apps for remote stacking,Encoding,viewing, and interacting with their personal content anywere, be it local LAN, WAN,or ISP upload bitrate etc...

Fair Enough, you learn and make your choices and do as you will,
http://x264dev.multimedia.cx/?p=249
if you care about low-latency LAN streaming etc then PIR is a good tool to have in your toolbox, a good workman learns to use the tools available to them to best effect, a bad workman....now back to regular updates and make a new thread if you care too!, and point the reader there, and Thanks again for the update incase that wasnt clear...

LoRd_MuldeR

#146
January 31, 2010, 10:20:54 PM
I\'m not going to continue this pointless discussion. Especially since this is the \"sticky\" thread that should be used for posting builds and for nothing else. So I just want to summarize a few facts: PIR does not give any benefits that are relevant for local playback. The only benefits are for low-latency video streaming! At the same time PIR has a major drawback: It hurts compression efficiency. So with PIR you will need a bigger file for the same quality. Therefore I wouldn\'t recommend to use PIR, unless you want to experiment with it or you are running a video streaming server (which doesn\'t apply to Avidemux).
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

lych

#147
February 01, 2010, 06:13:44 AM
One more thing about PIR... You should use slices with it to achieve the most benefit.

LoRd_MuldeR

#148
February 01, 2010, 08:24:17 PM
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

LoRd_MuldeR

#149
February 07, 2010, 08:16:38 PM
The GCC 4.5.0 builds of libx264 r1416 have been re-compiled with GCC 4.5.0 2010-02-06:
http://avidemux.org/admForum/viewtopic.php?pid=41780#p41780
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/
Print
Go Up Pages 1 ... 8 9 10 11 12 ... 16
User actions