Opened 9 years ago

Last modified 9 years ago

#1775 new defect

mpeg-ts - first frame corrupted - Regression?

Reported by: tbartdev@… Owned by: reimar
Priority: normal Component: core
Version: unspecified Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

This one's rather hard to report/reproduce...

What I am doing here is converting full quality HDV .mts captures to low-q,low-res previews. Due to limitations in the NLE (Edius) I have to keep the format as closely to the source as possible. I cannot use ffmpeg for ex. b/c it adds a "Service" to the .mts file (any help on disabling this is very much appreciated...)

MPLAYER SVN-r29796-4.4.3's mencoder (latest stable on Gentoo) produces output that mostly conforms to what the NLE needs, except that the clip length varies by a few frames (due to duplicate/skipped frames during the encoding process? If anyone knows how to get rid of that I'd be thankful. Playing with -mc * and -noskip only shortens the clip by a few seconds, that doesn't really help... Deviating clip lengths can be seen in our Austrian version of Edius as "Clip-Dauer" ;-> )

Using MPLAYER SVN-r32017-4.4.3's mencoder OTOH produces output with the first frame corrupted. This can however only be seen in Edius, that's what I meant with this bug being hard to report/reproduce..

I also tried with mpeg1 and the result is the same, so I guess it is a muxer/container problem.

I truncated the source HDV capture as much as possible so Edius still shows a video at all after conversion.. It is now called HDVCapture.m2t.
(dd if=Cap0722_000\(0142\).m2t of=HDVCapture.m2t bs=1024 count=28000)

The conversion command used was this:

export fileno=12

emerge -Kav =mplayer-9999-r2

mencoder "HDVCapture.m2t" -ovc lavc -lavcopts vcodec=mpeg2video:vbitrate=300:vrc_maxrate=300:vrc_buf_size=1100:o=g=12:aspect=1.7777 -ofps 25 -vf scale=640:480 -oac lavc -lavcopts acodec=mp2:abitrate=32 -noskip -of mpeg -mpegopts vbuf_size=1100 -o HDVCapturePreview_svn32017_$(printf %03d $fileno).m2t

emerge -Kav =mplayer-1.0_rc4_p20091026-r1

mencoder "HDVCapture.m2t" -ovc lavc -lavcopts vcodec=mpeg2video:vbitrate=300:vrc_maxrate=300:vrc_buf_size=1100:o=g=12:aspect=1.7777 -ofps 25 -vf scale=640:480 -oac lavc -lavcopts acodec=mp2:abitrate=32 -noskip -of mpeg -mpegopts vbuf_size=1100 -o HDVCapturePreview_svn29796_$(printf %03d $fileno).m2t

All files as well as the screenshot are uploaded at upload.mplayerhq.hu/MPlayer/incoming/mpeg-ts_-_first_frame_corrupted

Please let me know if I can test/submit anything more if needed & thanks in advance!

Attachments (1)

Edius_first_frame_corrupt_svn32017_not_in_svn29796.PNG (31.6 KB) - added by tbartdev@… 9 years ago.
Screenshot of Edius showing first corrupted frame

Download all attachments as: .zip

Change History (6)

Changed 9 years ago by tbartdev@…

Screenshot of Edius showing first corrupted frame

comment:1 Changed 9 years ago by tbartdev@…

(In reply to comment #0)

All files as well as the screenshot are uploaded at
upload.mplayerhq.hu/MPlayer/incoming/mpeg-ts_-_first_frame_corrupted

Sorry, this should read "upload.mplayerhq.hu/MPlayer/incoming/mpeg-ts_-_first frame_corrupted" (typo, cannot rename dir anymore..)

comment:2 Changed 9 years ago by tbartdev@…

(In reply to comment #1)

Sorry, this should read "upload.mplayerhq.hu/MPlayer/incoming/mpeg-ts_-_first
frame_corrupted" (typo, cannot rename dir anymore..)

.. which is a blank between first and frame, the linebreak makes this hard to see.

I further investigated and limited the error to a somewhat smaller pool of revisions:

29851 does NOT have the problem
30075 DOES have the problem

I could not get binaries for anything between these two, and compiling is somewhat tedious as my external libaries (ffmpeg) do not seem to be compatible to the code mplayer/mencoder expected back then.

I have another problem that seem to be somewhat related:
I have a short file that has a contrary problem.

Up till 29851, mencoder produces a file with "inf%" overhead and even mplayer itself is unable to play the file afterwards (no video stream).
Version from 30075 on however DO encode this file properly, that is, with the first frame being corrupted.
I can therefore neither use the one nor the other version!

I can provide the file if necessary (Cap0127_000(0017).m2t as a note to myself), but as this is fixed in newer versions I guess I don't necessarily have to provide it now.

Please tell me if can help/test any patches or where in the sources I could search for this problem. I am no C guru, but I can somewhat read code.

Thanks in advance!

comment:3 Changed 9 years ago by tbartdev@…

Further cut down the possible versions.

Mplayer-29971 (external repositories 20640) is the newest version showing the inf% overhead bug but does not produce corrupt first frames with longer files.
Mplayer-29973 (external repositories 20679) is the oldest version showing the corrupted frame bug.

29972 (external 20654) compiles fine but does nothing where other versions start to count frames and encode... weird...

External libraries were pulled from the same date as described in
http://lists.mplayerhq.hu/pipermail/mplayer-users/2008-August/073965.html

As there do not seem to be any relevant changes to mplayer's code in these revisions regarding mpeg(ts) I guess the error comes from ffmpeg's code..

Relevant ffmpeg changes:

http://git.ffmpeg.org/?p=ffmpeg;a=shortlog;pg=41

Must be somewhere between
2009-12-01 michael slif aka "SoftLab? MPEG-2 I-frames Codec" support.
and
2009-11-28 michael Simplify mpeg_decode_user_data()

Shall I report this on ffmpeg.org's bugzilla?

comment:4 Changed 9 years ago by tbartdev@…

regarding the reproduceability:

ffmpeg -t 0.04 -i <transcoded file>.m2t -vcodec png -an file%03d.png

clearly shows the first frame is corrupted. not only edius sees this.

comment:5 Changed 9 years ago by tbartdev@…

Further analyzed the problem:

It only occurs with -vf scale=640:480 (or other resolutions), disabling the scaling makes the first frame work again.

If I insert yadif like in -vf yadif,scale=640:480,harddup the problem is gone. This however comes at a 50% performance penalty and is unnecessary in my case. kerndeint and mcdeint do not seem to fix the problem.
-vf scale=640:480,harddup,yadif does NOT fix it!
I also tried different scalers with -sws <x> to no avail.

I will open another bug regarding the inf% Overhead files that contain no video stream. This happens when files are short and/or audio bitrate is too low..

Note: See TracTickets for help on using tickets.