FFmpegSource

[Myrsloik]

WRITE TIMECODES TO A FILE. Fix it yourself using that. This was also very harshly answered earlier in the thread.

For the <edit mod: removed profanity> of you trying to compile ffmpeg source this is what you need and what will happen:
A recent gcc compile like 4.2.3. Have fun compiling it yourself with mingw.
A recent ffmpeg. Straightforward IF it compiles.
Uneventfully compile zlib but forget --prefix=/mingw and confuse yourself.
Make an empty dll project in vs2005 and add all files. Also add a list of obscure gcc include libraries to appease ffmpeg.
Compile.
You are now likely to be the proud owner of a miscompiled ffmpegsource. Order a pizza and watch tv instead.

[TheFluff]

Originally Posted by Myrsloik

For the fools of you trying to compile ffmpeg source you need and what will happen:
A recent gcc compile like 4.2.3. Have fun compiling it yourself with mingw.
A recent ffmpeg. Straightforward IF it compiles.
Uneventfully compile zlib but forget --prefix=/mingw and confuse yourself.
Make an empty dll project in vs2005 and add all files. Also add a list of obscure gcc include libraries to appease ffmpeg.
Compile.
You are now likely to be the proud owner of a miscompiled ffmpegsource. Order a pizza and watch tv instead.

After successfully compiling Aegisub with ffmpeg in VS2005 (with your help) I wrote some slightly more detailed instructions on how to statically link ffmpeg with something compiled in MSVC. The configure flags are not completely identical (remember to add libpostproc and its corresponding .a) and you'll need zlib as well but maybe it helps somewhat.

[Shinta]

@Myrsloik: Thanks for the loud and extremly confusing answer.
@TheFluff: Thx for the slightly more helpful one.

After fixing a small problem running sh-scripts with exe-extension in msys (in ./configure) and adding a missing #define to rtsp.c, I was finally able (about 3 hours) to compile ffmpeg. The compiling of ffmpegsource (I tried this using precompiled ffmpeg libs, but this results in a very small ffmpegsource.dll (292 kBytes), which was obviously crap) was just (re-)linking.

So, if someone is interessted in a VS2005 project (including ffmpegsource and zlib sources and the ffmpeg libs compiled by me), you may send me a PM.

.oO(Now, lets see, what can I do to make the filter returning frames with cfr on vfr videos)°

[Shinta]

Is the source at https://spaceboyz.net/svn/aegisub/trunk/FFmpegSource the current version (1.16)?
The file ffmpegsource.html holds only changelog entries until 1.14...

Also, in matroskacodecs.cpp lines 137++:

case MAKEFOURCC('Z', 'L', 'I', 'B'):
	return CODEC_ID_FLV1;
case MAKEFOURCC('F', 'L', 'V', '1'):
	return CODEC_ID_ZLIB;

Shouldn't this be...?:

case MAKEFOURCC('Z', 'L', 'I', 'B'):
	return CODEC_ID_ZLIB;
case MAKEFOURCC('F', 'L', 'V', '1'):
	return CODEC_ID_FLV1;

[Myrsloik]

That's a really obscure bug. Why were you reading the whole codec list anyway?

Version 1.16 + that fix is now in the svn.

[Shinta]

Originally Posted by Myrsloik

That's a really obscure bug. Why were you reading the whole codec list anyway?

I was just speed-reading the code and it caught my eye.

But another thing. I really don't understand the whole video decoding stuff completely yet, so don't be mad if I understood it wrong.

In ffmpegsource.cpp & ffmatroskasource.cpp:

// Flush the last frame
if (CurrentFrame == VI.num_frames - 1  && VideoCodecContext->has_b_frames)
	Ret = avcodec_decode_video(VideoCodecContext, AFrame, &FrameFinished, NULL, 0);

Is it really only the last frame that isn't decoded at this moment? Aren't it as much as frames as the number of (deferred?) b-frames since the last seek?

// Flush the last frames
if (CurrentFrame <= VI.num_frames - 1  && VideoCodecContext->has_b_frames)
	Ret = avcodec_decode_video(VideoCodecContext, AFrame, &FrameFinished, NULL, 0);

Just one thing more: In FFBase::SaveTimecodesToFile you sort the timecodes before writing them to the file. Shouldn't the frames (or their DTSs) be sorted for seeking too?

[TheFluff]

Originally Posted by Shinta

In ffmpegsource.cpp & ffmatroskasource.cpp:

// Flush the last frame
if (CurrentFrame == VI.num_frames - 1  && VideoCodecContext->has_b_frames)
	Ret = avcodec_decode_video(VideoCodecContext, AFrame, &FrameFinished, NULL, 0);

Is it really only the last frame that isn't decoded at this moment? Aren't it as much as frames as the number of (deferred?) b-frames since the last seek?

// Flush the last frames
if (CurrentFrame <= VI.num_frames - 1  && VideoCodecContext->has_b_frames)
	Ret = avcodec_decode_video(VideoCodecContext, AFrame, &FrameFinished, NULL, 0);

This makes no sense. Even if there were more than one frame, which I highly doubt (read the loop above the mentioned code again), your fix wouldn't output more than one frame because avcodec_decode_video() only outputs one frame at a time. By the way the frame that is "decoded" is just NULL, so... (see avcodec.h)

[Myrsloik]

Due to b-frame reordering decodign will never lag more than one frame. Example:

Shown: IBPBPI
Stored: IPBPBI

Shown: IBBPBBPI
Stored: IPBBPBBI

Meaning that you will never have more than a one frame lag (indicated by has_b_frames). Thus there are no more frames to flush. As thefluff pointed out that part is also only triggered if all the other logic failed which is for the last frame with decoding lag OR for very unusual decoding errors and then only for the last frame.



FFBase::SaveTimecodesToFile - The whole DTS relation is a bit special. That function only sorts them because mkvmerge expects it as input (historical note: old versions used unsorted).

The reason ffmpegsource doesn't care about it being sorted or not is that the position of keyframes is independent of the reordering. As the only value extracted from it is "what frame number does this DTS correspond to?" and we know that seeking always goes to keyframes (minus bugs and that stuff). So the only thing the other DTS values in between are really used for are placeholders.

[Shinta]

For videos with only one b-frame your right, but I found a video that seems to have 2 frames left to decode after reaching EOF.

Using this code...

// Flush the last frames
if (CurrentFrame <= VI.num_frames - 1 && VideoCodecContext->has_b_frames)
	Ret = avcodec_decode_video(VideoCodecContext, AFrame, &FrameFinished, NULL, 0);

FILE* err=fopen("err.txt", "a");
if(err)
{
	fprintf(err, "%d %d %d %d %d\r\n", CurrentFrame, VI.num_frames-1, Ret, FrameFinished, VideoCodecContext->has_b_frames);
	fclose(err);
}

I got this err.txt:

90286 90287 0 200 2
90287 90287 0 200 2

I don't know what the 200s in the 4th column means exactly, but they're not zero and thus the frame were decoded.

[Myrsloik]

To debug these things it's usually much easier to encode a clip with similar settings and clearly number every frame. Does your clip by any chance have open GOPs?

[Shinta]

Maybe it has something to do with this:

(From the german wikipedia on h264)

Long-Term Prediction: P- und B-Frames können nicht nur Referenzen auf den jeweils letzten I- oder P-Frame enthalten, sondern auch zu theoretisch beliebig vielen vorhergehenden, um eine effizientere Kodierung von periodischen Bewegungen zu ermöglichen. In den Profiles und Levels ist die Anzahl von Referenzbildern allerdings auf maximal fünf begrenzt.

My translation (hope it is good enough):

Long-Term Prediction: P- and B-frames doesn't have to reference only the last I- or P-frame, but also to theoreticaly any number of previous (I- or P-)frames, to increase encoding performance on recurring movements. The profiles and levels limits the number of referenced frame to five.

To debug these things it's usually much easier to encode a clip with similar settings and clearly number every frame. Does your clip by any chance have open GOPs?

I don't know, and don't know how to find that out. But I've splitted the video at the last keyframe and can send you this 74 kByte mkv.

[Shinta]

Lets try an attachment: (it is that 74kb mkv)

[Myrsloik]

Seeking in h264 should be limited to IDR frames which means the assumption is still true (I is just another letter in between). Find some place to upload the file to and I will look at it.

[Shinta]

Or, http://www.megaupload.com/?d=Y9QNAHQB

[Manao]

The one-frame lag implied by bframes is valid for all codecs prior to H264. For h264, the possibility to create b-reference (and thus pyramidal b-gops) may create longer lags (one level of byramid is commonly used with x264 and creates a two frame lag)

[Myrsloik]

Bug fixed and put in the svn. As Manao hinted it only applied to h264 with pyramid stuff and would usually result in the last frame being dropped and the now second to last frame duplicated.

No new compile today though, ffmpeg svn is having one of those broken weeks it seems.

[thetoof]

Feature request: handling of the anamorphic flags

[Myrsloik]

So I've read the AR from the stream, now what? Return it in a variable with a user specified name? Rescale the video and kill kittens?

[jase99]

I regularly use the filter with anamorphic sources, what additional support is needed?

[Myrsloik]

How aspect ratio reporting is done now:
FFSAR_NUM, FFSAR_DEN and FFSAR are set to the container values for mkv and the video decoder values for all other filetypes.
The problem:
Several mp4 files report a SAR of 0/1 which isn't right or very helpful. Should the cases with 0 be converted to 1/1 or left as it is?