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

[Werner Johansson]

Diogo Franco wrote:
> 2008/5/4 Werner Johansson <wj at xnk.nu>:
>
>   
>> [root at 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 at 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