[Craig Seeman]

You could confirm by using the free MediaInfo but my guess it’s an H.264 file
https://mediaarea.net/en/MediaInfo/Download

.mp4 commonly contains H.264 but it can contain other things including the older MPEG4 (pre H.264) or even MPEG2.

Looks like it was already unconverted to 1920×1080 in some fashion.
Given the high data rate of the source it should transcode to 1920×1080 ProRes though without too much visual impact.

[Craig Seeman]

I see what you mean by tearing.
What does the source file look like at the same point in Quicktime?
ProRes really should cause tearing but it might expose less obvious issues in the source file.

Also If your source is H.264 .mp4 at 1920×1080 and you say your editor can use that, why are you re-encoding the file to H.264 as one of your options. ProRes can be a useful alternative though for many editors.

Sorry but something about what your doing and the information you’re providing doesn’t make sense especially since you described your source as Standard Def.

Please open the source in Quicktime and use Show Movie Inspector and provide a screen shot.

[Craig Seeman]

It looks like you cut and paste and it didn’t quite work out.
Perhaps provide a screenshot from Quicktime.
Your describing this as “old” TV footage but the file specs seem to say 1920×1080 and possibly AVC (h.264).

It’s hard to know what you mean by tears and breaks up. You may want to provide a screenshot of that as well as what it looks like before encoding.

You should read the pinned post at the top of the forum and provide more complete information otherwise there may be lots of wrong assumptions.

[Craig Seeman]

[Andrew Kimery] “My 2 cents was that given the $299 price point there’s only so many bases you can expect Apple to cover (and it’s by design). If you need/want specialized tools then you can most likely find them from a third party and if you don’t then you aren’t being charged ‘extra’ for features you don’t need. “

Although there has been, at times, concern that Apple’s hooks may have severe limitations such as interface design (one example I’ve heard cited).

[Craig Seeman]

[Michael Phillips] “The discussion becomes interesting as well with Blackmagic – but I suspect it would be fine as well as “editing” is a growth market for them in addition to the color correction. And I don’t think EditShare is dependent on Lightworks for its other offerings that are mainly used with other NLEs and workflows. “

… and then when Blackmagic buys EditShare…

[Craig Seeman]

24MB, 30 seconds. That would be about 6400kbps.
It’s not clear what the playback device can handle but h.264 (ideally using x264), High Profile, CABAC Entropy and it could be OK even though I’d really want a higher bit rate (but that would make the file size larger). I’m not sure what would encode that frame size though.

[Craig Seeman]

[Welland Man] “are they all compatible”
??? Cameras have specific batter compatibilities.
The biggest for this camera is BPU90 I believe.
They are 14.4v batteries.

[Craig Seeman]

.mp4 is a container, not a codec. It may contain H.264 but with XDCCAM EX it contains MPEG2.

That’s a very broad question.
Generally the camera supports XAVC Intra which is I frame AVC based which may be around 100mbps depending on frame rate
XAVC-L which is a GOP based AVC codec which may be 50mbps or 35mbps
MPEG HD422 which is related to XDCAM HD which is MPEG2 50mbps CBR
MPEG HD420 which is related to XDCAM EX which is MPEG2 35mbps VBR
AVCHD which is AVC GOP based at consumer bit rate of 28mbps or 24mbps

But you can find more detail in the spec sheet. It’s not clear at all what info you need and why though.

[Craig Seeman]

[Prathamesh Sathaye] “I re-encoded using CBR+Filler mode, and the file is working properly at the client side.”

Hmm, So Digital Rapids CBR isn’t CBR enough. Good that apps like Bitrate Viewer can reveal that.

[Craig Seeman]

[Prathamesh Sathaye] ” have played the file on VLC,MPC,Elecard Mpeg player. It plays just fine.”
[Prathamesh Sathaye] “My Client provides Inflight Entertainment solutions, so he tests the video files on his hardware device.”

Which may mean your playback devices aren’t representative of his playback device. Perhaps VLC etc. is much more forgiving.

[Prathamesh Sathaye] “I have previously delivered video content to him with the same above specs and it worked fine.”
Which means
Something changed on your end such as software update
Something changed on the client’s end such as software or firmware update
The encoded file is bad.

Since you must explore the cause to fix the problem you’re options are:
1) Re-encode the file again to see if it’s an issue with the encode.
2) Test with another file to see if the issue is specific to your source file. Give him the test file since you’re testing isn’t indicative of his experience.

Each of the above will yield results that may inform you of the next step to take.
If both the re-encode and the new test file fail it would mean something on your end or his end may have changed whether software or firmware.

3) if you believe you’ve updated software you may want to regress to using the version used to encode the last file compatible with his playback device.

This would eliminate possible change on your end. You’d have to discuss with the client possible changes on his end or, otherwise, explore other options such as testing different software.

[Prathamesh Sathaye] “Digital Rapids is the only encoder we have at the lab.”

3) You can download trials of Episode, Squeeze (or request a trial of Vantage) to see if another encoder with the same settings will yield different results.

This is all assuming that you are certain you’ve made no changes in the settings of your encoder you’ve been using to deliver to him previously.