[Cin] HDV on a Blu-ray Disc Without Re-encoding

Mon Nov 23 18:24:47 CET 2020

Den 23.11.2020 05:46, skrev Andrew Randrianasulu:
> В сообщении от Monday 23 November 2020 07:07:45 Terje J. Hanssen написал(а):
>> Den 23.11.2020 03:40, skrev Andrew Randrianasulu:
>>> В сообщении от Monday 23 November 2020 05:15:35 Terje J. Hanssen написал(а):
>>>> bd_20201122.udfs blocks 26871
>>> mkudffs /dev/shm/bd_20201122.udfs  26871
>>> filename=/dev/shm/bd_20201122.udfs
>>> label=LinuxUDF
>>> uuid=5fbb20bec1715abc
>>> blocksize=512
>>> blocks=26871
>>> udfrev=2.01
>>> start=0, blocks=64, type=ERASE
>>> start=64, blocks=13, type=VRS
>>> start=77, blocks=19, type=ERASE
>>> start=96, blocks=16, type=MVDS
>>> start=112, blocks=16, type=ERASE
>>> start=128, blocks=16, type=LVID
>>> start=144, blocks=112, type=ERASE
>>> start=256, blocks=1, type=ANCHOR
>>> start=257, blocks=26352, type=PSPACE
>>> start=26609, blocks=5, type=ERASE
>>> start=26614, blocks=1, type=ANCHOR
>>> start=26615, blocks=73, type=ERASE
>>> start=26688, blocks=16, type=RVDS
>>> start=26704, blocks=166, type=ERASE
>>> start=26870, blocks=1, type=ANCHOR
>>>
>>> without 'blocks' word :}
>>>
>>> but I do not know if you should set media type also? (-m)
>> Yes, thanks - that works better:
>>
>> mkudffs /data/tmp/bd_20201122.udfs  26871
>>
>>      filename=/data/tmp/bd_20201122.udfs
>>      label=LinuxUDF
>>      uuid=5fbb27bd6a141f84
>>      blocksize=2048
>>      blocks=26871
>>      udfrev=201
>>      start=0, blocks=16, type=RESERVED
>>      start=16, blocks=3, type=VRS
>>      start=19, blocks=237, type=USPACE
>>      start=256, blocks=1, type=ANCHOR
>>      start=257, blocks=16, type=PVDS
>>      start=273, blocks=1, type=LVID
>>      start=274, blocks=26340, type=PSPACE
>>      start=26614, blocks=1, type=ANCHOR
>>      start=26615, blocks=239, type=USPACE
>>      start=26854, blocks=16, type=RVDS
>>      start=26870, blocks=1, type=ANCHOR
>>
>> mkdir /mntX
>>
>> mount -o loop /data/tmp/bd_20201122.udfs /mntX
>>
>> which bdwrite
>>
>>      /usr/bin/bdwrite
>>
>>
>> /usr/bin/bdwrite /mntX /data/video/Diverse/20081103140154.m2ts
>>
>> umount /mntX
>>
>> =============
>>
>> Search for created BD file or folder:
>>
>> find / -name "bd_2020*"
>>
>>      /data/tmp/bd_20201122.udfs
>>
>>
>> file /data/tmp/bd_20201122.udfs
>>
>>      /data/tmp/bd_20201122.udfs: data
>>
>> ==========
>>
>> Compare sizes of udfs older and the original m2ts file:
>>
>> du -h /data/tmp/bd_20201122.udfs
>>
>>      45M /data/tmp/bd_20201122.udfs
>>
>> du -h /data/video/Diverse/20081103140154.m2ts
>>
>>      45M /data/video/Diverse/20081103140154.m2ts
>>
>> ============
>>
>> But I had expected a BD_folder with tree structure and empty udfs like
>> this sample from previous rendering;
>>
>> tree -h /data/video/bd_20161216-153642
>>
>>      /data/video/bd_20161216-153642
>>      ├── [183M]  bd.m2ts
>>      ├── [ 394]  bd.sh
>>      ├── [191M]  bd.udfs
>>      ├── [5.3K]  bd.xml
>>      └── [4.0K]  udfs
>>
>>      1 directory, 4 files
>>
>>
>> Possibly some additional steps to write it to harddisk (before BD burning)?
> I think structure created in file (udfs) so you can burn it already.
> (but you can attempt to mount -oloop it on some directory and see how it looks inside)
>
> What you have in bd_20161216-153642 just result of script doing all those steps you just did manually ...
>
>
Ok, I try to follow the procedure explained in GG's reply to an early 
related post
https://lists.cinelerra-cv.org/pipermail/cinelerra/2016q2/004844.html
https://lists.cinelerra-cv.org/pipermail/cinelerra/2016q2/004878.html

cd /data/tmp/bd_20201122.udfs

mkdir /data/tmp/udfs

mount -o loop ./bd_20201122.udfs ./udfs

cd /data/tmp/udfs

tree -h
.
├── [ 520]  BDMV
│   ├── [  40]  AUXDATA
│   ├── [ 332]  BACKUP
│   │   ├── [  40]  BDJO
│   │   ├── [  92]  CLIPINF
│   │   │   └── [ 480]  00000.clpi
│   │   ├── [  40]  JAR
│   │   ├── [ 110]  MovieObject.bdmv
│   │   ├── [  92]  PLAYLIST
│   │   │   └── [ 184]  00000.mpls
│   │   └── [ 124]  index.bdmv
│   ├── [  40]  BDJO
│   ├── [  92]  CLIPINF
│   │   └── [ 480]  00000.clpi
│   ├── [  40]  JAR
│   ├── [  40]  META
│   ├── [ 110]  MovieObject.bdmv
│   ├── [  92]  PLAYLIST
│   │   └── [ 184]  00000.mpls
│   ├── [  92]  STREAM
│   │   └── [ 44M]  00000.m2ts
│   └── [ 124]  index.bdmv
└── [ 272]  CERTIFICATE
     ├── [ 224]  BACKUP
     │   ├── [  40]  BDJO
     │   ├── [  40]  CLIPINF
     │   ├── [  40]  JAR
     │   └── [  40]  PLAYLIST
     ├── [  40]  BDJO
     ├── [  40]  CLIPINF
     ├── [  40]  JAR
     └── [  40]  PLAYLIST

23 directories, 9 files

=============

I don't understand why this BDMV tree structure is much larger than the 
simple 2016/2017 structures I got written to hdd as shown above. I 
thought the previous structures were some tests to hdd without the need 
to burn BD discs, but don't remember how they were created. As mentioned 
I also got successful BD video written to BD-R/RE disks at last.

=============

    ffplay -vf setdar=dar=16/9 -playlist 0 bluray:/data/tmp/udfs

....
[bluray @ 0x7fcc980016a0] 0 usable playlists:
bluray:/data/tmp/udfs: Input/output error
     nan    :  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0

That is ffplay did not replay the video here using that command to udf 
(ffplay is build with libbluray)

Both ffplay and VLC does playback pointing directly to the stream file

    ffplay /data/tmp/udfs/BDMV/STREAM/00000.m2ts
    vlc /data/tmp/udfs/BDMV/STREAM/00000.m2ts