FFmpegSource - Page 70

the_weirdo · 13th December 2011, 09:18

Thanks for the fix

TheRyuu · 21st December 2011, 14:16

Quote:

Originally Posted by the_weirdo

Thanks for the fix

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

qyot27 · 23rd December 2011, 13:21

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.

Code:

svn merge http://ffmpegsource.googlecode.com/svn/trunk

C plugin compilation fails.

Code:

svn merge -r 583:head http://ffmpegsource.googlecode.com/svn/trunk

C plugin compilation succeeds.

TheRyuu · 23rd December 2011, 15:08

Quote:

Originally Posted by 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.

Code:

svn merge http://ffmpegsource.googlecode.com/svn/trunk

C plugin compilation fails.

Code:

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 · 23rd December 2011, 16:45

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 · 5th January 2012, 22:52

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 · 6th January 2012, 18:31

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 · 9th January 2012, 21:55

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 · 10th January 2012, 01:21

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 · 10th January 2012, 07:46

Any new builds?

TheFluff · 10th January 2012, 09:34

Quote:

Originally Posted by burfadel

Any new builds?

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

redfordxx · 10th January 2012, 12:54

Quote:

Originally Posted by kemuri-_9

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 · 10th January 2012, 13:58

Quote:

Originally Posted by redfordxx

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 · 11th January 2012, 13:57

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_ · 11th January 2012, 14:14

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 · 11th January 2012, 14:50

Quote:

Originally Posted by 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.

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

Yellow_ · 11th January 2012, 14:56

Ok, will do. :-)

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

TheFluff · 11th January 2012, 15:09

Quote:

Originally Posted by Yellow_

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 · 11th January 2012, 15:20

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 · 11th January 2012, 16:02

Quote:

Originally Posted by 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...

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

23rd December 2011, 13:21	#1383 \| Link
qyot27 ...? Join Date: Nov 2005 Location: Florida Posts: 1,420	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. Code: svn merge http://ffmpegsource.googlecode.com/svn/trunk C plugin compilation fails. Code: svn merge -r 583:head http://ffmpegsource.googlecode.com/svn/trunk C plugin compilation succeeds.

5th January 2012, 22:52	#1386 \| Link
redfordxx Registered User Join Date: Jan 2005 Location: Praha (not that one in Texas) Posts: 863	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. __________________ Camera rotation script RedAverage plugin Last edited by redfordxx; 5th January 2012 at 23:03.

9th January 2012, 21:55	#1388 \| Link
redfordxx Registered User Join Date: Jan 2005 Location: Praha (not that one in Texas) Posts: 863	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... __________________ Camera rotation script RedAverage plugin

10th January 2012, 01:21	#1389 \| Link
kemuri-_9 Compiling Encoder Join Date: Jan 2007 Posts: 1,348	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. __________________ custom x264 builds & patches \| F@H \| My Specs

11th January 2012, 13:57	#1394 \| Link
TheRyuu warpsharpened Join Date: Feb 2007 Posts: 787	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.

13th December 2011, 09:18	#1381 \| Link
the_weirdo Yes, I'm weird. Join Date: May 2010 Location: Southeast Asia Posts: 271	Thanks for the fix

23rd December 2011, 16:45	#1385 \| Link
qyot27 ...? Join Date: Nov 2005 Location: Florida Posts: 1,420	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.

6th January 2012, 18:31	#1387 \| Link
TheFluff Excessively jovial fellow Join Date: Jun 2004 Location: rude Posts: 1,100	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.

10th January 2012, 07:46	#1390 \| Link
burfadel Registered User Join Date: Aug 2006 Posts: 2,229	Any new builds?

11th January 2012, 14:14	#1395 \| Link
Yellow_ Registered User Join Date: Sep 2009 Posts: 378	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.

11th January 2012, 14:56	#1397 \| Link
Yellow_ Registered User Join Date: Sep 2009 Posts: 378	Ok, will do. :-) Are you aware of anything that could occur with IQ incorrectly interpreting yuv420P as yuvj420P?

11th January 2012, 15:20	#1399 \| Link
burfadel Registered User Join Date: Aug 2006 Posts: 2,229	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...