Problem with field order

[harissa]

This problem started a year ago with 1 hdtv channel called CTV , and it s spreading faster than I could imagine to all hdtv canadian channel
I am having a huge problem with some HDTV capture I m sure that the field order of the video is changing at diffrent times during the video. I m postin the d2v file .
I can send a sample to anyone who can help me ,
the problem of this HDTV cap , is the lenght of the video and the audio , they are way offsync
for a 5 min file , the audio is still 5 min and the video drop to 4:30 min
when i load that mpeg file into vdub without d2v process the problem remain the saem , but when I load it into virtualdub mepg edition it load correctly with the exact lenght
I have tried all the programs who can process mpeg without any success

[GOP]
1838 [B]: 1859,1859.............0
1839 [B]: 1860,1860,1861........3 [FIELD ORDER TRANSITION!]
1840 [I]: 1861,1862,1862........1
1841 [B]: 1863,1863,1864........3
1842 [B]: 1864,1865,1865........1
1843 [P]: 1866,1866.............0 [FIELD ORDER TRANSITION!]
1844 [B]: 1867,1867,1868........1 *
1845 [B]: 1868,1869,1869........1 [FIELD ORDER TRANSITION!]
1846 [P]: 1870,1870,1871........3
1847 [B]: 1871,1872,1872........1
1848 [B]: 1873,1873,1874........3
1849 [P]: 1874,1875,1875........1
1850 [B]: 1876,1876,1877........3
1851 [B]: 1877,1878.............0 *
1852 [P]: 1878,1879.............0
[GOP]
1853 [B]: 1879,1880,1880........3 [FIELD ORDER TRANSITION!]
1854 [B]: 1881,1881,1882........1
1855 [I]: 1882,1883,1883........3
1856 [B]: 1884,1884.............0 *
1857 [B]: 1885,1885.............0
1858 [P]: 1886,1886.............0
1859 [B]: 1887,1887,1888........1 *
1860 [B]: 1888,1889,1889........1 [FIELD ORDER TRANSITION!]
1861 [P]: 1890,1890,1891........3
1862 [B]: 1891,1892.............0 *
1863 [B]: 1892,1893.............0
1864 [P]: 1893,1894,1894........3 [FIELD ORDER TRANSITION!]
1865 [B]: 1895,1895,1896........1
1866 [B]: 1896,1897,1897........3
1867 [P]: 1898,1898.............0 *
[GOP]
1868 [B]: 1899,1899.............0
1869 [B]: 1900,1900,1901........3 [FIELD ORDER TRANSITION!]
1870 [I]: 1901,1902,1902........1
1871 [B]: 1903,1903,1904........3
1872 [B]: 1904,1905.............0 *
1873 [P]: 1905,1906.............0
1874 [B]: 1906,1907,1907........3 [FIELD ORDER TRANSITION!]
1875 [B]: 1908,1908,1909........1
1876 [P]: 1909,1910,1910........3
1877 [B]: 1911,1911,1912........1
1878 [B]: 1912,1913,1913........3
1879 [P]: 1914,1914,1915........1
1880 [B]: 1915,1916,1916........3
1881 [B]: 1917,1917.............0 *
1882 [P]: 1918,1918.............0
[GOP]

[neuron2]

Please post a link to an *unprocessed* source clip that I can use to duplicate your issue.

[harissa]

done check your pm

[lineman]

I also have had no success in indexing the hdtv sources mentioned. I know that some of these sources originate as 1080i(30fps) hdtv and are then converted by the provider to 720p(60fps). These files play perfectly on my PC and on my IOData player. There seems to be two problems when trying to convert to any other format, audio sync and field order transitions -which cause severe "jumping" in the video. If you need more raw samples I can help out as this type of video is becoming very common place on two north american providers.
Thanks
Lineman:o

[SeeMoreDigital]

Any possibility I can see these sources too please?

[lineman]

Any possibility I can see these sources too please?

Any suggestions where to host some files for all too view?

[neuron2]

harissa, your FTP server fails to give me any data after accepting my login.

lineman, yes, provide a stream for testing.

[neuron2]

Any suggestions where to host some files for all too view? harissa is unable to deliver files to me due to technical issues.

Please read this to find a site:

http://forum.doom9.org/showthread.php?t=96362

I'm willing to help but I am not willing to spend hours trying to get files from dodgy upload sites.

[harissa]

here the link for an hdtv file
for a specific one ( in ts ) or smaller or bigger just ask

http://www.megaupload.com/?d=AY47SIIT

[neuron2]

here the link for an hdtv fileAh, that's better. Downloading now...

[neuron2]

when i load that mpeg file into vdub without d2v process the problem remain the saem , but when I load it into virtualdub mepg edition it load correctly with the exact lenght How are you managing to load the file into plain vanilla VirtualDub without the D2V process?

[harissa]

vdub gave me wrong lengh
so load it in vdub mpeg edition
it load great but the resize and the decimate plugin cannot be used it s too old and they give bad result

[neuron2]

vdub gave me wrong lengh
What are you talking about? VirtualDub cannot open MPEG2. Do you mean VirtualDubMod?

Anyway, I have a solution. I will post it in a few minutes when the upload finishes.

[neuron2]

Hmm, interesting! Just to show you that I know what is going on, I made this 720x480x29.97fps 2000kbps DivX 6.4.0 encoding (47MB) from your stream. Of course it would look better with a higher bitrate.

http://neuron2.net/misc/c1.avi

I will keep you in suspense for a while about the explanation and the method I used. I think my friend SeeMoreDigital wants to have a go at it. :)

[harissa]

In fact evryone wanna have the solution it s been a year , and no one wanna ask you how , becauz if you say how evryone will know
but it worth it
leechin the file now

[neuron2]

I'm 95% sure I know the cause of the D2V process failing. I want to verify it in the debugger tomorrow before saying it. :)

EDIT: BTW, those girls are majorly cute.

[harissa]

great , work perferctly the timeline is ok
u really good at that ,
i ve tried evrything without succes

[drmpeg]

It's just the real-time encoder jumping in and out of inverse telecine. For this clip, the encoder is having a really difficult time finding the repeated frames. This is probably due to the 1080i to 720p conversion method where each repeated frame has just enough difference to fool the inverse telecine detection. Almost the entire clip is video with a few brief moments of film.

BTW, what (or who) is Saar Software?

Ron

[harissa]

i thought too it s a conversion problem until I found this problem in fox show who also air in CTV and Global ( cannadian channels )
fox is 720p , and also canndian channels , so it must be somthing else
Saar Software is mytheater , a dvb programe

[drmpeg]

i thought too it s a conversion problem until I found this problem in fox show who also air in CTV and Global ( cannadian channels )
fox is 720p , and also canndian channels , so it must be somthing else
Saar Software is mytheater , a dvb programe
It may also be due to re-encoding an MPEG-2 feed. The repeated frames will always be a bit different just from quantization and motion compensation.

The bitstream has GOP user data packets that have this text:

(c) 2004 Saar Software

I'll guess mytheater was used to edit the capture.

Ron

[neuron2]

harissa is right. I think it is something else, something real simple. I believe that the RFF flags are being used for frame repeats rather than field repeats. That makes perfectly good sense given that the output is supposed to be progressive: 720P. That causes a big problem for DGMPGDec, because it supports only field repeats. I'll have to add support for frame repeats.

I will verify my theory in the debugger today but it's the only plausible theory that fits the known facts. My successful encode working with that theory also tends to corroborate it. But I want to see the MPEG syntax in the debugger.

As to why there are patches of frame repeats mixed with non-repeated sections, I do not know, but at least I know how to fix the D2V process for streams like these.

EDIT: Theory confirmed in the debugger (RFF plus progressive_sequence = 1)!

[lineman]

It looks as though there is a solution...If you need more files I can help...I have been just so busy this week

Lineman:)

[neuron2]

There's a solution in theory. But the changes are so extensive to DGMPGDec, given the inherited design from DVD2AVI, that it's unlikely frame repeat handling will be added any time soon. Luckily, however, they are supported by VirtualDub MPEG2.

[lineman]

There's a solution in theory. But the changes are so extensive to DGMPGDec, given the inherited design from DVD2AVI, that it's unlikely frame repeat handling will be added any time soon. Luckily, however, they are supported by VirtualDub MPEG2.

You may have to point me in the right direction! I have never used VirtualDub MPEG2 to index/encode a file. :confused:

[neuron2]

What specifically are you asking for? The right direction is VirtualDub MPEG2.

You have to configure it to honor RFF flags (options/Preferences/MPEG). Use the resize filter to get your final frame size. Then set decimate by 2 in Video/Frame Rate. Then save to an intermediate file and finish up with an Avisynth script [for Decimate(5)] and anything else you need to do.

[lineman]

What specifically are you asking for? The right direction is VirtualDub MPEG2.

You have to configure it to honor RFF flags (options/Preferences/MPEG). Use the resize filter to get your final frame size. Then set decimate by 2 in Video/Frame Rate. Then save to an intermediate file and finish up with an Avisynth script [for Decimate(5)] and anything else you need to do.

Thanks...I am with you so far, the only problem that I still see is the audio/video sync.

Actually I have got the audio/video to sync...

[neuron2]

Use DelayAudio() as needed.

[neuron2]

You'll be happy to hear that I have frame repeat working now in my latest build of DGMPGDec and it will be included in the next beta release.

[lineman]

You'll be happy to hear that I have frame repeat working now in my latest build of DGMPGDec and it will be included in the next beta release.

Great work Neuron (as always)! I will give the new Beta a try tonight.

Lineman

[harissa]

that s great thx a lot