60i to 30p without re-encoding?

[budwzr]

At the time, I thought "Lite" meant no 1080

I don't have the box anymore, but they DID state 720p60 on it, and of course at Amazon too. If there was an asterisk, I didn't see it.

Here's a snip from the manual, where they DO mention a 30fps sensor, but only someone that really knows these technicalities will realize what that means and how it negatively impacts the recording.

I don't think a camera maker can state 120fps and then deliver 4 repeating frames in a row and not cause an uproar in the industry. But somehow the other camera makers close one eye because they want to get away with their own slick stuff too.

[budwzr]

My Canon does the same thing, 30p in 60i.

But were the advertising specs misleading or unclear?

I feel like making a YT video about this now. Damn it! It's revolution time! If the hardware cannot do 60p then there should be NO MENTION of 60p!

I'm hopping mad. "fps" should refer to the capture rate, NOT the file format. Look at the chart above, and the settings are describing the QUALITY mode, and the fps column doesn't even belong in this chart. It's referring to differences in bitrate only. All the resolutions are the same too. They just threw that in there to help fuzz things up too.

In a comparison chart, attributes that are constant should not be included. That's like a car comparison chart having a "steering wheel?" column.

[poisondeathray]

Why not just load the footage (30p flagged as 60i) in to Vegas as a 60i project and render as a 30p file. My Canon does the same thing, 30p in 60i. It bugs me, progressive should be progressive. Interlace is a pain in the ass. I've been able to do as I mentioned, 60i project render as 30p (some h.264 container, AVC, MP4, ect.). Seems to work OK.

It's not ideal, because of chroma upsampling error (CUE)

Vegas upsamples to RGB as interlaced in these files, and the result is crappy looking color edges

You have 4 options: either interpret the footage as progressive or interlaced, project settings as either progressive or interlaced . None of them work properly in vegas for "30p in 60i" AVCHD footage . (Premiere has this problem too, as do most NLE's. You can do a search if you want more info, I've made several posts about this in the past)

A better way to do it is to use a digital intermediate, maybe with avisynth and ffdshow(libavcodec) which decodes properly then feed that into vegas or NLE of your choice. Cineform has a free version now since GoPro bought them out. Or you can use other options like DNxHD, or UT Video Codec, Huffyuv,etc...

Here is a 2x zoom in and crop from Canon HF 10 "30p" footage

Now my 24p in 60i footage is alltogether a different issue.

Yes, that is hard telecined, encoded as interlaced. There are no flags to strip. It's not "soft pulldown". The newer consumer camcorder models and DSLR's shoot native 24p now. And 24p native is supported by blu-ray and AVCHD

[poisondeathray]

My Canon does the same thing, 30p in 60i.

But were the advertising specs misleading or unclear?

I feel like making a YT video about this now. Damn it! It's revolution time! If the hardware cannot do 60p then there should be NO MENTION of 60p!

I'm hopping mad. "fps" should refer to the capture rate, NOT the file format. Look at the chart above, and the settings are describing the QUALITY mode, and the fps column doesn't even belong in this chart. It's referring to differences in bitrate only. All the resolutions are the same too. They just threw that in there to help fuzz things up too.

In a comparison chart, attributes that are constant should not be included. That's like a car comparison chart having a "steering wheel?" column.

Hahaha

Yes that's right the "fine print" says "sensor output is 30 fps"

Eitherway, the "AVCHD Lite" marketing department got you and many others I'm sure

[edDV]

I have a question. Is there ANY upside WHATSOEVER to having the frames split like this? AFA creating a 60p file?

Why would Panny do this then? If not as a cheat.

As said before, for interoperaility. That is the big picture.

Around 1980, computer nerds considered digital video to be a square pixel progressive RGB frame buffer.

Broadcast engineers knew this wouldn't work for limited bandwidth transmission so designed digital video as field sequence based, non-square pixel YPbPr/YCbCr. 13.5 MHz sampling was chosen to allow compatibility for 50/60Hz and legacy NTSC/PAL analog broadcast.

This formed the basis of all the digital video standards that followed. All are interoperable with legacy analog video and with each other.

CCIR-601/ITU Rec.601 (the basis for SD digital video)
SMPTE-259M (Serial Digital Video)
MPeg2
"Studio-RGB" (16-235)
DV/DVCPro
DVD
ATSC
DVB
h.264
VC-1
AVCHD
Blu-Ray

The square pixel RGB camp went on to develop JPEG and M-JPEG. These were adopted for first generation digital cameras. As mega-pixels grew to make HD video possible on digital cameras, it became clear M-JPEG wasn't going to offer sufficient compression to fit reasonable record times to flash media. Also, consumers wanted to play their HD videos on their HDTV sets. For these reasons, the h.264 codec was selected with MPeg2 TS or mp4 containers along with HDMI connections.

Meanwhile, the standards above were enhanced to accommodate progressive and RGB modes but within the field based infrastructure.

Not all digital camera manufacturers comply with AVCHD/Blu-Ray standards straying into non-compatible h.264 settings or containers.

[budwzr]

Not all digital camera manufacturers comply with AVCHD/Blu-Ray standards straying into non-compatible h.264 settings or containers.

Well, digital photos are not compatible with printing. Printers are Process Color. One is additive, the other subtractive. Photographers know they will have to convert to another color model to print their image.

It should be the same for NTSC users. If they want a tube tv format, then it should be on them to re-author for that.

[edDV]

Not all digital camera manufacturers comply with AVCHD/Blu-Ray standards straying into non-compatible h.264 settings or containers.

Well, digital photos are not compatible with printing. Printers are Process Color. One is additive, the other subtractive. Photographers know they will have to convert to another color model to print their image.

It should be the same for NTSC users. If they want a tube tv format, then it should be on them to re-author for that.

The digital camera manufactures know from their research that the customer wants:

Analog output for classic TV sets
Compatible HDMI output for HDTV sets
DVD downsize software
A path to AVCHD or Blu-Ray disc.
Maybe conversion for Youtube.

That leaves you as the odd man out.

[2Bdecided]

With MPEG-2, it's possible to just change the flag, and get a real native progressive file without re-encoding.

Here's a thread about it:
http://www.hv20.com/showthread.php?32552-HV30-30p-workflow-Vegas-smart-render

Here's the tool:
https://www.videohelp.com/tools/Restream

You can do that and fool a program into thinking the video is progressive. But the chroma channels will be messed up. When encoded interlaced the chroma channels are interlaced as well as the luma channel. If you change the interlace flag to say the video is progressive the decoder will handle the interlaced luma channels as if they are progressive, leading to more blurring of the colors.

Have you tried it Jagabo?

I haven't, because I never use 25p. But if you look at the chroma sampling for 25p vs 50i, treating 25p-in-50i as standard 25p wrt chroma sampling points is actually the right thing to do if they sampled it as 25p to start with (i.e. without the field-based chroma downsample to start with). If they did field-based chroma downsample at the start, then I've never figured out what's "best" - though TGMC seems to get the chroma pretty good in this case (yes, I know it's not really interlaced, but...!).

As for the interlaced quantisation of chroma, when the stream is re-flagged progressive: doesn't seem to be a problem, but I guess that's testament to how resilient some MPEG decoders are to errors in the stream.


This would be just the kind of thing I'd take great pleasure in figuring out the best solution for - if I ever shot 25p! Since I don't, I'm not bothered.

For the OP, if there's no flag-based hack that can solve it, then just sticking with what they have seems fine - avoiding re-encoding is usually a good thing if possible (unless there are specific problems to fix - and I'm not convinced this "problem" is big enough to matter).

Cheers,
David.

[jagabo]

With MPEG-2, it's possible to just change the flag, and get a real native progressive file without re-encoding.

Here's a thread about it:
http://www.hv20.com/showthread.php?32552-HV30-30p-workflow-Vegas-smart-render

Here's the tool:
https://www.videohelp.com/tools/Restream

You can do that and fool a program into thinking the video is progressive. But the chroma channels will be messed up. When encoded interlaced the chroma channels are interlaced as well as the luma channel. If you change the interlace flag to say the video is progressive the decoder will handle the interlaced luma channels as if they are progressive, leading to more blurring of the colors.

Have you tried it Jagabo?

Yes. It does what I said. Fortunately, the intricacies of YV12 to RGB (for display) decoding often means that the incorrect conversion looks better.