x264 LAVF/FFMS input public beta test (v2.1) - Page 4

roozhou · 4th January 2010, 13:22

Quote:

Originally Posted by Selur

Sad. Hoped for an easy way to create vfr files from cfr input in linux (without needing wine and avisynth) by:
1. reencode input with x264 (creating a .264 and a timecode file)
2. convert audio (creating a bunch of .mp3, .aac, .ac3 files)
3. multiplex subtitles, audio, video with the timecode file and a bunch of tags

Would it be hard to output mp4 time code files?

You don't need it because we have ffmpeg. Timecodes are only needed when you are using outdated frameworks that does not correctly handle timestamps.(e.g. avisynth, vfw)

1. encode input with x264 and create a vfr mp4
2. convert audio
3. multiplex subtitle, audio and video using ffmpeg

I know there are several bugs in ffmpeg's muxers, but one day ffmpeg will handle all these things.

bob0r · 10th January 2010, 15:00

Patch used: "x264.LAVF.FFMS.input.public.beta.test.v2.2.diff", it's not public and probably not v2.2 eighter, i just saved it as 2.2 instead of 2.1 (laziness).
This patch was given to me by Dark to fix a x264 configure issue.

- pthreads, gpac, ffmpeg and ffmpegsource all compiled with gcc 4.4.2 aswell.
- upx --lzma --best x264.exe

x264.1376.LAVF.FFMS.gcc.4.4.2.make.exe
x264.1376.LAVF.FFMS.gcc.4.4.2.make.upx.exe
x264.1376.LAVF.FFMS.gcc.4.4.2.make.fprofiled.exe
x264.1376.LAVF.FFMS.gcc.4.4.2.make.fprofiled.upx.exe

What do we want to know? Are there any (encoding) speed differences?
Do they work at all? Compare them to Dark's .exe.

roozhou · 10th January 2010, 16:34

Quote:

Originally Posted by bob0r

What do we want to know? Are there any (encoding) speed differences?
Do they work at all? Compare them to Dark's .exe.

I don't think we should care about speed atm but focus on fixing various bugs concerning ffmpeg input. Is there any improvement in v2.2?

kemuri-_9 · 10th January 2010, 16:44

Quote:

Originally Posted by roozhou

I don't think we should care about speed atm but focus on fixing various bugs concerning ffmpeg input. Is there any improvement in v2.2?

"2.2" is outdated, should wait on the current revision.

Quote:

Originally Posted by bob0r

- pthreads, gpac, ffmpeg and ffmpegsource all compiled with gcc 4.4.2 aswell.

and supply what options you gave to configure for your ffmpeg compile....

bob0r · 10th January 2010, 17:27

Quote:

Originally Posted by roozhou

I don't think we should care about speed atm but focus on fixing various bugs concerning ffmpeg input. Is there any improvement in v2.2?

Speed between the versions, not speed input wise.

And yeah the patch is outdated, just need to know if it runs at all. (If there are no GCC 4.4.2 issues.)

roozhou · 10th January 2010, 17:33

Quote:

Originally Posted by kemuri-_9

"2.2" is outdated, should wait on the current revision.

Where is the current version?

Dark Shikari · 10th January 2010, 18:08

A lot of the "bugs" at this point are bugs in FFMS and in LAVF. Most programs don't run into these bugs because they use constant framerate, or they hack around them in ugly fashion.

For example, we have issues with:

1) LAVF returning invalid PTS (duplicate PTS, and sometimes AV_NOPTS_VALUE)
2) FFMS returning wrong FPS and broken PTS on telecined files
3) FFMS breaking on raw video AVIs
4) FFMS breaking on .h264 files

LoRd_MuldeR · 11th January 2010, 02:05

I hope all the FFMS problems can be fixed and backported to the standalone FFMS2 plugin for Avisynth. Better FFMS2 source would be great

popper · 11th January 2010, 15:08

Quote:

Originally Posted by roozhou

You don't need it because we have ffmpeg. Timecodes are only needed when you are using outdated frameworks that does not correctly handle timestamps.(e.g. avisynth, vfw)

1. encode input with x264 and create a vfr mp4
2. convert audio
3. multiplex subtitle, audio and video using ffmpeg

I know there are several bugs in ffmpeg's muxers, but one day ffmpeg will handle all these things.

as i understand it <kierank> intends at some point to try and make a generic DVB-* style 'Stat Mux' capable TS (Transport Stream) framework for x264, so industrial Timecode capability and even New stat mux and related timecode insertion/editing apps if the need arises will be useful in the future for many AVC x264 things it seems, although its not clear exactly how he will impliment it yet!

BTW why dont you spend time on the #x264dev IRC roozhou ?,
http://gogloom.com/client2/index2?ma...nel=%23x264dev
your coding skills will help out there for review and patchs etc it seems.

SledgeHammer_999 · 12th January 2010, 21:31

Quote:

Originally Posted by LoRd_MuldeR

I hope all the FFMS problems can be fixed and backported to the standalone FFMS2 plugin for Avisynth. Better FFMS2 source would be great

I second that!

Also, (I haven't tested it) but does it handle subs too?(hardsubbing them mainly)

kemuri-_9 · 12th January 2010, 21:35

as the avs plugin is a wrapper around the FFMS2 API, the same API that x264 uses, any issues found and fixed should also be fixed for the avisynth plugin.

Quote:

Originally Posted by SledgeHammer_999

Also, (I haven't tested it) but does it handle subs too?(hardsubbing them mainly)

no.

roozhou · 13th January 2010, 03:56

Quote:

Originally Posted by SledgeHammer_999

I second that!

Also, (I haven't tested it) but does it handle subs too?(hardsubbing them mainly)

I have improved vsfilter.dll's csri interface and hardsub works perfectly with my dshow x264 build under windows. As soon as ffmpeg input in x264 is finished, this can be easily port to lavf input. However hardsub requires true timestamp for each frame not fake cfr or average fps.

buzzqw · 13th January 2010, 08:17

a request: could be added a --size XXX parameter ?

using this option x264 will compute the bitrate (on 2 pass encoding) to achive the size requested

thanks

BHH

Sharc · 13th January 2010, 21:04

Quote:

Originally Posted by buzzqw

a request: could be added a --size XXX parameter ?

using this option x264 will compute the bitrate (on 2 pass encoding) to achive the size requested

I one sets --bitrate yyyyy --size xxxx: who will be the winner? The last parameter superseding the first one?

sneaker_ger · 13th January 2010, 21:25

Quote:

Originally Posted by roozhou

I have improved vsfilter.dll's csri interface and hardsub works perfectly with my dshow x264 build under windows. As soon as ffmpeg input in x264 is finished, this can be easily port to lavf input. However hardsub requires true timestamp for each frame not fake cfr or average fps.

Can we expect this to be ported into FFmpegSource?

LoRd_MuldeR · 13th January 2010, 21:29

Quote:

Originally Posted by buzzqw

a request: could be added a --size XXX parameter ?

using this option x264 will compute the bitrate (on 2 pass encoding) to achive the size requested

thanks

BHH

IMO a "--size" parameter would be kind of superfluous. All it would do is set "--bitrate" to "size/duration", which can be calculated easily before calling x264.

Also x264 doesn't always know the duration in advance! As far as I understood, it doesn't know the framecount in advance with the "lavc" demuxer, only with the "ffms2" demuxer. And of course with Avisynth.

It doesn't know the number of frames for sure when reading source from STDIN, unless the user passes "--frames" explicitly. So how should "--size" behave in those situations ???

Quote:

Originally Posted by Sharc

I one sets --bitrate yyyyy --size xxxx: who will be the winner? The last parameter superseding the first one?

In that case, if "--size" really is added, x264 should abort with error, because the user has set contradictory options...

J_Darnley · 13th January 2010, 23:49

Quote:

Originally Posted by LoRd_MuldeR

In that case, if "--size" really is added, x264 should abort with error, because the user has set contradictory options...

x264 doesn't abort at present if you do --bitrate x --crf y. The latter option would be used. Whether it should, I don't know.

But I agree, with your statement that it is pointless.

bnshrdr · 14th January 2010, 03:09

In my opinion, the whole --size option shouldn't be part of the program that does the encoding, but part of a front-end, as it has been done in the past. (MeGUI, Staxrip, and others....)

But then again, I have the whole linux way of looking at things, one program should have one task. I don't want to see my media players turn into web browsers

.

roozhou · 14th January 2010, 04:44

Quote:

Originally Posted by LoRd_MuldeR

It doesn't know the number of frames for sure when reading source from STDIN, unless the user passes "--frames" explicitly. So how should "--size" behave in those situations ???

--size should work in 2nd pass.

kypec · 14th January 2010, 07:58

Quote:

Originally Posted by bnshrdr

In my opinion, the whole --size option shouldn't be part of the program that does the encoding, but part of a front-end, as it has been done in the past. (MeGUI, Staxrip, and others....)

My words exactly. If someone is not able to calculate the most simple algebra of elementary school (Bitrate = Size / Duration hence Size = Bitrate * Duration) he shouldn't be using x264 at all.

It really goes beyond my comprehension why an author of multiple x264 GUI's [buzzqw] would have requested such useless option...

10th January 2010, 18:08	#67 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	A lot of the "bugs" at this point are bugs in FFMS and in LAVF. Most programs don't run into these bugs because they use constant framerate, or they hack around them in ugly fashion. For example, we have issues with: 1) LAVF returning invalid PTS (duplicate PTS, and sometimes AV_NOPTS_VALUE) 2) FFMS returning wrong FPS and broken PTS on telecined files 3) FFMS breaking on raw video AVIs 4) FFMS breaking on .h264 files __________________ Follow x264 development progress \| akupenguin quotes \| x264 git status ffmpeg and x264-related consulting/coding contracts \| Doom10

11th January 2010, 02:05	#68 \| Link
LoRd_MuldeR Software Developer Join Date: Jun 2005 Location: Last House on Slunk Street Posts: 13,248	I hope all the FFMS problems can be fixed and backported to the standalone FFMS2 plugin for Avisynth. Better FFMS2 source would be great __________________ Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

13th January 2010, 08:17	#73 \| Link
buzzqw HDConvertToX author Join Date: Nov 2003 Location: Cesena,Italy Posts: 6,552	a request: could be added a --size XXX parameter ? using this option x264 will compute the bitrate (on 2 pass encoding) to achive the size requested thanks BHH __________________ HDConvertToX: your tool for BD backup MultiX264: The quick gui for x264 AutoMen: The Mencoder GUI AutoWebM: supporting WebM/VP8

10th January 2010, 15:00	#62 \| Link
bob0r Pain and suffering Join Date: Jul 2002 Posts: 1,337	Patch used: "x264.LAVF.FFMS.input.public.beta.test.v2.2.diff", it's not public and probably not v2.2 eighter, i just saved it as 2.2 instead of 2.1 (laziness). This patch was given to me by Dark to fix a x264 configure issue. - pthreads, gpac, ffmpeg and ffmpegsource all compiled with gcc 4.4.2 aswell. - upx --lzma --best x264.exe x264.1376.LAVF.FFMS.gcc.4.4.2.make.exe x264.1376.LAVF.FFMS.gcc.4.4.2.make.upx.exe x264.1376.LAVF.FFMS.gcc.4.4.2.make.fprofiled.exe x264.1376.LAVF.FFMS.gcc.4.4.2.make.fprofiled.upx.exe What do we want to know? Are there any (encoding) speed differences? Do they work at all? Compare them to Dark's .exe.

14th January 2010, 03:09	#78 \| Link
bnshrdr Registered User Join Date: Jun 2009 Location: Indianapolis, IN Posts: 103	In my opinion, the whole --size option shouldn't be part of the program that does the encoding, but part of a front-end, as it has been done in the past. (MeGUI, Staxrip, and others....) But then again, I have the whole linux way of looking at things, one program should have one task. I don't want to see my media players turn into web browsers .