I'm even more confused. After installing everything in the guide (I found a page on the SDL thing), the SDL was already in the ffmpeg folder, I came to the part where I build ffmpeg. The guide says...
FFmpeg
To configure a basic build you just need to run configure in the FFmpeg source directory.
Once you installed all the necessary packages (MinGW is the only strict requirement for building FFmpeg, git is required to update your FFmpeg source), you need to open a MinGW shell, change directory to where you checked out the FFmpeg sources, and configure and make FFmpeg the usual way.
NOTE: configure is sometimes painfully slow in MinGW.
Like I mentioned earlier, I didn't get a MinGW Shell and I have no idea how to make ffmpeg the regular way since I've never made an ffmpeg build before. I doubleclicked the config file in the ffmpeg folder and Microsoft Visual Studio opened up but I have no clue what to do next or if I should even be in Visual Studio.
If someone could just download the ffmpeg-patched file and make an ffmpeg.exe file, it would make my life a lot easier. I've been at this for hours and I don't think I'm getting anywhere. I built a fdkaac.exe file a couple of weeks ago but all I had to do was download an autobuild file and follow the instructions by double clicking bat files and withing 5 or 10 minutes, I had an exe file.
Nevermind. Looking inside the 265 folder, the dates are all old.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 31 to 60 of 2222
Thread
-
Last edited by DarrellS; 1st Aug 2013 at 00:03.
-
I've never managed to compile ffmpeg either There are TONS of "dependencies" involved, and so many "config tweaks" are required,... but more importantly, I'm an old and impatient and grumpy man already : - /
I'm even more confused. After installing everything in the guide (I found a page on the SDL thing), the SDL was already in the ffmpeg folder, I came to the part where I build ffmpeg. The guide says...
FFmpeg
To configure a basic build you just need to run configure in the FFmpeg source directory.
Once you installed all the necessary packages (MinGW is the only strict requirement for building FFmpeg, git is required to update your FFmpeg source), you need to open a MinGW shell, change directory to where you checked out the FFmpeg sources, and configure and make FFmpeg the usual way.
NOTE: configure is sometimes painfully slow in MinGW.
I doubleclicked the config file in the ffmpeg folder and Microsoft Visual Studio opened up but I have no clue what to do next or if I should even be in Visual Studio.
You really shouldn't be "double-clicking" config files or anything in this case.
Nevermind. Looking inside the 265 folder, the dates are all old.Last edited by El Heggunte; 1st Aug 2013 at 04:20. Reason: misunderstanding : - /
-
Nor sure if it helps at all, but If I need to I normally compile ffmpeg for windows with https://github.com/rdp/ffmpeg-windows-build-helpers which I run in a VM.
-
sounds like they just don't want to do it--or, they don't know how!
whats is needed to get x265 to accept yuv or y4m from an "alternative" source ?
is it how the data is read? what format, exactly ?
does avisynth send rgb or yuv data ?
can we just create a *new* frameserver (ie, like vdub, avisynth, etc) engine ?
i'm asking because i've always wanted to build my own frameserve and this looks like a good time to ask such questions. -
Well, I understand the fact that they are too busy ATM, actually "running against time" (since they are being sponsored by not-so-small companies), but hey, ...
whats is needed to get x265 to accept yuv or y4m from an "alternative" source ?
is it how the data is read? what format, exactly ?
then Avisynth support would be "automagic",
since the primary job of Avisynth is make an AVS script appear as a real AVI file to the requesting application.
BTW, a couple of hours ago, I modified part of the x265 code, in an attempt to include an AVIReader.cpp and an AVIreader.h...
Because I still don't know very-well what I am doing , the progress indicator of the compiling process stopped at 25% ,
certainly because of incorrect and/or insufficient referencesLast edited by El Heggunte; 1st Aug 2013 at 18:17. Reason: my English still sucks : - /
-
well, iyam, what someone should do is create a wrapper for avisynth -> -*-wrapper-*- -> [yuv]-encoder so that when these new encoders (they always start out req'ring YUV) do come out, that there is a way to frameserve (using avisynth) to them.
what i mean is, if you had the following items, it should work, in theory..
avs script
new proxy/frameserver utility (to feed script into) and outputs the raw YUV data
encoder
..unless something like this is already been done but forgotten. -
it would be possible if the encoder would support input via pipe/std:in, then you could use ffmpeg/mencoder/avs2yuv to feed the encoder,...
-
If ffmpeg would implement the MinGW 265 encoder then I would be in business since ffmpeg would read the uncompressed video in Virtualdub and just call the encoder to encode the file but I'm sure they're waiting for a finished encoder before they will implement it. I already have the old encoder working (I guess it's working since it goes all the way through without any errors) in a patched ffmpeg but nothing will read the finished file. It looked promising since it encoded a 640x480 file at 3.8 frames per second which was much faster than the TAppEncoder which took almost two hours to encode a 300 frame file. The ffmpeg package that I downloaded (preview 8) said it was based on hm10 but when I looked inside the 265 folder, all the files were around May of 2012 so I gave up on even trying to build it. I also found an SDK with the files to build and encoder but it's from February I think and it looks just like another encoder that I tried already.
The Lentoid encoder looked promising but with the watermark and the release of the MinGW encoder, it's pretty much died down. It suffered from the same faults as the Windows Media Encoders and the TAppEncoder in that it was not just a plain old CLI encoder but relies on scripts and dlls to work. At least the files would play though.
I hope that eventually this new encoder gets stdin. It's supposed to be built on the x264 model since thy got involved and it supports stdin. I also hope that ffmpeg implements the x265 encoder but I'm not holding my breath on that since they never did implement wmv9/VC-1 and they haven't implements VP9 even though it's been out a while. Speaking of VP9, it doesn't look like that encoder supports stdin either. Working with Virtualdub I've come to find that there are a whole lot of encoders (audio and video) that don't support stdin. Luckily, the only encoder that I'm really interested in using does and that is x264. It's fast and all of my hardware players support it in either MP4 or MKV containers.
Everyone keep up the good work though. Eventually all the great minds on this site and Doom9 will get it figured out. It seems like a lot more gets done over here than Doom9 though. Everyone over here seems a lot more willing to help with getting problems solved. I guess that's why it's called Videohelp. -
Speaking of Mencoder, it would be great if that would work in Virtualdub. All the experts at Virtualdub tried to get it working when the external encoder feature first came out but they had no success. I guess mencoder is not able to read raw input and like a few of these X265 encoders, needs yuv4mpeg. From what I've read, the x265 encoder doesn't need width, height and frame rate in the command line with Y4M since it can read it from the input file (which is strange because all the YUV files I've tried to encode with the external encoder list those attributes in the log file).
I saw a post you made at Doom9 about the vp8vp9 encoder so I downloaded the file and I can't get it working in Virtualdub either, although I have no problem with libvpx for vp8 in ffmpeg with the external encoder feature in Virtualdub. I'm guessing it doesn't support stdin either which is no surprise. Hardly any encoders seem to support it. -
mencoder does support yav video via pipe without a problem.
Code:mencoder -demuxer rawvideo -rawvideo w=640:h=480:fps=25 - .....
vpxenc does support input via pipe too, works fine here.
-> I guess you are doing something wrong. -
i think its more about the strickness of rules and imediate flaug we get when even the slight hint of wrong is mentioned that scares people from participating there. i saw one guy posting something in one of the 265 threads and he imediately got flaugged about it. i didn't see anything wrong but someone else did. yeah, it used to be a heavily used forum. but now more a ghost town, and the only thing keeping it alive are topics like new encoders.
mencoder does support yav video via pipe without a problem.
Code:
Code:mencoder -demuxer rawvideo -rawvideo w=640:h=480:fps=25 - .....
vpxenc does support input via pipe too, works fine here.
-> I guess you are doing something wrong.
.
it would be possible if the encoder would support input via pipe/std:in, then you could use ffmpeg/mencoder/avs2yuv to feed the encoder,...
avisynth -> dummy file -> x265
or something like that...unless i am misunderstanding somthing, it may still be possible, if x265 is reading a file, why not create a dummy file in realtime and write frame to it. i must be missing something here, since i can read videos that are encoding through mediainfo.dll it might be still possible to write data to this dummy file.
.
the stongne lentoid is a good encoder, simple with virtually no params to adjust and gives very good results, but tie'ing it to directshow (graphstudio) is not a user-friendly interface. not when gs is a suite of all sorts. basically, its not an encoder. however, i did manage to build a cheap front-end to it, once you build the graph on your pc, and is working, you simply open that graph and it encodes. the problem is, there is no feedback as to what is going on. but i did learn you can open the videofile.flv as it is still encoding and view the timecode. i was trying to update the utility to show just the timecode (and hopefully, the current or last framenumber) but a) couldn't find the frame number, if there was one in mediainfo.dll, and b) i couldnt' figure out how to just extract the timecode, from mediainfo.dll, in my delphi app. i'm still looking. if i can figure out that, then we can have a basic encoder with real-time preview. so, if anyone knows how to get those two for me, let me know right away and i'll add that and post the utility.
i'm rushing out of here, sorry for any typos. -
that's because doom9, over the years, has evolved into a place devoted to kissing the ass of the x264 developers coupled with promoting the half-assed software of a few other members of that suck ass forum.
all you have to do is read DS' comments on x265, where he basically said that x265 exists because he allows it to exist, i'm not making this up, you can go read it for yourself.
let's be honest with ourselves, any of the x264 crew or some of the experienced programmers over there could add stdin support to x265 very easily but they have a vested interest in slowing down the adoption of x265 as much as possible.
the x264 developers make a pretty penny off of x264 and have been doing so since at least 2005. they see the writing on the wall, that their cash cow their little money maker that they have spent years promoting and years denouncing all competitors, is about to be usurped and they know that once adoption of any h265 encoder becomes widely prevalent their income source will start drying up and of course they are in no hurry to see this happen.
that's why they, the x264 developers and supporters, have already started spreading FUD about the future of h265 and VP9 and started promoting DAALA, an encoder for which not a single line of code has yet been written and an encoder based on a faulty premise built around a mathematical circular dependency that the only way to get around is by using a different route that negates the presumed benefits of what the circular dependency would offer if it wasn't logically flawed.
as a side note, i've been playing around with the Strongene hevc encoder an i am blown away by the quality. if it wasn't for the fact that it adds a watermark to the video (of course it's just a sample of what a fully licensed encoder can do), i would be willing to put up with the slow encode speeds, it's really that good. -
that's because doom9, over the years, has evolved into a place devoted to kissing the ass of the x264 developers coupled with promoting the half-assed software of a few other members of that suck ass forum.
-
Nope --- but wait, there is more:
That's it.
The PIGgest problem in the Doom9 forums has a name, and his name is Dorian "2-neurons" Gray
Seriously, their "ultimate forum rule", the 17th one, which states:
Code:No discussion about the rules or their interpretation.
Originally Posted by deadrats -
@vhelp: Regarding VirtualDub&mencoder I just did the following:
- installed 32bit versions of ffdshow 1.3.4500 (to have somethin that can decode via vfw)
- installed 32bit versions of VirtualDub-1.10.3.zip (is the latest version I saw)
- started VirtualDub
- loaded an .avi sample file
- disabled the audio processing
- set video to fast recompress (since I want to stay in Yv12 color space)
- configured an external encoder
Code:{ "description": "VirtualDub external encoder profile collection", "externalEncoders": { "sets": { "Mencoder": { "videoEncoder": "Encoder Profile2", "audioEncoder": "", "multiplexer": "", "description": "Mencoder x264", "extension": "mp4", "processPartial": false, "useOutputAsTemp": false } }, "profiles": { "Encoder Profile2": { "name": "Encoder Profile2", "program": "G:\\Hybrid\\mencoder.exe", "commandArguments": "-demuxer rawvideo -rawvideo w=%(width):h=%(height):fps=%(fps) - -ovc x264 -x264encopts bitrate=3000 pass=1 nr=2000 -o %(outputname).mp4", "outputFilename": "%(outputname)", "type": 0, "inputFormat": 0, "checkReturnCode": false, "logStdout": true, "logStderr": true, "bypassCompression": false, "predeleteOutputFile": true } } } }
- called File->Export->Using external encoder and selected the encoder set I just configured
Output was created as expected.
---------------------------
any of the x264 crew or some of the experienced programmers over there could add stdin support to x265 very easily
Naming it x265, gave it a bad taste for a lot of people. Doesn't seem to be more than a publicity stunt.
Cu Selur -
@ El Heggunte
Could you explain better how to do this installation and compile x265?, it is zs4mingw dir?
I have this in my VM win7
Code:Directorio de C:\MSYS 02/08/2013 17:46 <DIR> . 02/08/2013 17:46 <DIR> .. 23/07/2013 07:06 4.401 !components.txt 23/07/2013 07:11 <DIR> bin 23/07/2013 07:11 <DIR> etc 02/06/2013 21:28 5.632 getcp.exe 02/06/2013 21:28 1.405.952 git-receive-pac 02/06/2013 21:28 1.405.952 git-upload-arch 02/06/2013 21:28 1.405.952 git.exe 02/06/2013 11:28 340.234 gitk 02/08/2013 17:36 <DIR> home 23/07/2013 07:11 <DIR> include 23/07/2013 07:11 <DIR> lib 28/02/2009 11:58 978.432 libiconv2.dll 11/07/2009 19:34 2.238 m.ico 23/07/2013 07:11 <DIR> manifest 01/06/2013 07:23 <DIR> mingw 29/09/2010 00:48 7.167 msys.bat 11/07/2009 19:34 37.758 msys.ico 23/07/2013 07:11 <DIR> postinstall 23/07/2013 07:11 <DIR> sbin 28/09/2010 17:34 <DIR> share 23/07/2013 07:11 <DIR> var 10 archivos 5.593.718 bytes 13 dirs 5.844.729.856 bytes libres
-
It didn't work for me. First off, the vdprof file would not load. Said there was an error on line 25 so I manually created the profile. There is a warning at the start about the output being avi but it acts like it's encoding the file and gets to the end and fails with...
[i] VideoEnc: File not found: 'pass=1'
[i] VideoEnc: Failed to open pass=1.
[i] VideoEnc: Cannot open file/device.
[i] VideoEnc: Exiting...
[E] Error: CLI: The video encoding process failed with error code 1
(00000001). Check the log for possible error messages.[*] Ending operation.
Looking at the log, it shows 1440 empty frames. Acted like maybe it did the first pass of a two pass encode?
A few things look off in the profile. With the x264 encoder you use -o "%(tempvideofile)" - with no extension at the end and under
%(outputname)" you put .264 but looking at "Mencoder.exe -of help" it only shows avi, mpeg, lavf and rawvideo.
What is the command argument you use for vpxenc32.exe and vp9? I tried piecing mine together looking at the ffmpeg vpx profile for vp8 that works, the vpxenc help file and an argument I found online. Couldn't find anything on the webm site explaining how to create the command line. -
First off, the vdprof file would not load. Said there was an error on line 25 so I manually created the profile.
Acted like maybe it did the first pass of a two pass encode?
No clue what you did differently then me, I used the external encoder and used test as output name, due to the .mp4 ending I configured in the profile mencoder created mp4 file,...
-----------------------
What is the command argument you use for vpxenc32.exe and vp9?
Couldn't find anything on the webm site explaining how to create the command line.
Also look at the vpxenc help output you get when you simply call vpxenc.exe in the command line.
Cu Selur
Ps.: won't try to get vpxenc with VirtualDub running, since it would be a real waste of time for me, especially since it looks like that even the simple mencoder call doesn't work for others,... -
First things first: msyshome is a folder created by the user himself ( me, as the case seems to be ). You can (re)name it and place it (nearly-)anywhere, as long as it's defined in the file etc\fstab
As for zs4mingw, it's just a renamed mingw folder --- simply because, by starting with z, it automagically goes to the bottom of the directory listing, making it easier to find by me Yep, I do like to tweak things according to my preferences / habits / tastes, if I am allowed to --- for example, I do prefer
[C:\]
=>
to
C:\> ,
and I also *don't* think that a console window / command prompt "must be" a synonym for white or gray text on a black blackground
Second things secondly: install (or rather, *unpack*) both CMake and Mercurial to their respective folders. Make sure that "Path-To\CMake\bin" and "Path-To\Mercurial" were added the PATH environment-variable --- if they weren't, then do it manually.
Create the folder where you want to store the x265 source-code.
Open a command prompt on that folder.
Type and enter this command-line: hg clone https://bitbucket.org/multicoreware/x265
After the download is complete, type msys and press Enter.
Change the working directory to "Path-To/x265/build/msys".
Run cmake -G "MSYS Makefiles" ../../source && cmake-gui ../../source
IGNORE the warning about the stupid Visual Leak Detector thing.
In the CMake GUI, click the buttons "Configure" and "Generate".
Back in the Msys console, run make.
Go out for a break , and PRAY that the downloaded code does not contain some fatal error
IF the compiling process manages to reach 100%, THEN type exit, and go test your newborn x265.exe.
Good-luck!Last edited by El Heggunte; 2nd Aug 2013 at 16:15. Reason: spelling, grammar
-
Just for the notes:
https://bitbucket.org/multicoreware/x265/downloads/x265ContributorAgreement.pdf -
Thanks! The zipped vdprof file worked. I added mp3 passthrough to create an mp4 and mp3 but could not get a muxer to work. It takes some work to get a finished file because mediainfo sees the mp4 file as a h264 avi but I demuxed with Yamb to get a 264 file and muxed the 264 file and mp3 with Yamb. Looks like I need to study Mencoder to see what all it will encode. There isn't a help file in the execute file so I'll have to search to find it.
I'll try VP9 in Hybrid to get the command. I didn't realize that Hybrid supported it. I'll download your latest version so I'm up to date on all your encoders.
I'll probably never use any of these encoders for myself except for testing to see what all encoders will work with Virtualdub's external encoder. Most the guys that started all the guides on Virtualdub have disappeared so there are only a couple of us left to try and figure this stuff out. You have been a really big help to me and there are a couple of guys here that are trying to get encoders going. It is pretty neat to be able to open a file in Virtualdub and do all your editing and save as pretty much anything you want. WMV9/VC-1 is a no go. WMA9 professional works but only stereo. Hopefully they get Stdin input in the X265 final release and we can use it like we do X264 and other command line encoders.Last edited by DarrellS; 2nd Aug 2013 at 16:57.
-
Oooops, yet another ooops
BUT if an error happens, please don't hesitate and yes, send an e-mail to Steve Borho
Example:
[ 94%] Building CXX object encoder/CMakeFiles/encoder.dir/encoder.cpp.obj
G:/0000/Mercurial263/322bea3/source/encoder/encoder.cpp: In member function 'void x265::Encoder::determineLevelAndProfile(x265_param _t*)':
G:/0000/Mercurial263/322bea3/source/encoder/encoder.cpp:43:59: error: declaration of 'param' shadows a member of 'this' [-Werror=shadow]
G:/0000/Mercurial263/322bea3/source/encoder/encoder.cpp: In member function 'void x265::Encoder: :configure(x265_param_t*)':
G:/0000/Mercurial263/322bea3/source/encoder/encoder.cpp:163:44: error: declaration of 'param' shadows a member of 'this' [-Werror=shadow]
G:/0000/Mercurial263/322bea3/source/encoder/encoder.cpp: In member function 'bool x265::Encoder: :initializeGOP(x265_param_t*)':
G:/0000/Mercurial263/322bea3/source/encoder/encoder.cpp:335:48: error: declaration of 'param' shadows a member of 'this' [-Werror=shadow]
cc1plus.exe: all warnings being treated as errors
make[2]: *** [encoder/CMakeFiles/encoder.dir/encoder.cpp.obj] Error 1
make[1]: *** [encoder/CMakeFiles/encoder.dir/all] Error 2
make: *** [all] Error 2Last edited by El Heggunte; 2nd Aug 2013 at 18:50.
-
{ outdated content deleted }
Last edited by El Heggunte; 5th Apr 2014 at 21:53. Reason: : - /
-
have you ever stopped by doom10? it's practically a requirement that any question involving the usage and/or configuration of x264 include a statement that x264 is the best encoder currently available and something along the lines of "keep up the great work".
doom10 was put up for those times that doom9 doesn't supply Jason with enough ass kissing.
actually i think DS got into a tiff with the other fruitcake Donald and left thinking that everyone from doom9 would follow him to the very creatively named doom10. -
-
it wasn't a publicity stunt at all, Jason started the whole thing. go into the doom9 threads that deal with hevc and read through them, there is one where one kiss ass asks DS if it would be possible to take the x264 code base and build an hevc encoder around it. DS responded by saying it would be extremely difficult, if not impossible, because h264 and h265 are way too dissimilar in function. he concluded by saying "but, if anyone wants to take a whack at it, they're free to try".
the chinese guy, i forget his name, was an experienced programmer, having had a few commits to x264 years ago, i think mainly related to SSE and decided to take DS up on his offer.
near as i can tell he started with the reference encoder but also took cues from the x264 framework and started plugging away. this guy was a phd candidate at a chinese university (at least i think he was on his way to a doctorate) and his university took notice of his work and decided to join in. that collaboration came to the attention of this multicore company (i forget his name), a company that had created an opencl accelerated version of x264 (i think their version is different from the OCL patch that accelerates lookahead) and this company decided to copy the x264 developer's dual licensing scheme as a way of offering a final x265 version as a gpl'd product to the general product but also monetizing their work with a commercially friendly license.
DS was "nice enough" to "give his blessing" (as if he had anyway of stopping it) and even said that in the future he may commit some code to the project, if it stays true to the promise of a gpl'd version that mirrors the development of the commercial product.
here's the reality check, DS and friends don't own the rights to naming an encoder using "x" as a prefix" and a 3 number sequence as a suffix. no one seems to have a problem with x262, an mpeg-2 encoder built around the x264 code base, none of the core x264 developers have anything to do with that.
furthermore it's kind of hypocritical for Jason and Loren to be pissed about the x265 name when x264 was clearly a play on xvid, which itself was just divx spelled backwards.
so i don't think anyone has any right to have any problem whatsoever with the name x265. -
Thanks to El Heggunte
To contribute a little, up-to-date whith commit 3db96ea (Mediafire) x265-2013-08-03[3db96ea]
Happy testing -
^ Good-news indeed ,
it means I'm not alone anymore
Muchas gracias =^.^=
Similar Threads
-
help - how to compile latest "nightly" ffmpeg for win32 (XP) with mingw
By hydra3333 in forum ProgrammingReplies: 32Last Post: 20th May 2017, 01:33 -
x265 vs x264
By deadrats in forum Video ConversionReplies: 71Last Post: 10th Jan 2016, 07:14 -
ffdcaenc (an upgrade to dcaenc)
By El Heggunte in forum AudioReplies: 22Last Post: 9th Dec 2014, 07:09 -
MulticoreWare Annouces x265/HEVC Mission Statement
By enim in forum Latest Video NewsReplies: 4Last Post: 9th Aug 2013, 23:09 -
New PC Build(s)
By thedeificone in forum ComputerReplies: 6Last Post: 25th May 2010, 17:57