--pulldown

[Sharc]

I want to convert a frame based 1080i / 25 fps / MBAFF source to 720p. Blu-ray compliance requests progressive@50fps. Does --pulldown double produce a blu-ray compliant stream@50fps from the original 25fps?
(What does --pulldown euro do?)

[kieranrk]

It should work.

Pulldown euro does 2:2:2:2:2:2:2:2:2:2:2:2:3 pulldown for converting 24fps sources to 25fps.

[Sharc]

Thanks!
Is there a description anywhere about the various --pulldown parameters? MeWiki explanations are very basic only ....

[Selur]

Here's what I wrote together for the tool tip I use in Hybrid:
Pulldown: Sets a pulldown flag for playback in the output stream.
(doesn't change the acctual framerate/framecount stored in container)
- 32: 3:2 pulldown e.g. 24->30fps
- 64: 6:4 pulldown e.g. 24->60fps
- double: double the frames e.g. 24->48fps
- triple: triples the frames e.g. 24->72fps
- euro: NTSC to PAL conversion 24->25 fps

Cu Selur

[Sharc]

Thanks for the hints on pulldown.
You pointed me to Hybrid. I have not been aware of your GUI before. Looks promising, I plan to try it at the next occasion.

[Sharc]

--pulldown double for converting frame-based 1080i@25fps -> 720p@50fps gives jerky playback on blu-ray standalone and VLC. Playback with MPC-HC or DGindexNV is smooth however.
Looks like frame duplication - e.g. bob() or changefps(50) - is the (only) way to go for 720p/50fps blu-ray compliance.
Is the pulldown issue playback device related, or is it just not blu-ray compliant?

[shroomM]

What about converting 23.976 fps to 25 fps? Can "euro" be used in that case (Bluray source)?

[Sharc]

Source is 1080i/25fps/MBAFF. I want to resize to 720p. For blu-ray this must be either 23.976, 24 or 50 fps.
So I already slowed down video, audio and sups to 23.976 which works perfectly (slight change in audio pitch - who cares)
I just experimented with --pulldown double as an alternative for 50 fps, but no success.

[Guest]

1080i/MBAFF is interlaced. You can't apply pulldown to interlaced material! It will make it jerky. It plays smooth in DGIndexNV because pulldown is not honored in the DGIndexNV display window.

[kieranrk]

What about converting 23.976 fps to 25 fps? Can "euro" be used in that case (Bluray source)?

No it cannot.

1080o/MBAFF is interlaced. You can't apply pulldown to interlaced material! It will make it jerky. It plays smooth in DGIndexNV because pulldown is not honored in the DGIndexNV display window.

I assume his source is 1080MBAFF with all frames being progressive.

[Guest]

He said 1080i and says pulldown makes it jerky. That appears to make your assumption doubtful.

@Sharc

Is it in fact interlaced or progressive *content*.

[Sharc]

He said 1080i and says pulldown makes it jerky. That appears to make your assumption doubtful.

@Sharc

Is it in fact interlaced or progressive *content*.

I would say it is encoded interlaced but with progressive content. When I separate fields and step through the fields, the sequence progresses like aa, bb, cc .... i.e. pairwise identical fields, no temporal movement, no combs or the like.
- MediaInfo reports the stream as AVC/25fps/MBAFF.
- DGIndexNV same, i.e. AVC/25fps/MBAFF.
- eac3to reports the video stream as h264/AVC, 1080i50.

[kieranrk]

- MediaInfo reports the stream as AVC/25fps/MBAFF.
- DGIndexNV same, i.e. AVC/25fps/MBAFF.
- eac3to reports the video stream as h264/AVC, 1080i50.

What all these programs report is irrelevant. What matters is the actual nature of your footage.

[Guest]

Since it is progressive based on your analysis, then what you call jerkiness is simply pulldown judder.

[SeeMoreDigital]

Can a combination of "frame repeat" and/or "field repeat" data be added to the AVC stream?

AVCHD-Lite (720p50) camcorder captures use a system of "frame repeat" signalling, which converts 25fps progressive frame captured sources into 50fps upon playback!

Cheers

[Sharc]

Since it is progressive based on your analysis, then what you call jerkiness is simply pulldown judder.
No, its much worse than normal pulldown judder: It looks like the frame sequence is getting messed up, with the movie stepping backwards/forward, similar when the field order is wrong in true interlaced material. In a way it looks to me as if pictures are pulled down not following the correct sequence.

(Why would --pulldown double create judder? It's just duplicating every frame, very regularly)

Another question: Would I have to deinterlace the progressive MBAFF source before encoding it with --pulldown double? I thought deinterlacing shouldn't be necessary for progressive content....

[kieranrk]

No, its much worse than normal pulldown judder: It looks like the frame sequence is getting messed up, with the movie stepping backwards/forward, similar when the field order is wrong in true interlaced material. In a way it looks to me as if pictures are pulled down not following the correct sequence.

Post a sample (preferably in raw .264)


Another question: Would I have to deinterlace the progressive MBAFF source before encoding it with --pulldown double? I thought deinterlacing shouldn't be necessary for progressive content....

There might be some interlaced sections (graphics etc.), you don't know.

[Sharc]

Post a sample (preferably in raw .264)
@neuron2
Is the [.....] F1 no longer supported for cutting a sample of the stream?

[Sharc]

Post a sample (preferably in raw .264)



There might be some interlaced sections (graphics etc.), you don't know.
I will make another test with deinterlacing the source - e.g. FieldDeinterlace() - before encoding with --pulldown double and see if the jerkiness disappears.

[Guest]

@neuron2
Is the [.....] F1 no longer supported for cutting a sample of the stream? Works fine for me.

DGIndexNV:

trim transport stream - F1

save project and demux video - no hotkey for that

[Sharc]

Works fine for me.

DGIndexNV:

trim transport stream - F1

save project and demux video - no hotkey for that
Ah, it works on transport stream; I tried with raw .264, sorry.

Deinterlacing before encoding with --pulldown double didn't solve the problem. The playback is still jerky. I will upload a sample.

Here my sample:
http://www.mediafire.com/download.php?abawkj9q8fonojo

[kieranrk]

How are you feeding the source to x264?

This looks like a problem unrelated to pulldown.

[Sharc]

How are you feeding the source to x264?

This looks like a problem unrelated to pulldown.
Frameserving via avisynth script.
I tried with DirectshowSource and with DGMultiSource. It didn't make a difference. As mentioned before, I encoded the same source with slowdown to 23.976 and with ChangeFPS(50) for frame doubling, and both cases worked well. Problem comes only with the pulldown exercise.
Here the encoder settings:
--crf 19.5 --preset medium --level 4.1 --keyint 24 --min-keyint 1 --ipratio 1.2 --aud --vbv-bufsize 14500 --vbv-maxrate 17500 --slices 4 --me umh --b-adapt 2 --b-pyramid strict --open-gop bluray --subme 8 --ref 4 --bframes 3 --nal-hrd vbr --pic-struct --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --pulldown double --threads auto --thread-input --sar 1:1

[Sharc]

Still no luck with --pulldown double. All tests I did - with and without prior deinterlacing of the source (progressive content I believe) produced a jerky playback when applying --pulldown double.
Here a short clip of the source, if somone likes to try:
http://www.mediafire.com/download.php?wrf9y5l7mqlvdr6.

Bob() or ChangeFPS(50) or setting deinterlace=2 in DGSource all work, but produce about 50% bigger file size at same crf and longer encoding times due to frame duplication. I thought I could avoid this by applying pulldown. So far the only method not blowing up the filesize is to slowdown the 25fps source to 23.976 or 24fps (sort of opposite which was routinely done for film => PAL conversion for commercial DVDs).

[SeeMoreDigital]

Hi Sharc,

When you scan thru' that source, one frame at a time, it "looks"progressive to me...

[Sharc]

Hi Sharc,

When you scan thru' that source, one frame at a time, it "looks"progressive to me...
Yes, that's what I found as well. Content is progressive, scantype MBAFF, 25fps. (If it is progressive, pulldown should actually work.)
However, I want to resize the 1080 source to 720, blu-ray compliant. Unfortunately blu-ray does not accept 25fps at 720p resolution but only 23.976, 24 or 50fps - hell knows why. So I have to produce 50fps and I thought pulldown would be smart.....

[Guest]

Can you post a link to a sample of your --pulldown double encode? I can check if it is properly flagged, etc.

[Sharc]

Can you post a link to a sample of your --pulldown double encode? I can check if it is properly flagged, etc.
Here we go:
http://www.mediafire.com/download.php?abawkj9q8fonojo
I am just wondering if tsMuxer introduces something odd?

[SeeMoreDigital]

Your latest sample plays incorrectly in all my hardware players too!

By-the-way. As a cross-check, here's a short sample from an AVCHDlite camera. Which is Blu-ray compliant and works perfectly in my hardware players.

http://www.mediafire.com/?objspqn04gn55xq

Cheers

[Guest]

The file looks perfectly correct to me. It plays smooth with DGDecNV.

I suppose if it bombs in bluray players it is somehow not bluray compliant. Not my field of expertise. :)

[Sharc]

The file looks perfectly correct to me. It plays smooth with DGDecNV.

I suppose if it bombs in bluray players it is somehow not bluray compliant. Not my field of expertise. :)
Yes, it plays smooth with DGDecNV. It bombs with VLC media player however, not only with blu-ray players.

Btw., SeeMoreDigital's clip plays fine here, even when re-muxed with tsMuxer into BD structure.

Thanks guys for your feedback.:)

[SeeMoreDigital]

I must admit it would be kinda cool to have an application for use with elementary AVC streams that offers "some" of the comparative functionality of ReStream (for elementary MPEG-2 streams).

Cheers

[Sharc]

Exploring SMD's stream I found that it has no b-frames.
I set --bframes 0 for my encode and - believe it or not - playback in VLC is now smooth!
So there seems to be an issue with the b-frames when using pulldown. No idea if this conclusion is valid.:rolleyes:

Here the stream without b-frames:
http://www.mediafire.com/download.php?ywv6uwwdohd66du

[kieranrk]

I am just wondering if tsMuxer introduces something odd?

Yes, tsMuxer does a lot of weird things to the stream. I'm not at a PC to prove that's the case but I'd wager that's the problem.

[SeeMoreDigital]

Exploring SMD's stream I found that it has no b-frames.
I set --bframes 0 for my encode and - believe it or not - playback in VLC is now smooth!
So there seems to be an issue with the b-frames when using pulldown. No idea if this conclusion is valid.:rolleyes:Well here's another AVCHD Lite sample for you to try: -

http://www.mediafire.com/?obol4dk6z4ztvog


Cheers

[Sharc]

Exploring SMD's stream I found that it has no b-frames.
I set --bframes 0 for my encode and - believe it or not - playback in VLC is now smooth!
So there seems to be an issue with the b-frames when using pulldown. No idea if this conclusion is valid.:rolleyes:

Here the stream without b-frames:
http://www.mediafire.com/download.php?ywv6uwwdohd66du

Hmmm...., my interpretation of what might be happening:
- with b-frames: display order of the frames is not the same as the stream order. Looks like when using --pulldown double the stream is displayed sequentially according to the stream order => jerkyness. (I don't know where the control for the correct display order gets lost).
- without b-frames: display order = stream order. This prevents jerkyness a priori.

Just guessing .....

[Guest]

That sounds very plausible. Whoever wrote the display code may have failed to reorder the pic timing SEIs along with the pictures, i.e., they apply the flags in the received coding order, forgetting that they have to be reordered.

I made this same mistake in my first implementation of honoring pulldown for AVC. Since it is correct now, that explains why it plays smooth in DGDecNV.

[SeeMoreDigital]

This is all very weird....

When I mux your last 50fps sample into the MP4 container using MP4muxer set to 50fps, the playback speed in my hardware player is twice as fast as it should be. And my players GUI reports the .MP4 file as being 50fps.

And MediaInfo reports this: -General
Complete name : D:\Users\SeeMoreDigital\Desktop\02 pd_1_no_b-frames 50fps.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 18.6 MiB
Duration : 12s 20ms
Overall bit rate : 13.0 Mbps
Encoded date : UTC 2010-07-22 20:23:36
Tagged date : UTC 2010-07-22 20:23:36
Writing application : mp4creator 1.6.1d

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Frame mode : Frame doubling
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 12s 20ms
Bit rate mode : Variable
Bit rate : 13.0 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 50.000 fps
Original frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.281
Stream size : 18.6 MiB (100%)
Language : English
Encoded date : UTC 2010-07-22 20:23:36
Tagged date : UTC 2010-07-22 20:23:36
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177


However, when I mux the same 50fps sample into the MP4 container using MP4muxer set to 25fps, the playback speed in my hardware player is perfect. And my players GUI reports the .MP4 file as being 50fps.

And MediaInfo reports this: -
General
Complete name : D:\Users\SeeMoreDigital\Desktop\02 pd_1_no_b-frames 25fps.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 18.6 MiB
Duration : 24s 40ms
Overall bit rate : 6 484 Kbps
Encoded date : UTC 2010-07-22 20:06:04
Tagged date : UTC 2010-07-22 20:06:05
Writing application : mp4creator 1.6.1d

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Frame mode : Frame doubling
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 24s 40ms
Bit rate mode : Variable
Bit rate : 6 483 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.281
Stream size : 18.6 MiB (100%)
Language : English
Encoded date : UTC 2010-07-22 20:06:04
Tagged date : UTC 2010-07-22 20:06:05
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

So the "frame doubling" data is present in both MP4 files. And both files display the same 50fps playback speed in my hardware player.

[Sharc]

I would assume that setting the container to 25fps is probably correct as the 50 fps are produced by the pulldown process during playback.
Did you try muxing with tsMuxer? I guess it would be much the same.

What happens if you don't set the fps for the container? Does MP4muxer then take the value from the stream? (I am not familiar with MP4 muxer).

Anyway, another source of confusion :devil:

[SeeMoreDigital]

As far as I'm aware, current MP4 muxing applications (such as YAMB and MP4muxer), are not able to set FPS speeds at the container level. It's all at the stream level.

And when I generated some .M2TS muxes using TSmuxer GUI and my hardware player plays the 50fps mux at 50fps and the 25fps mux at 25fps.

And MediaInfo reports this for the 50fps mux: -General
ID : 1
Complete name : K:\03 Test Files\00 Sharc\02 pd_1_no_b-frames 50fps.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 19.5 MiB
Duration : 24s 0ms
Overall bit rate : 6 821 Kbps
Maximum Overall bit rate : 35.5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Frame mode : Frame doubling
Duration : 24s 0ms
Bit rate mode : Variable
Bit rate : 6 544 Kbps
Maximum bit rate : 17.5 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.284
Stream size : 18.7 MiB (96%)
Writing library : x264 core 104 r1677 19df41a
Encoding settings : cabac=1 / ref=4 / etc, etc
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

And this for the 25fps mux. Note the 12.5fps frame rate: -General
ID : 1
Complete name : K:\03 Test Files\00 Sharc\02 pd_1_no_b-frames 25fps.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 19.6 MiB
Duration : 48s 0ms
Overall bit rate : 3 422 Kbps
Maximum Overall bit rate : 35.5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Frame mode : Frame doubling
Duration : 48s 0ms
Bit rate mode : Variable
Bit rate : 3 279 Kbps
Maximum bit rate : 17.5 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 12.500 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.285
Stream size : 18.8 MiB (96%)
Writing library : x264 core 104 r1677 19df41a
Encoding settings : cabac=1 / ref=4 / etc, etc
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177


Cheers

[Sharc]

That sounds very plausible. Whoever wrote the display code may have failed to reorder the pic timing SEIs along with the pictures, i.e., they apply the flags in the received coding order, forgetting that they have to be reordered.

I made this same mistake in my first implementation of honoring pulldown for AVC. Since it is correct now, that explains why it plays smooth in DGDecNV.
Interestingly the display order is correct with MPC-HC, but fails with VLC and with my standalone. Is it eventually a problem of the playback device/software which in case of --pulldown with b-frames does not correctly interpret the pic timing (?)

[Sharc]

As far as I'm aware, current MP4 muxing applications (such as YAMB and MP4muxer), are not able to set FPS speeds at the container level. It's all at the stream level.

And when I generated some .M2TS muxes using TSmuxer GUI and my hardware player plays the 50fps mux at 50fps and the 25fps mux at 25fps.

And MediaInfo reports this for the 50fps mux: -General
ID : 1
Complete name : K:\03 Test Files\00 Sharc\02 pd_1_no_b-frames 50fps.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 19.5 MiB
Duration : 24s 0ms
Overall bit rate : 6 821 Kbps
Maximum Overall bit rate : 35.5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Frame mode : Frame doubling
Duration : 24s 0ms
Bit rate mode : Variable
Bit rate : 6 544 Kbps
Maximum bit rate : 17.5 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.284
Stream size : 18.7 MiB (96%)
Writing library : x264 core 104 r1677 19df41a
Encoding settings : cabac=1 / ref=4 / etc, etc
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

And this for the 25fps mux. Note the 12.5fps frame rate: -General
ID : 1
Complete name : K:\03 Test Files\00 Sharc\02 pd_1_no_b-frames 25fps.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 19.6 MiB
Duration : 48s 0ms
Overall bit rate : 3 422 Kbps
Maximum Overall bit rate : 35.5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Frame mode : Frame doubling
Duration : 48s 0ms
Bit rate mode : Variable
Bit rate : 3 279 Kbps
Maximum bit rate : 17.5 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 12.500 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.285
Stream size : 18.8 MiB (96%)
Writing library : x264 core 104 r1677 19df41a
Encoding settings : cabac=1 / ref=4 / etc, etc
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177


Cheers
I noticed this as well with tsMuxer GUI.
It muxes correctly when you just delete the fps=xx in the .meta. Then tsMuxer takes the fps from the raw .264 stream (50fps in my case), DGindexNV reports it as 50fps, and MediaInfo as 25fps .... don't ask me why.