Liquid - Tech Support (Installation - Import - Export - Hardware)

Re: Re:why is export MPEG2/HDV causing re-encode

Draske — Tue, 07 Jul 2009 12:19:53 GMT

I think that your player has problems with a variable GOP size. Liquid supports a variable GOP size which allows a native editing of HDV MPEG-2 files in the timeline. Basically what happens if you make a cut in the middle of a GOP Liquid will make two small GOPS on both sides if the cut and leave the rest of the MPEG-2 stream in tact. If it would not do this it would need to reencode the entire sequence every time you make a cut, only allow you to make cuts between two GOP's or reencode the entire sequence in another format then MPEG.

If you fuse the sequence probable keeps the variable GOP size (I'm waiting for a confirmation on this, but it would make sense). It might be that your player can not handle this and this is why you see the color artifacts on cuts.

Re: Re:why is export MPEG2/HDV causing re-encode

BenoitM — Mon, 06 Jul 2009 08:28:37 GMT

ok, makes sense

this means: it was indeed not such a smart idea to save my "master archives" using export/MPEG2/HDV2, instead of fusing...
It does not help me much figuring out who carries the bug (".. when I export an HDV2 project using export/MPEG2/HDV2, the WD TV HD media player shows unexpected sudden color changes near cuts (presumably at the new GOP boundaries)... "): Pinnacle or WDC ? ; AL is a product that is not longer actively supported and WDC just says "we don't support MP@HL14" . But that's part of life in the digital world....

Re: Re:why is export MPEG2/HDV causing re-encode

Smetvid — Fri, 03 Jul 2009 13:20:52 GMT

Fuse is the way to go. Export was never designed to be smart. It cannot figure out if something should just copy the frames or encode. If it did then we wouldn't really need fuse. Export takes the timelines frames and encodes them to the format you choose. It doesn't care if the slices or grey, green, yellow or red.

Fuse is a little bit smarter at exporting because it will choose what frames can be directly copied. This is why we have a fuse process. There is no bug with export, that is the way it is supposed to work.

If you need a program stream there are oodles of open source muxers out there that can mux the fused video and audio stream into a program stream or transport stream. Tsmuxr is an excellent one for transport streams and Blu-ray authoring. Muxing is very fast and doesn't change the quality at all. It just sort of "fuses" the two streams together. It would have been nice is Liquid fusing could have done so to a program stream like it can for a MXF file but it isn't that big of a deal.

Re:why is export MPEG2/HDV causing re-encode

BenoitM — Fri, 03 Jul 2009 12:26:26 GMT

did some further research: looks to me that the MPEG2 export is really the culprit; I remember from the AL 7.0/7.1 times that MPEG2 export was buggy, but apparently 7.2 did not solve all problems..

first of all, when you select export/MPEG2/HDV2, you get a file tagged as VBR, with "nominal bitrate" = 35 Mbps (even if the actual bitrate is 25 Mbps): this also matches the settings of the preset...strange because HDV2 is normally CBR 25 Mbps ???.....

Also, when I export an HDV2 project using export/MPEG2/HDV2, the WD TV HD media player shows unexpected sudden color changes near cuts (presumably at the new GOP boundaries) (see my other post here), while software MPEG decoders don't have this problem (BTW, of course the support engineers at WD tell me that HDV2 i.e. MP@HL14 is not supported by their device - which is not true b/c it plays HDV fine....except for this color cast change near GOP boundaries of files edited with AL (and only those....)).
....but I strongly suspect the MPEG2 exporter of AL....

So I realize that it was a bad idea to archive all my finalized HDV projects as .mpg files (exported MPEG2/HDV), hoping to combine highest quality (initial rushes only re-encoded at cuts, transitions & FX) with ease of use (single file, playable by media player boxes) and occasional future editability:

for playability: obviously I was out of luck the day I bought the WD TV player, because of the color bug mentioned above (I must be the only person on earth using this player with AL produced files..)
for lossless editability: I incurred already one unnecessary re-encode during export to MPEG2/HDV (should have fused instead) and now if I re-open any of those .mpg files, no matter which workflow I use (import, then export or fuse) I will have re-encoding again

Moral: for simple lossless HDV cut editing , a tool like Womble MPEG Video Wizard remains my best friend (or stay with Fuse and the burden of separate uncompressed audio files)

Re: why is export MPEG2/HDV causing re-encode

Draske — Fri, 03 Jul 2009 12:08:49 GMT

There is a different in approach when fusing or exporting.

When you export, Liquid will always reconstructure a file from scratch. Which means it will calculate and checks every single frame.

When you fuse, liquid copies groups of frames together. It will only calculate the parts that are missing (for example if you have an effect applied). So fusing is always faster and will always give the best result. Of course you are stuck to the original, native Liquid format of the file. So in this case M2V.

When you export to DVD and the file is already a DVD compatible MPEG-2, Liquid will basically fuse the sequence. Unless you have the option “Re-encode -> always the whole movie” ticked.

why is export MPEG2/HDV causing re-encode

BenoitM — Fri, 03 Jul 2009 08:48:23 GMT

I'd like to come back on this topic....because it is still a mystery for me why AL insists on full re-encoding "legal" HDV2 files, even those produced by...AL

scenario:

create a short HDV2 sequence, using HDV video clips
export as MPEG2/HDV2 1080i
import the resulting clip
export again: AL fully re-encodes the whole stuff (or most of it) (how do I know ? several hints: both CPU cores are maxed out at 100%; the preview window in the export dialog clearly shows AL processing images in "packets", waiting 1 or 2 seconds at GOP boundary; the export time is about twice the length of the clip; after export, the output files does not have the exact same size as the imported file; after a few import/export cycles, there is visible/severe generation loss)

If you use fuse instead of export at steps 2 & 4, there is no problem, export occurs at I/O speed limit and the CPU is barely touched

Why is there a MPEG2 video stream difference between fusing a HDV2 sequence, and exporting as MPEG2/HDV2; in my mind only the container and muxing should be different....?
What's the best method to export a finished HDV2 sequence without this unnecessary re-encoding; obviously, exporting as MPEG2/HDV is not the answer, despite the fact that it creates a nice .mpg file that can be easily archived and played back by most media centers; perhaps fuse, then re-encode audio and mux using a third-party program...?
I can't understand why AL "smart rendering engine" is not capable of detecting it's own children and avoid re-encoding HDV2 PS files it has previously exported ???

Or am I overlooking something basic ?