[Cin] HDV files at archive.org

Terje J. Hanssen terjejhanssen at gmail.com
Sat Nov 12 16:30:09 CET 2022



Den 10.11.2022 20:20, skrev Andrew Randrianasulu:
>
>
> чт, 10 нояб. 2022 г., 18:02 Terje J. Hanssen <terjejhanssen at gmail.com>:
>
>
>
>     Den 10.11.2022 14:56, skrev Andrew Randrianasulu:
>>
>>
>>     чт, 10 нояб. 2022 г., 14:18 Terje J. Hanssen
>>     <terjejhanssen at gmail.com>:
>>
>>
>>
>>         Den 10.11.2022 01:09, skrev Andrew Randrianasulu:
>>>
>>>
>>>         чт, 10 нояб. 2022 г., 00:17 Terje J. Hanssen
>>>         <terjejhanssen at gmail.com>:
>>>
>>>
>>>
>>>             Den 08.11.2022 20:30, skrev Andrew Randrianasulu:
>>>>
>>>>
>>>>             вт, 8 нояб. 2022 г., 22:07 Andrew Randrianasulu
>>>>             <randrianasulu at gmail.com>:
>>>>
>>>>
>>>>
>>>>                 вт, 8 нояб. 2022 г., 21:57 Andrew Randrianasulu
>>>>                 <randrianasulu at gmail.com>:
>>>>
>>>>
>>>>
>>>>                     вт, 8 нояб. 2022 г., 21:50 Andrew Randrianasulu
>>>>                     <randrianasulu at gmail.com>:
>>>>
>>>>                         https://archive.org/details/jvc_hd7
>>>>
>>>>                         unfortunately they all seems to be 25 fps ...
>>>>
>>>>
>>>>
>>>>                     also see
>>>>
>>>>                     https://archive.org/details/hdv01
>>>>
>>>>                     click on details look for mpeg2 files
>>>>
>>>>
>>>>
>>>>                 oh, look 29.97!
>>>>
>>>>                 https://archive.org/details/pioneerpower10
>>>>
>>>>
>>>>                 11 gb in full but we hopefully need only part of it
>>>>                 for testing ....
>>>>
>>>>
>>>>
>>>>
>>>>             also this
>>>>
>>>>             https://archive.org/details/snowplow14
>>>>
>>>>             like https://archive.org/download/snowplow14/B01C013.mpg
>>>>
>>>>             they also 29.97
>>>>
>>>>             thing is, while bdwrite does not choke on those -
>>>>             resulting  udfs displays errors if I not transcode
>>>>             audio first ... (
>>>>
>>>>
>>>
>>>             Just to mentione that I downloaded the latter file,
>>>             B01C013.mpg
>>>
>>>             and checked its video format with
>>>
>>>             mediainfo reported
>>>              FileExtension_Invalid                    : ts m2t m2s
>>>             m4t m4s tmf ts tp trp ty
>>>
>>>
>>>
>>>         yeah, extension IS wrong
>>>
>>>
>>>
>>>             ffmpeg -v error -i B01C013.mpg -f null - 2>error.log
>>>             and
>>>             cat error.log
>>>             [mpeg2video @ 0x55989aae8500] Invalid frame dimensions 0x0.
>>>                 Last message repeated 12 times
>>>             [mpeg2video @ 0x55989ad2c980] 00 motion_type at 11 13
>>>             [mpeg2video @ 0x55989ad2c980] Warning MVs not available
>>>
>>>
>>>         I think those are there because file was force-cut by byte
>>>         boundary, not by frame/content boundary?
>>>
>>>         you can try some other files if you have bandwidth to burn :)
>>>
>>>
>>>
>>>             I don't know if the above imply anything, but the small
>>>             "3.m2t" file had none such error messages ......?
>>>
>>>
>>
>>         About the same errors for  another FX1_01.mpg
>>         FileExtension_Invalid
>>         [mpeg2video @ 0x5598692b9500] Invalid frame dimensions 0x0.
>>             Last message repeated 2 times
>>         [mpeg2video @ 0x55986953ccc0] invalid cbp -1 at 74 53
>>         [mpeg2video @ 0x55986953ccc0] Warning MVs not available
>>
>>         The first I would expect the first is due to change from M2T
>>         transport stream to internet MPG program stream(?)
>>
>>
>>
>>     well, I hoped internet archive uploader will not change files
>>     just because, but who knows, may be it changed more than
>>     extension ....
>
>     On of previous discussion of some interest
>     https://www.dvinfo.net/forum/general-hd-720-1080-acquisition/96546-difference-between-m2t-mpg.html
>
>>
>>         By the way, when I'm home again I have my own true HDV
>>         1080i.m2t from FX7E to test on, beside the downloaded 2008xxx.m2t
>>
>>         And next month CinGG app release will include the interlace
>>         patched bdwrite, right?
>>
>>
>>
>>     I am not sure my idea is good, considering I do not know how to
>>     detect those pulldown flags ... If your camera has this 'film'
>>     mode it will be interesting to get sample ....
>>
>>
>>
>
>     No, my HDR-FX7E uses consumer standard 1080i at 50i (25 fps) or
>     HDV2 (Sony/Canon). The other type was 720p or HDV1 (JVC)
>     The first HDV 1080i camcorder to implement recording progressive
>     video within an interlaced stream,was the Sony HVR-V1
>     https://en.wikipedia.org/wiki/HDV#HDV_1080i
>
>     I certainly do not understand the problem regarding bdwrite. If
>     automatic detection of interlaced video cannot be recognized i.e
>     via ffmpeg, possibly the user can tell it the same way NLE's
>     pre-requisit.
>
>
> well, I'll try to add manual switches to bdwrite then.
> Plain interlace probably not a problem, but this weird patterned 
> framerate conversion might be ...
>
>
>     I.e from a previous Premiere Pro tutorial:   When working in
>     Premiere Pro, we highly recommend that you use the sequence
>     settings that match the settings of the footage you are working
>     with.
>     https://www.agitraining.com/adobe/premiere-pro/tutorials/understanding-digital-video-in-premiere-pro
>
>     And also noticed from Wikipedia (not only in the CinGG manual):
>     For consumer use, HDV-sourced video can be delivered on a Blu-ray
>     Disc without re-encoding, can be converted to AVCHD and delivered
>     on an AVCHD disc, or can be downconverted to DVD-Video.
>     https://en.wikipedia.org/wiki/HDV#Distributing
>


"Finally home again", just to discover that I have not 'bdwrite' 
available on my workstations upgraded with the latest 31. Oct 2022 CinGG 
appimages.
Therefore I wonder if CinGG Appimage not provide and make it possible to 
run bdwrite from command line (similar like no ffmpeg) without a single 
user build?

If this is the case, the recent testing I have done with bdwrite on my 
ultrabook, has unhappily been with a 2 year old and possibly outdated 
version from the last Cin 5.1 Package version dated October 31, 2020 for 
openSUSE. In lack of other ways to verify or querry bdwrite's version:

# which bdwrite
/usr/bin/bdwrite

# stat /usr/bin/bdwrite
   File: /usr/bin/bdwrite
   Size: 41934488      Blocks: 81904      IO Block: 4096   regular file
Device: 10305h/66309d    Inode: 3703700     Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/ root)
Access: 2022-11-12 13:46:45.544144893 +0100
Modify: 2020-10-31 17:50:23.000000000 +0100
Change: 2021-03-13 17:44:43.179917682 +0100
  Birth: 2021-03-13 17:44:42.011917748 +0100














-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20221112/278679a0/attachment-0001.htm>


More information about the Cin mailing list