Premiere Frameserves SD in Rec 709?

[koberulz]

I had that issue with a different frame server, but not this one. In any event, this is for both AFS and...are physical files a thing? But yeah, those. It's been taking a minute or two to load anything into AME, and today it just decided 'screw it, not working at all'. Again, all started after those 709 Ut files.

In today's progress, I burned two coasters because I left a layer on accidentally and the mask turned out to be slightly wrong.

[poisondeathray]

When I say "physical files" I mean large files on HDD, not frameserving. IMO neither frameserver is reliable since CS4/5 . Not worth the problems it causes . You're going to find other issues pop up later too. Might be ok for short tests, but it even fails on that half the time. Way too buggy. If you had it working semi-reliably , consider yourself in the minority

[koberulz]

I knew what you meant, it's just an odd term.

I've had no issues with frameserving outside of the 601/709 thing. Everything seems to be these Ut 709 files; it's just completely murdered two hard drives and the entire Creative Suite.

And now I'm stuck having to remember to turn a layer off because I can't access that project because I'm frameserving straight out of PP for a 14-hour HD2SD encode instead of being able to go through AME. On an encode I shouldn't have to do anyway because I've ALREADY DONE IT dammit.

I'm also curious as to what my monitor is made out of. I tried a post-it note as a reminder about that layer and it just fell off. My MediaLight keeps falling off. I tried electrical tape and it wouldn't even stick at all, it was like there was no adhesive whatsoever. Must be some sort of Teflon or something.

And why can't I burn a DVD ISO to a Blu-Ray and have it play as a DVD? I keep throwing DVD-9 discs in the bin instead of just re-burning a BD-RE.

Speaking of the bin, the ffmpeg commands relating to that mov file worked fine using the environment variable, but I still can't run the command for the MJPEGs without having everything in the bin folder.

[jagabo]

Nobody seems to care, but here's a slight update to my earlier UYVYtoYUY2 script. I added some error detection and the returned video retains the source parity (TFF or BFF).

#############################################################################
#
# Converts UYVY to YUY2.  AviSynth doesn't support UYVY.  But UYVY is the
# same as YUY2 -- but each pair of bytes is swapped:
#
#   UYVY: UY VY
#   YUY2: YU YV
#
# AviSynth can be tricked into opening an uncompressed UYVY source with:
#
#   AviSource("UYVY.AVI", pixel_type="YUY2")
#
# then the UYVY video can be converted to YUY2 with this function:
#
#   UYVYtoYUY2()
#
# Note: that this function is reversible, so it can also be used to
# convert YUY2 to UYVY.  It works with interlaced video as well as
# progressive video.  It does not otherwise change the components.
# So full range YUV remains full range, rec.601 remains rec.601, etc.
#
#############################################################################

function UYVYtoYUY2(clip c)
{
  Assert(c.isYUY2(), "UYVYtoYUY2() requires YUY2 video.")
  Assert(c.isFrameBased, "UYVYtoYUY2() requires frame based video.")
  parity = c.GetParity()

  # build Y plane
  Y1 = c.UtoY().TurnRight()
  Y2 = c.VtoY().TurnRight()
  Interleave(Y1, Y2)
  AssumeFieldBased()
  AssumeTFF()
  Weave()
  Y = TurnLeft()

  # build U and V planes
  c.ConvertToY8()
  TurnRight()
  AssumeFrameBased()
  AssumeTFF()
  SeparateFields()
  U = SelectEven().TurnLeft().ConvertToYUY2()
  V = SelectOdd().TurnLeft().COnvertToYUY2()

  # interleave Y, U and V
  YtoUV(U, V, Y)

  # restore properties
  AssumeFrameBased()
  parity ? AssumeBFF() : AssumeTFF()
}

#############################################################################

Again, you use it by opening your uncompressed UYVY video as if it was YUY2, then call this function:

AviSource("UYVY.AVI", pixel_type="YUY2")
UYVYtoYUY2()

By the way, the transform is reversible. So the same script can convert YUY2 to UYVY.

[koberulz]

So I've done more MJPEG captures, and I've been trawling through this thread trying to reconstruct the batch file and make sure it's still doing the right thing, which has resulted in two discoveries:
1. My MJPEG caps are now accurate. Previously there was a batch file that left the orange reds, and one that fixed them. Now, the first batch file turns reds orange and the second one makes no observable difference. Me no understand.
2. The problem with the batch files crashing appears to be caused by the existence of a file called "ffmpeg.bat". Renaming it to "bat.bat" causes it to run just fine, but trying to run "bat.bat" in a folder that also contains "ffmpeg.bat" results in a crash. I assume it reads the "ffmpeg" command in the first line and tries to run the batch file, instead of ffmpeg itself.

[poisondeathray]

So I've done more MJPEG captures, and I've been trawling through this thread trying to reconstruct the batch file and make sure it's still doing the right thing, which has resulted in two discoveries:
1. My MJPEG caps are now accurate. Previously there was a batch file that left the orange reds, and one that fixed them. Now, the first batch file turns reds orange and the second one makes no observable difference. Me no understand.
2. The problem with the batch files crashing appears to be caused by the existence of a file called "ffmpeg.bat". Renaming it to "bat.bat" causes it to run just fine, but trying to run "bat.bat" in a folder that also contains "ffmpeg.bat" results in a crash. I assume it reads the "ffmpeg" command in the first line and tries to run the batch file, instead of ffmpeg itself.

Is there a question buried somewhere in there ?

You can list the full paths to a specific ffmpeg.exe version in the batch file

Do you even need to use that convoluted workflow anymore ? Have you heard of voukoder ? CS6 is supported too. You can export directly with x264,x265, prores etc... it's basically a ffmpeg/libav export plugin for premiere

https://github.com/Vouk/voukoder
https://www.voukoder.org/forum/

[koberulz]

No question, just observations that are thread-relevant and might be of interest.

If the MJPEGs are correct then no, there's no need for anything. The actual plan is to sort out hardware that can bypass the need to capture in MJPEG in the first place.

Never heard of voukoder, but my issue was colour shifts going in to Premiere so from your description I'm not sure it'd help. Nonetheless, I'll have a look at it.

[poisondeathray]

Was it just a 601/709 ? I don't remember the details and it's a long thread. I think one of the questions was how to force PP to interpret something in a certain way

Another workaround would be to use a 601<=>709 LUT . For CC there is a direct way to apply a LUT with lumitri color , but in CS6 there used to be a free 3rd plugin called LUT Buddy . This would be similar to using colormatrix in avisynth to swap between 601 <=> 709 . But LUTS are applied in RGB , whereas colormatrix in avisynth works in YUV . But if you have AFS in your workflow , it gets converted to RGB there anyway.

[koberulz]

The final solution was this:

for %%a in ("*.avi") do ffmpeg -i "%%a" -vf scale=in_range=full:out_range=tv:in_color_matrix=bt601:out_color_matrix=bt709,lutyuv="u=val+1:v=val+1" -c:v libx264 -pix_fmt yuv422p -x264opts tff=1:keyint=1:colorprim=bt709:transfer=bt709:colormatrix=bt709:force-cfr -crf 2 -an "%%~na.mp4"
pause

Which also had the side effect of fixing the issue where the fields were the wrong way around.

The result of that script, though, now matches the initial MJPEG almost exactly (there are small changes if you zoom in enough, but only a couple of pixels here or there).

I'm using a new capture machine, perhaps it handles MJPEG differently. No idea. But hopefully in the next day or two I'll have a drive that will allow lossless capture, and I can bin the entire process. I just felt it was worth updating for anyone who was interested. That may well be zero people, but meh. More information is never a bad thing, and you never know which Google search this might turn up in at some point in the future.