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.

 Doom9's Forum FFmpegSource
 Register FAQ Calendar Search Today's Posts Mark Forums Read

 12th September 2011, 21:55 #1281  |  Link TheRyuu warpsharpened   Join Date: Feb 2007 Posts: 788 ffms2-r555.7z Libav 273aab9 Most notable change is a fix in libav for unbreaking certain VC1 decoding.
13th September 2011, 09:54   #1282  |  Link
Midzuki
Unavailable

Join Date: Mar 2009
Location: offline
Posts: 1,477
Quote:
 Originally Posted by TheRyuu ffms2-r555.7z Libav 273aab9 Most notable change is a fix in libav for unbreaking certain VC1 decoding.

and

 14th September 2011, 00:44 #1283  |  Link TheRyuu warpsharpened   Join Date: Feb 2007 Posts: 788 ffms2-2.16-avs-cplugin.7z This is the cplugin version of ffms 2.16. LoadCPlugin(X:\path\to\ffms2.dll") This archive contains BOTH 32-bit and 64-bit binaries. The primary use for this is access to the new colorspaces provided by avisynth 2.6. This plugin is also compatible with 2.5x.
 17th September 2011, 01:50 #1284  |  Link TheRyuu warpsharpened   Join Date: Feb 2007 Posts: 788 ffms2-r559.7z Libav 3a78fb5 More correct handling of colorspace/range flags. No longer rescales fullrange to limited range.
22nd September 2011, 23:29   #1285  |  Link
TheFluff
Excessively jovial fellow

Join Date: Jun 2004
Location: rude
Posts: 1,073
Quote:
 Originally Posted by rean I have catched this bug on a simple x264-encoded file. Instructions, scripts, files, versions, screenshots are here: http://media.namerenie.info/bug/ It is my home PC, so please download them within these days. Also please look at the bug with my file from a Sony NEX-5 (rewrapped to mkv). I cannot open it at all using ffms2. Sorry for the big files.
Okay, so I finally got around to taking a look at these.

20110522_11163.mkv ("bug 1") can't be played at all with Haali's media splitter for some reason. A remux with mkvmerge fixes that issue, but whatever, that's unrelated; it's probably just lavf's mkv muxer doing odd stuff again. FFMS2 opens and decodes it fine (well, "fine" if you disregard the usual funky interlaced h.264 issues) if you use threads=1. Didn't I ask you to try that a few posts ago? Oh well, whatever, the issue here is that libavcodec's multithreaded decoding is broken. Who coulda' thunk it. I can't do anything about that, unfortunately, so just use threads=1 for now.

20110521_11462.mkv ("bug 2") works just fine with 32-bit FFMS2. I don't have a 64-bit OS nor 64-bit Avisynth so I can't reproduce your issue. I've asked TheRyuu to take a look.

Last edited by TheFluff; 22nd September 2011 at 23:54.

23rd September 2011, 18:55   #1286  |  Link
Chumbo
Registered User

Join Date: Feb 2005
Posts: 585
Quote:
 Originally Posted by TheRyuu ffms2-r559.7z Libav 3a78fb5 More correct handling of colorspace/range flags. No longer rescales fullrange to limited range.
Is a 64bit version available? Thanks.
__________________
Chumbo

 25th September 2011, 02:13 #1287  |  Link TheFluff Excessively jovial fellow   Join Date: Jun 2004 Location: rude Posts: 1,073 I was very bored so I made a quick hack that makes FFMS2 able to output 10-bit YV12 video as the ugly 16-bits-per-sample doubled height stuff that cretindesalpes' Dither package uses. I've tested it on a grand total of one (1) video so far but it seems to work. Download: ffms-r561+10bithack.7z It will act just like an ordinary FFMS2 and downsample 10-bit input to 8-bit, unless you set the colorspace parameter to ffvideosource like so: Code: ffvideosource("10-bit.mkv", colorspace="YV12_10-bit_hack") Note that this stuff isn't officially supported; it will not be committed to SVN and will not be in official releases. All of the FFMS developers agree that such hacks are not the way to go. If you want to go further with this, the 7z contains a patch for the FFMS2 source code so you can create your own fork if you enjoy this sort of stuff. Last edited by TheFluff; 25th September 2011 at 02:16.
 25th September 2011, 03:41 #1288  |  Link jmac698 Registered User   Join Date: Jan 2006 Posts: 1,867 @fluff Hey, thanks! Saves me some time, I was going to try to compile that but was busy. Anyhow, it turns out that a straight 16bit word is quite acceptable, I found out recently. To quote chikuzen, Code: cd /d d:\sintel_rgb48 ffmpeg -f image2 -i %08d.png -pix_fmt yuv444p16le -vcodec rawvideo -an -f rawvideo d:\sintel_raw_yuv\yuv444p16le.yuv #read_16bit_yuv.avs LoadPlugin("RawSource26.dll") LoadPlugin("flash3kyuu_deband.dll") RawSource("d:\sintel_raw_yuv\yuv444p16le.yuv", width=2048, height=436, fpsnum=24, fpsden=1, pixel_type="i444") f3kdb_dither(stacked=false) I like your method though because we can use 2.58 (I've been told 2.6 isn't ready for production; anyhow I put a lot of work into verifying the operations for my very accurate scientific work).
 25th September 2011, 13:58 #1289  |  Link mp3dom Registered User   Join Date: Jul 2003 Location: Italy Posts: 1,044 RawSource 2.6 is for AviSynth 2.6. The version for AviSynth 2.58 is here: http://www.mediafire.com/?3bmwyi1lztt4h1j
25th September 2011, 14:00   #1290  |  Link
kolak
Registered User

Join Date: Nov 2004
Location: UK
Posts: 2,412
Quote:
 Originally Posted by TheFluff I was very bored so I made a quick hack that makes FFMS2 able to output 10-bit YV12 video as the ugly 16-bits-per-sample doubled height stuff that cretindesalpes' Dither package uses. I've tested it on a grand total of one (1) video so far but it seems to work. Download: ffms-r561+10bithack.7z It will act just like an ordinary FFMS2 and downsample 10-bit input to 8-bit, unless you set the colorspace parameter to ffvideosource like so: Code: ffvideosource("10-bit.mkv", colorspace="YV12_10-bit_hack") Note that this stuff isn't officially supported; it will not be committed to SVN and will not be in official releases. All of the FFMS developers agree that such hacks are not the way to go. If you want to go further with this, the 7z contains a patch for the FFMS2 source code so you can create your own fork if you enjoy this sort of stuff.

It looks like it's always only 8bit. Should it work with v210 mov?

Last edited by kolak; 25th September 2011 at 14:05.

25th September 2011, 20:18   #1291  |  Link
TheFluff
Excessively jovial fellow

Join Date: Jun 2004
Location: rude
Posts: 1,073
Quote:
 Originally Posted by kolak It looks like it's always only 8bit. Should it work with v210 mov?
If outputs something that isn't 8-bit it should be immediately obvious to you because it'll be double height and the lower half will be full of LSD hallucinations. On the flip side, if it outputs 8-bit it's because you didn't explicitly set the colorspace correctly. Read my post again. On a side note it would be great if you could learn to edit posts instead of posting five times in a row.

Now, please take the unrelated rawsource and high bitdepth general discussion out of this thread and somewhere else, as it isn't related to FFMS2.

 25th September 2011, 21:23 #1292  |  Link mp3dom Registered User   Join Date: Jul 2003 Location: Italy Posts: 1,044 Is it normal that this hacked version of FFMS outputs different LSB than the ReadV210mod method? In FFMS the LSB is anyway 'visible' (hallucinated colors, but the image is 'identified') while the ReadV210mod outputs generally all green (similar to component 'green' tint) and some unrecognized patterns. Shouldn't both produce the same output? (For reference the input was a V210 file)
25th September 2011, 21:36   #1293  |  Link
kolak
Registered User

Join Date: Nov 2004
Location: UK
Posts: 2,412
Quote:
 Originally Posted by TheFluff If outputs something that isn't 8-bit it should be immediately obvious to you because it'll be double height and the lower half will be full of LSD hallucinations. On the flip side, if it outputs 8-bit it's because you didn't explicitly set the colorspace correctly. Read my post again. On a side note it would be great if you could learn to edit posts instead of posting five times in a row. Now, please take the unrelated rawsource and high bitdepth general discussion out of this thread and somewhere else, as it isn't related to FFMS2.
I prefer to write new post if it provides bit different information than original ( I deleted useless posts).

Hmmm- I just downloaded your moded version and used your cmd line with v210 mov. I could see normal video, but not really Rest was not seen because my laptop has to small resolution- had to change preview in Vdub to 25%- sorry

So now I can confirm that it does work with v210 mov or at least it shows something in low bits.

Does ffvideosource support ProRes and DNxHD 10bit decoding, so I can use it to pass 10bit to dither directly in avisynth?

update: it produces output with banding, so not sure if it works.

Thanks,
Andrew

Last edited by kolak; 25th September 2011 at 22:19.

25th September 2011, 23:30   #1294  |  Link
TheFluff
Excessively jovial fellow

Join Date: Jun 2004
Location: rude
Posts: 1,073
Quote:
 Originally Posted by mp3dom Is it normal that this hacked version of FFMS outputs different LSB than the ReadV210mod method? In FFMS the LSB is anyway 'visible' (hallucinated colors, but the image is 'identified') while the ReadV210mod outputs generally all green (similar to component 'green' tint) and some unrecognized patterns. Shouldn't both produce the same output? (For reference the input was a V210 file)
It's entirely possible that it's a bug. I'm not completely sure the code that gets the LSB part is correct. I will not maintain this patch however, so if you want it investigated you'll have to do it yourself. The relevant code is on line 61 of the included patch; I think I got the LSB case wrong and the Right Thing would be to shift away the MSB before casting to uint8_t.

Quote:
 Originally Posted by kolak Does ffvideosource support ProRes and DNxHD 10bit decoding, so I can use it to pass 10bit to dither directly in avisynth?
It should support both ProRes and DNxHD. 10-bit ProRes should be supported but I dunno about DNxHD, try it and find out I guess. If it produces banding that's probably a result of swscale being retarded.

Last edited by TheFluff; 25th September 2011 at 23:39.

25th September 2011, 23:45   #1295  |  Link
kolak
Registered User

Join Date: Nov 2004
Location: UK
Posts: 2,412
Quote:
 Originally Posted by TheFluff It's entirely possible that it's a bug. I'm not completely sure the code that gets the LSB part is correct. I will not maintain this patch however, so if you want it investigated you'll have to do it yourself. The relevant code is on line 61 of the included patch; I think I got the LSB case wrong and the Right Thing would be to shift away the MSB before casting to uint8_t. It should support both ProRes and DNxHD. 10-bit ProRes should be supported but I dunno about DNxHD, try it and find out I guess. If it produces banding that's probably a result of swscale being retarded.
Something is not right. You can see difference here:

My laptop screen is so crap- need to see it at work on proper monitor

10bit DNxHD decoding/encoding is supported in latest ffmpeg/ffmbc. ProRes 10bit decoding seams to be also stable- tested on few different files.

Andrew

Last edited by kolak; 25th September 2011 at 23:57.

 26th September 2011, 00:56 #1296  |  Link cretindesalpes ͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿     Join Date: Feb 2009 Location: No support in PM Posts: 610 Suggested modification, just by looking at the patch code. I not even tried to compile it: Code: // we need to iterate over the source buffer twice; once to get the MSB and once to get the LSB. //for (int i = 1; i >= 0; i--) { uint16_t *SrcP = (uint16_t*)Frame->Data[p]; int height = (p == 0) ? Frame->ScaledHeight : Frame->ScaledHeight / 2; // remember UV planes are half height const int lsb_offset = height * DstPitch; for (int y = 0; y < height; y++) { for (int x = 0; x < (Frame->Linesize[p] / 2); x++) { // assume 2 bytes per pixel // wouldn't it have been nice if we could just use Env->BitBlt()...? if (x >= DstPitch) { *SrcP++; // advance the source pointer until we hit the next line continue; } // I sure hope a shift by 0 gets optimized away by the compiler... // *DstP++ = (uint8_t)(*SrcP++ >> (2*i)); // yuv420p10le uses the 10 least significant bits. shift right by 2 to get the 8 most significant ones. const int data10 = *SrcP++; *DstP = (uint8_t)(data10 >> 2); DstP [lsb_offset] = (uint8_t)(data10 << 6); ++ DstP; } } //} Actually I'm not sure if Frame->ScaledHeight always equals VI.height / 2, but I supposed it does. If not, lsb_offset calculation has to be changed. __________________ dither 1.27.2 for AviSynth | avstp 1.0.3 for AviSynth development | fmtconv r19 for Vapoursynth | trimx264opt segmented encoding Last edited by cretindesalpes; 26th September 2011 at 01:02.
26th September 2011, 02:00   #1297  |  Link
TheFluff
Excessively jovial fellow

Join Date: Jun 2004
Location: rude
Posts: 1,073
Quote:
 Originally Posted by cretindesalpes Suggested modification, just by looking at the patch code. I not even tried to compile it: Code: // we need to iterate over the source buffer twice; once to get the MSB and once to get the LSB. //for (int i = 1; i >= 0; i--) { uint16_t *SrcP = (uint16_t*)Frame->Data[p]; int height = (p == 0) ? Frame->ScaledHeight : Frame->ScaledHeight / 2; // remember UV planes are half height const int lsb_offset = height * DstPitch; for (int y = 0; y < height; y++) { for (int x = 0; x < (Frame->Linesize[p] / 2); x++) { // assume 2 bytes per pixel // wouldn't it have been nice if we could just use Env->BitBlt()...? if (x >= DstPitch) { *SrcP++; // advance the source pointer until we hit the next line continue; } // I sure hope a shift by 0 gets optimized away by the compiler... // *DstP++ = (uint8_t)(*SrcP++ >> (2*i)); // yuv420p10le uses the 10 least significant bits. shift right by 2 to get the 8 most significant ones. const int data10 = *SrcP++; *DstP = (uint8_t)(data10 >> 2); DstP [lsb_offset] = (uint8_t)(data10 << 6); ++ DstP; } } //} Actually I'm not sure if Frame->ScaledHeight always equals VI.height / 2, but I supposed it does. If not, lsb_offset calculation has to be changed.
Yes, that does the LSB part right, I think. I'm not sure if it's faster though, since you do the extra step of assigning the result to a temporary variable. On the other hand, maybe the compiler is smart enough to optimize that out.

 28th September 2011, 12:49 #1298  |  Link kolak Registered User   Join Date: Nov 2004 Location: UK Posts: 2,412 Can you compile it with these fixes, please. Thanks, Andrew
 28th September 2011, 16:35 #1299  |  Link jmac698 Registered User   Join Date: Jan 2006 Posts: 1,867 Kolak, I made a new readv210.
 28th September 2011, 18:35 #1300  |  Link kolak Registered User   Join Date: Nov 2004 Location: UK Posts: 2,412 Where ? Saw one but it was only for grayscale not?