FFmpegSource

[TheFluff]

I'm fairly new to using ffms2, but I just discovered something simple that seems impossible: I can't open a 5.1 and make it dolby stereo. There is no way to downmix to DPL/2. Also can you add a simple feature in the PP string for contrast adjust on import, cont:100
You have functions to support different colorspaces so don't ignore audio.

FFMS2 does not support any channel mixing operations at all, because libavcodec doesn't support that sort of stuff either. Adding some simple audio processing options such as resampling, bitdepth conversion and channel mixing (either via an external library or via our own code) has been on the todo list for a long time. The reason we support colorspace conversion and resizing is that ffmpeg comes with libswscale.

Video postprocessing is mostly the same thing, it's provided via libpostproc and we don't have any control over what features it supports. Not that it matters, because the ffmpeg devs hate it and are going to remove it, and thus so are we.

[TheFluff]

On all mpeg2 I can have (dvd rips, dvb recordings, fresh HCEnc encodes...),
this script does show something wrong :

a=mpeg2source("v.d2v") # or avisource("v_uncompressed_by_virtualdub.avi")
b=ffvideosource("v.mkv") # muxing the stream in a mkv does fix the ffms2 frame inaccuracy
subtract(a,b)
histogram("luma") # needed for humans eyes



I remember when testing some ffdshow settings, I did try the "use speedup tricks" and got some funky pixels like that (but much more visible).
Dunno if it is related since both ffms2 and ffdshow use ffmpeg.

If that's supposed to be a bug report I'll have to say it's a remarkably bad one. At least have the decency to include a sample file and a screenshot.

That being said, AFAIK MPEG2 decoders are not required to have bit-exact output so it's not entirely surprising that two different decoders could have subtly different outputs.

[MatLz]

If that's supposed to be a bug report I'll have to say it's a remarkably bad one. At least have the decency to include a sample file and a screenshot.
On all mpeg2 I can have (dvd rips, dvb recordings, fresh HCEnc encodes...)


That being said, AFAIK MPEG2 decoders are not required to have bit-exact output so it's not entirely surprising that two different decoders could have subtly different outputs.Dunno... I thought they should output identical thing, like avc ones do.

[TheRyuu]

Dunno... I thought they should output identical thing, like avc ones do.

iDCT bro.

[TheFluff]

Dunno... I thought they should output identical thing, like avc ones do.

MPEG2 does not specify exactly how the IDCT algorithm should work. Bit-exact decoding is not required. Ever noticed how you can choose between like five different IDCT algorithms in DVD2AVI? Yeah, all of those give different outputs.

See also http://guru.multimedia.cx/the-mpeg124-and-h26123-idct/

[LigH]

Something similar (but not related to iDCT) happened between DivX 5.02 and 5.03 too, probably a change in the rounding (Oct. 2003 (http://forum.doom9.org/showthread.php?p=384974#post384974)). That resulted in what I called "orange-blue bug". But quite soon after I reported it (March 2004 (http://forum.doom9.org/showthread.php?p=458322#post458322)), ffdshow was able to adapt its decoding.

[TheFluff]

The MeGUI thread (http://forum.doom9.org/showthread.php?p=1532631#post1532631) discusses an issue with FFindex which crashes on uncompressed YUY2 / YV12 videos — not only with dozens of GB in size.

I don't think you ever got an official reply to this, but Chikuzen is correct; FFMS2 does not support uncompressed formats (because libavcodec handles them weirdly). Crashes are possible. Indexing such files should work just fine, but when I checked the MeGUI threa I did not see any indications that it's the indexing process itself that is crashing.

[TheFluff]

Something similar (but not related to iDCT) happened between DivX 5.02 and 5.03 too, probably a change in the rounding (Oct. 2003 (http://forum.doom9.org/showthread.php?p=384974#post384974)). That resulted in what I called "orange-blue bug". But quite soon after I reported it (March 2004 (http://forum.doom9.org/showthread.php?p=458322#post458322)), ffdshow was able to adapt its decoding.

Since you apparently need histogram("luma") to even see the differences MatLz is speaking of, it does not appear to be an issue of anywhere near that magnitude.

[MatLz]

The real visible things without enhancing the luma differences are mostly in flat areas.

Thx for the explanations.

Btw, could be possible to easily implement the ffms2 idct algorithm in mpeg2source ?
Using 1 thread (to be fair) does show it is 20% faster.

[TheRyuu]

The real visible things without enhancing the luma differences are mostly in flat areas.

Thx for the explanations.

Btw, could be possible to easily implement the ffms2 idct algorithm in mpeg2source ?
Using 1 thread (to be fair) does show it is 20% faster.

DGDecode or Mpeg2Dec3 are the recommended methods for sourcing mpeg2 material. For VOBS and transport streams I would trust them more than ffms2.

You get something like 6-7 different iDCT options with both DGDecode and Mpeg2Dec3. They both default to whatever is found in the d2v file but can be overridden in avisynth. DGIndex defaults to Skal SSE and DVD2AVI defaults to SSE2MMX. The one most like libav's default is probably Simple iDCT although that's just a guess based on libav's naming of a constant.

Mpeg2Dec3 is normally faster than DGDecode especially when seeking. I prefer DVD2AVI's default choice (with mpeg2dec3) for all things mpeg2. YMMV and opinions also.

[LigH]

@ TheFluff:

1) Yes, we found out that one can make MeGUI use AviSource by pressing the button "DirectShowSource". Great feature, but surprising. That button might need a better title (e.g. [ DirectShow / VfW ] or similar).

2) Yes, iDCT differences are usually extremely minor. I already wonder how the linked thread was able to produce an example with such obvious green streaks.

[TheRyuu]

Same issue. Does anyone can confirm this ?
I used build 579.
Thanks.

Cannot reproduce (http://puu.sh/82Iq) with r579 or one which was just compiled (which would have an updated libav).

With the lastest beta r580, if I try to set the output format (with FFMS_SetOutputFormatV or FFMS_SetOutputFormatV2) to any planar format (I tested all) the program crashes with a memory violation (trying to write in protected area). I tested with non planar formats (rgb & yuv) and it worked.

Well the avisynth portion of ffms2 calls the same function and uses planar formats fine all the time (yv12). Could you if possible post the code in question which calls FFMS_SetOutputFormatV2?

[Mr VacBob]

You get something like 6-7 different iDCT options with both DGDecode and Mpeg2Dec3. They both default to whatever is found in the d2v file but can be overridden in avisynth. DGIndex defaults to Skal SSE and DVD2AVI defaults to SSE2MMX. The one most like libav's default is probably Simple iDCT although that's just a guess based on libav's naming of a constant.

Simple MMX is the libav default idct. It's called "XviD simple mmx" in some other places, but Xvid doesn't actually use it, it's just there but unused in the Xvid source.

The fastest idct available is libav's "xvidmmx", which is actually a version of Skal SSE2 which I/Michael optimized further. It's the default in libav for Xvid content but not for MPEG2.

If someone wants to write an even faster idct SSE4 has some nice instructions for it…

[pandv2]

Sorry for the delay. I get bussy.

This is the code used to activate a planar format, is c#:

int[] TargetFormat = new int[2];
TargetFormat[0]=FFMS_GetPixFmt(fmt);
TargetFormat[1]=-1;
fixed (char* msg = ErrorMsg)
{
Error.Buffer = msg; //Attempted to read or write protected memory.
ret = FFMS_SetOutputFormatV2(VideoSource, TargetFormat, TheWidth, TheHeight, 1, ref Error);
if (ret != 0) throw new Exception("FFmpegSource2 error en SetOutputFormat." + new string((sbyte*)Error.Buffer));
}

The values for vars are:
VideoSource (a created object. It works in rgb32 format).
fmt = "nv12" (yv12 is not a valid format name)
TheWidth = 64 (not the original width)
TheHeight = 64 (not the original height)

If I use fmt="rgb32" it works, only if i use a planar format it crashes with "Attempted to read or write protected memory"

With past versions the same code works. This happens with beta r580.

[pandv2]

add sanity check for cases where the video decoder returns an empty frame.

I get this error in a video (in 2 frames), but previously (2.15 version) the same video (same file, not touched) decodes ok. FFMS2 doesn't crash.
I am using the library. Not avisynth.

That's not good at all and sounds like a regression in either FFMS2 or libavcodec. Can you provide a sample file?

I uploaded a sample. The url is:

https://rapidshare.com/files/2847794572/SupTest.avi

The error happens in the frames 298 & 744 (0 based).

[TheFluff]

Sorry for the delay. I get bussy.

This is the code used to activate a planar format, is c#:

int[] TargetFormat = new int[2];
TargetFormat[0]=FFMS_GetPixFmt(fmt);
TargetFormat[1]=-1;
fixed (char* msg = ErrorMsg)
{
Error.Buffer = msg; //Attempted to read or write protected memory.
ret = FFMS_SetOutputFormatV2(VideoSource, TargetFormat, TheWidth, TheHeight, 1, ref Error);
if (ret != 0) throw new Exception("FFmpegSource2 error en SetOutputFormat." + new string((sbyte*)Error.Buffer));
}

The values for vars are:
VideoSource (a created object. It works in rgb32 format).
fmt = "nv12" (yv12 is not a valid format name)
TheWidth = 64 (not the original width)
TheHeight = 64 (not the original height)

If I use fmt="rgb32" it works, only if i use a planar format it crashes with "Attempted to read or write protected memory"

With past versions the same code works. This happens with beta r580.

It's sort of hard to tell what's going on because you didn't include how you're allocating ErrorMsg but I'm betting that the problem is related to that in one way or another and not to the actual call to FFMS_SetOutputFormatV2.

[pandv2]

It's sort of hard to tell what's going on because you didn't include how you're allocating ErrorMsg but I'm betting that the problem is related to that in one way or another and not to the actual call to FFMS_SetOutputFormatV2.

I thinked this intially, too. But the error happens in the call to FFMS_SetOutputFormatV2 (or FFMS_SetOutputFormatV, I tried this also). Only happens with planar formats. Never with other formats. And if I pass a invalid value (as "YV12"), i get a correct error message in the msg buffer.

The error happens in the line calling FFMS_SetOutputFormatV2 (the comment is in the above line because there is more space).

This is the msg initialization (at class level).

private char[] ErrorMsg= new char[2050];

And this is the Error Object initialization (in the constructor):

public FFVideo()
{
Error = new FFMS_ErrorInfo();
Error.ErrorType = 0;
Error.SubType = 0;
Error.BufferSize = 1024;
}


And, I am currently using the version dated Oct, 19, because this version works without this problem.

[pandv2]

Triyng to investigate if the bug is in my code or in the library, I tried your sample code directly in C++ (Visual Studio 2010). From:

http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-api.html

First, there are 2 typos:

original: int pixfmts[2];
corrected: int pixfmt[2];

original: const FFMS_Frame *propframe = FFMS_GetFrame(videosource, 0, errinfo);
corrected: const FFMS_Frame *propframe = FFMS_GetFrame(videosource, 0, &errinfo);

I used the sample file uploaded to rapidshare messages ago.

The sample compiles and runs ok.

But, if I change the line:
pixfmt[0] = FFMS_GetPixFmt("bgra");

to:
pixfmt[0] = FFMS_GetPixFmt("nv12");

I get this error:
Unhandled exception at 0x0f42dc24 in TestFFMS2.exe: 0xC0000005: Access violation reading location 0xffffffff

The error happens in the call to FFMS_SetOutputFormatV2.

(using the dll from version r580).

So, I think there are a bug in the library.

Many thanks for your work. My level of english is not good, and sometimes my simple writing can be confused with rudeness. It's not.

[[DB-FR] Nikko]

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.


I had the same problem since the 2.16 version, insanity detected randomly. I tested threads=1 on 5 h264 sources and I have no error anymore, so this trick seems to work until now ^^

Thx TheFluff !

[qyot27]

I've been experiencing an odd behavior with ffmsindex's progress meter. If I give it an MKV file, the progress is updated correctly. But for other types of files - I tried MOV, MP4, FLV, and even a couple AVIs I tested out of curiosity - it doesn't. It stays at 0% until it's finished, upon which it jumps to 100% and then exits normally. The strange thing is that I tried the C-plugin build of 2.16 on googlecode and it showed progress updates for those kinds of files just fine. So I go and checkout a revision from that point in time and compile it locally. It doesn't update. I tried changing the configuration for the libraries to [mostly*] fit what the working one used, nothing. Switched between using w32threads and pthreads, switched between branches of FFmpeg/libav, still nothing. In all of these cases the files used H.264, except for the AVIs, which were ASP and ffvhuff.

*I omitted the AMR stuff and changed the target CPU to pentium3. I think that was it.

The actual indexes that ffmsindex writes for these files seem fine, so I don't know if it's something ffmsindex-centric or if it was caused by some change in libavformat that doesn't affect MKV, or if it's another gcc-related issue.

It seems to occur on *all* files of those container types, and I noticed it both on my normal setup (the old PIII-based Celeron) with several revisions, including r582, and on a laptop that has a Core 2 Duo T5450 in it (and that build of FFMS2 is from the middle of October). Even if the file involved was 7.5 minutes long and 848x480. I took an MKV and remuxed it to MP4: the MKV shows update progress, the MP4 doesn't (the MP4's index file is also almost half the size of the MKV's, but I assume that's just because of the difference in how the indexing manages different containers).

If it helps, this is a debug build affected by the issue:
http://www.mediafire.com/?8axqb47gjfr7j5x

[TheFluff]

Sounds like whatever libav version you use has broken the byte position reporting that we use for reporting indexing progress. Are you using libav or ffmpeg? What version?

For MKV, FFMS2 will always use Haali's matroskaparser.c rather than lavf, unless you explicitly tell it to use lavf, so that's why it's not affected.

[the_weirdo]

Maybe because of this:
http://git.libav.org/?p=libav.git;a=commit;h=c10731e78b3ed89090b808b0919947f5729841c3
lavf: deprecate AVFormatContext.file_size

[qyot27]

That particular debug build is using FFmpeg git-4b7ef5a, from November 8th. The libav test was yesterday morning. It was whatever the latest revision was at the time. When I saw that it exhibited the same issue I just deleted it without taking note of the exact version. Generally I update to the latest git right before compiling FFMS2, but I don't know exactly when this cropped up, except obviously some time after 2.16 was committed.

I don't know why I forgot that the default MKV demuxer isn't lavf.

Maybe because of this:
http://git.libav.org/?p=libav.git;a=...9947f5729841c3
lavf: deprecate AVFormatContext.file_size
Yeah, I think it is. I went to a backup I have of a build from October 16th, and sure enough, it has no issue with the progress meter.

[TheFluff]

Maybe because of this:
http://git.libav.org/?p=libav.git;a=commit;h=c10731e78b3ed89090b808b0919947f5729841c3
lavf: deprecate AVFormatContext.file_size

That sounds like it, yep.

[TheRyuu]

Fixed in r584 (http://code.google.com/p/ffmpegsource/source/detail?r=584).

[forclip]

How about adding an option to ffmsindex.exe and to FFIndex, that will turn on\off this "file signature check" (off = everything works as before r580)? And then FFMS2.avsi can be modified to call FFIndex without this check, so FFmpegSource2() will work as before r580. At least for me with my workflow I would like to have such an option for ffmsindex and for ffindex..

So what?

[the_weirdo]

First, please excuse for my poor English. I'm not sure I can explain the problem clearly as my English is not good enough to express my thought.

Recently, after this commit (http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=26ae9a5d7c448a3eb42641b546ee8d585ab716e6), I've noticed FFMS2 build that linked against ffmpeg's lavc/lavf seems to have a timestamp issue. It seems there're delayed frames (number of delayed frames is number of decoding threads -1). I only tested with H.264 in MKV and MP4, so I don't know if this happens with other video formats or not. Because offical builds are linked againt libav's lavc/lavf so I thought nobody actually care about it, and I've switched to use libav for my builds. But now, libav have that commit (http://git.libav.org/?p=libav.git;a=commit;h=0945eddec09d1c2b69643afc70377d86febc0591) too, so I think I should report it.

I added a series of images to demonstrate this issue. Top images are decoded by FFMS build that linked against libav before that commit, while bottom images are decoded by the build after that commit. (There's a Textsub line with a timed ASS so you can easily see the issue).
http://thumbnails33.imagebam.com/16083/c666cf160825811.jpg (http://www.imagebam.com/image/c666cf160825811) http://thumbnails62.imagebam.com/16083/36824c160825846.jpg (http://www.imagebam.com/image/36824c160825846) http://thumbnails46.imagebam.com/16083/9740cb160825873.jpg (http://www.imagebam.com/image/9740cb160825873) http://thumbnails61.imagebam.com/16083/27b4c1160825933.jpg (http://www.imagebam.com/image/27b4c1160825933) http://thumbnails33.imagebam.com/16083/a16ffb160825974.jpg (http://www.imagebam.com/image/a16ffb160825974)
http://thumbnails22.imagebam.com/16083/8dff91160826010.jpg (http://www.imagebam.com/image/8dff91160826010) http://thumbnails50.imagebam.com/16083/a90217160826045.jpg (http://www.imagebam.com/image/a90217160826045) http://thumbnails33.imagebam.com/16083/fe0295160826098.jpg (http://www.imagebam.com/image/fe0295160826098) http://thumbnails27.imagebam.com/16083/bfcafc160826140.jpg (http://www.imagebam.com/image/bfcafc160826140) http://thumbnails47.imagebam.com/16083/4cd064160826173.jpg (http://www.imagebam.com/image/4cd064160826173)

[jmac698]

I'm trying to open an interlaced ts, avc, and the frames are coming in some nearby but not sequential order (more like decode order maybe). ffdshow/directshowsource doesn't work (grey screen). I don't know how to open this.

[TheRyuu]

I'm trying to open an interlaced ts, avc, and the frames are coming in some nearby but not sequential order (more like decode order maybe). ffdshow/directshowsource doesn't work (grey screen). I don't know how to open this.

dgdecodenv/di.

Workarounds are provided in the ffms2 documentation to get interlaced stuff working sometimes but it is unreliable. The neuron2 stuff is the only reliable and guaranteed frame accurate way currently.

Workarounds suggested: specifying fpsnum/fpsden, threads=1, lavf demuxer, seekmode=-1 or 0.

[TheRyuu]

Well three weeks later and it's fixed (http://code.google.com/p/ffmpegsource/source/detail?r=588).

ffms2-r588.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms2-r588.7z)

It should now perfectly emulate the old behavior of has_b_frames (which is a little funky to begin with I suppose). The problem commit (http://git.libav.org/?p=libav.git;a=commit;h=0945eddec09d1c2b69643afc70377d86febc0591) as mentioned before caused the thread count to no longer get added as an additional delay which caused frame accuracy issues (off by number of threads - 1).

I tested it on a limited number of things and it appeared to work correctly but feel free to test it out and report any issues you find with it.

[the_weirdo]

Thanks for the fix :thanks:

[TheRyuu]

Thanks for the fix :thanks:

It's not really fixed so consider it still broken! :D

[qyot27]

I've been working around this for a while now, but including r583 in a merge causes the C plugin to fail compilation. Leaving it out sidesteps the error and allows it to finish successfully.

svn merge http://ffmpegsource.googlecode.com/svn/trunk
C plugin compilation fails.

svn merge -r 583:head http://ffmpegsource.googlecode.com/svn/trunk
C plugin compilation succeeds.

[TheRyuu]

I've been working around this for a while now, but including r583 in a merge causes the C plugin to fail compilation. Leaving it out sidesteps the error and allows it to finish successfully.

svn merge http://ffmpegsource.googlecode.com/svn/trunk
C plugin compilation fails.

svn merge -r 583:head http://ffmpegsource.googlecode.com/svn/trunk
C plugin compilation succeeds.

Feel free to just keep it reverted locally, the problem which it was designed to fix only affects shared libs on linux as far as I know.

[qyot27]

Turns out the compilation error I was seeing was due to codectype.cpp not getting inserted into the Makefile, and so it was screwing up during the linking phase. Once I did that, it actually matched Issue 64 and so I just ifdeffed around UTVIDEO and it finished without errors. I'll need to use a fresh set of libs and see if that's still needed; the ones I used for the test were lying around from September, so it's no real wonder that Ut Video would be an issue for it.

[redfordxx]

Hi, according to my observation, there seems to be problem with pp="hb/vb:10:60" on non mod16 files.
My source was 712x360.x264.mkv (it shows wrong colors on left side, seems to be 8 pixels width...surprisingly)

Or is it only me?

But besides that, thank you for the fabulous tool.

[TheFluff]

Postprocessing is deprecated and will be removed in a future release (probably 2.18). Even if it wasn't, it's not our code so you'd have to complain to the FFmpeg people. They're going to remove libpostproc though, which is why we are deprecating it in the first place.

[redfordxx]

Too bad ... afaik FF makes deblocking based on info about quantization of the block, which is not possible later in the script.
So there will be no deblocking anymore? I thought the deblocking is part of the codec in case of AVC...

[kemuri-_9]

libpostproc is a completely independent framework of any decoder, therefore it has no information that a decoder could possibly offer to 'make the processing better'.

As such, libpostproc's deblocking and the deblocking within the h264 standard are distinct.

[burfadel]

Any new builds? :)

[TheFluff]

Any new builds? :)

Not at this very moment, but 2.17 is going to be released Real Soon Now.

[redfordxx]

libpostproc is a completely independent framework of any decoder

I see, so I thought it wrong all the time and it is not like MPEG2Source(cpu=4). I hope at least in that MPEG2 case I am correct when saying the deblocking is based on the quant information ;-)

[TheFluff]

I see, so I thought it wrong all the time and it is not like MPEG2Source(cpu=4). I hope at least in that MPEG2 case I am correct when saying the deblocking is based on the quant information ;-)

kemuri_-9 is at least partially wrong; while libpostproc is completely standalone, the pp_postprocess() function has parameters for passing in quantizer info, and FFMS2 does pass that information on from the decoder if it's available. I'm not sure exactly which decoders fill the quantizer tables in, but I'm pretty sure MPEG2 does, at least. So libpostproc can do quantizer-based deblocking for some codecs, just like MPEG2Source.

The h.264 inloop deblocking filter is a completely unrelated thing though, it's actually part of the decoding process and is implemented inside the decoder itself. Skipping it is technically a violation of the specification.

[TheRyuu]

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

It's the first proper build since 2.16 (proper meaning non-broken) and it's some what of a release candidate for 2.17 so all it really needs is a few days of testing by the masses. Built with libav rev. cf53a21.

Some changes to look forward to:

Reworked colormatrix and color range handling a bit, which fixed a bug that could cause FFMS2 to always output TV range even if the input was fullrange. (TheFluff)
The autotools build system can now create debug builds properly. (Daemon404)
Deprecated parts of the API will now cause compiler warnings when you use them. (TheFluff)
Added a FFMS_GetVersion function to the API (lets library users get the version number at runtime) and exposed it in Avisynth as FFGetVersion. (TheRyuu, TheFluff)
Added a variable prefix option to the Avisynth functions. Its primary purpose is to get subsequent calls to source functions from overwriting variables from earlier calls. (TheFluff)
Make it possible to open single-frame videos without explicitly setting seekmode to -1 for you weird people who want to open images with ffms (Plorkyeran)
Fixed bug where indicies would sometimes be incorrectly considered valid (TheRyuu)
Add support for recent versions of libav/ffmpeg built as shared libraries (Plorkyeran, TheRyuu, Kovensky)
When possible, non-API symbols are no longer exported (Daemon404)
Deprecate postproc support. Libav and FFmpeg will probably kill it at some point in the future and it's really not very useful.
Fix the pkg-config version on OS X (Plorkyeran).
General bitrot fixes to deal with changes in Libav/FFmpeg
Bump minimum required version of FFmpeg to 0.6.


Additionally there is some internal reworking of the way CodecID's work (now stored at indexing instead of the whole table shenanigans) and also the major threading problems caused by changes in libav and ffmpeg have been addressed so ffmpegsource should now work correctly with more recent versions. Plus the usual couple hundred bug fixes and what not.

[Yellow_]

I have a query which relates a little to the first entry, "Reworked colormatrix and color range handling a bit..."

Following that 'discussion' on a thread recently about lossless codecs and problems with ffmpeg on the CLI transcoding full range h264 in a mov to restricted range in other codecs including lossless codecs because ffmpeg treats the mov's a yuvj420p, is there anything to be concerned about with ffmpegsource2 in this regard?

Omitting v2.16 as that does the TV thing, 2.15 not so.

[TheFluff]

I have a query which relates a little to the first entry, "Reworked colormatrix and color range handling a bit..."

Following that 'discussion' on a thread recently about lossless codecs and problems with ffmpeg on the CLI transcoding full range h264 in a mov to restricted range in other codecs including lossless codecs because ffmpeg treats the mov's a yuvj420p, is there anything to be concerned about with ffmpegsource2 in this regard?

Omitting v2.16 as that does the TV thing, 2.15 not so.

Don't know, test it and find out. If it doesn't work file a bug report.

[Yellow_]

Ok, will do. :-)

Are you aware of anything that could occur with IQ incorrectly interpreting yuv420P as yuvj420P?

[TheFluff]

Ok, will do. :-)

Are you aware of anything that could occur with IQ incorrectly interpreting yuv420P as yuvj420P?

What do you mean by "IQ"? I think I've fixed the handling in FFMS2 so it should always give correct results now, but as I said, please test any funny files you might have.

Edit: for reference, FFMS2 now behaves like this: if the input pixel format is one of the YUVJ* ones, the video is assumed to be fullrange, regardless of what the CodecContext->color_range metadata flag might say. For all other pixel formats, FFMS2 uses whatever the CodecContext->color_range flag says. If that's unspecified, limited range is assumed.

[burfadel]

Build r624 seems to not like certain .mkv files whereas r588 has no issues... When remuxed the offending .mkv files with mkvtoolnix v5.2.1 r309 they worked with r624, but I ommitted the subtitle and chapter info...

[TheFluff]

Build r624 seems to not like certain .mkv files whereas r588 has no issues... When remuxed the offending .mkv files with mkvtoolnix v5.2.1 r309 they worked with r624, but I ommitted the subtitle and chapter info...

What exactly do you mean by "not like"? What happens? Can you provide a sample file?