MEncoder

„MEncoder is a free command line video decoding, encoding and filtering tool released under the GNU General Public License. It is a close sibling to MPlayer and can convert all the formats that MPlayer understands into a variety of compressed and uncompressed formats using different codecs.“

MEncoder. (2008, February 23). In Wikipedia, The Free Encyclopedia. Retrieved 18:57, April 5, 2008, from
http://en.wikipedia.org/w/index.php?title=MEncoder&oldid=193447614


My Blog List

Sunday, May 4, 2008

Re: [MEncoder-users] MEncoder SVN-r26664 interlaced AVCHD decoding issues, sample PF24 M2TS clip available

Diogo Franco wrote:
> 2008/5/4 Werner Johansson <wj@xnk.nu>:
>
>
>> [root@rofs ~]# mencoder 00028.mts -noaspect -noskip -o 28ffvhuff.avi
>> -fps 60000/1001 -ofps 24000/1001 -oac pcm -ovc lavc -vf
>> softskip,detc,harddup -lavcopts vcodec=ffvhuff
>>
>
>
> All inverse telecining filter need to see all frames, so the softskip must
> come after detc. Not sure because you also harddup, but do this just to be
> sure. The docs also suggest that you should not use detc because it is
> unmaintained. Try pullup or filmdint. You should test each filter and see
> which one works better.
> _______________________________________________
> MEncoder-users mailing list
> MEncoder-users@mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users
>

The issue doesn't seem to be related to the inverse telecine or the fact
that the frame rate is doubled, but more that the decoding/demuxing of
the m2ts stream fails. I have tried both filmdint and detc with
identical results. I interpreted the MEncoder manual in the way that
softskip was supposed to go first to avoid any frame drop until the
detc/filmdint filter had been run? It really didn't matter whether the
harddup and softskip were present. I also tried using MEncoder to skip
every second frame in a first step to first produce 30000/1001fps video
instead of 60000/1001, but the results were still the same (playback of
that huff file still showed the odd sporadic blocky artifacts, and the
3:2 cadence looks just fine (3 frames of good data followed by 2 with
interlacing artifacts).

A svn checkout and build of ffmpeg shows identical results with the 4
broken initial frames.

After closer inspection of the m2ts file and it's parsing it seems that
MPlayer/MEncoder doesn't quite know how to handle the timestamp present
before the ts sync byte of every ts packet, and that the file actually
contains some packets that are out of order (!?) According to the m2ts
page on wikipedia the format is supposed to handle ts packets arriving
out of order, but it wouldn't make any sense to have a flash memory
based camcorder writing them in such a way, would it?

/Werner


_______________________________________________
MEncoder-users mailing list
MEncoder-users@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users

No comments:

PCBs

Links

Forex brokers, Forex online


Privacy Policy