Location of frame error?

[asarian]

Darn, got one of these (in a Blu-Ray):

[h264 @ 00000280112c7740] concealing 698 DC, 698 AC, 698 MV errors in B frame


How can I calculate where is that error located, frame-wise?! Or is that even possible to know?

N.B. Looks ere like an ffmpeg error to me (built into x264?)

Thanks.

[asarian]

I wonder whether this is a bug somehow inside x264?! I did several checks, like

eac3to saturn3.mkv -check

Or

ffmpeg.exe -v error -i saturn3.mkv -f null - >error.log 2>&1

Both report no errors of any kind. I run x264 core:148 r2665 a01e339 (64-bit). And I've had more of these spurious errors of late (whereas I had none before).

[asarian]

Odd. Just watched the entire re-encoded movie: no visible errors of any kind.

[LoRd_MuldeR]

It said "concealing ... errors", so that might be the reason. Either that, or the distortion was just too subtle to be noticeable.

[asarian]

Got another one of these, today:

[h264 @ 00000163c738f520] left block unavailable for requested intra4x4 mode -1
[h264 @ 00000163c738f520] error while decoding MB 0 4, bytestream 40330
[h264 @ 00000163c738f520] Cannot use next picture in error concealment
[h264 @ 00000163c738f520] concealing 1609 DC, 1609 AC, 1609 MV errors in P frame


Why can't the ffmpeg people not use a human-readable timestamp code?! You know, like something that will tell you where things went wrong (in which frame). And their documentation says nothing on the matter of error stamps, either. Lovely.

[raffriff42]

If you attempt to reencode the video, you should see the (approximate) problem areas:
https://www.dropbox.com/s/t9i25qzls1dcfh8/ffmpeg-errors2.png?raw=1

[asarian]

If you attempt to reencode the video, you should see the (approximate) problem areas:
https://dl.dropboxusercontent.com/u/108089426/Screenshots/ffmpeg-errors2.png


I'm not getting that kind of useful info on my screen. :) x264 just outputs the ffmep errors, but there's, sadly, no frame info.

[asarian]

If you attempt to reencode the video, you should see the (approximate) problem areas:


What re-encoder did you use here? Yours seems a lot more verbose. :)

[raffriff42]

I used a simple command, something like ffmpeg -i "known-bad.mp4" -c:v libx264 "test.avi"

What's weird is this: when I set the console screen buffer width to 120 (to show the full width of the output) the "frame = " lines went away! The output you see was generated with console buffer width set to 80.

[LoRd_MuldeR]

What's weird is this: when I set the console screen buffer width to 120 (to show the full width of the output) the "frame = " lines went away! The output you see was generated with console buffer width set to 80.

Windows console madness ;)

An applicaton can print a '\r' char (or an adequete number of '\b' chars) in order to move the cursor back to the beginning of the current line. And then it can "overwrite" the current line content.

This way the application can "update" the current line, like progress indicators typically do - instead of appending a zillion of new lines. And I think that is exactly what FFmpeg does here with the "frame =" line.

However, once you have had a line break, there is no way back to the previous line! At least not without using some low-level Win32 API console functions - which you don't have in plain C.

So, by reducing the console width, you force a line break and thus each "frame =" line is preserved (at least the part before the line break). But, as long as the console width is sufficient, the line gets replaced.

[asarian]

I used a simple command, something like ffmpeg -i "known-bad.mp4" -c:v libx264 "test.avi"

What's weird is this: when I set the console screen buffer width to 120 (to show the full width of the output) the "frame = " lines went away! The output you see was generated with console buffer width set to 80.


Thanks! :) I'll try that.