FFmpegSource

[cretindesalpes]

I tried to replace the r473 I was successfully using with r517 but FFVideoSource seems to have now random crashes in its destructor. It's not a huge problem because x264 seems to finalize the output file before deleting the avisynth instance so nothing is lost, but it gets stuck with debugging dialogs which is a more serious issue if you let your computer do a batch processing overnight.

I tried with avisynth 2.5.8 MT, with and without activating the MT modes. It occured with different scripts so I don't think it's caused by a rotten plugin. I also tried with threads=1 in FFVideoSource but to no avail. The read files were lossless AVC MP4 produced with x264. I'll try to do more testing later to make this bug as reproducible as possible.

[TheRyuu]

The read files were lossless AVC MP4 produced with x264. I'll try to do more testing later to make this bug as reproducible as possible.

Why are you using mp4 for h264 lossless that you're just going to read in with ffms2 anyway?

[cretindesalpes]

Why not? Is there a contraindication?

[TheRyuu]

Why not? Is there a contraindication?

There's no reason no to use mkv, which means you should use mkv.

[cretindesalpes]

Well, does that mean you're not interested in this issue?

[TheFluff]

nono, I'm ok by just being aware, I don't want you to fix them, that's ffmpeg business (right?), but by allowing ffms2 to use bugged features I understand it also supports them, you know...

I wasn't aware of the issue until you reported it. I filed a bug report (https://bugzilla.libav.org/show_bug.cgi?id=33) with libav, that's pretty much all I can do right now. I suggested two possible workarounds for you until the libav devs can fix the issue.


I tried to replace the r473 I was successfully using with r517 but FFVideoSource seems to have now random crashes in its destructor. It's not a huge problem because x264 seems to finalize the output file before deleting the avisynth instance so nothing is lost, but it gets stuck with debugging dialogs which is a more serious issue if you let your computer do a batch processing overnight.

I tried with avisynth 2.5.8 MT, with and without activating the MT modes. It occured with different scripts so I don't think it's caused by a rotten plugin. I also tried with threads=1 in FFVideoSource but to no avail. The read files were lossless AVC MP4 produced with x264. I'll try to do more testing later to make this bug as reproducible as possible.
What is a "random crash"? Does it mean it only crashes sometimes? If you have a sample file that always crashes, please upload it and we'll take a look.

[cretindesalpes]

Does it mean it only crashes sometimes?
Yes, from very rarely to always, depending on the script and the loaded files.

I found a configuration crashing almost always (on my computer at least) and put it here:
http://dl.free.fr/kHxsHUKoR

f = "crash-clip.mp4" # 100 frames
a = FFVideoSource (f)
b = FFVideoSource (f)
c = FFVideoSource (f)
l = a.FrameCount ()
b + a + c
Trim (l, -10) + last.BlankClip (length=1500-20) + Trim (l*2-10, -10)

EDIT:

I also tried with
- ffms2-r519-jeeb.7z: crash with ffms2-ffmpeg.dll and ffms2-libav.dll
- ffms2-r519-debug.7z: no crash
- ffms2-r507.7z: no crash
- ffms2-r494.7z: no crash

[TheFluff]

Yes, from very rarely to always, depending on the script and the loaded files.

I found a configuration crashing almost always (on my computer at least) and put it here:
http://dl.free.fr/kHxsHUKoR

f = "crash-clip.mp4" # 100 frames
a = FFVideoSource (f)
b = FFVideoSource (f)
c = FFVideoSource (f)
l = a.FrameCount ()
b + a + c
Trim (l, -10) + last.BlankClip (length=1500-20) + Trim (l*2-10, -10)

EDIT:

I also tried with
- ffms2-r519-jeeb.7z: crash with ffms2-ffmpeg.dll and ffms2-libav.dll
- ffms2-r519-debug.7z: no crash
- ffms2-r507.7z: no crash
- ffms2-r494.7z: no crash

I can reproduce the issue, and with Myrsloik's assistance I think I have fixed it. You can try this build (http://mod16.org/ffms2/ffms2-r526.7z) if you want to test it yourself.

Furthermore, I wish very much everyone was as good as you are at reporting bugs. Your detailed report and test case made it very easy to find the bug.

[cretindesalpes]

I can reproduce the issue, and with Myrsloik's assistance I think I have fixed it. You can try this build (http://mod16.org/ffms2/ffms2-r526.7z) if you want to test it yourself.
Thank you very much, I did a few tests with this new version and had no problem so far. I notice ffmsindex.exe is missing from this package, shall I take the one contained in r517?

[TheFluff]

Thank you very much, I did a few tests with this new version and had no problem so far. I notice ffmsindex.exe is missing from this package, shall I take the one contained in r517?

Whoops, I missed including it. But yes, the one from r517 should work fine with this version too. There have been no API/ABI changes nor any changes to ffmsindex itself.

[TheFluff]

New test build: ffms2-r532.7z (http://mod16.org/ffms2/ffms2-r532.7z)
Edit: now with 100% more pthreads thanks to Myrsloik.

We're slowly working on trying to fix enough bugs to motivate a release of 2.16, so test everything, submit all your weirdest sample files and win a prize if it causes a reproducible crash. Test audio in particular since we've been messing around with that a lot lately.

[TheRyuu]

Yet another new test build: ffms2-r533.7z (https://ffmpegsource.googlecode.com/files/ffms2-r533.7z)

All of the above plus this should fix the invalid postprocess bug (for good). Go forth and test.

[TheFluff]

FFMS 2.16 has been released. It is mostly a bugfix release, but it adds a few features as well; most importantly full support for YUV 4:4:4 as well as high bitdepth YUV.

The following downloads are now available:

ffms-2.16.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16.7z) - the usual binary. Includes multithreaded decoding functionality; you do no longer need a special -mt version.
ffms-2.16-x64.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16-x64.7z) - 64-bit version, for use with avs64. Note that it is a native Avisynth plugin now; no need for LoadCPlugin or LoadStdcallPlugin.
ffms-2.16-src.tar.bz2 (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16-src.tar.bz2) - source code.
ffms-2.16_SDK.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16_SDK.7z) - package for Windows developers who want to develop programs that use FFMS2 but don't want to deal with MinGW.


Full changelog since 2.15:

Reimplemented output colorspace selection, this should fix all issues with the avisynth plugin when opening yuv420p10 or yuv444 material plus several other less common cases. (Myrsloik)
Added FFMS_SetOutputFormatV2 to the API. This function allows you to specify PixelFormats >= 64 for use as output. (Myrsloik)
Fixed a serious bug that could cause crashes and completely useless index files with h264 in matroska. (Myrsloik)
Automatically detect number of decoding threads. The avisynth video source funtion already did this, now moved so the api can use it as well. (TheRyuu)
Re-add the ability to target x64 with msvc since it's a bit more sane now. (TheRyuu)
Fixed a bug that could cause crashes when reading audio if FFMS2 was compiled with GCC. (Myrsloik)
ffmsindex will no longer crash if it cannot open the file given to it for indexing. (TheFluff)
FFMS2 will no longer crash if the video decoder feeds it an empty frame (can sometimes happen when using lots of decoder threads); you'll get a nice error message instead. (TheFluff)
The C-plugin can now act as both an Avisynth 2.6 plugin (including support for new colorspaces) as well as an Avisynth 2.5 one, in the same binary. (kemuri_-9)
Fixed an issue that could cause opening Vorbis audio to fail because FFMS2 couldn't find an initial valid PTS. (TheFluff)
FFMS2 will no longer crash if forced or tricked into using an index file generated by a FFMS2 version compiled for a different architecture. (TheRyuu)
Fixed a crash when the last frame was requested using the Avisynth plugin's forced CFR mode. (Plorkyeran)
Fixed various issues with decoding audio from the Ogg container without Haali's splitter. (Myrsloik, TheFluff)
Fixed the "invalid postprocessing settings"; they were caused by a parsing bug in libpostproc, and a workaround has been added. (Myrsloik)
Tinkered a bit with the non-MSVS build system. (Daemon404, Kovensky)


Important notice for postprocessing users:
Support for postprocessing in FFMS2 will be dropped in the next release. The reason is that both libav is dropping the libpostproc library from their own releases, and so we cannot continue supporting it.

[TheRyuu]

Could you also upload an x64 version? I use it to mix video clips, but a 32-bit version of Avisynth cannot be used - no memory...

I'll probably get to it later today or tomorrow.

[chipzoller]

I'm not sure if this thread also doubles as the "official" support thread and so hate to cross-post, but I'm having an issue with 2.16 throwing "decoder returned an empty frame". Original thread is here and will gladly merge/delete if desired: http://forum.doom9.org/showthread.php?t=162391

[TheFluff]

I'm not sure if this thread also doubles as the "official" support thread and so hate to cross-post, but I'm having an issue with 2.16 throwing "decoder returned an empty frame". Original thread is here and will gladly merge/delete if desired: http://forum.doom9.org/showthread.php?t=162391

This thread isn't the officially designated anything, really, but if you want to be sure your questions are seen by one of the devs this is the place to post (most of us do prowl the rest of the forums from time to time as well, though). You can chill here as much as you want and ask about whatever you like, as long as you take off your shoes before entering and don't act like a dick.

As for your problem: as I posted in the other thread, it turns out libavcodec doesn't support interlaced VC-1 at all (yet), so unfortunately we cannot help you. You'll have to turn to some other source plugin.

[qyot27]

When cross-compiling the C plugin, the recent version.sh-related changes result in the .dll being built as ffms.dll instead of ffms2.dll. On Windows this isn't an issue, because of MSys' bash quirks or file permissions for NTFS always being executable or something.

This is the problematic section:
version=`version.sh`
API=$(echo $version | cut -f 1 -d '.')
On Linux, this results in version.sh not being found when configure gets called (so the version info is left blank and the '2' isn't inserted into the filename of the .dll), and even when having used chmod +x on version.sh, it seems to still not want to add it as an environment variable.

I managed to fix it (and have it work on both Windows and Linux), by commenting out the version ENV line and adjusting the API variable to use version.sh's filename directly:
#version=`version.sh`
API=$(echo $(./version.sh) | cut -f 1 -d '.')

[kemuri-_9]

oops -> fixed

[henryho_hk]

why not simply

API=$(./version.sh | /bin/cut -f 1 -d '.')

[Chumbo]

I'll probably get to it later today or tomorrow.
Thank you.

[TheRyuu]

ffms-2.16-x64.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16-x64.7z) - 64-bit version, for use with avs64. Note that it is a native Avisynth plugin now; no need for LoadCPlugin or LoadStdcallPlugin
ffms-2.16_SDK.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16_SDK.7z) - updated to now include the 64-bit stuff.

Little late.
Have at it.

[Chumbo]

ffms-2.16-x64.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16-x64.7z) - 64-bit version, for use with avs64. Note that it is a native Avisynth plugin now; no need for LoadCPlugin or LoadStdcallPlugin
ffms-2.16_SDK.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16_SDK.7z) - updated to now include the 64-bit stuff.

Have at it.
Very much appreciated.

[Chumbo]

It seams, a 64-bit version creates incorrect indexes. I get audio position error messages or program response lost (most cases) using VirtualDub. My videos are x264-10bit encoded .mkv with a pcm audio ~ 15-30 minutes and joined using v1++v2++v3++v4... I cannot change a view position in all cases. Deleting of index files do not resolve the situation - seems indexes are not valid.

A x86 version works as charm. Also in some cases a 64 bit version uses a 32-bit-generated index files. Also switching an edition produces every reindex. It is very bad, because eats a time. Please do not overwrite existing indexes, if they are exist and creates by a wrong edition. Create a new one with a different extension or save a new portion in the same file. Or (the best solution) - use the same file format for x64 and x86 edition.

So, I returned to x86 with temp lossless files :(
It shouldn't overwrite an existing index file unless you're using the -f switch.

[TheRyuu]

Also in some cases a 64 bit version uses a 32-bit-generated index files.
Are you sure about this? It should never happen (it will detect the incompatibility and reindex).

use the same file format for x64 and x86 edition.
Indeed. It's been suggested before but no real work has been done on it yet.

It shouldn't overwrite an existing index file unless you're using the -f switch.
If you directly use ffvideosource it will overwrite without asking.

[TheFluff]

It seams, a 64-bit version creates incorrect indexes. I get audio position error messages or program response lost (most cases) using VirtualDub. My videos are x264-10bit encoded .mkv with a pcm audio ~ 15-30 minutes and joined using v1++v2++v3++v4... I cannot change a view position in all cases. Deleting of index files do not resolve the situation - seems indexes are not valid.

A x86 version works as charm. Also in some cases a 64 bit version uses a 32-bit-generated index files. Also switching an edition produces every reindex. It is very bad, because eats a time. Please do not overwrite existing indexes, if they are exist and creates by a wrong edition. Create a new one with a different extension or save a new portion in the same file. Or (the best solution) - use the same file format for x64 and x86 edition.

So, I returned to x86 with temp lossless files :(

Provide a sample file.

Regarding indexes: neither the Avisynth plugin nor ffmsindex.exe will treat an index file that was created with a different architecture as valid. As far as they are concerned the index file might as well never have existed at all. Thus, such an index file will always be silently overwritten.
Valid index files that were created with the same version of FFMS2 as the one doing the reading do have some degree of protection, but only if you specified the filename for the index file explicitly. Otherwise they too will be overwritten if they don't match the media file.

[TheFluff]

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.

I've downloaded the files but I won't have time to investigate until Sunday. I'll get back to you if nobody else has found the bug by then.

[Chumbo]

...
Indeed. It's been suggested before but no real work has been done on it yet.
...
+1 to use the same file format for both x86/x64 please.
If you directly use ffvideosource it will overwrite without asking.
Would you kindly add this to the "wish list" to change please so ffvideosource would not recreate the index file automatically? So right now there's no point to use the CLI if using ffvideosource. Maybe add an input parameter to ffvideosource force recreating the index which defaults to not doing so if the file already exists. Thank you.

[Myrsloik]

+1 to use the same file format for both x86/x64 please.

Would you kindly add this to the "wish list" to change please so ffvideosource would not recreate the index file automatically? So right now there's no point to use the CLI if using ffvideosource. Maybe add an input parameter to ffvideosource force recreating the index which defaults to not doing so if the file already exists. Thank you.

Hint: just specify the index name if you really have to mix stuff like that

Also, x86/x64 will probably never use the same index format or at least the work for doing so would require reading piles of libav code to check so it really does behave identically

[TheFluff]

Another bug. I use my function FF_Clip() from my previous bugreport with an x86 version.
I get "FFVideoSource: Insanity detected: decoder returned an empty frame" after this code:

SelectRangeEvery(50, 1, 0, false)

and some processing time on every my h264 source.

That (probably) isn't really a bug in FFMS2. The error message means exactly what it says: libavcodec returned a video frame object with no actual image data in it. Prior to 2.16 the behavior with such frames was to just crash.

Sometimes you can make this problem go away by setting threads=1.

edit: since you're already wrapping ffvideosource() etc and are dynamically loading ffms2.dll, it'd be pretty simple for you to add a global "is_x64" variable and add an arch-specific filename suffix to the index files based on that. That'd at least solve your problems with index files overwriting each other.

[TheFluff]

But they are really exist. I able to point to the bug-catched fame by direct point in vdub using a timeline. This message is only when I process frames from one to one.

I don't doubt that you're having the issue, I'm just saying that the bug is probably inside libavcodec, not in FFMS2 itself. Try with threads=1 as I suggested and see if the issue is still there.

I haven't had time to look at your samples yet, but I'll do that Soon(tm).

[TheRyuu]

ffms2-r555.7z (http://ffmpegsource.googlecode.com/files/ffms2-r555.7z)

Libav 273aab9
Most notable change is a fix in libav for unbreaking certain VC1 decoding.

[Midzuki]

ffms2-r555.7z (http://ffmpegsource.googlecode.com/files/ffms2-r555.7z)

Libav 273aab9
Most notable change is a fix in libav for unbreaking certain VC1 decoding.

:goodpost:

and

:thanks: :thanks: :thanks:

[TheRyuu]

ffms2-2.16-avs-cplugin.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=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.

[TheRyuu]

ffms2-r559.7z (http://ffmpegsource.googlecode.com/files/ffms2-r559.7z)

Libav 3a78fb5

More correct handling of colorspace/range flags. No longer rescales fullrange to limited range.

[TheFluff]

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.

[Chumbo]

ffms2-r559.7z (http://ffmpegsource.googlecode.com/files/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.

[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 (http://mod16.org/ffms2/ffms-r561+10-bithack.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:
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.

[jmac698]

@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,

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).

[mp3dom]

RawSource 2.6 is for AviSynth 2.6.
The version for AviSynth 2.58 is here: http://www.mediafire.com/?3bmwyi1lztt4h1j

[kolak]

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 (http://mod16.org/ffms2/ffms-r561+10-bithack.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:
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?

[TheFluff]

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.

[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)

[kolak]

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

[TheFluff]

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.

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.

[kolak]

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:

http://forum.doom9.org/showthread.php?p=1528674#post1528674

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

[cretindesalpes]

Suggested modification, just by looking at the patch code. I not even tried to compile it:
// 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.

[TheFluff]

Suggested modification, just by looking at the patch code. I not even tried to compile it:
// 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.

[kolak]

Can you compile it with these fixes, please.

Thanks,
Andrew

[jmac698]

Kolak, I made a new readv210.

[kolak]

Where :)?
Saw one but it was only for grayscale not?