DGAVCPulldown 0.3

[Guest]

The previous version did not apply pulldown in correct display order. This version corrects that and also includes the (messy) source code under GPL, which may be of use to anyone trying to parse AVC or do restreaming of AVC streams.

http://neuron2.net/dgavcpulldown/dgavcpulldown03.zip

[SeeMoreDigital]

How embarrassed do I feel... I totally missed this thread!

Many thanks Donald. I'll do some testing in my hardware players and report back.


Cheers

[NorthPole]

Thank you Don for this useful utility. I've been waiting for something like this for awhile. Any chance of adding an option to change the frame rate from 29.97 fps to 59.94 fps. Thanks.

[Guest]

Fixed a problem with re-ordering from display to encoding order. It affected all streams with GOP sizes not a multiple of 4. I think I've finally gotten this program right. :)

I plan to add support for frame pulldown and arbitrary conversions as in DGPulldown.

http://neuron2.net/dgavcpulldown/dgavcpulldown03.zip

[Shevach]

I would be very grateful if someone will provide a link to a H.264 stream with 3:2 cadence.

[kieranrk]

I would be very grateful if someone will provide a link to a H.264 stream with 3:2 cadence.

You can generate a stream from a 24000/1001 source with x264 --pulldown 32 INPUT -o out.264

[Guest]

Or just apply DGAVCPulldown to an existing file encoded by x264.

[Shevach]

I would like to get a stream with pulldown SEI messages which originally generated from 3:2 cadence material.
I want to run this stream on a particular decoder ("silicon" decoders) in order to check whether it supports pulldown or not.

[Guest]

What do you mean by "generated from 3:2 cadence material"? If that material is soft pulled down then the SEIs are already there. If hard pulled-down you'd have to IVTC first and then add soft pulldown. My point is that the original material must be progressive.

And it doesn't matter whether pulldown is added by the encoder or via postprocessing.

[kieranrk]

And it doesn't matter whether pulldown is added by the encoder or via postprocessing.

It matters if you are using HRD.

[Guest]

Can you elaborate on that please?

My understanding is that decoders are free to ignore PIC timing SEIs and that the HRD is not complicated by them because buffer removal times, etc., are not affected.

[SeeMoreDigital]

I guess he'e referring to this: http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F4378863%2F4379738%2F04379826.pdf%3Farnumber%3D4379826&authDecision=-203

[Guest]

I know what HRD is. :)

[Shevach]

What do you mean by "generated from 3:2 cadence material"?
3:2 cadence means raw video date processed Telecine machine where corresponding fields are identical.
An encoder should detects identical fields and generate corresponding commands to a decoder (like MPEG repeat_first_field).

[Guest]

3:2 cadence means raw video date processed Telecine machine where corresponding fields are identical.
An encoder should detects identical fields and generate corresponding commands to a decoder (like MPEG repeat_first_field). Can't fully parse your English, but it sounds like you want the original source to be hard pulldown and the encoder to make it soft. I don't see the point of insisting on that if your goal is to just to test a decoder for its ability to honor pulldown.

[Shevach]

I'll try articulate my point.

I have a H.264 decoder and want to check whether the decoder supports 3:2 pulldown or not.
I need a H.264 stream with 3:2 pulldown.
As already mentioned I can generate such stream by x264. To do it I need take x264 sources, compile them and run on selected video raw data. This operation will take a couple of days for me.
If someone simply will provide to me a H.264 stream with pulldown it would help me.

[SeeMoreDigital]

I don't see the point of insisting on that if your goal is to just to test a decoder for its ability to honor pulldown.Well if it helps anyone... I can confirm that my hardware player (decoder) is able to play/display the correct amount of frames when pull-down is added to a progressive AVC stream :)

[Guest]

I told you you can use DGAVCPulldown!

And you can get ready-made binaries of x264!

Here is a stream with pulldown:

http://neuron2.net/misc/transformers.264

[Shevach]

Well if it helps anyone... I can confirm that my hardware player (decoder) is able to play/display the correct amount of frames when pull-down is added to a progressive AVC stream :)

It's interesting what chip is in your player?
By the way I know several HW decoders that fail to play H.264 stream with pulldown.

[Shevach]

I told you you can use DGAVCPulldown!

And you can get ready-made binaries of x264!

Here is a stream with pulldown:

http://neuron2.net/misc/transformers.264

Thanks.

I downloaded DGAVCPulldown.
In my opinion you developed a Telecine machine which takes 24fps progressive stream and converts it to 30fps one by repeating/reversing corresponding fields. In other words one can make 24fps stream to be played as 30fps provided that a decoder correctly interprets pic_struct with values 4, 5 and display unit can repeat fields.

[kieranrk]

Can you elaborate on that please?

My understanding is that decoders are free to ignore PIC timing SEIs and that the HRD is not complicated by them because buffer removal times, etc., are not affected.

For 3:2 pulldown on 23.976 material the time_scale changes from 48000 to 60000 and num_units_in_ticks remains at 1001. The buffer removal times (derived from cpb_removal_delay and dpb_removal_delay) are based on this time_scale value. This changes the output times.

As far as I know the hrd is not guaranteed to be compliant even when you make the necessary cpb removal delay changes (i.e some frames have a delta of 3 and some frames have a delta of 2) because you've changed the cpb removal delays of frames.

fixed_frame_rate is assumed to be 1 and the restrictions of that syntax element means you can't just scale up the time_scale to fit.

By the way I know several HW decoders that fail to play H.264 stream with pulldown.

This is bad considering Blu-Ray allows pulldown. It might be something to chalk up on the H.264 failure list then.

[SeeMoreDigital]

It's interesting what chip is in your player?
By the way I know several HW decoders that fail to play H.264 stream with pulldown.I currently have two players up and running, both are fitted with a Realtek RT1283DD chip-set.

[Guest]

In my opinion you developed a Telecine machine which takes 24fps progressive stream and converts it to 30fps one by repeating/reversing corresponding fields. In other words one can make 24fps stream to be played as 30fps provided that a decoder correctly interprets pic_struct with values 4, 5 and display unit can repeat fields. Umm, yes, that is the entire point of it. I don't know why that would ever have been less than fully apparent.

I do plan to support arbitrary pulldown, however, to support (for example) 25->29.97 pulldown.

[Guest]

The STmicroelectronics set-top decoders properly handle AVC pulldown. I just verified that yesterday, although I had no reason to doubt it.

[poisondeathray]

By the way I know several HW decoders that fail to play H.264 stream with pulldown.

Would it be possible to list the models / chips that you know have problems with h.264 and pulldown ?

[Shevach]

I can't disclose this information.

[NorthPole]

I plan to add support for frame pulldown and arbitrary conversions as in DGPulldown.


This would be wonderful. I have been looking for something to pulldown 29.970 fps content to 59.940 fps for awhile.

[Shevach]

There are techniques which convert 30fps stream to 60fps one by interpolation of frames but as far as I know a new sort of annoying visual distortion appears - motion jadder.

[NorthPole]

Currently I get HD Captures at 1080i @ 29.97fps. I field match, decimate and reduce to 720p @ 23.976 but sometimes I get too much blending on the decimation. I don't like to blend but I'll take that over the frame jitter. If I skipped the frame decimation, I'd have 720p @29.970 fps... then I could just double the frame rate and dump it on a avc dvd disk. Not sure what techniques your thing of, but I'm all ears.

[nm]

Currently I get HD Captures at 1080i @ 29.97fps. I field match, decimate and reduce to 720p @ 23.976 but sometimes I get too much blending on the decimation.

What's the source of your captures? A video camera or a television broadcast? If it's interlaced video from a camera, there are no matching fields and you should bob to 60p (60000/1001 fps).

If it's a TV capture with hybrid telecined and interlaced content, you could try to pull down progressive 24p sequences to 30p or 60p and deinterlace/bob the interlaced sequences. But I don't know what standalone players would say about that.

[NorthPole]

What's the source of your captures? A video camera or a television broadcast? If it's interlaced video from a camera, there are no matching fields and you should bob to 60p (60000/1001 fps).

It's tv broadcast. I'm using tritical's tfm and decimate as follows:

tfm(mode=4).tdecimate(mode=1,hybrid=1,hint=true,nt=1,concycle=1,dupthresh=2.5,vidthresh=3.5,vidDetect=3)

I've stuck with 23.976fps to stay as blue-ray compliant as possible for my standalone sony player. Going to 720p @ 59.94fps should still be compliant and work on my player without having to do the decimation.

[osgZach]

Dumb question time.. (sort of related to the couple of posts above I guess?)

Is this meant only to be applied to 24p Film content, or would this work with Hybrid sources as well? I'm really surprised there hasn't been a big hoopla about someone releasing such a program yet.. Sure would make archiving Anime better if we had a tool that could do this and just avoid the whole IVTC/VFR decimation process ;)

[sneaker_ger]

How would this help avoiding IVTC? You still have to start with your CFR TS streams/DVD/Blu-Ray.
And why would you want to avoid VFR with containers like Matroska around in favor of some pulldown?

[Ghitulescu]

I can't disclose this information.

Why ?

[osgZach]

How would this help avoiding IVTC? You still have to start with your CFR TS streams/DVD/Blu-Ray.
And why would you want to avoid VFR with containers like Matroska around in favor of some pulldown?


Well the idea being, if someone would figure out a way to reliably note the Telecine pattern(s) in an MPEG2 source, and produce an H264 stream appropriately ready to receive the flags for pulldown on the proper frames, then... no IVTC process needed.

I'm certainly able to, and do, perform all the needed processing on my DVD's when making playable backups, but it doesn't mean I wouldn't prefer something that is potentially less of a headache, if it were to come along.

It's just another way to do things, far as I'm concerned.

[sneaker_ger]

if someone would figure out a way to reliably note the Telecine pattern(s) in an MPEG2 source, [...] no IVTC process needed.

Figuring out the patterns is pretty much the whole work. I don't see how pulldown would make the process easier compared to creating an VFR Matroska file.

I guess you want to somehow copy some soft pulldown pattern from source to the final encode, but you'll rarely find sources with changing soft pulldown patterns. Or are they more common than I think?