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. |
2nd September 2013, 12:18 | #241 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
If it can read YUV files already, implementing "pipe support" (i.e. reading the YUV data from the STDIN rather than from a "physical" file) should be done with one line of code.
And then you get Avisynth or VapourSynth or FFmpeg input for free Code:
- FILE input = fopen(input_path, "rb"); + FILE input = (strcmp(input_path, "-")) ? fopen(input_path, "rb") : stdin; Code:
_setmode(_fileno(stdin), _O_BINARY); BTW: Looks like there is Y4M support already: https://bitbucket.org/multicoreware/...cpp?at=default
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 2nd September 2013 at 12:29. |
3rd September 2013, 11:43 | #244 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
Due to the edit:
Yes, x265 can read Y4M, which is certainly better than reading raw YUV. But only from a disk file, that's the drawback. Having e.g. ffmpeg pipe Y4M into x265 would be useful, but x265 would have to choose STDIN as input "file" when its name is exactly "-" (but you will know better than me what else may be necessary, depending on the OS, e.g. forcing binary file mode?). |
4th September 2013, 07:48 | #245 | Link |
Registered User
Join Date: May 2008
Posts: 1,840
|
It's understandable the core devs are focusing on video coding and as long as they can test it with current input options it's good enough. From a user's view it's very difficult to test (special input, decoder, etc.) and progress seems stagnant although it's not. Usability of the encoder is the biggest roadblock atm, improving it by simply allowing more inputs might lead to libav/ffmpeg decoders which might lead to more pull requests coming in which may land x265 more coders. From the posts on Doom9 seems they welcome contributions and are looking for developers.
During x264's infancy it had many input options and decoder support very early on even if the video quality/speed wasn't up to xvid's at the time.
__________________
PC: FX-8320 GTS250 HTPC: G1610 GTX650 PotPlayer/MPC-BE LAVFilters MadVR-Bicubic75AR/Lanczos4AR/Lanczos4AR LumaSharpen -Strength0.9-Pattern3-Clamp0.1-OffsetBias2.0 |
4th September 2013, 18:38 | #246 | Link | ||
Guest
Posts: n/a
|
Quote:
Quote:
Tom |
||
5th September 2013, 13:04 | #247 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
I'd love to be able to contribute, but C / C++ don't belong to the list of programming languages I know good enough...
Anyway: for being busy and research the future of video coding. |
5th September 2013, 22:09 | #248 | Link |
Registered User
Join Date: May 2008
Posts: 1,840
|
Is Lord_Mulder's 'patch' sufficient?
__________________
PC: FX-8320 GTS250 HTPC: G1610 GTX650 PotPlayer/MPC-BE LAVFilters MadVR-Bicubic75AR/Lanczos4AR/Lanczos4AR LumaSharpen -Strength0.9-Pattern3-Clamp0.1-OffsetBias2.0 |
6th September 2013, 00:51 | #250 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
This was not an actual patch, just a broad hint on how this stuff is done in general
Actually, x265 uses C++ fstream's rather than classic FILE* pointers, so a slightly different (though equivalent) solution will be needed. I would write a proper patch, but I'm about to leave for vacation...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 6th September 2013 at 00:55. |
18th October 2013, 00:52 | #251 | Link | |
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
Quote:
|
|
19th October 2013, 15:01 | #252 | Link | |
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
Quote:
Code:
Steve Borho 09fe406 commit JCT-VC HM source with cmake based build scripts 2013-03-07 https://bitbucket.org/multicoreware/x265/commits/all?page=152 ) Last edited by filler56789; 19th October 2013 at 15:03. |
|
21st October 2013, 00:26 | #253 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,751
|
They are cranking HARD on improving image quality, and there's tons of x264 features to port over. I'd expect that "utility" features like this aren't going to get a lot of attention for a while yet.
|
21st October 2013, 17:14 | #254 | Link |
Registered User
Join Date: Jun 2013
Posts: 95
|
@filler56789
Note: I didn't test x265 myself yet. You can have pipe support with all applications at a higher level if the application does not seek. In *nix for example, you can use process substitution which is a feature provided by shells: Code:
# Substitute dump_command with any command that outputs to stdout x265 -o outfile <(dump_command) Code:
mkfifo dump.yuv x265 -o outfile dump.yuv Code:
dump_command > dump.yuv |
21st October 2013, 17:29 | #255 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
Both may not be helpful for Windows users...
Well, it is for testers. Testers are expected to have some "pioneer attitude". A few short "standard trailers" (e.g. Blender movies) will be fine for first experiences. Some of these are even downloadable as Y4M, I believe? |
Thread Tools | Search this Thread |
Display Modes | |
|
|